The software in the middle

Mar 27, 2000
Guest Contributor
© 2001 TechRepublic, Inc.

By Mike Rosen

I used to think I knew what middleware was. After all, I've been building it or using it for the past 20 years. The truth is, as technology has matured, so has our perception of middleware.

One definition of middleware is "the software in the middle"—in other words, that which is between the operating system and the application code that we write. Most people would add that middleware is part of a distribution infrastructure.

And this seems like as good a place as any to start describing middleware and the application code that we write.

A reprint from Software Magazine

This article originally appeared in last month's issue of Wiesner Publishing's Software Magazine and appears on TechRepublic under a special arrangement with the publisher.

Changes in middleware
With today's technology, we write application code at a much higher level of abstraction than we did two, five, or 10 years ago. Today, distribution is simply assumed to be part of an application. So while the basic definition of middleware hasn't really changed, the amount of middleware available and the capabilities that this category now includes are dramatically different.

To begin, let's look at what has traditionally been called middleware. Originally, middleware was the communications channel—e.g., TCP/IP—that provided a communication session between two communicating peers. As technology progressed, this basic functionality was subsumed into the operating system itself, and middleware took on the task of providing higher-level abstractions and services.

The Remote Procedure Call, or RPC, provided this higher level of abstraction to programmers. They could write code that treated calls to a remote system as though they were calling a local subroutine. Of course, it wasn't really that easy. And there was still too much complexity, which caused RPC systems like DCE (Distributed Computing Environment) to be left behind in the middleware race.

About the same time that RPC was being developed, two other themes were playing out in the middleware space. One was the development of messaging software. This was originally known as queuing, or message queuing, and today is called message-oriented middleware, or MOM. The basic difference between MOM and other middleware has to do with whether the client must wait while the message is being delivered, either synchronously or asynchronously. Some applications are more suited to one communications model than the other, and some applications need both, so both synchronous and asynchronous messaging will continue to be used.

While middleware vendors squabbled about which model is better, other companies worried about a different problem. Distributed systems introduced new error scenarios into previously non-distributed applications. One way to deal with this was to group operations together within an all-or-nothing transaction. Such two-phase transaction capabilities were most commonly needed in larger enterprises, and in conjunction with other communications and middleware services.

Thus, vendors tried to provide customers with a packaged set of software that met all of their infrastructure needs. The enterprises using these systems had a more stringent set of requirements than most other applications; in particular, the need for security, scalability, interoperability and manageability, and high availability, which were also addressed by such products.

Impact of ORBs
The other major advancement in middleware came from the marriage of traditional RPC-based systems with the concepts of object technology. This took the form of products called object request brokers (ORBs), most of which were based on CORBA (Common Object Request Broker Architecture) from the Object Management Group (OMG).

ORBs provide a higher level of abstraction beyond RPC and allow programmers to simply invoke a method on an object and let the infrastructure handle the distribution. Although not based on CORBA, JavaRMI (Remote Method Invocation) and Microsoft's COM+ are also generically ORBs.

The middleware market was affected by several other phenomena over the past decade. One was the growth of packaged enterprise resource planning (ERP) solutions by vendors such as SAP and Baan. Corporations invested billions of dollars in new applications based on these proprietary systems. At the same time, consolidation through mergers and acquisitions swept through virtually all industry sectors. As a result of these forces, corporations are now faced with the problem of integrating many different applications together.
Enterprise application integration
EAI (enterprise application integration) is technology for making all of these different enterprise applications work together. Essentially, EAI works by having some agreed-upon message semantics between applications, and a set of adapters (one for each type of system) that know how to translate between their own format and the agreed-upon neutral format. Some EAI systems tie the adapters together through the use of a workflow engine, which may be based on sophisticated rules processing.

Probably the biggest change in the computer industry, and also in middleware, has occurred due to the Internet and the Web. This has changed the way we do business, whom we do business with, how we relate to our customers and suppliers, and how we build systems.

New technologies have emerged to support this paradigm, specifically WebServers, firewalls, browsers, HTTP, HTML, and XML. It is important to understand, however, that the Internet is much more than just the Web. Some studies predict that the Web will account for only 30 percent of future e-business, the rest being made up of business-to-business (B2B) e-commerce applications such as supply chain management.

Finally, we see the consolidation and merger of the middleware industry, exemplified by the application server package. A cynical view would say that AppServer is just a new name for whatever technology a middleware vendor used to sell. Although there is some truth to this, there is really much more to the story.

The AppServer Story
The basic application server is the combination of component technology, the features for enterprise-scale support, and communications middleware. An AppServer programmer has an even higher level of abstraction and now only needs to write the business logic in the form of a standards-based component; for example, Enterprise JavaBeans (EJBs). The AppServer system takes care of distribution, run-time environment, security, transactions, etc., which are now transparent to the application programmer.

For the first time, three-tier, server programming is ready to experience the kind of productivity gains already seen in client/server and user interface development. Of course, it's not really that simple, and there is still plenty of opportunity for tools to better exploit the potential of the technology.

In some cases, the AppServers are new technology, perhaps based on WebServers. In other cases, the AppServers represent the next generation of technology from existing middleware or database vendors. For example, enterprise vendors such as IBM and BEA have integrated EJB component technology into their mature, enterprise-class execution and transaction environments.

These vendors have more than the simple application server described above, and sell a package of related technologies. A typical enterprise application server package might contain: WebServer, AppServer, messaging, EAI adapters, object/relational mapping software, and management/administrative support. To complete the package, the enterprise vendors will have partnerships with other vendors to provide tool support, workflow, persistence, and additional EAI capabilities.

E-Business Middleware Architecture
Now that we've taken a quick survey of the technologies that could be called middleware, let's try to put them together in the context of today's enterprise applications. The diagram illustrates a high-level, e-business middleware architecture with clients on the left and legacy systems on the right.

Still in the middle. Middleware today encompasses everything to the right of the clients and to the left of the legacy systems (pictured here). It resides above the OS and below the application logic.

First, notice that there are two different types of clients in the picture. Consumers, using standard Web technology like browsers, come into the system through WebServers, which handle HTTP and HTML and pass requests onto the AppServer. B2B applications come into the system through servers that are customized for that purpose, either using an AppServer or a WebServer.

There are no real, off-the-shelf B2B servers yet, but with the rapid acceptance of XML (eXtensible Markup Language) as a standard B2B protocol, we can expect to see products extended to support these requirements in the near future. Between the client and the AppServer, there will typically be one or two firewalls in place for security.

The AppServer is where new business logic and applications are implemented, and where object/relational mapping middleware is used for storing ("persisting") object states. AppServers, through the use of component wrappers, also provide the link between these new capabilities and existing legacy or packaged applications. A component wrapper exposes a business interface to the new enterprise infrastructure, and then uses EAI features such as dedicated adapters or messaging to access the legacy systems. Finally, management and operational controls extend to all of the pieces of the enterprise system.

So, what is middleware today? In the diagram, it's everything to the right of the clients and to the left of the legacy systems. It is that which resides above the operating system and below the application logic. It's still just "the software in the middle," and that definition hasn't changed fundamentally.

The difference is that the middle has moved and expanded as technologies have been introduced and then matured. Middleware has just grown more layers on top of itself in response to market and technology forces. You can expect this trend to continue.

Mike Rosen is practice director for Enterprise Middleware with Genesis Development Corp., Westchester, PA. He has broad experience in distributed technologies, including CORBA, COM, DCE, transaction processing, and messaging.

How do you see middleware changing?

What changes and advances do you see for middleware in the next two or three years? Post a comment below or send us an e-mail.