Having understood the structure of the blueprint covered in Chapter 3, Integration
Architecture Blueprint, this chapter will use individual scenarios to illustrate how the
business pattern can be implemented using the Integration Architecture Blueprint.
The scenarios shown in this chapter have been deliberately designed to be
independent of specific vendor products, and are based solely on the building
blocks that form part of the different layers of the blueprint.
The symbols used have the same semantic meaning as described in Chapter 3.
This chapter will:
- Explain service-oriented integration scenarios
- Use scenarios to show how data integration business patterns can be
- Present a description of scenarios for implementing the business patterns for
- Look in detail at the implementation of event processing business patterns
- Describe a scenario for implementing business patterns for grid computing
and Extreme Transaction Processing (XTP)
- Explain how an SAP ERP system can be combined with the integration
- Explain how an existing integration solution can be modernized using SOA,
and describe a scenario that has already been implemented in practice
- Combine the integration blueprint with the other Trivadis Architecture
Service-oriented integration scenarios
These scenarios show how the service-oriented integration business patterns described in
Chapter 1 can be implemented. These business patterns are as follows:
- Process integration: The process integration pattern extends the 1: N
topology of the broker pattern. It simplifies the serial execution of business
services, which are provided by the target applications.
- Workflow integration: The workflow integration pattern is a variant of the
serial process pattern. It extends the capability of simple serial process
orchestration to include support for user interaction in the execution of
individual process steps.
Implementing the process integration business pattern
In the scenario shown in the following diagram, the process integration business pattern
is implemented using BPEL.
Insertt iimage 1049EN_04_05.png
An application places a message in the queue.
- The message is extracted from the queue through JMS and a corresponding JMS
- A new instance of the BPEL integration process is started and the message is
passed to the instance as input.
- The integration process orchestrates the integration and calls the systems that are
to be integrated in the correct order.
- A content-based router in the mediation layer is responsible for ensuring that the
correct one of the two systems is called. However, from a process perspective, this
is only one stage of the integration.
- In the final step, a “native” integration of an EJB session bean is carried out using
an EJB adapter.
Variant with externalized business rules in a rule engine
A variant of the previous scenario has the business rules externalized in a rule engine, in
order to simplify the condition logic in the integration process. This corresponds to the
external business rules variant of the process integration business pattern, and is shown in
the form of a scenario in the following diagram:
Insert image 1049EN_04_06.png
The JEE application sends a SOAP request.
- The SOAP request initiates a new instance of the integration process.
- The integration process is implemented as before, with the exception that in
this case, a rule engine is integrated before evaluating the condition. The call
to the rule engine from BEPL takes the form of a web service call through
- Other systems can be integrated via a DB adapter as shown here, for example
to enable them to write to a table in an Oracle database.
Variant with batch-driven integration process
In this variant, the integration process is initiated by a time-based event. In this case, a
job scheduler added before the BPEL process triggers an event at a specified time, which
starts the process instance. The process is started by the scheduler via a web service call.
The following diagram shows the scenario:
Insert image 1049EN_04_07.png
- The job scheduler building block does a web service request at a specified
- The call from the job scheduler via SOAP initiates a new integration process
- As in the previous variants, the BPEL process executes the necessary
integration steps and, depending on the situation, integrates one system via a
database adapter, and the other directly via a web service call.
Implementing the workflow business pattern
In this scenario, additional user interaction is added to the integration process scenario.
As a result, the integration process is no longer fully automated. It is interrupted at a
specific point by interaction with the end user, for example, to obtain confirmation for a
certain procedure. This scenario is shown in the image below.
Insert image 1049EN_04_08.png
An application places a message in the queue.
- The message is removed from the queue by the JMS adapter and a new
instance of the integration process is started.
- The user interaction takes place through the asynchronous integration of a
task service. It creates a new task, which is displayed in the user’s task list.
- As soon as the user has completed the task, the task service returns a callback
to the relevant instance of the integration process, and by that, informs the
process of the user’s decision.
- The integration process responds to the decision and executes the remaining
Latest posts by Krishna Srinivasan (see all)
- Difference Between FilterDispatcher and StrutsPrepareAndExecuteFilter in Struts 2 - December 13, 2013
- Struts 2 Control Tags - December 13, 2013
- Struts 2 Generator Tag Example - December 13, 2013