A clear example of the potential benefit of method-oriented B2B application integration is the simple binding of two or more applications to integrate both business processes and data. Let's assume that two applications exist within a given enterprise. One application is C++based and runs on a Linux machine. The other is a Windows NT-based client/server application written in Java on the front end, with Sybase serving as the back-end database.
Confronted with these independent applications, the B2B application-integration architect seeks to create a composite application using method-oriented B2B application-integration techniques and technology. To accomplish this, the applications need to be tightly coupled so that common business logic can be shared and so that the business logic of both applications can be exposed to other applications for future use.
Unlike other B2B application integration levels, at the method-oriented level, the architect has no option but to rebuild the applications so that they support method-oriented B2B application integration. The architect has only two choices in determining how to accomplish this: First, he can move much of the business logic to a shared server, such as an application server. Second, he can rebuild each application using a method-sharing mechanism, such as distributed object technology, to create a tightly coupled application that allows easy cross-access of methods.
If he decides that the second choice is the most attractive, he will have to "wrap" the application logic inside both applications. To accomplish this, he will use a distributed object technology, such as CORBA or COM+, so that there is a common mechanism to share methods remotely. This requires rewriting the applications and then testing them. Fortunately, this is not as daunting of a task as it might appear. There are tools for each environment to wrap each application, re-creating the applications as truly distributed systems capable of sharing both methods and data.
Even with the availability of such tools, the process is laborious. For example, if both applications need to add a common customer to their systems, they may invoke different methods. Consider this example:
Add_Cust(); on the Linux/C++ system, and AddNewCustomer(); on the NT/Java system.
By using a distributed object standard or a custom programming solution, the architect could expose each method. As a result, he could bind the methods or invoke one of them. After the methods are bound, the applications move to a coupled state in which methods and data are shared easily within both domains, solving the B2B application integration problem.