EAI: Design Pattern (I)

This is to share one of the high level implementation design patterns of Enterprise Application Integration irrespective of technologies and tools.

Implementation design of Enterprise Application Integration largely depends on present systems, the reusability of the existing applications and tools being used (if any). Following is the design, which I find, in principal suits most of the application integration:




Here the arrows indicate the data flow through synchronous and asynchronous calls. The circles at one end of the arrows signify which module can initiate the data flows or service calls.

To discuss the above design in details we’ll go through an example. Let us consider the business scenario of a telecom company. To make it simple let’s assume that the company has two Applications which need to be integrated to implement the business processes:

• Application 1: Manages the asset details
  
• Application 2: Manages the provisioning and scheduling details
  

Following describes the different modules mentioned in the design (in details) :

Processes:

Every business scenario should be divided into processes which control the flow of business object from start to end. In our example of the telecom company, the processes could be – installing a new telephone service, installing a video service, disconnecting a service etc. All business rules and business exception handling should be implemented here. At different stages of the flow, process will interact with system blades or application services.

Processes allow us to have central controller which is easy to maintain and troubleshoot.

System Blades:

System Blades is the interface for any application. It routes requests/responses through adapters/connectors for the particular application (in the above picture rectangles inside system blades indicate connectors/adapters). All requests from the processes and responses from the application should go through this component. System blades will convert business objects to system objects. This is the place holder where system exceptions (example: connection exception with the application) should be handled. The particular design helps to manage resources (connection etc) at one place and improve scalability by clustering the blades (or managing the threads of the blade).

Considering our example, the system blade for application 1, which manages assets, should be able to handle all query/update/delete requests related to the application.


Application Services:

These are utility services – different processes will interact with these application services in different business state. This helps to have a service oriented reusable architecture.

Taking into account the use case of telecom processes, the examples of application services could be provisioning service, custom database, logging service etc.