How Fast is Real Time?
Posted by Mike Canniff on March 18, 2011
In Part 2 of this blog series I focused on the importance of implementing an entire business process between enterprises. I want to emphasize that an integration solution should be viewed as much more than simply connecting two applications together.
The IT architect needs to understand the business objective when designing the integration process. Once the sequence of communication steps is understood, the next issue to look at is the mode of communication between B2B participants. By this, I mean looking at the urgency of receiving acknowledgements or the handshaking between applications.
It seems that everyone wants real time access to data these days. Yet in some cases, true real time may not be practical or required. There exist a variety of design patterns that can be used when implementing B2B integrations.
The four most common patterns for B2B Integration designs are:
- Request and Response: In this pattern, data is transferred in real time. A request is made from the initiating application in the business process. In a B2B scenario this would usually be in the form of a web service. The web service would request a “punch out” through the corporate firewall, request information from the trading partner, and wait for a response. The key point here is that the requester is “blocking” or waiting upon the reply. The target application must transform the web service call, build a response, and send back a corresponding web service call / acknowledgement. All of this needs to happen within microseconds so that the calling application is not slowed down. Typical examples for this design pattern would be for credit check or authorization, freight calculations, and inventory status.
- Publish and Subscribe: This design pattern represents an asynchronous communication model. A message is published from the sending application (usually onto a message or Enterprise Service Bus), transmitted across the network, received by the B2B trading partner, and then consumed for processing in the target application. The target application queues incoming messages and executes business logic to determine the appropriate acknowledgement. In error messages would be routed for automated rejection noticed or manual handling. For each business transaction within the message, the target application builds a response and the entire batch is sent back to the sender at a later time. The originating application would typically monitor the status for each of the published messages. Upon acknowledgement receipt, this status would be updated for each transaction. Typical examples for publish/subscribe would include order processing, advanced ship notices, voucher remittances, payroll distributions, etc.
- Hub and spoke: In this scenario, the B2B integration technology acts as a broker to route data between multiple senders and receivers. The hub acts like a traffic cop that directs incoming data traffic from sending applications. It can perform a variety of services such as message duplication, data transformation, data cleansing as it processes a transaction. Data is then distributed to appropriate target(s). Audit trails and error management is also provided. A typical example could be the distribution of RFQs to multiple trading partners.
- Point to Point: Finally, this pattern is the most basic. The goal is to route data directly from one sender to one receiver. Either of the first two design patterns could be leveraged in a point to point scenario (among others). This pattern works for relatively simplistic business processes where the cost of a full scale integration broker may not be justified. Typical examples may be sending time card data to a cloud based payroll processing system, uploading batch orders to a major customer, or importing inventory levels from a distribution center.
It is important that the B2B integration solution that provides the middleware integration functionality support these design patterns (and others). Some products focus on the hub and spoke model witha a lot of data quality features, but are not as strong with the other patterns.
The B2B solution should permit the integration architect the ability to mix and match the design patterns listed above. These are not mutually exclusive. The challenge is to evaluate middleware products to meet both internal and B2B integration requirements.
My next post in this series will address in more detail – error management, data quality, and automated processing concepts. Combined with the design patterns discussed here, enterprises can implement advanced integration processing capability.
Tags: Application Integration, B2B integration design, Business Process Integration, hub and spoke, integration architecture
No Comments »
No comments yet.