Goals of the BizTalk Framework -- Part 2

Previous Integration Attempts As the need for improving integration has grown more pressing, several solutions to address this need have been developed. These solutions are grouped into three generations, which are discussed below. First Generation: Distributed Objects The earliest integration attempts centered on the idea of distributed objects. Examples of these early solutions include the Distributed Component Object Model (DCOM) and the Common Object Request Broker Architecture (CORBA). In these first-generation solutions, for each pair of applications that needed to communicate, there had to be an interface specific to that pair. That is, they had to be tightly coupled. But the interface between these tightly coupled applications was not flexible. To extend the analogy used earlier, this interface can be compared to translation between human languages at a conference. If there is one person who understands English and another who understands French, the interface would be an interpreter who knows both these languages. Similarly, for two incompatible applications, an interface is needed that can talk to both. This situation is shown in Figure 1.1. Figure 1.1 The first generation of integration These tightly coupled interfaces required extensive programming and were costly to implement. In addition, the interfaces were not reusable-having one pair of applications connected in this way didn't put you even one step closer to solving the integration problem between one element of the pair and some other application. If you wanted to add another application to interconnect with your original pair, you needed to add more interfaces. To compare this again to the communication between the conference participants, if you wanted another person to join the conversation, and that person spoke German, but didn't know English or French, you would need two more interpreters, one between English and German, and another between German and French. If you then invited someone who spoke Italian, you would need four more interpreters. The applications behaved the same way in that you needed as many interfaces as the applications you needed to connect to. As you can see, the number of connections rapidly becomes unmanageable. So, scalability became a big problem in this scheme, which for practical uses limited the number of applications you could connect. Another problem of tight coupling was the reduced availability of each application due to slowness caused by blocked connections. This is analogous to someone needing something to be translated when the interpreter is working on several conversations all at once. As the interpreter's attention is focused on another conversation, all the person can do is wait. For this reason, this solution didn't scale well. An even bigger problem was scaling across a large geographical area; such interfaces were unbearably slow. While the distributed object model was able to address integration between a pair of applications, this first-generation solution wasn't as successful in addressing the business and risk-control requirements discussed earlier in this section: The business requirement of embracing the global marketplace was extremely difficult to meet because interfaces were application-specific. The remaining business requirements could not be met effectively for this same reason. The technical requirement of having a solution work correctly and the operational requirement of meeting the specific needs of an organization were difficult to satisfy. Because the interfaces required extensive programming, it was difficult to avoid bugs. For the same reason, operational flexibility was difficult and costly to achieve. The technical requirement and operational requirement were at odds with the requirement of cost effectiveness. Since each coupling had to be programmed separately, the cost was proportional to the number of couplings. Second Generation: Fire-and-Forget The biggest drawback of first-generation solutions was that they didn't perform well over large, geographically-distributed systems. Because globalization was (and is) a non-negotiable requirement in business integration, a new solution was needed. The second-generation solutions addressed the globalization issue by employing a fire-and-forget strategy. An example of this is the Microsoft Message Queue (MSMQ) technology. The idea was that instead of tight coupling, messages were used for communication. The messages were placed in the queue by using a message broker, and they could be processed at a later time, thus enabling asynchronous communication. With this approach, there still was a need for some mechanism to do the actual processing. Therefore, the solutions such as DCOM weren't replaced by this approach, but rather, they were augmented by it. Using the human languages analogy again, with this type of solution you still need interpreters for every language pair. The difference is that if the interpreter is not available at a particular moment, you can put the text you want translated on his desk to be translated as soon as he becomes available. Since you do not have to wait for the interpreter, you can go and do other things and the interpreter will let you know when he's completed his task. Your translation will be done when the interpreter becomes available. In this way, the waiting is reduced and the system availability is significantly improved. But because the interpreter might have a large stack of papers to translate, he needs to manage those papers in a predetermined way. For integration purposes, a good mechanism for managing the items to be translated is a queue. So, the central idea for the second-generation integration systems was a queuing mechanism. Figure 1.2 The second generation of integration Although the second-generation integration solutions represented significant progress on the road toward system integration, they were far from ideal. Most used proprietary technology and were therefore expensive to buy and maintain. Another problem is that while these systems worked well within an organization, they didn't scale well outside an organization's boundaries. What about risk-management requirements for these second-generation solutions? Again, there was the same problem as encountered with the first-generation solutions: technical and operational criteria were outweighed by the financial costs of the solutions. In addition, by the time these solutions became available, the need for cross-business communication became even more pressing.