SMILA/Documentation/Pipelets

This page describes Pipelets, ProcessingServices and their lifecycle.

Definition

Pipelets and ProcessingServices are reusable Java Components in a BPEL workflow and can be orchestrated like any regular BPEL Service. Both are used to process the data contained in Records.

Pipelets

A Pipelet is a POJO that implements the interface org.eclipse.smila.processing.SimplePipelet. It's lifecycle and configuration are managed by the workflow engine. An instance of a Pipelet is not shared by multiple Pipelines (workflows), even multiple invocations of a Pipelet in the same Pipeleline do not share the same instance. Each <invokePipelet> Pipeline has it's own instance. An instance may still be accessed by multiple threads, for example if the same Pipeline is executed in parallel. The configuration of each Pipelet instance is included in the <invokePipelet> call in the BPEL pipeline. Technical details on Pipelet development can be found in the tutorial How to write a Pipelet.

ProcessingServices

A ProcessingService is an OSGi service (preferably a Declarative Service) that implements the interface org.eclipse.smila.processing.ProcessingService. It's lifecycle and configuration are NOT managed by the workflow engine, but by the OSGi runtime. An instance of a ProcessingService can be shared between multiple Pipelines and so is frequently accessed by multiple threads. The configuration for a ProcessingServices is not contained within the <invokeService> call. Each ProcessingService can have it's own configuration file(s). Typically these are located in a folder equal to the ProcessingServices bundle name within the global configuration folder. For simple configuration options a ProcessingService can use the same XML format used to configure Pipelets. There are ready to use classes for reading and parsing such configuration files available. Technical details on ProcessingServices development can be found in the tutorial How to write a ProcessingService.

Lifecycle

Pipelet Lifecycle

The following diagram shows the lifecycle of Pipelets.

Pipelets live inside the workflow engine. When the engine starts, it reads the pipeline definitions (i.e. BPEL workflows) from the ConfigurationHelper. The pipelines are introspected for pipelet invocations (invokePipelet extension activities) and the pipelet configurations that are contained in the invocation XML elements. For each invocation it creates an instance of the specified pipelet class, parses the configuration from the BPEL document and injects it into the pipelet instance. The pipelet instance is stored in the workflow engine as long as the engine is not stopped (and as long as the bundle providing the pipelet is available, of course). So for each single pipelet invocation occurring in the pipelines a different pipelet instance exists with a single configuration.

ProcessingService Lifecycle

The following diagram shows the lifecycle of ProcessingServices.

ProcessingServices have a live independent from the workflow engine. They are created, activated and registered by the OSGi Declarative Services runtime just like the engine itself (of course, they can also be started and registered using bundle activators or other code, if declaring them as a DS is not appropriate for some reason). They read their configuration by themselves, e.g. by using the ConfigurationHelper. Eventually, the DS runtime binds all correctly registered ProcessingServices to the workflow engine so that it can invoke them when it reaches an invokeService extension activity during execution of a pipeline.

Combined Lifecycle

The following diagram shows the lifecycle of both Pipelets and ProcessingServices.

Of course, pipelines can combine the use of Pipelets and ProcessingServices. The main purpose of this figure is to emphasize the main difference between Pipelets and ProcessingServices: Pipelets live inside the workflow engine and instance are not shared, even if they have the same class and configuration. ProcessingServices live independent from the engine, manage their configuration on their own and instances can be shared by multiple pipelines. This makes them the more appropriate integration model if functionality to be integrated needs a complex internal model uses a lot of memory during runtime, or if resources should not be duplicated if used in multiple pipelines.