Method-Oriented B2B Application Integration
- Method-Oriented B2B Application Integration
- Method-Oriented Example
- Scenarios
Method-oriented B2B application integration allows trading partners to share common business logic. However, method-oriented B2B application integration requires that most, if not all, enterprise applications be changed to take advantage of the paradigm. EAI expert David S. Linthicum discusses the advantages and obstacles surrounding this option.
Method-oriented B2B application integration allows trading partners to share common business logic, or methods. This is accomplished either by defining methods that can be shared, and therefore integrated, or by providing the infrastructure for such method sharing. Methods may be shared either by hosting them on a central server or by accessing them interapplication (for example, distributed objects).
Attempts to share common processes have a long history, one that began more than 10 years ago with the multitiered client/server—a set of shared services on a common server that provided the enterprise with the infrastructure for reuse and now for integration—and the distributed object movement. "Reusability" is a valuable objective. A common set of methods among enterprise applications invites reusability and, as a result, significantly reduces the need for redundant methods and applications.
Sharing Common Methods
Although most methods exist for single-organization use, we are learning that sometimes it makes sense to share between organizations. In a new twist on the longstanding practice of reusability, we are now hoping to expand this sharing beyond intraenterprise to trading partners as well. For example, a common logic could be shared to process credit requests from customers or to calculate shipping costs.
Unfortunately, absolute reuse has yet to be achieved at the enterprise level. It is an even more distant goal between trading partners. The reasons for this failure are primarily political; they range from internal politics to the inability to select a consistent technology set. In most cases, the actual limit on reuse results directly from a lack of enterprise architecture and central control.
Utilizing the tools and techniques of B2B application integration gives us the opportunity to learn how to share common methods. More than that, these tools and techniques create the infrastructure that can make such sharing a reality. By taking advantage of this opportunity, we are integrating applications so that information can be shared, even as we provide the infrastructure for the reuse of business logic.
Sounds great, doesn't it? The downside might give you pause, however. This great-sounding B2B application integration solution also confronts us with the most invasive level of B2B application integration.
Although data-oriented and application interface–level B2B application integration generally do not require changes to either the source or the target applications, method-oriented B2B application integration requires that most, if not all, enterprise applications be changed to take advantage of the paradigm. Clearly, this downside makes method-oriented B2B a tough sell between trading partners.
Changing applications is a very expensive proposition. In addition to changing application logic, there is the need to test, integrate, and redeploy the application within the enterprise, a process that often causes costs to spiral upward.
Before embracing the invasiveness and expense of method-oriented B2B application integration, enterprises must clearly understand both its opportunities and its risks. Only then can its value be evaluated objectively. The opportunity to share business logic that is common to many applications—therefore making it possible to integrate those applications—represents a tremendous benefit. However, that benefit comes with the very real risk that the expense of implementing method-oriented B2B application integration will outpace its value.