Part 3: Develop work flow activities using Spring Integration framework
Understanding Spring Integration Components
The Spring Integration uses dependency injection founded in the Spring framework to instantiate the objects required for implementing the work flow. It abstracts several components which interact in tandem to complete the work flow. These components are categorized as
- Message Channel
- Message Endpoints
Message is the java object that transverse the workflow with information required to complete the tasks. It contains information in the form of header and payload. The header is a name-value pair data structure that holds information required throughout the workflow and is passed from one task to another. Payload on the other hand is the information that is added to the message relevant to the task at hand.
Since Spring integration follows the messaging patter it uses channels to propagate information from one task to another. A channel can be point-to-point where the message from one task(producer) is handed over to another task(consumer) or it can be publish subscribe type where move than one consumer can receive the message.
Message endpoints in a work flow encapsulates the implementation of
tasks. These are java classes that contain methods that are invoked to
process the information and complete the task. Based on the different type of
task ideally required in a work flow, Spring Integration has the following
Gateway marks the entry point to
workflow; it provides information of the first task that is to be initiated.
Use filter to block the work flow under undesired condition.
For example use filter to stop work
flow if the information being processed is a duplicate of a previously
Use router to choose from mutually exclusive alternate paths.
For example use router to route
work flow to process 1 for type 1 and process 2 for type 2 items.
A transformer is used to transform or augment the payload.
For example the payload may have information in the form of a large comma delimited string, Transformer can be used to convert it to a name value pair map before passing it to subsequent task in the work flow.
- Service Activator
Service activators are used to execute a service for the work flow.
For example a service may be available to
add a new item to inventory system. The
work flow can use Service Activator to reference and execute this service.
Splitter is used to split the work if the payload contains a collection of similar task to be executed.
For example, if payload contains 10 items to be added to inventory, Splitter is used to split the work flow into 10 messages, each containing a single item as payload. Each of these message are then processed independently as a separate message.
Aggregator is the mirror image of
Splitter. It aggregates the messages back to a single message after the messages split by the Splitter have completed their tasks. It can used as a junction to verify all the messages have successfully completed individual tasks
before continuing the work flow.
In implementation of a workflow, using Spring integration, the individual tasks are implemented as messaging end points (@MessagingEndpoint). Spring Integration provides the following method level annotations, to indicate the messages that are capable of handing Message Objects.
The information flows as Message object through Channels from one Endpoint to another. The Endpoints and Channels are implemented as POJOs and defined as beans in the Application Context. These beans are created and initialized by Spring using dependency injection.
The Application Context can be declaratively created using a
XML file. This file is used to define the beans that represent the required
channels and messaging endpoints. The elements and end points used by Spring
Integration in this XML file is defined in the schema using namespace
such as xmlns:int="http://www.springframework.org/schema/integration" (See Listing 1)
The schema for which is available at http://www.springframework.org/schema/integration/spring-integration.xsd
Listing 1: Schemas used in Application Context xml file
The required Channels and Messaging Endpoints are defined in this XML file as beans.For example, a Transformer bean is defined as follows,
Listing 2: Sample Transformer
and the Transformer class is implemented as follows. It contains the @Transformer annotation to define the method that needs to be invoked for transformation. This method contains the implementation required to perform the transformation.
Listing 3: Sample Transformer class implementation
Thus when a message arrives at the channel “postTransform”, specified as the input-channel (see listing 3) the message is processed by method ‘transform’, specified as method(see listing 3), This method expects that the message payload to be object of type ‘MIMEData’. After successfully executing method "transform" the message is passed on to channel ‘checkDuplicates’, specified as output-channel.
Similarly a Filter can be implemented as follows
Listing 4: Sample Filter
Wherever a message arrives in the ‘check duplicates’ channel, specified as input-channel (see listing 4), the message is passed to the method ‘notDuplicate( )’ annotated as @Filter (see listing 5) to determine whether the message contains a duplicate work item in the payload or not.
If the item in the payload is not a duplicate the message is passed to the output channel “accept”, otherwise it is filtered out of the work flow and discarded by re-directing the message to discard channel.
Listing 5: Sample Transformer class implementation
Listing 6 below illustrates how the messaging channels and messaging endpoints are defined and how they are wired to pass information from one end point to another.