What is Petals ESB ?Petals ESB is an Open Source (LGPL License) Enterprise Service Bus (ESB) provided by the OW2 middleware consortium. Petals ESB is build with and on top of agile technologies such as:
Java Business IntegrationThe 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. EnvironmentComponents 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. Unable to render embedded object: File (Environnement.jpg) not found.
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. JBI ArtifactsThe 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 :
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:
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. MessagesThe 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:
The Message Exchanges can be classified by patterns (inspired by the WSDL 2.0 specification); we talk about Message Exchange Pattern (MEP):
More details on section 5.4.2 of the JBI specification. Delivery channelThe Delivery Channel (DC) is the interface between the components and the Normalized Message Router:
Petals ESB High Level ArchitectureThe 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. Unable to render embedded object: File (High Level Architecture.jpg) not found.
Details about the software components are detailed in the next section. Software componentsThe 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! Petals ESB ComponentsAs described in the previous section, Petals ESB is built using the software component approach. The main Petals ESB components are listed below :
Petals ESB JBI ImplementationThe current section introduces how JBI artifacts are used in the Petals ESB JBI container and how they help to instanciate the SOA. The Petals ESB container is based on the JBI 1.0 specification and has been certified as a JBI compliant container by SUN MicroSystems. This certification has been obtained by running the official SUN JBI test suite with Petals ESN as JBI runtime. This suite tests that all the features defined in the specification are well implemented. In this section, a 'container service' is a software service which is provided by the container like, for example, the message routing, the exchange security. A 'JBI service' is a service created from a JBI artefact which is used to send, receive and potentially process JBI messages. The Petals ESB JBI ContainerThe JBI container is a Java based library which can be used in several forms such as standalone server, embedded in an entreprise application server, embedded in a standard Java application, … . The JBI container is generally called 'kernel' in Petals ESB and implements all the JBI specification. There is no container lifecycle defined in the JBI specification. Starting Petals ESB instantiates all the software services needed to welcome the JBI artefacts, exchange messages between JBI services and some additional features which will be detailed later in this document. The JBI container can be seen as a service container and like a web application container, a JBI container is not useful when used alone. To use the container, artifacts needs to be installed/deployed into the container with the help of management operations. Unable to render embedded object: File (Petals JBI Container.jpg) not found.
Using a JBI ComponentThe Petals ESB components are packaged as ZIP archives which contains the following files : + META-INF - jbi.xml - petals-COMPONENT-NAME.jar - a.jar - b.jar COMPONENT-NAME is the name of the component. This JAR file contains the classes which implements the JBI component interface. The other JAR files are third party libraries which are used by the component implementation. The JBI component must be installed in the JBI container. The container handles the component and its descriptor file (the jbi.xml file) which defines JBI properties such the name, the type (binding component or service engine) and component specific properties. The component properties will ne used by the component implementation to configure the component (a pool size, a socket address, …). The Java classes, which are packaged into the component, are used to create the component class loader and the container links the component to the container with a context and the delivery channel used to send and receive JBI messages. Once these steps are achieved, the component is started but it can not receive and process JBI messages. Unable to render embedded object: File (Using JBI Component.jpg) not found.
Using a JBI Service UnitThe Petals ESB Service Units are packaged as ZIP archives which contains the following files : + META-INF - jbi.xml - Service.wsdl The service unit is used to activate consumer or provider endpoints on JBI components. When the service unit is deployed on the container, this one will create an endpoint with the information provided in the service unit descriptor (jbi.xml file). A service provider endpoint is defined by a service name, an interface name, an endpoint name, a WSDL description (locally from the service unit or remotely with an URL) and some additional properties. Once deployed, the messages, which are sent to the endpoint, will be delivered to the component the service unit is deployed on. It is up to the component to process the message and to return a message, a response, a fault, or nothing. Processing a message is specific to the component implementation and is not defined in the service unit :
The service unit can not be used alone since the component to deploy the service unit onto is not defined in its descriptor. Unable to render embedded object: File (Using a JBI Service Unit.jpg) not found.
Using a JBI Service AssemblyThe Petals ESB Service Assemblies are packaged as ZIP archives which contains the following files : + META-INF - jbi.xmlsu-A.zip - su-N.zip The service assembly contains a collection of service units and a JBI descriptor file (jbi.xml under META-INF folder). Each service unit is deployed onto the component which is defined in the service assembly descriptor file. By deploying the service assembly into the container, it will get all the service units and will try to deploy each one on the sepcifed component. Using a JBI Shared LibraryThe Petals ESB shared libraries are packaged as ZIP archives which contains the following files : + META-INF - jbi.xml - lib-A.zip - lib-N.zip The shared library contains a collection of Java libraries and a JBI descriptor file (jbi.xml under the META-INF folder). The descriptor file gives the description of the shared library (its name, version) and the list of embedded Java libraries. A shared library is deployed into the container. Once deployed, this artifact may be potentially used by components to enrich their class loader. This type of artefact is generally used by components which uses the same libraries and so to limitate the resources in the Petals ESB container. Using the JBI environmentNow that the container is started, the components are installed and the endpoints are activated with the help of the service unit deployment, services can be invoked and messages can be exchanged between service consumers and providers. Unable to render embedded object: File (Using the JBI Environment.jpg) not found.
In the previous figure, a web service client calls a web service which is hosted by the JBI container. This web service is just a facade. The JBI service which is consumed by the facade can be changed as many time as needed. The only condition is to provide the same interface. This approach is extremely flexible since the JBI service can be a service composition of other JBI services (and recursively to reach atomic JBI services). Petals ESB JBI ExtensionsPetals ESB is not a simple JBI implementation, the current chapter introduces specificities and additionnal features which are not defined in the standard specification. Distributed EnvironmentThe JBI specification does not deals with any distributed aspect. The main JBI extension and Petals ESB main feature is the distributed approach. A Petals ESB container can share its services and access services which are hosted by other containers in a transparent way. It means that on the service consumers and providers' point of view there is no additional configuration like in other JBI containers. Where other JBI containers provide a distributed approach by connecting containers with the use of JBI Binding Components plus huge configuration, Petals ESB provide this feature natively without any additional configuration. Unable to render embedded object: File (Distributed Environment.jpg) not found.
The previous figure shows that multiple containers with their deployed JBI artifacts are completelu equal to a single container which holds all these artefacts. The following sections introduce the software modules which are needed to build this Distributed Entreprise Service Bus. The advantages of this distributed environment are :
Technical Registry
The Petals ESB JBI services, endpoints, interfaces, WSDL descriptions and container location are stored in an embedded technical registry. This registry is used by the Petals ESB containers to register services and to route the JBI messages to the right endpoint. In order to have a unified vision, the registry entries are replicated among all the Petals ESB nodes using a Distributed HashTable over a multicast channel. This is quite equivalent to data flooding between registries so when an entry is added to the registry, the data is send to all the network registries. All the registries have a complete vision of the services hosted by all the containers.
Inter nodes communicationIn order to exchange (send/receive) messages between Petals ESB containers, Petals ESB extends the JBI specification by introducing a message transporter layer. In a standard JBI implementation, the Normalized Message Router gets the local endpoint reference from the local registry and sends the message to a local JBI endpoint. In the Petals ESB approach, once the endpoint is retrieved from the local registry, the message and the endpoint reference are sent to the transport layer which is in charge to deliver the message to the JBI endpoint whereever the container it is hosted on. This is possible by getting the foreign container information where the JBI services is hosted on from the technical registry. Once all the required information is retrieved, Petals ESB serializes the JBI message to the 'wire format' and send it to the foreign container. The response is sent back from the remote container is needed. All the containers are linked together by the transporter layer. All the services providers and consumer scan potentially send messages to each other. All the links which were at the charge of the distributed application developer are now hidden by the Petals ESB container not only at the service level but also at the communication one. Unable to render embedded object: File (Inter Nodes Communications.jpg) not found.
The previous figure illustrates two visions of the inter node communication which are totally equivalent. On the left side, all the containers are linked together by point to point communication channels. On the right side, all the containers can also communicate to each other but the links are totally hidden by an abstract communication layer. At the lower level, the links exist but are not important on the transport user point of view (in the Petals ESB case, the router layer does not care about links between containers). JMS is the historical messaging system Petals uses to exchange messages between hosts (OW2 JORAM JMS implementation http://joram.ow2.org). Since Petals ESB 2.0, a new message transporter has been added. The OW2 DREAM project (http://dream.ow2.org) used for this transporter implemantation is a component-based framework dedicated to the construction of communication middleware. It provides a component library and a set of tools to build, configure and deploy middleware implementing various communication paradigms: group communications, message passing, event-reaction, publish-subscribe, etc... DREAM is alo build upon the FRACTAL component framework, which provides support for hierarchical and dynamic composition. This communication abstraction is also important on the JBI service consumers and providers side. When standard applications need to create links between service consumers and providers (for example an application which wants to get weather forecast from a Yahoo service and get stock values from the Google service) needs to basically create the links between the client (application under development) and services (Yahoo, Google, and more). Of course, the ideal solution wil be to add an abstraction layer to all of this in case of service provider modification (URL, interface, …). A solution such as an ESB already offers this abstraction layer since the links are the container responsability. ManagementA specification section (chapter 6) is dedicated to the container management using JMX. It mainly deals with the JBI artefacts management such as installation, deployment, starting and stopping. Additionally, the specification defines a set of Apache Ant (http://ant.apache.org) taks to manage the container from Ant scripts. Petals ESB implements and extends the management requirement of the specification in the way that additional JMX operations have been added to the specification ones. This is possible by extending the Managed Beans (MBeans) and adding new ones. Monitoring
Petals ESB provides various types of monitoring features :
There is actually some work to generalize these monitoring approaches to all the container software components and also to provide monitoring data in more standard ways (using OASIS WSDM specification and WS-* seems to be good candidates). The following figure is a general vision of what is planned by adding aspects/wrappers/controllers to Fractal software components : Unable to render embedded object: File (Monitoring.jpg) not found.
Kernel FeaturesThe kernel fully implements the JBI specification. Some features have been introduced in the previous chapters, other ones are defined below. DomainsPetals ESB is not a simple distributed JBI container where all services can be accessed by all the consumers. To add some visiblity control containers can be classified by domains and subdomains. Unable to render embedded object: File (Domains.jpg) not found.
This domain and subdomain settings are basically called 'topology' and are defined in the topology.xml file under the Petals ESB distribution configuration folder. JBI exchange optimisationJBI message responses, faults or acknowledgements generates extra trafic between consumer and provider because the JBI container must transfer all the message exchange content (the input message, the output one, …) at each pattern step. It is clear that serializing this data and sending it to the wire are time consuming in the distributed environment. By setting the org.ow2.petals.messaging.noack property on the message exchange, the acknowledgement and error messages will not be sent through the NMR. Address ResolverThe Adress Resolver acts as the router level (embedded into a router module) to select the right endpoint to send the message to. To select the right endpoint, the AR interacts with the Endpoints Registry to get all the endpoints which provide a valid interface and filter the endpoint list by applying a strategy (org.ow2.petals.jbi.messaging.routing.strategy.Strategy interface). The strategy is defined at the Message Exchange level (org.ow2.petals.routing.strategy property) set by the service consumer. Current strategies are :
Router Module
The router module has been decomposed into atomic modules (org.ow2.petals.jbi.messaging.routing.module.Module interface). Once the router receives a JBI message from the Delivery Channel or from the Transport layer, it injects this message sequentially in each module for processing. The standard modules are:
These modules are activated (or not) in the router.cfg configuration file located under the conf folder of the Petals ESB distribution. This part has been designed to be extended by your own module to add some functionnalities at the router level (logging, reporting, …). Transport layer
The Transport layer, which is in charge of sending/receiving messages to/from the wire, is electing a message transport from the message exchange properties. Selecting the right message transporter depends on the QoS the service consumer has defined in the org.ow2.petals.transport.qos message exchange property. Possible values are:
In Petals ESB v2.x, the technologies used to transport messages are OW2-JORAM (open source JMS), OW2-Dream (open source Extensible Messaging Framework, used in TCP/IP mode) and 'InVM' (Memory transport in the same Java Virtual Machine). Since Petals ESB v3.x, the transporter has been completely rewriten to take advantage of the Java New I/O features, to speed up inter-node communication. Hot DeploymentThe kernel provides a hot deployment features to avoid any Ant script or JMX commands. This hot deployment feature allows to install and start JBI artifacts archives (Component, Service Unit, Service Assembly and Shared Library as ZIP files) by copying them in the distribution install folder. When the kernel detects a new artifact, it install/deploy it and process the lifecycle steps to effectively start the artifact. The same feature is also available for the uninstallation/undeployment steps. By deleting the artifacts from the uninstall folder, the kernel detects that the artifact must be stopped and undeployed/uninstalled. Behind the scenes, the kernel calls the JMX management operations needed to process all these steps. These hot deployment/undeployment features are similar to the web application deployment feature you can find when copying a WAR file into the webapps folder of an Apache Tomcat container. Data compressionSince JBI messages are XML based and potentially contain redundant data, the compression feature has been added when exchanging messages between Petals ESB containers. This compression is done at transport level when a property (org.ow2.petals.transport.compress) is detected in the message exchange (set by the service consumer). |
Table of contents
Contributors
No contributors found for: authors on selected page(s)
|