Petals ESB (http://petals.ow2.org) is an Open Source ([LGPL License|http://www.gnu.org/licenses/lgpl.html]) Enterprise Service Bus (ESB) provided by the OW2 middleware consortium (http://www.ow2.org).

Petals ESB is build with and on top of agile technologies such as:
* The Java Business Integration (JBI) v1.0 specification (http://www.jcp.org/en/jsr/detail?id=208). This is the Java standard for enterprise application integration. Note that in 2008, Petals ESB has been certified by SUN Microsystems as a valid JBI implementation.
* The FRACTAL Software Component Framework provided by the OW2 consortium. Fractal is a modular and extensible component model that can be used with various programming languages to design, implement, deploy and reconfigure various systems and applications, from operating systems to middleware platforms and to graphical user interfaces. On the Petals ESB point of view, all the container services (such as service registry, message router, message transporter, discovery etc...) are provided by the Fractal framework. This is a major feature which allows core developers to specialize a Petals ESB distribution by choosing the software components to be used for specific needs.

Petals ESB is not only a JBI container, the project also contains tools for management, monitoring, frawework to create JBI components to hide the JBI complexity and a collection of Binding Components and Service Engines. All of this will be detailed in the next chapters.

h1. Java Business Integration

The following section introduces the high level concepts of the specification which will be used next in the Petals ESB related parts. For more advanced details, please refer to the specification.

The JBI specification has been standardized by the Java Community Process (JCP) expert group in the JSR208 document.

The specification defines a standard means for assembling integration components to create integration solutions that enable a SOA in an enterprise information system.

h2. Environment

Components are plugged into a JBI environment and can provide or consume services through it in a loosely coupled way. The JBI environment then routes the exchanges between those components and offers a set of technical services. JBI is built on top of state-of-the-art SOA standards : service definitions are described in WSDL format and components exchange XML messages in a document-oriented-model way.

!Environnement.jpg!

The central part of the JBI specification is the Normalized Message Router (NMR), described as the "JBI Environment" in figure above. The NMR ensures loosely coupled communication by providing standard Service Provider Interfaces (SPI) that promote the exchange of XML documents between plugged JBI components and loose references via the use of their interface name.

h2. JBI Artifacts

The JBI specification defines a set of artifacts which are used to add connectivity, bind/expose services and configure the Service Bus.

The main artefacts are the JBI components which are divided in two families :
* *Binding Components* (BC) are "connectors" which are used to interface the JBI bus with the rest of the Information System (Green boxes in figure above). Binding Components enable both the exposure of external resources in the bus and the exposure of services available on the bus for their use by external consumers: e.g. connections to Web services, FTP, Mail, Message-Oriented Middleware, or even standard business communications like EDI or ebXML.
* *Service Engines* (SE) provide the integration logic (Blue boxes in the figure above). They typically handle messages that pass through the bus in order to provide routing (e.g. content-based routing, priority-based routing), transformation (XSLT), orchestration (BPEL), log or audit features.

In order to activate endpoints in the JBI environment, artifacts named *Service Units* (SU) must be deployed on the JBI component (both BC and SE). The SU contains configuration file which are used by the JBI component consume or provide a JBI service. A SU has two modes:
* Consumer : The component on which the SU is deployed on will consume the service described in the SU configuration file.
* Provider : The component on which the SU is deployed on will provide the service described in the SU configuration file.

Service Units are packaged in artifacts named *Service Assembly* (SA). The SA can contain a collection of SU plus a configuration file which describe on which component each SU must be deployed.

The last artefact defined in the JBI specification is the *Shared Library* (SL). The SL is an artefact which can be shared between JBI components. The components will potentially use the Java libraries and resources bundled in the SL to create their class loaders.