Petals Artifacts

Petals ESB inherited from the JBI specification different kind of artifacts.
This page defines and illustrates these artifacts and their relations.

Components

What we call the Petals kernel is in fact a JBI container.
Like any other container, it can host components, that act as platform extensions.

The notion of container and component is well-known in Computer Science and Software.

EJBs are JEE components, and need to run in a JEE container (this is the core of a JEE application server).
(OSGi) Bundles are OSGi components, and run in an OSGi runtime / container.
Fractal and SCA define other component models, each one running in a container.

From this point of view, JBI (and so Petals ESB) is completely similar to other component models.


Each extension (component) is associated with a specific technology or usage:

  • The Petals SOAP component is in charge of the SOAP communications and of the exchanges as and between Web services.
  • The Petals BPEL component is in charge of executing BPEL processes in Petals ESB.
  • The list of the Petals components is available here.


The pictures below try to illustrate the relations between the Petals container and its components.


1. You can deploy any JBI component in Petals ESB.



2. The Petals SOAP component is one of them.



3. You can deploy several components at once.



4. This is true for every JBI component.


In Petals, a component is identified by its name, and configured by a JBI descriptor (a jbi.xml file).
A component can be directly deployed in Petals ESB.

Petals being a JBI container, it can host any JBI component.
In the same way, all the Petals components are JBI components and can be deployed on any container that respect the JBI specification.


Note that in practice, JBI components often need minor changes to work with other containers than the one on which they were originally tested.

Service-Units

Service-units are ZIP archive used to create services or define service consumers in Petals.
A service-unit always targets one component. This component must be deployed before any service-unit that would target it.
The content of the service-unit will be used to emulate a service (the component handles the messages and uses the service-unit resources and configuration to process the messages).


1. A service-unit always target a component.



2. The service-unit content depends on the target component and its version.



3. You can deploy several service-units on a same component.



4. You cannot deploy a service-unit on a different component than the expected target.


In Petals, a service-unit is identified by its name, and configured by a JBI descriptor (a jbi.xml file).
A service-unit cannot be directly deployed in Petals ESB. Its deployment must be done through a service assembly.

Service Assemblies

Service assemblies are ZIP archives that contain one or several service-units.
The service assembly is only a deployment unit. It associates service-units and target components.
All the target components described in a service assembly must be deployed before the assembly is deployed.


Deploying several service-units within a single service assembly ties their life cycle.
More exactly, deploying one of these service-units means deploying them all. And vice-versa for the undeployment.


1. A service-unit cannot be directly deployed in Petals ESB.



2. Instead, it must be deployed through a service assembly.



3. If a service assembly contains a SOAP service-unit, then the SOAP component must have been deployed first.



4. A service assembly can contain several service-units.



5. To be successfully deployed, a service assembly must be deployed only after the components it targets.



6. The service-units of a service assembly can target different components.


In Petals, a service assembly is identified by its name, and configured by a JBI descriptor (a jbi.xml file).
A service assembly can be directly deployed in Petals ESB.

Grouping several service-units per service assembly can be a good solution in integration projects.
In SOA projects, the best practice is rather to have only one service-unit per service assembly.

Shared Libraries

Shared libraries are ZIP archive that contain libraries that can be mutualized in the bus and shared among several components.
These libraries can also be referenced by service-units.


1. Shared-libraries address the need of common libraries between Petals artifacts...



2. ... e.g. between two Petals components.



3. A shared-library can directly be deployed into Petals.



4. Once it is deployed, you can deploy the artifacts that depend on it...



5. ... one after the other.



6. At runtime, the two Petals components will load and use this library.



7. A service-unit which is deployed on a Petals component...



8. ... can reference any of the component's shared library.



9. That can be very useful for components like the EJB component.


In Petals, a shared library is identified by its name, and configured by a JBI descriptor (a jbi.xml file).
A shared library can be directly deployed in Petals ESB.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.