E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (17)
View Page History
...
{section} 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!
!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.
...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!
!High Level Architecture.jpg|height=450,width=600!
Details about the software components are detailed in the next section.
...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!
From the Petals ESB developer point of view, working with Fractal components is like working with Java interfaces, annotations and descritpor files.
{code}
@FractalComponent
@Provides(interfaces = @Interface(name = "service", signature = org.ow2.petals.jbi.management.installation.InstallationServiceMBean.class))
public class InstallationServiceImpl implements InstallationServiceMBean {
@Requires(name = "configuration", signature = org.ow2.petals.kernel.configuration.ConfigurationService.class)
private ConfigurationService configurationService;
…
}
{code}
This code snippets taken from the Petals ESB kernel sources specifies that :
* The {{InstallationServiceImpl}} is a Fractal component (FractalComponent annotation).
* The Fractal component provides a service to other components which is defined by the {{InstallationServiceMbean}} interface (Provides annotation) and which is implemented in the current class.
* The {{InstallationServiceImpl}} need to use a service which provides the {{ConfigurationService}} interface.
Since the Fractal component implementation provides and requires services implementation, all the component implementations are binded together using XML descriptor files. This descriptor file is processed at compile time is used to generate the final Java byte code.
The OW2 Fractal component model has been chosen for its very structuring architecture and is used in the Petals ESB container to separate and identify modules. Fractal is not limited to the features introduced above. The framework is really powerful; we really encourage users and developers to have a look to the documentation which can be found on the Fractal Web Site (http://fractal.ow2.org).
{code}
@FractalComponent
@Provides(interfaces = @Interface(name = "service", signature = org.ow2.petals.jbi.management.installation.InstallationServiceMBean.class))
public class InstallationServiceImpl implements InstallationServiceMBean {
@Requires(name = "configuration", signature = org.ow2.petals.kernel.configuration.ConfigurationService.class)
private ConfigurationService configurationService;
…
}
{code}
This code snippets taken from the Petals ESB kernel sources specifies that :
* The {{InstallationServiceImpl}} is a Fractal component (FractalComponent annotation).
* The Fractal component provides a service to other components which is defined by the {{InstallationServiceMbean}} interface (Provides annotation) and which is implemented in the current class.
* The {{InstallationServiceImpl}} need to use a service which provides the {{ConfigurationService}} interface.
Since the Fractal component implementation provides and requires services implementation, all the component implementations are binded together using XML descriptor files. This descriptor file is processed at compile time is used to generate the final Java byte code.
The OW2 Fractal component model has been chosen for its very structuring architecture and is used in the Petals ESB container to separate and identify modules. Fractal is not limited to the features introduced above. The framework is really powerful; we really encourage users and developers to have a look to the documentation which can be found on the Fractal Web Site (http://fractal.ow2.org).
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 :
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* ({{org.ow2.petals.container.ContainerService interface}}) 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{*} ({{org.ow2.petals.jbi.messaging.routing.Router interface}}) *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* ({{org.ow2.petals.transport.Transporter interface}}) 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.
** Receiving messages which is exactly the opposite of the sending role.
** Receiving messages which is exactly the opposite of the sending role.
...* The *Endpoint Registry* ({{org.ow2.petals.jbi.messaging.registry.EndpointRegistry interface}}) is in charge of storing the endpoint references and their service descriptions (WSDL descriptions). The endpoints are stored in a database in order to optimize their retrival.
* The *Network Service* ({{org.ow2.petals.communication.network.NetworkService interface}}) is responsible of managing nodes whi want to join or leave the Petals ESB network.
{note}
This service must handle the state of the remote nodes by sending hello/ping messages…
{note}
This service must handle the state of the remote nodes by sending hello/ping messages…
{note}
* The *Topology Service* ({{org.ow2.petals.communication.topology.TopologyService interface}}) 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 *Configuration Service* ({{org.ow2.petals.kernel.configuration.ConfigurationService interface}}) handles the configuration of the local Petals ESB container. This local configuration ({{org.ow2.petals.kernel.configuration.ContainerConfiguration}}) contains data for the container such as topology, server properties (name, timeouts, QoS, JAAS, SSL…) but also domain and subdomain informations.
* The *Repository Service* ({{org.ow2.petals.platform.repository.RepositoryService interface}}) handles JBI artefacts resources needed at runtime by the container. When a JBI artefact is installed/deployed on the container, it is exploded in a distinct folder holded by the Repository Service. When the container is restarted, all the JBI resources are reloaded from their repository path. This allows JBI artefacts such as components to store/persist resources to be reused in their dedicated workspace.
* The *System State Service* ({{org.ow2.petals.platform.systemstate.SystemStateService interface}}) 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* ({{org.ow2.petals.communication.jmx.JMXService interface}}) 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* (_org.ow2.petals.communication.jndi.client.JNDIService interface_) provides facilities to connect to a JNDI repository (http://java.sun.com/products/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* ({{org.ow2.petals.jbi.management.installation.InstallationServiceMBean interface}}) role is to manage the installation (and provide the the lifecycle information) of the JBI components and shared libraries.
* The *Deployment Service* ({{org.ow2.petals.jbi.management.deployment.DeploymentServiceMBean interface}}) 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.
The links between these components are at the charge of the Petals ESB kernel developer. The final assembly of different component implementations will result to various Petals ESB behaviours. This is what it is used to created specific Petals ESB distributions (see Petals ESB distributions section).
The Fractal architecture of the Petals ESB container can be found on the [Fractal Architecture|petalsesb:Fractal Architecture] page.