Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SMILA/Documentation/Pipelets"
m |
|||
| Line 6: | Line 6: | ||
=== Pipelets === | === Pipelets === | ||
| − | A Pipelet is a POJO that implements the interface <tt>org.eclipse.smila.processing.SimplePipelet</tt>. 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 <tt><invokePipelet></tt>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. Technical details on Pipelet development can be found in the tutorial [[SMILA/Development_Guidelines/How_to_write_a_Pipelet|How to write a Pipelet]]. | + | A Pipelet is a POJO that implements the interface <tt>org.eclipse.smila.processing.SimplePipelet</tt>. 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 <tt><invokePipelet></tt> 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 <tt><invokePipelet></tt> call in the BPEL pipeline. For simple configuration options a ProcessingService can use the same XML format used to configure as Pipelets. There are ready to use classes for reading and parsing such configuration files available. Technical details on Pipelet development can be found in the tutorial [[SMILA/Development_Guidelines/How_to_write_a_Pipelet|How to write a Pipelet]]. |
=== ProcessingServices === | === ProcessingServices === | ||
| − | A ProcessingServices is an OSGi service (preferably a Declarative Services) that implements the interface <tt>org.eclipse.smila.processing.ProcessingService</tt>. 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. Technical details on ProcessingServices development can be found in the tutorial [[SMILA/Development_Guidelines/How_to_write_a_ProcessingService|How to write a ProcessingService]]. | + | A ProcessingServices is an OSGi service (preferably a Declarative Services) that implements the interface <tt>org.eclipse.smila.processing.ProcessingService</tt>. 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 <tt><invokeService></tt> 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. Technical details on ProcessingServices development can be found in the tutorial [[SMILA/Development_Guidelines/How_to_write_a_ProcessingService|How to write a ProcessingService]]. |
Revision as of 06:03, 26 September 2008
This page describes Pipelets, ProcessingServices and their lifecycle.
Contents
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. For simple configuration options a ProcessingService can use the same XML format used to configure as Pipelets. There are ready to use classes for reading and parsing such configuration files available. Technical details on Pipelet development can be found in the tutorial How to write a Pipelet.
ProcessingServices
A ProcessingServices is an OSGi service (preferably a Declarative Services) 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. Technical details on ProcessingServices development can be found in the tutorial How to write a ProcessingService.
Pipelet Lifecycle
The following diagram shows the lifecycle of Pipelets.
ProcessingService Lifecycle
The following diagram shows the lifecycle of ProcessingServices.
Combined Lifecycle
The following diagram shows the lifecycle of both Pipelets and ProcessingServices.
