The Message and Medium Paradigm

There is a saying, "A message is more important than its medium," but in some cases, depending on the context, the opposite is true, "The medium is more important than its message." Certainly the approach the information technology revolution has taken in the past decade has focused on the medium. From a medium perspective, multi-platform languages (Java) and application-development specifications (J2EE) have pioneered a means for designing and constructing very robust, scalable, and distributed component-based business solutions.

These business solutions can easily be deployed into pervasive networked computing environments, such as PDAs, cellular phones, personal computers, and application servers. From the message perspective, HTTP (Hypertext Transfer Protocol) and XML (Extensible Markup Language) have become the industry-standard , system-independent data transfer and messaging protocols. However, the focus of this technology revolution has primarily been in the area of architecting a new wave of applications that interact with the end users through a Web browser.

However, to achieve a federated enterprise architecture enabling Business to Business ( B2B ) or Enterprise Application Integration ( EAI ) operations, there is a minimal requirement for applications to communicate among themselves . The traditional mechanism to achieve B2B or EAI is through exposing an application's functionality through a series of application programming interfaces (APIs). This type of integration is known as a point-to-point integration mechanism, and does not scale well because applications have their own proprietary APIs, which are often bound to hardware platforms and the implementation software platforms. For this reason, point-to-point proprietary integration solutions do not solve the stovepiped application integration dilemma in a cost-effective , maintainable , or extensible manner.

In order for communication to be achieved between applications written in different programming languages and on different platforms, typically a common gateway or proprietary adapter needs to be available, as illustrated in Figure 7.1. The role of this gateway or adapter is to provide interpretation services for service requests or responses on behalf of the communicating applications.

Figure 7.1. A simple example of application integration.

Note

Gateways and proprietary adapters require specific knowledge of all the communicating applications. This proposition can be very complex and expensive because consultants from the gateway and adapter vendors will need to be resourced to achieve any level of success. To mitigate this complexity and expense, use adapters that are based on proven industry-accepted integration standards such as the Java Connector Architecture, which is part of the J2EE specification.