Now you're ready to move beyond EAI to learn about Application-to-Application B2Bi, extending integration beyond the corporate enterprise. I will describe four additional patterns related specifically to B2B integration, beginning first with the Application-to-Application B2Bi pattern. The Application-to-Application pattern is the logical extension of what occurs in EAI. When EAI vendors tout their products as being B2Bi, this specific pattern is what they have in mind. However, as you will discover, this is not the only pattern and very likely not even the primary pattern for B2Bi.
Application-to-Application B2Bi, which is often referred to as inter-enterprise integration, involves corporate entities linking their applications directly to the applications of their partners or customers, as shown in Figure 3.6. In practice, this type of integration is often implemented as part of a supply chain of goods and services to the customer.
Figure 3.6 Application-to-Application B2Bi.
This picture does not imply that each application is entirely exposed. Only a subset of application data is externalized. The externalized application messages are the ones that are relevant to the partners or customers as part of the supply chain.
How is this pattern fundamentally different from application integration within the enterprise? As in enterprise integration, patterns such as the Multi-Step Application Integration pattern or the Brokering Application pattern may be applied. However, this pattern differs essentially from EAI in that it involves integration with external business entities, not simply applications. In this pattern, the applications are a direct point of entry into the business entity. This pattern will also likely require the use of a public network such as the Internet or a third-party network. This extension for inter-enterprise integration means that a number of additional issues need to be accounted for.
The use of external networks and collaboration between external parties require a focus on security. Trust levels have to be established between participants. This means security measures have to be implemented for authentication, authorization, nonrepudiation, and secured data transport.
The issue of federated control means that each entity needs to be able to control elements of its own integration environment independently. However, it needs to be able to effectively participate in the common integration environment.
Finally, the management of the entire integration system needs to be addressed as well. Establishing the service-level agreements between the participants is essential for long-term success. This means that each participant signs up to ensure application availability and performance levels.