{section}
{column}
This page lists the main concepts to remember when developing a Petals component.
{column}
{column:width=350px}
{panel:title=Table of contents}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}
h1. Components and Service-Units
A component can be a *service engine* or a *binding component*.
A component may support several *roles*: it can act as a *service provider*, *a service consumer* or *both*.
A *service-unit targets* a given component.
A service-unit is used to configure the *role of its target component*.
Not very role of a component may be configured by a service-unit. It depends on the component.
A service-unit supplies resources and configuration to make its target component emulate a service.
h1. Components classes
The component class is in charge of the *component life cycle*.
The component class has a *pool of (internal) message listeners*.
The component class has an *object in charge of managing the life cycle of service-units* (the Service-Unit manager).
The *JBI listener* is the class in charge of *handling and processing messages coming from the bus*.
The *JBI listener* must check the target end-point, the MEP and the operation name.
*JBI listeners work in a pool with a waiting queue*.
The *external listener* is the class in charge of *handling external messages and external events to the bus*.
*External listeners* may emit exchanges into the bus.
There are as many external listeners than consumes sections for a given component.
The *SU manager* is the class in charge of service-units life cycle.
The *SU manager* is created and maintained by the component class.
h1. Developing Petals components
Petals provides a framework that ease the development of Petals components (the CDK).
Concrete developments steps are listed [here|Concrete developments steps].
{column}
This page lists the main concepts to remember when developing a Petals component.
{column}
{column:width=350px}
{panel:title=Table of contents}{toc}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list}{panel}
{column}
{section}
h1. Components and Service-Units
A component can be a *service engine* or a *binding component*.
A component may support several *roles*: it can act as a *service provider*, *a service consumer* or *both*.
A *service-unit targets* a given component.
A service-unit is used to configure the *role of its target component*.
Not very role of a component may be configured by a service-unit. It depends on the component.
A service-unit supplies resources and configuration to make its target component emulate a service.
h1. Components classes
The component class is in charge of the *component life cycle*.
The component class has a *pool of (internal) message listeners*.
The component class has an *object in charge of managing the life cycle of service-units* (the Service-Unit manager).
The *JBI listener* is the class in charge of *handling and processing messages coming from the bus*.
The *JBI listener* must check the target end-point, the MEP and the operation name.
*JBI listeners work in a pool with a waiting queue*.
The *external listener* is the class in charge of *handling external messages and external events to the bus*.
*External listeners* may emit exchanges into the bus.
There are as many external listeners than consumes sections for a given component.
The *SU manager* is the class in charge of service-units life cycle.
The *SU manager* is created and maintained by the component class.
h1. Developing Petals components
Petals provides a framework that ease the development of Petals components (the CDK).
Concrete developments steps are listed [here|Concrete developments steps].