- General E-business Approaches
- Considerations for Traditional Middleware
- Types of B2B Application Integration
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Considerations for Traditional Middleware
Is it reasonable to suggest that traditional middleware will provide the proper services for the new e-business problem domains? Perhaps, in some cases. Traditional middleware still needs to add many more features if it is going to learn to do everything that it needs to.
To move forward, existing middleware vendors need to understand the various design patterns of the machine and the human entities they are interacting with. For the most part, traditional information movement applications utilized an API and employed synchronous and asynchronous mechanisms to communicate with systems. Unfortunately, APIs may have little value in the new world of e-business. In most cases, changing the systems that exist within other enterprises to solve an e-business problem is not an option. Instead, e-business systems must interface with source and target systems through innocuous points of integration. This might require extracting data from a database or dynamically reading Web pages. More to the point, e-business–enabled middleware must understand how to use the Internet as its primary mechanism of communication. It must also learn to deal with such pesky realities as firewalls and bursty performance.
Additionally, middleware vendors must consider the type of interface to be employed. Traditional synchronous request-reply interfaces are much too primitive for a typical e-business problem domain. B2B-enabled middleware must take a more event-driven approach. B2B interactions are bound to challenge the capabilities of today's static interfaces. New, more dynamic and intelligent mechanisms need to be devised to deal with systems that may not be under the control of the e-business system owner.
We may well have to interact with systems whose only interface exposes data through a set of Web pages. If the pages change, which they always do, the interface must be capable of reacting to the change without requiring redevelopment. When XML becomes more of the standard, these types of interfaces will present less of a challenge. However, XML itself will inevitably bring its own set of complexities and level of sophistication.
Finally, information movement mechanisms, which include brokering and transaction processing, were the traditional choice to provide middle-tier processing capabilities. Within the e-business problem domain, we may have to mix and match the two, providing brokering capabilities (such as translation, routing, and rules) along with application and user interface processing. Therefore, transactional middleware needs to incorporate the basic features of a message broker, and message brokers must incorporate the basic features of transactional middleware to provide the maximum amount of value to e-business systems.
To illustrate this point, consider that an application server might do a good job externalizing information from many different systems through a Web interface. However, the application server's strict use of transactional semantics limits its capability to operate independently of the remote resources (such as queue, database, packaged application, and so on) that it is interacting with. Message brokers are very good at moving information from place to place, and they do so independently of the source and target systems, but they are not particularly good at externalization back office information through a user interface.
E-business development demands the best of both worlds.