This chapter is from the book
This chapter is from the book
This chapter is from the book
Business Integration Patterns
Patterns help architects, designers, and developers use a common vocabulary to efficiently describe their solutions. This section discusses patterns at the business integration level, which fall into two classes: intraenterprise and interenterprise. These break down into Enterprise Application Integration (EAI) scenarios and business-to-business (B2B) scenarios. The EAI patterns deal mainly with application integration and database replication, whereas the B2B patterns deal with data exchange and process integration.
A.2.3
Another classification of business integration or Enterprise Integration Pattern is based on messaging architectures and messaging specifications such as Java Messaging Service (JMS) and Web services. The common categories in this case are channel patterns, endpoint patterns, routing patterns, system management patterns, and transformation patterns.
Data Exchange Patterns
A data exchange pattern is a rather simple pattern that is predicated on an agreement to use a common data format. The idea behind the SDO standard is to enable Java applications to support the following three common data exchange patterns. Actually, these are mechanisms that you can implement using different design patterns:
- The Plain Business Object pattern
- The Disconnected Object pattern
- The Event pattern
The Plain Business Object Pattern
The Plain Business Object pattern, also known as the Document pattern, is the most common data exchange mechanism. A client component populates a business object and then submits the object to a service by invoking a specific operation. Chapter 4 discusses defining and using plain business objects.
The Disconnected Object Pattern
The Disconnected Object pattern or the Transfer Object pattern is another common data exchange mechanism. Its primary purpose is to minimize the amount of time an application needs to be connected to the back end when making changes to an object. It extends the Transfer Object pattern of the Model-View-Controller architecture.
The Disconnected Object pattern enables an application to get hold of data from a back-end system and manipulate the data without requiring a connection to the back end. Then the application makes the changes persistent in a separate transaction that involves connectivity with the back end. The pattern extends this concept by introducing a mechanism to track the changes made to the business object or to any of the business objects contained by that business object.
In the Disconnected Object pattern, a system uses the change history in addition to the information stored in the object itself. The mechanism to track changes is called a business graph (BG), and it essentially includes four things:
- A copy of the business object data that can be manipulated even when no connection exists to the repository that holds the business object itself
- A change history, which stores the values of the business object before any manipulation occurred (for example, the original values), with an indication of the operations that modified the state of the business object
- An event summary, which contains the identifiers of objects affected by a change and event information recording the actual data involved in the business transaction
- A verb, which specifies the kind of operation that was performed (for example, a create or delete operation)
The Event Pattern
The Event pattern is the data exchange mechanism used when an event is produced by an EIS and is injected into WPS through an adapter. Typically, an adapter captures an event that occurred in a back-end system and creates the appropriate business object within WPS. For instance, in a travel reservation application that maintains profiles for travelers, a user might add a new airline company to the list of preferred airlines in his or her traveler's profile. Using the event pattern, that operation is captured as an "update" event that involves a certain traveler ID and a certain airline ID. The appropriate business objects will be materialized in WPS for the benefit of the business processes that can manipulate them.
The Event pattern makes use of the "delta image" information, which is a recording of what was changed in the original object. In our example, the addition of an airline to the list of preferred airlines would be the delta image. The Event pattern becomes important when you design complex relationships between different back ends, especially in integration scenarios that require keeping information about equivalent entities, managed by different applications, synchronized.
Many patterns have limitations, which are overcome by the use of a complementary or associated pattern. The Process Integration pattern takes the limitations raised by the Data Exchange pattern and addresses them by providing Business Process Integration (BPI) services. The common underlying entity in both cases is the exchange of XML-based documents, which permits richer, more complex relationships.