This section of the wiki lists gathers resources to use Petals components.
{multi-excerpt:name=abstract}
Petals ESB has been designed in a modular way. As such, it is composed of a main part, the container, which provides ESB typical features, and components, which bring additional communication and message processing features.
There can be distinguished two families of Petals components.
{multi-excerpt}
{multi-excerpt:name=abstract-BC}
*Binding components (BC)* are links between the services in the bus and external applications.
The natural way to provide these bounds is the usage of communications protocols. This is why binding components are generally associated with communication protocols, like SOAP, RMI, JMS...
{multi-excerpt}
{multi-excerpt:name=abstract-SE}
*Service engines (SE)* are pieces of application logics fully integrated in the bus.
They are exposed directly as services into the bus. It can be executing code (POJO), performing transformations (XSLT), scheduling (Quartz) and so on...
{multi-excerpt}
{components-list}
{multi-excerpt:name=abstract}
Petals ESB has been designed in a modular way. As such, it is composed of a main part, the container, which provides ESB typical features, and components, which bring additional communication and message processing features.
There can be distinguished two families of Petals components.
{multi-excerpt}
{multi-excerpt:name=abstract-BC}
*Binding components (BC)* are links between the services in the bus and external applications.
The natural way to provide these bounds is the usage of communications protocols. This is why binding components are generally associated with communication protocols, like SOAP, RMI, JMS...
{multi-excerpt}
{multi-excerpt:name=abstract-SE}
*Service engines (SE)* are pieces of application logics fully integrated in the bus.
They are exposed directly as services into the bus. It can be executing code (POJO), performing transformations (XSLT), scheduling (Quartz) and so on...
{multi-excerpt}
{components-list}