content/asyncweb-project/index.mdtext - mina-site - Git at Google

 Title: AsyncWeb
 Notice:    Licensed to the Apache Software Foundation (ASF) under one
            or more contributor license agreements.  See the NOTICE file
            distributed with this work for additional information
            regarding copyright ownership.  The ASF licenses this file
            to you under the Apache License, Version 2.0 (the
            "License"); you may not use this file except in compliance
            with the License.  You may obtain a copy of the License at
            .
              http://www.apache.org/licenses/LICENSE-2.0
            .
            Unless required by applicable law or agreed to in writing,
            software distributed under the License is distributed on an
            "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
            KIND, either express or implied.  See the License for the
            specific language governing permissions and limitations
            under the License.


 # Apache AsyncWeb

 <DIV class="note" markdown="1" >
 The **AsyncWeb** project is currently dormant. We don't have committers for it, so if you feel like you can give an hand, please do contact us !
 </DIV>

 Apache AsyncWeb (built on top of the Apache MINA network framework) employs non-blocking selector driven IO at the transport level, and is asynchronous thoughout - from the initial parsing of requests, right through to and including the services implemented by users.

 Apache AsyncWeb breaks away from the blocking request / response architecture found in todays popular HTTP engines. This allows it to be highly scalable and capable of supporting very high throughput - even in high processing latency scenarios.

 A simple API allows new asynchronous services to be created easily - and out-of-the-box Spring integration allows them to be configured simply and with great flexibility. In addition to "endpoint" HTTP services, AsyncWeb also allows configurable "chains" of behaviour - enabling "filter" like behaviour to be applied to all requests. Pluggable "resolvers" map incoming requests to their target HTTP service - and are given access to the entire incoming request - allowing the routing possibilities to be very flexible.
	Title: AsyncWeb
	Notice: Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at
	.
	http://www.apache.org/licenses/LICENSE-2.0
	.
	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.


	# Apache AsyncWeb

	<DIV class="note" markdown="1" >
	The AsyncWeb project is currently dormant. We don't have committers for it, so if you feel like you can give an hand, please do contact us !
	</DIV>

	Apache AsyncWeb (built on top of the Apache MINA network framework) employs non-blocking selector driven IO at the transport level, and is asynchronous thoughout - from the initial parsing of requests, right through to and including the services implemented by users.

	Apache AsyncWeb breaks away from the blocking request / response architecture found in todays popular HTTP engines. This allows it to be highly scalable and capable of supporting very high throughput - even in high processing latency scenarios.

	A simple API allows new asynchronous services to be created easily - and out-of-the-box Spring integration allows them to be configured simply and with great flexibility. In addition to "endpoint" HTTP services, AsyncWeb also allows configurable "chains" of behaviour - enabling "filter" like behaviour to be applied to all requests. Pluggable "resolvers" map incoming requests to their target HTTP service - and are given access to the entire incoming request - allowing the routing possibilities to be very flexible.