Figure 1. Solutions-oriented middleware contains server components that enable developers to tie applications with little or no additional development.
Although middleware has revolutionized the world of client/server, distributed development, and the Web, the technology is still primitive. Middleware remains a developerıs technology for connecting disparate systems using a common API. Developers must adapt the middleware to meet the specific requirements of applications. In other words, we are simply hiding the complexities of the network, database, application processor, and operating system behind an API. This may be better than programming down to the metal, but it is not ideal.
Solutions-oriented middleware, however, is an emerging concept in the middleware marketplace. It lets developers link various systems together like traditional middleware but also understands the features of the applications it is connecting. Solutions-oriented middleware is thus able to link deeper into resources (such as packaged applications) without a lot of new code. For instance, instead of having a developer link ERP applications together by using each applicationıs respective API sets and middleware such as IBMıs MQ Series, the middleware itself would provide a common interface that would understand how to gather information and invoke processes in each connected application.
The middleware products from CrossWorlds Software and other ERP-to-ERP "processware" products are prime examples of solutions-oriented middleware. In addition to tying applications together, the solutions-oriented middleware layer defines how those applications interact with external resources such as TP monitors, databases, legacy applications, and object request brokers (ORBs). The middleware becomes a point of integration, not merely a data and process access layer. Although the products that fit in the new solutions-oriented middleware category today are few and far between, this area will grow quickly as organizations seek to integrate enterprise applications ı which seems to be an emerging problem.
The idea behind middleware is to hide the complexities of the underlying operating system and network to facilitate the easy integration of various systems in the enterprise. Developers deal with an API on each system, and the middleware handles passing information through the different systems on behalf of the application. These APIs, however, are general-purpose information and data movement mechanisms and typically donıt know which applications and databases they are tying together. The developers have to create the links with applications and resources programmatically.
Middleware gives developers an easy way to access external resources using a common set of application services such as APIs. External resources may include database servers, queues, 3270 terminals, ERP applications, or access to realtime information. In the world of distributed computing, we usually think of middleware as a means of connecting clients to servers without having to negotiate many operating systems and network and resource server layers. Peer-to-peer middleware, however, is on the rise as well. Peer-to-peer middleware such as DCE, ORBs, and most message-oriented middleware products, provides a kind of "information bus" thatıs accessible across many different types of computing environments, providing developers with a means of tying applications together.
In the early days of distributed systems development, developers had to use protocols to access information directly or processing services that existed on other computers. Therefore, developers had to commit to a particular protocol. This commitment limits compatibility with other platforms and networks. Kids, donıt try this at home.
The networking components of middleware function like a protocol converter. The distributed systems developer uses an API to dispatch a message. The network services translate the message into the appropriate protocol (such as TCP/IP, HTTP, or NetBIOS). Protocol differences are resolved in the background, away from the application. Using this model, you can conceivably swap network protocols, even platforms, every day without users ever knowing and without making any changes to the applications if the API does not change. Iıve rarely found that to be the case, however.
Besides protocol translation services, middleware is also responsible for translating data on the fly between systems. For example, data residing on mainframes is very different from data residing on Unix systems or Windows. This data translation happens in the background as well. The arrival of advanced middleware layers allowed distributed application development to take off. Middleware enabled developers and application architects to tie many different systems together to form virtual systems. These virtual systems give users the ability to access a multitude of distributed resources through a single login or API. More important, the interest in middleware continues. Microsoft, for instance, is extending its interest in middleware beyond ODBC to message-oriented middleware (Microsoft Message Queue Server) and TP monitors (Microsoft Transaction Server). This trend will continue.
The easiest way to look at types of middleware, as well as where middleware is emerging, is to divide middleware products into three principal categories: primitive, database-oriented, and solutions-oriented.
Primitive middleware does not mean that the middleware lacks advanced functionality, but rather that the middleware is designed to perform a variety of roles besides accessing data. This type of middleware is also known as general-purpose middleware. Primitive middleware is the middleware layer that ties together many different systems to create a single logical system. For example, using primitive middleware you can access hundreds of computers and resource servers (such as application servers, database servers, and knowledge servers) through a single application interface. The application can access all these resources through the magical API of the primitive middleware layers. In other words, primitive middleware is the plumbing and wiring of distributed computing. Primitive middleware, however, is not solutions-oriented ı the middleware layer does not understand the applications and resources it is tying together. Developers must adapt the middleware layer to each resource using custom code.
Primitive middleware technology includes remote procedure calls (RPCs), message-oriented middleware, ORBs, TP monitors, and mainframe access middleware. These powerful middleware technologies give developers the ability to customize distributed applications while remaining network and platform independent. They also facilitate communications through a known platform-independent API found on each platform that makes up the distributed system.
Database-oriented middleware, in contrast, refers to middleware built specifically for database access. Database-oriented middleware is all the software that connects an application to a database. Like primitive middleware layers, database-oriented middleware lets developers access the resources of another computer (in this case a database server) using a single well-defined API. Although database middleware is a bit easier to understand in architecture and more like solutions-oriented middleware, many products make up this market, and each does things in different ways.
SQL gateways are magical APIs that provide access to most databases residing on many different types of platforms using a single API set. They are like virtual system middleware products but are just for database processing. For example, using an ODBC interface and a SQL gateway (such as Information Builders Inc.ıs EDA/SQL), you can access data residing in DB2 on a mainframe, Oracle running on a minicomputer, and Sybase running on a Unix server. The developer simply makes an API call and the SQL gateway does all the work.
SQL gateways translate the SQL calls into a standard format known as Format and Protocol (FAP). FAP is the common connection between the client and server, as well as the common link between different databases and platforms. The gateway can translate the API call directly into FAP, moving the request to the target database and translating the request so that the target database and platform can react.
So now that we know about primitive and database-oriented middleware, what about solutions-oriented middleware? Solutions-oriented middleware, as I mentioned already, lets developers access information and processes on different systems, and it lets them understand the solutions that exist in each system.
Solutions-oriented middleware lets developers link various systems together like traditional middleware, but it also understands the features of the applications it is connecting. For instance, instead of having a developer link ERP applications together by using each applicationıs respective API sets (such as SAPıs BAPI) and a common middleware layer, the middleware itself knows how to gather information and invoke processes in each connected system. This native intelligence saves a great deal of development time because you no longer need to understand the native API sets of each application or resource server. The systems are joined together through integration mechanisms and not through custom programming using a general-purpose primitive middleware API.
In addition to tying applications together, the solutions-oriented middleware layer defines how the application interacts with external resources such as TP monitors, databases, legacy applications, and ORBs. Each of these entities can be either a resource that an application may need or a mechanism to have applications created using these technologies link back to the packaged or custom application. Solutions-oriented middleware uses a single common pipe to connect many resources, and it goes beyond the bounds of traditional middleware by understanding the details of the applications, databases, and processes itıs connecting.
The way I see it, solutions-oriented middleware (see Figure 1) needs to include the following features:
The pipe (or pipeware, as Iıve called it in the past) provides the common information bus that ties all participating systems together. The best examples of pipeware today include the OMG's Internet Inter-ORB Protocol (IIOP) or Microsoftıs Distributed Component Object Model (DCOM). These primitive middleware layers provide applications with a synchronous RPC mechanism that spans platforms. For solutions-oriented middleware, this is simply plumbing.
A major component of solutions-oriented middleware is a mechanism to access any number of databases. Again, the idea is to expose the data to the other applications that the solutions-oriented middleware is integrating. Each application sees a virtual database. Unlike traditional database-oriented middleware, solutions-oriented middleware does not provide data access through an API. Since the applications are known, the database is simply integrated.
Like the database access layer of solutions-oriented middleware, the products need to provide a middleware integration layer as well. Therefore, solutions-oriented middleware must know how to integrate resources accessible by primitive middleware layers such as RPCs, message-oriented middleware, and TP monitors. Again, the notion here is not to expose the remote processes and data through an API but provide points of integration with the solutions.
In addition to simple middleware integration, the solutions-oriented middleware layer must provide a transactional component as well. This is not a TP monitor but rather a simple transactional layer thatıs able to control any number of remote or local transactions. Again, this layer serves the needs of the applications being linked by the solutions-oriented middleware. For example, this transactional layer would coordinate many remote transactions either on proprietary TP monitors (such as SAP R/3) or on open TP monitors (such as Tuxedo).
Because solutions-oriented middleware is so complex, a management layer is also required where the application integrator and the developers can link the appropriate resources together to integrate the applications. Whatıs more, this layer will provide security management, performance monitoring, and the ability to integrate additional components to access even more applications.
Last but not least is the application adapter layer, which is where the applicationıs knowledge exists. For instance, this is the layer that would store information about SAP, PeopleSoft, and Baan packages and provide the solutions-oriented middleware layer with the details pertaining to points of integration with each package or applications. Solutions-oriented middleware will also let other application vendors and developers create their own application adapters.
So where is solutions-oriented middleware today? Most of the components currently exist, but no monolithic products provide all the features I think should exist in a true solutions-oriented middleware product. Things, however, are changing. With the advent of the current line of ERP integration middleware products, we are moving closer to the notion of solutions-oriented middleware. I think itıs only a matter of time before middleware becomes a place for integration, not development. Itıs about time.
Figure 1. Solutions-oriented middleware contains server components that enable developers to tie applications with little or no additional development.