{section}
{column}
h1. What is Petals ESB ?

[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.
{column}
{column:width=350px}
{panel}{toc}{panel}
{column}
{section}

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|height=345,width=600!

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.

In this document, a JBI artefact will refer to the previously detailed items. More details on Binding Components, Service Engines, Service Units, Service Assemblies, Shared Libraries, their lifecycles and usage are described in the JBI specification.

h2. Messages

The atomic JBI message, also called Normalized Message, is composed of a XML payload, attachments (binary data) and key-value properties (also view as message context). A JBI message transits between service consumer and provider in a Message Exchange. A Message Exchange contains an input Normalized Message, a set of key-value properties and potentially:
* An output Normalized Message representing the service invocation response. This depends on the Message Exchange Pattern (MEP) used to invoke the service.
* A Fault (extension of a Normalized Message) when something wrong occurs on the service side.
* A Pattern
* A Status
* …

The Message Exchanges can be classified by patterns (inspired by the WSDL 2.0 specification); we talk about Message Exchange Pattern (MEP):
* InOnly: This pattern is used for one-way exchanges
** The service consumer sends a message
** The service provider replies by an aknowledge
* InOut: This pattern is used for two-way exchanges.
** The service consumer sends a message
** The service provider reploies by a message or a fault
** The service consumer acknowleges
* InOptionalOut: This pattern is used for a two-way exchange where the provider's response is optional
** The service consumer sends a message
** The service provider can send back a response, a fault or just an acknowledgement. The consumer:
*** Acknowledges the response
*** Or sends a fault, in this case the provider must acknowledge this fault
*** Or acknowledges the initial fault
* RobustInOnly: This pattern is used for reliable, one-way message exchanges
** The service consumer sends a message
** The service provider acknowledges or send back a fault
** If a fault is returned, the service consumer acknowledges

More details on section 5.4.2 of the JBI specification.

h2. Delivery channel

The Delivery Channel (DC) is the interface between the components and the Normalized Message Router:
* The consumer (a JBI component) sets the message exchange (payload, attachments and properties) and send the message to the delivery channel
* The message bus is in charge of transmiting the message to the component which is providing the requested service
* The provider (a JBI component) receives the message exchange from its delivery channel and processes the message. Depending on the message pattern, a response, fault or acknowledgement can be set in the message exchange. The message exchange is then sent back to the consumer through the delivery channel.

h1. Petals ESB High Level Architecture

The Petals ESB architecture has been defined using the software component paradigm. The following figure introduces the main components which are required to build the Petals ESB container.

!High Level Architecture.jpg|height=450,width=600!

Details about the software components are detailed in the next section.

h2. Software components

The container kernel is build upon the software component paradigm. The Component Based Development (CBD) emphasises on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components. Components are considered to be a higher level of abstraction than objects and as such they do not share state and communicate by exchanging messages carrying data.

By assembling components implementations, it is possible to specialize a software for different needs. In the Petals ESB container context, we can easily replace a complex distributed registry by a local hastable and provide a simple standalone Petals ESB distribution (plus some distributed components). This is one of the interesting features the software component model provides.

One other powerful feature will be the possibility to replace software components at runtime. Even if this approach will never be used in production environment, let's imagine that you need to replace the JMS based communication channel by a HTTP one because your network topology or firewall settings have changed. This will be possible without stopping the container. Just stop the component (all the calls to this component are buffered during the operation), undeploy it then deploy and start the new component which provide the same interface. There is no impact on the container and all the buffered messages are then send to the new component!

h2. Petals ESB Components

As described in the previous section, Petals ESB is built using the software component approach. The main Petals ESB components are listed below :

* The *Container Service* is the main container component. Its role is to create the JBI artefacts lifecycles, installers. In the kernel point of view, the resources created by this service are wrapped into Fractal components.

* The *Router* acts as the central part of the JBI container. The router is in charge of choosing the right endpoint to send the JBI message to.

* The *Transporter* is the mediator between the router and the communication channel. Its roles are :
** Sending messages to the endpoint resolved by the NMR. As explained in the inter node communication section, sending a message to an endpoint can be just an in memory process or if the endpoint is located on a foreign container, the message is serialized into the wire format then send to the foreign container.

{note}
This service must handle the state of the remote nodes by sending hello/ping messages…
{note}

* The *Topology Service* holds all the Petals ESB nodes configuration. The complete topology information of the Petals ESB network is updated when nodes are joining or leaving the network.

* The *System State Service* is in charge of storing states (lifecycle state, installation URL, source URL, … ) and maintening the consistency whenever a JBI artefact state is updated. The system state and the repository services work together to reload resources on container reload.

* The *JMX Service* is used to manage JMX connections to a local or a remote Petals ESB container. The JBI specification defines a set of JMX operations to be exposed in order to manage a JBI container such as installation, deployment, lifecycle management, … (see the JBI specification section). This service is the local access point to all the remote containers JMX operations. By using this service, the local container can call these operations and so manage all the remote containers.

* The *JNDI Service* provides facilities to connect to a JNDI repository. In Petals ESB 1.x and 2.x, the JNDI repository is used to share knowledge between nodes such as JBI Endpoints and container configuration. This is a central point of the Petals ESB environment and you are, of course, free to choose the JNDI repository provided by Petals ESB or a third party one. This is possible by setting the JNDI factory properties at the domain level in the topology configuration. Petals ESB 3.0 comes with a new approach where the JNDI repository is replaced by an extensible and configurable distributed repository.

* The *Installation Service* role is to manage the installation (and provide the the lifecycle information) of the JBI components and shared libraries.

* The *Deployment Service* role is to manage the deployment (and provide the lifecycle information) of the service assemblies. The service units bundled into the service assemblies are deployed to the right component by this service implementation. As a result, JBI service consumers and providers are activated in the JBI and Petals ESB environment.