Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Transaction Server and Middleware
Notice that in Figure 1, the file transfer and Remote Procedure Call (RPC) is used; in Figure 2, in contrast, the messages described real-time and deferred. The implication is that file transfer is used to implement the deferred messages and RPC is used to implement the real-time messages: To make the same information available across the enterprise. Thus, the message "queuing" is the best solution for deferred messages: A message can be processed and be available at a later time, and "middleware" is the best solution for real-time messages. There is a built-in feature in message queuing called responsiveness and integrity. With regard to responsiveness, the implication is that message queuing has less overhead than file transfer. In this way, the messages are sent immediately rather than when the next file is transferred. For integrity message queuing, there is a built-in mechanism to ensure that the messages are sent and sent only once. With the file transfer, there are normally manual procedures to ensure that both conditions are met.
){kind=link}
){kind=link}
Similarly, there is a case for moving from RPC to transactional component middleware. The benefits of transactional component middleware are as follows:
The use of components helps reuse
The use of object interfaces may simplify the client code
The use of distributed transactional processing makes it possible to call many operations in one transaction
A further difficulty with moving to middleware is that in contrast to message queuing and RPC, the client must be written in an object-oriented language, or at least must use a gateway that is written in an object-oriented language. As shown in Figure 2, this can be a serious concern if the existing applications aren't object-oriented.
In many organizations, most of these technology-based solutions are being used: wrapping, Gateway, Integration Ware, Enterprise Application Integration (EAI), straight-through processing, EDI, messaging, XML, B2B, process integration, bridges, and much more. Surely, somewhere there must be a solution to the problems of integration. Integration has been recognized by the industry as a major problem, and where there are problems, there are opportunities. None of these concepts or technologies is invalid. The problem is that they overlap, and the quantity of acronyms people are inventing with such abundance has led to a situation in which we don't know what people are talking about any longer.
The other fashionable solution to the problem of integration is XML. XML is a way of encoding data into text, but not the way the message is sent. Let's contrast XML with old-fashioned EDI (Electronic Data Interchange), in which there were fixed message formats. XML has a number of advantages:
A number of different middleware standards can be used to send the message.
XML is flexible; it can easily represent lists, and values can be of any length.
Humans can read the message with a simple text editor.
But for application X to receive messages from Y and to understand the messages it receives, several things need to take place:
It has to know which part of the message corresponds to which data item. XML does this by tags; EDI does it by field location.
The designers and programs of both the applications must have the same understanding of what a field really means.
The message must contain all the fields that application X requires.
XML does not solve the problem. The only solution for applications X and Y is to agree upon a common message-format standard. The good news is that many application vendors are adopting the XML standard. The fact that tools are being developed around XML can potentially make the integration much easier.