Network Computingwww.networkcomputing.com

Realizing that there is little remaining value in providing single components, vendors are beginning to form strategic suites around tried-and-true middleware technologies. Although these suites aren't yet integrated so that their services are interdependent wit h consistent interfaces, they do derive additional value from their availability as a complete set of OS services.

Of course, you'll hear predictable arguments about best-of -breed versus integrated solutions. In this case, however, middleware is clearly different. Why? Because unlike productivity applications where best-of-breed configurations bring the advantage of allowing each application to stand on its own, today's middleware comprises the fundamental and interrelated communication services--RPC, messaging, data access and transaction control--that need to be at the ready in any heterogeneous and distributed enterprise network application.

Middleware integration may also come about as specific middleware products adopt features from other segments, such as database management systems (DBMSes) that support specific messaging application programming interfaces (APIs). But too often these supported features serve more to maintain existing customer bases than to provide the best middleware solution fo r a given situation. In many cases, applications are built with one type of middleware supporting another. If the application is dependent on the "primary" middleware, then the network can be left vulnerable to poor performance by the "secondary" middleware.

In contrast, whereas significant selection criteria for middleware used to be performance issues and transparency of networks and protocols, that is no longer the case today. TCP/IP is so readily available on all platforms that it has solved the network transparency issue for all practical purposes. Network managers need to be concerned about connectivity on the back end only when legacy, particularly mainframe, resources come into play.

Similarly, performance issues are being mitigated by deployment of the right middleware technology for specific network environments. For example, a three-tier design may use RPC middleware (like Oracle Corp.'s SQL*Net) between the second tier and the RDBMS, while employing a message-queuing solution between that mi ddle tier and the client. This setup provides a fast request-reply connection on the network backbone with asynchronous communications out to potentially high-latency clients.

Ev en Common Object Request Broker Architecture (CORBA)-based ORBs have demonstrated sufficient performance for request-reply applications on local networks. CORBA ORBs interoperate (over the Internet Inter-Orb Protocol or other proprietary protocols) using a special-purpose RPC mechanism, but incur a higher processing overhead from extensive data formatting and instance management.

Other middleware options let you resolve particular performance problems, such as using directory services to provide load-balancing and fault-tolerance. Unfortunately, few middleware packages support any sort of standard directory service. As LDAP gains acceptance, this issue may be resolved.

Waiting in the Wings The middleware market used to be defined by small, independent vendors with their scores of proprietary products. But there are discernible signs that industry forces are moving the market toward emergence of an integrated platform by the year 2000. By that time, there will be far fewer vendors, but those remaining will have a broader and more integrated set of products, because most IT organizations taking up new projects won't want to settle for narrowly targeted products.

More specifically, we see the following three forces exerting great influence over the reshaping of the middleware market: vendor consolidation, Microsoft and Java.