Originally, the first commercial ESB products were mainly described as a way to integrate existing middleware services (J2EE application servers, message-oriented brokers, etc.) and products (such as B2B solutions) and to connect applications with the required protocol. More recently, since the advent of the SOA approach, ESB has also been presented as a way to create a SOA.

ESB editors clearly face two major challenges:

• How to integrate heterogeneous technologies and products possibly produced by separate vendors in a way that sizes appropriately to each particular integration problem;
• How to provide the required features to fully address the specificities of SOA needs.

The Java Business Integration (JBI) standard (see the related section below) seeks to address the first challenge by adopting SOA principles. An ESB is built from JBI containers that can be seen as an integration framework, a host for Java connectors, an XSLT engine, or a mediation engine. JBI maximizes the decoupling between the JBI containers that all provide and consume services, while the ESB links the containers together allowing them to interact. Currently, it turns out that JBI-compliant ESBs are mostly open source ESBs that aim at promoting highly configurable and made-to-measure ESBs to fit business needs better.

Companies are currently struggling with the second challenge, since they realize that the ESB vendor's solution doesn't fit their needs. The reasons are manifold: for example, the ESB doesn't provide management models to control and enforce QoS at different levels and track consumer use; it doesn't fit into existing management and security frameworks; it's unable to connect to or evolve toward a highly distributed architecture that encompass the border of the enterprise. This problem will still exist as long as SOA technology editors don't address immediate and long-term business needs and concrete functional SOA.

Leveraging the ESB market momentum, the OW2 open source consortium (the old ObjectWeb) launched an ESB Initiative in June 2004 to facilitate the reuse and integration of several existing middleware components and respond to market requirements better.

JBI
PEtALS⁶ is the European flagship, JBI-compliant, open source Enterprise Service Bus developed by the OW2 community. It provides lightweight and packaged integration solutions, with a strong focus on distribution and clustering. Based on SOA principles, it offers a solid backbone for enterprise information system and acts as a bus where all data are exchanged in a technologically agnostic way. (See Figure 2)

The JBI specification promotes a plug-in architecture that enables the creation of tailored integration solutions by putting together best-of-breed integration components. The JBI specification is standardized in the JCP framework. JSR 208 describes JBI 1.0. The center part of the JBI specification is the Normalized Message Router (NMR). This NMR ensures loosely coupled communications between JBI components by providing standard SPIs that promote the exchange of XML documents between the components and loose references between the components via the use of their interface name.

Binding Components (BC) are "connectors" that interface the JBI bus with the rest of the information system. Binding Components enable both the exposition of external resources in the bus and the exposition of services available on the bus for their use by external consumers. Available BCs are: Filetransfer (send and receive files), FTP (put, get, or detect files on a FTP server), JMS (interact with an external JMS destination), Mail (send or receive files from or to an external mail service), SOAP (interact with external Web Services and expose JBI services as Web Services) and XQuare (lets users interact with databases).

Service Engines (SE) provide the integration logic. Available SE are: CSV (transforms a CSV document in an XML document), EIP (implements Enterprise Integration Patterns), Forward (chain calls to service engines before forwarding the result to an output service), POJO (deployment of Java classes as services), RMI (access to the JBI bus implementation context from an external RMI client), and XSLT (processes XML transformations based on the XSL style sheet).

Semantic-Based Service Governance
Many companies are still in the early stages of SOA adoption and so the practice of SOA governance will be new territory for many IT professionals.

According to Wikipedia7, SOA governance is a concept used for activities related to exercising control over services in a SOA. SOA governance can be seen as an overlay on IT governance, but its focus is more organizational, since services are closely related to business activities. Loose coupling and the smaller granularity of services in a SOA also increase the demand on good governance. While the specific focus of SOA governance is on the development and use of services, effective SOA governance must cover the people, processes, and technologies involved in the entire SOA lifecycle.

Some key activities that are often mentioned as being part of SOA governance are:

• Managing the portfolio of services: planning the development of new services and updating current services.
• Managing the service lifecycle: meant to ensure that service updates don't disturb current service consumers.
• Using policies to restrict behavior: rules can be created that all services have to apply to ensure their consistency.
• Monitoring the performance of services: because of service composition, the consequences of service downtime or underperformance can be severe. By monitoring service performance and availability, action can be taken instantly when a problem occurs.

We use the following definition of SOA governance: "The ability to organize, enforce, and reconfigure service interactions in an SOA8." Consequently, the target SOA governance framework will provide a full set of software tools for SOA governance for managing the whole service lifecycle:

-  At design time: a governance repository that stores information about services, SLA contracts, and other metadata such as semantic properties. Based on WS-Policy it allows service lookup and discovery based on metadata as well as service lifecycle management.

-  At runtime: a JBI framework for policies' enforcement with a special emphasis on security and fault compensation and dynamic composition and routing.