<?xml version="1.0" encoding="UTF-8"?>
	<!--

		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.
	-->
<chapter id="background" xmlns="http://docbook.org/ns/docbook"
	xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
        http://docbook.org/ns/docbook
        http://www.docbook.org/xml/5.0/xsd/docbook.xsd"
	version="5.0" xml:lang="en">

	<title>Background</title>

	<para>
		The Enterprise Service Bus (ESB) - which can be defined as
		middleware
		that brings together both integration technologies and
		runtime
		services to make business services widely available for reuse -
		offers
		the best solution for meeting today's enterprise application
		integration challenges by providing a software infrastructure that
		enables SOA. However, there are currently a number of different
		vendors that provide ESB solutions, some of which focus purely on
		SOAP/HTTP and others who provide multi-protocol capabilities. Because
		these vendors span the horizon from big enterprise generalists
		(application servers), to mid-tier enterprise integration providers,
		all
		the way to smaller, ESB/integration specific-providers; there
		doesn't
		seem to be an established consensus regarding the key
		requirements
		for an ESB.
    </para>

	<para>
		As application architects, we have often thought about what
		requirements
		would define an ESB designed specifically to cater to the
		needs
		of an agile, enterprise integration model. In building for the
		specific
		requirements, we realized that we actually needed to develop a
		new
		type of ESB, hence the Apache ServiceMix project.
    </para>

	<para>
		The main criteria we were looking for in our ESB are as follows:
	</para>
	<section>
		<title>Standards based</title>
		<para>
			While standards-based support is marketed by many ESB vendors,
			the support
			is provided externally, requiring developers to work with
			proprietary APIs when directly interacting with internal APIs.
			ServiceMix was
			designed with the requirement to eliminate product API
			lock-in, by being built from the ground up to support the Java
			Business
			Integration specification (JSR-208). Our agile ESB needs to
			use JBI as a first class citizen, but also support POJO deployment
			for
			ease of use and testing.
            </para>
	</section>
	<section>
		<title>Flexible</title>
		<para>
			Another characteristic of an agile ESB is the flexibility with
			which it can
			be deployed within enterprise application integration
			framework:
			standalone, embedded in an application component, or as
			part of the
			services supported by an application server. This allows
			for
			component
			re-use throughout the enterprise. For example, the
			binding for a real-time
			data feed might be aggregated as a web-service
			running within
			an application server, or streamed directly into a fat
			client on a
			traders desk. An agile ESB should be able to run both
			types of
			configurations
			seamlessly.
            </para>
		<para>
			To provide rapid prototyping, an agile ESB should support both
			scripting languages and embedded rule engines, allowing business
			processes to be
			modeled and deployed quickly.
            </para>
		<section>
			<title>Reliable</title>
			<para>
				Our ESB needs to handle network outages and system failures and
				to be
				able to reroute message flows and requests to circumvent
				failures.
			</para>
		</section>
		<section>
			<title>Breadth of Connectivity</title>
			<para>
				An agile ESB must support both two way reliable Web Services
				and
				Message Oriented Middleware and needs to co-operate seamlessly
				with
				EIS and
				custom components, such as batch files.
                </para>
		</section>
	</section>

	<para>
		We also wanted our agile ESB to be vendor independant and open source,
		to promote user control of source code and direction.
		An added benefit of this is not only the zero purchase cost, but the
		total cost of ownership will be reduced where users are
		actively contributing and maintaining our ESB.
	</para>
	<para>
		We rapidly came to the conclusion, that as there was no single product
		adequately meet our needs, we would have to just go
		a head and build one.
	</para>

</chapter>