Middleware polishes c/s - importance of middleware in developing client/server applications - Forum - Column

I have been around the computer industry long enough to have seen a few silver bullets whiz by.

A current silver bullet is client/server, the new architecture for cutting costs and empowering users. Reality, however, has tarnished that silver bullet. Many development organizations are hitting the wall with client/server development tools that do not incorporate middleware. As a result, they cannot scale their applications throughout the enterprise.

Most of the popular application builders are fine for throwing together simple, department-level applications. They can support architectures where, for example, client PCs on a local-area network (LAN) share the resources of a server-oriented, relational database. However, more complex, heterogeneous, enterprise-wide applications present greater obstacles. Development teams quickly find they need a more robust development environment to complete the job.

For the communications capabilities required in enterprise-wide client/server systems, the key ingredient is middleware -- specifically, message-based middleware.

Middleware is a software layer that sits between the network and the applications. It provides a common application programming interface (API) for exchanging messages among the various pieces of distributed applications. Other threads in an integrated toolset typically include analysis and design tools, a repository and a rapid prototyping methodology for quickly constructing reusable systems.

Middleware shields developers from the complexities of dealing with multiple computing environments. It connects disparate operating systems, such as OS/2, Microsoft Windows, CICS, VAX/VMS and Unix. It also supports widely differing communications protocols and topologies such as Named Pipes, NetWare, NetBios and TCP/IP.

Most corporate developers are not accustomed to these interplatform communications complexities underlying the new style of enterprise-wide client/server computing. It is a lot easier with host-based systems, where data communication consists of sending data from the mainframe to a 3270 terminal. Network administrators handle the rest.

With client/server, however, network communication becomes an essential part of the development process. To partition application logic among client and servers nodes, developers must contend with these platform-specific dependencies and low-level networking protocols.

Middleware removes this burden from application developers. It provides a unified communication layer that simplifies interplatform communications. This is the capability most client/server tools lack. Without middleware, any claim to deliver systems that can be scaled through a heterogeneous enterprise is an empty promise.

MASKING COMPLEXITIES

There are three basic types of middleware: remote procedure calls (RPCs), standalone middleware and integrated middleware.

RPCs, which are not message-based, connect distributed parts of applications via synchronous calls that originate from subroutines embedded in those applications. RPCs are coded into each application. This means developers must modify, recompile and relink applications whenever network addresses change.

In contrast, applications built on message-based middleware are more flexible because network addresses are determined at runtime. If the network configuration changes, a developer does not need to modify the program.

Standalone middleware products, which organizations can tailor to many different development environments, are available from independent vendors. This allows organizations to assemble a development environment from "best of breed" technologies and tools.

For some applications this is appropriate. If an organization has a very well-defined or limited problem space, a standalone middleware solution may be sufficient. An example is a production environment that will never grow beyond OS/2 clients talking to a CICS back end using LU6.2.

Message-based standalone middleware products are available. Unfortunately, standalone, non-integrated middleware requires that developers design, code and test application interfaces and low-level communications mechanisms. And they must do this before they get to the more important business problem at hand: building client/server applications.

Integrated middleware, which is message-based, in incorporated within a vendor's own application development and deployment tools. The communications capability is already compatible with other components of the development architecture, such as analysis and design tools and the repository.

The middleware distribution services are woven into the overall application development fabric. As a result, developers do not have a big integration job on their hands before they start building applications. The environment provides a set of communications APIs that developers install on each client and server node. These APIs handle communications between nodes without requiring additional programming.

The benefits are clear. Developers can start building heterogeneous client/server applications immediately, without first having to integrate a hodgepodge of specialized tools from different vendors. Each piece of the development environment is mutually tuned for all the others. And all are accessible through a unified interface, right out of the box.

For most client/server applications now hitting the drawing board at Fortune companies with largescale, heterogeneous, enterprise-wide systems, an integrated toolset with integrated, message-based middleware is essential. Developers must design these corporate applications for eacy scalability. That way, the applications can flex with changing business dynamics and take advantage of new platforms and processors as they become available.

COPYRIGHT 1993 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group