FEATURES Driving Applications On the Network by Bruce Robertson Middleware is impacting network applications significantly. Little, however,is understood about specific middleware products and how they really work,mostly because a deployment and networking perspective hasn't been usedin evaluating middleware. Developers evaluate middleware from the top down.Often, an application developer is like the car driver who doesn't reallywant to know how the car operates or is maintained. They just want to driveit. They really only touch the steering wheel and the pedals. A thoroughperspective requires understanding middleware from the bottom up, from theinside out and over time. Experienced drivers know that a car has to bemaintained, that some cars work better on some roads than others and thatan educated driver is less likely to have accidents or breakdowns. Whilethe developer still does the network application driving, consulting witha qualified network application mechanic will improve the life of the application. From the Driver's Seat Programmers essentially define middlewareby its Applications Programming Interface (API). They want to know how touse it. This top-down view yields a characterization of products by howthey are accessed without necessarily specifying what they actually do (seediagram "Middleware Functionality: The API Perspective," page70). Thinking that two cars are very different because one is manual whilethe other is automatic misses the point that underneath they might be mostlythe same. Nevertheless, these t op-down categories are commonly used: Message-Oriented Middleware (MOM) products Remote Procedure Call (RPC)-based products Data access products Distributed Transaction Processing (DTP) moni tor products Object Request Broker (ORB) products Some products, however, provide more than one API, and vendors are increasinglyworking together to offer multiple products layered together as a suite.Each product has chosen a set of services to offer underneath these APIs,and they are often remarkably related even if the APIs are different. MOM systems typically offer a very basic set of commands for network communication--oftenas few as SEND and RECEIVE (see Figure 1, page 76). We're not talking about"e-mail" messaging. MOM products let programs send data to programsin real time (or slower), while e-mail infrastructures are still primarilyfor store-and-forward text message exchanges between people. MOM is about as manual, yet as general purpose, as it can get for the programmer.Application developers create application-specific functions or routinesbuilt on these basic messaging functions. As far as transports go, the interfaceis even simpler than programming to a particu lar network transport API,like TCP/IP sockets. Many message-oriented products exist, including CoviaCommunications Integrator (CI), PeerLogic Pipes, Momentum XIPC/Message Express,IBM MQSeries, Digital DECmessageQ and NetWeave, but RDBMS vendors like Oracleand Sybase are getting into the fray as well with products like Oracle MobileAgents and EMS. RPC-based products are function oriented. Developers define their own application-specificfunctions using an interface description language (IDL), and then compilethat function into the client and server stub code that actually does thenetworking (see Figure 2, page 76). The application just makes normal functioncalls. Developers essentially create their own APIs. Many RPC-based productsonly generate function stubs for 3GL languages like C, but some supp ort4GL products like PowerBuilder. While many 4GL tools can call C functions,it is easier if the functions are tool-specific. When distributing existinghost-based multiuser applications, the RPC approach is v ery intuitive: Eachexisting function can be split across the network as needed--just recompileto distribute a given function. RPC-based products are fairly automaticcompared with message-oriented solutions. RPC-based products come from many vendors, which includes Distributed ComputingEnvironment (DCE) standard vendors such as the major Unix players (IBM,Digital, Hewlett-Packard and so on, except Sun), along with Gradient, OpenHorizons and others. Sun's ONC RPC is implemented on many Unix platforms.NobleNet and NetWise offer third-party products. Data access products offer data-oriented APIs that reveal data in tables.Using a standard API (ODBC), applications get at remote data using SQL (seeFigure 3, page 76). However, most RDBMS vendors have proprietary APIs inaddition to ODBC, since those let them directly expose unique RDBMS functionality.If the application only needs to have its data distributed to, and sharedfrom, database servers, data access works well. Many tools already supportthis A PI, and since no application-specific programming is required on theback end, it empowers ad-hoc application development. Here, only the data can be on another node. With all the others, whole piecesof the overall application can be split across the network to run on othernodes. While the more recent development of stored procedures provides someadditional program execution across the network, this is still limited toSQL data manipulation, and it's RDBMS-specific at that. Besides the bigRDBMS vendors like Oracle (SQL*Net), Sybase (Open Client/Open Server), Microsoft(DB-Library) and so on, third-party vendors like IBI, TechGnosis (recentlypurchased by Intersolv), Cross Access, NetWise (recently acquired by Microsoft),Neon Systems and many others offer RDBMS-independent data access products. DTP monitor products offer a middleware environment oriented toward handlingtransactions over a network. Transaction monitors add BEGIN and END TRANSACTIONsemantics to the generic SEND and RECEIVE (see Figu re 4, page 76). By usingDTP services, the application doesn't have to include logic to assure transactionintegrity. DTP products are often built on top of message-oriented or RPC-based technologybut add significant control and management functionality. Most DTP vendorsare working to implement new X/Open standard APIs, but today, most haveproprietary APIs. DTP products interact with database resources via theX/A standard interfaces supported by most RDBMS vendors. Products includeNovell Tuxedo, Transarc Encina, AT&T GIS Top End and IBM CICS. From thedeveloper's viewpoint, this is a manual transmission with more gears, butthe car has airbags to keep passengers as safe as possible. ORB products support network interaction between pieces of an applicationwith yet another programmer API: the object (see Figure 5, page 76). Oncethe developer starts working in an object-oriented tool (a 3GL, like C++or a 4GL), the easiest middleware would directly network the objects createdin the tool. An ORB jus t lets the developer of an application containingmany objects easily partition those objects onto different network nodes.This is similar to the RPC-based approach, except for object-oriented tools,not function-oriented tools. If the object-oriented developer does not use an ORB, the programming jobwill be complicated by having to create the links between objects and thefunctions or other APIs offered by the other middleware solutions. The ORBworld has many standards: the Object Management Group's Common Object RequestBroker Architecture (CORBA), along with de facto standards like Microsoft'sOLE (which is waiting for Cairo before it gets distributed functionality)and OpenDOC. Much of CORBA currently defines developer APIs, although laterversions are finally defining services to expose via the APIs and eve n someinteroperability options. ORBs are available from large system vendors (IBMSOM/DSOM, HP, Digital, NEC, AT&T GIS) and many third parties, includingIona (Orbix), Expersoft (PowerBroker), PostM odern (ORBeline) and NeXT. Some development tools contain middleware components, such as Forté,Dynasty, Seer and Antares Alliance Group (Huron ObjectStar). Tool productswith built-in middleware can usually be adapted to use external middlewaresolutions. Looking Under the Hood Beyond hiding things from developers(and thus controlling diversity), middleware takes care of things developerswould normally have to handle in the application. Middleware provides services,and can therefore reduce the effort, time and cost required to implementan application (see diagram "Middleware Functionality: The ServicesPerspective," below). Application-oriented network mechanics don't focus so much on what API amiddleware product offers, but on the complex issues surrounding the actualmiddleware services--specifically how they impact the network and scaleto the enterprise. Dependencies and deficiencies often become apparent onlyduring deployment, just like you might only realize your car is guzzlinggasoline after driving it for a while. Each middleware product can offer, or decline to offer, many services acrossthe network, but even if programmers notice and appreciate them, they stillmay only see the service as options in the API, instead of something tobe deployed and maintained. Take name services: Most data access middlewarehas a name service that lists the RDBMS servers users can access, and translatesthat name into an underlying network address (an IP address or a DNS hostname, for example). That's usually enough for the programmer; the user willsee names. The networker notices that a given RDBMS' implementation for naming lookupand address resolution is completely static and based on tables that haveto be manually maintained at each client node. Only lately have RDBMS vendorsoffered a more centralized and dynamic approach--one that is infinitelyeasier to deploy and manage over time. The networker might insist on usingthese more scalable implementation s. Moreover, each product is a mix of APIs and services, each unique and possiblyright for a particular application environment. Some products even supportmultiple APIs and services. NetWeave and ISIS, for example, support bothmessage-oriented and data access approaches. Middleware products can also be layered on top of each another. Many DCERPC-based products use DCE's other services (like directory and security).Open Horizons provides data access over DCE, while Transarc Encina providesDTP services over DCE. The Orbix ORB runs on top of other middleware (ISIS).IBM has announced it will create a service provider API for SOM/DSOM, soother middleware products like PeerLogic Pipes can fit underneath. Middleware Transport Services Middleware is where the applicationhits the network. Like different car models, different middleware productsoffer a variety of ways to get the basic transportation job done. The largestdifferences come in the model for interacting over the net work, includingone-to-one interaction using request/reply conversations or events, andone-to-many interaction using broadcasts and publish/subscribe. Underneaththose basic interaction models lurk interesting differences between products. All middleware supports communication in all directions, except data accessmiddleware where only clients can initiate conversations and make requests.Data access interaction also typically places the largest burden on networkbandwidth, since large result sets can be requested ad hoc by end users. The typical request/reply model used by network transports, such as TCP/IP,characterizes most RPC and data access middleware: Ask a question; waitfor an answer. This synchronous blocking behavior suits procedural applications,where things happen in a logical order, well controlled by a single codebase usually running on the client. The middleware makes sure that the requestand reply are delivered. Often, the middleware does little, only passingthe message directly do wn to TCP/IP or another stack for reliable connection-orienteddelivery. Conversations are set up, data is exchanged and the conversationis torn down. Such mechanics are most efficient if servers aren't overloadedand if the client only talks to one server at a time. Applications, however, are increasingly becoming event oriented. Effectiveevent orientation means ditching the conversational model, since eventsrequire a more dynamic and flexible model with lower overhead per interaction:non-blocking asynchronous communication. Applications can't stop workingwhile waiting for events. Instead, events just happen. Asynchronous communication is possible with multithreaded RPCs (DCE usingDCE threads, for example) but has proven much easier with message-orientedmiddleware. Many message-oriented solutions implement their asynchronousbehavior by using the underlying operating system's threads support or deliverit internally for operating systems that aren't inherently multitasking(like Windows 3.x). Mess aging products like NetWeave and Covia CI offersynchronous and asynchronous behavior. So, the great "RPC vs. message-oriented middleware" debate comesdown to this: RPCs and messages really aren't completely distinct options.They are different sets of services and APIs delivered in typical packagingcombinations. Most RPC implementations are blocking and synchronous, andtherefore not perfect for distributed event-oriented applications. An event-oriented application working over an asynchronous middleware mechanismcan exploit the parallelism of a network of resources by sending off multiplerequests to multiple servers up front and accepting responses as they comeback, rather than contacting one server and waiting to hear back from itbefore continuing to the next. User response time would improve since morethi ngs get done at once. This is particularly well oriented to integratingmultiple legacy systems into a single end-user application. Message-oriented solutions (and this woul d include ORBs, DTP products andany other systems built on message-oriented infrastructure) also typicallyoffer connectionless services. Now, a message doesn't have to require anyresponse at all, even within the underlying network transport layers. Thisis lower overhead than having the middleware's own non-blocking functionalityimplemented over connection-oriented transport protocols. It does requiremore data per message to include connection-like information, but sincecentralized resources no longer have to keep up connections, they can bemore heavily loaded. MOM products, like PeerLogic Pipes, offer reliableyet connectionless services over IP. When message-oriented interaction is combined with queuing, applicationsno longer have to be online at the same time (the same benefit as with e-mailor voice mail). Clients and servers can queue up messages for each other,and when an actual connection is made, the messages are exchanged. SomeMOM products work with in-memory queues for performance, while others supportdisk-based queues for reliability. Some, like NetWeave, use a single queue(for best performance with least latency) while others, like IBM MQSeries,use two (for highest availability and reliability). This queued messaginglets applications function well for the mostly disconnected user over low-speedor wireless links, as well as for very heavily loaded servers (where thequeue enables session concentration and batch-like processing typical ofmainframe systems). Most request/reply environments use point-to-point connections. One devicetalks to another. A growing number of middleware products, however, aretaking advantage of broadcast and multicast paradigms. In a stock tradingapplication, for example, people on a trading floor might want to trackthe cost of a given stock on their workstations. A server could send thatdata out 50 separate times in 50 separate messages to 50 separate machines,or the 50 workstations could poll the server separately. The most efficientway, however, is to broadcast i t once and let them all listen. Multicastis a special case of broadcasting to more than one, but not all, nodes onthe network. These one-to-many approaches can provide interesting networking implications,specifically because most routed networks don't support broadcasting betweensubnetworks. Multicast may only be supported on particular datalinks andnetwork transports. Teknekron's Rendezvous Software Bus, for example, offersextensive broadcast functionality, for example, letting Microsoft Excelusers publish parts of spreadsheets anonymously for other users to subscribeto independently over the network along with a broadcast relay componentto move messages across subnetwork boundaries. Middleware Transparency Services A key benefit of middlewareis how it hides differences between deployment environments. Transparencymust exist not only across, but between, lots of different platforms. Takenetwork transparency. It's not just that the middleware API is simpler thanthe underlying transport API, it's that the middleware makes differencesbetween multiple transports transparent to the application, and makes formore ongoing deployment and maintenance flexibility. Beyond transparency, middleware should offer network protocol, operatingsystem, programming language and even API independence. Network independence,for example, means that two devices communicating with each other need nothave a single network protocol in common. Between operating system platforms, middleware normalizes data format differences.Some use a single platform-independent data representation on the wire (likeXDR in ONC RPC or ASN.1). Most let the "receiver make right" anydifferences, which means the middleware has to know from which machinesmessages are coming, but it still results in less overhead per message whilekeeping s ervers pumping out natively formatted data at their fastest clip. Moreover, middleware can hide real differences between different databasesystems (by supporting multiple vendor products like IBI EDA/SQL does) orbetween different legacy application environments (by providing proceduralaccess to existing business logic in CICS transactions, for example). Allthese resources look similar to the application running on the client, althoughsome programming may be required to integrate legacy transactions. Some applications will want full transparency from middleware itself. Inthis case, programmers create their own meta-API. Applications also gainmiddleware independence by using three-tier application designs that usedifferent middleware between different tiers of the application. SAP AG'sR3, for example, uses messaging between desktops and application servers,but uses data access between application servers and database servers. Middleware Directory Services Directory services are alarge differentiating factor between products offering similar APIs, transportand transparency services. Without some level of naming indirection, changingservi ce locations (server names or IP addresses, for example) on the flywill be difficult after the application is deployed to hundreds or thousandsof desktops. Some middleware products offer no help. Others rely on underlying networktransport-specific mechanisms (like DNS, NetWare SAP or NetBIOS) for namelookup and address translation. These, however, aren't consistent acrossall transports, nor are any of them perfectly suited to the needs of applicationstrying to name components dynamically. Still others offer their own simplename services or full enterprise scalable naming. Nowhere is this more pronounced than when comparing DCE RPC with other RPCimplementations. While most RPC products punt on the naming service issues,DCE RPC is often implemented with DCE's other services including directoryservices (cell directory service) and secu rity (Kerberos with DCE-specificintegration). Moreover, DCE's services are not simple naming services, butcomplete authentication and data encryption services deli vered in a scalableway. Contrast this with PeerLogic's Pipes naming service. Since there's no securityservice, Pipes provides only name/address translation services. Authenticationis the application developer's problem. However, its name service is welloptimized for robust distributed dynamic name services. A service can announceitself via the directory and users can immediately tell that a new resourceis available. Applications can easily search the name space for servicesthey need. While it's not infinitely extensible, the Pipes directory serviceoffers some attribute fields that can be populated as required for applicationneeds, allowing the application developer to type and otherwise identifyservices. Middleware's use of external directory services can be platform specific.Oracle, for example, now supports NDS in Oracle 7.2, but only when the serverruns directly on the NetWare platform. If you need to run Oracle on Unix,you can't authenticate against NDS. Directory services enhance their basic location transparency benefits withassociated services like transparent load balancing across services. Somemiddleware products offer their own directories along with other mechanismsfor load balancing (Tuxedo and other DTP products). Reliable messaging productslike ISIS support load balancing. High availability and load balancing gohand in hand with a good dynamic directory service. Middleware Security Services Directories are better deployed in conjunctionwith security services designed to support a single system image. This is,for example, when a user logs in once to the network and no longer individuallylogs in over and over again to each application or server. Security functionality should include authentication and privacy (encryption),data integrity and identification (perhaps using digital signature technology) and non-repudiation (return receipt). Not many middleware products do thisinternally, although DCE does provide directory and security services inaddition t o the RPC transport to handle most of these needs. Only recentlyhas Novell announced that the Tuxedo transaction monitor will use NDS fordirectory and security needs (a product called TransactionLink), but onlyon the NetWare NLM platform version. While Kerberos (RFC 1510) seems like the external security system of choiceoutside the NOS proprietary implementations, it has only recently (in V5)supported public-key encryption solutions like RSA. A new standard API calledGeneric Security Services API (GSSAPI, defined in RFC 1508) should makeit easier for non-DCE middleware to use security services such as Kerberosor any other service that supports that API. Other applications that donot use the DCE RPC mechanism may still directly authenticate using Kerberos.Suite Software's SuiteDOME ORB uses message-oriented mechanisms across thewire, but supports Kerberos. Kerberos, however, isn't perfect. It doesn't, by itself, protect from password-guessingattacks. Nor does it support hardware-based one-time passcode options likeSecurity Dynamics SecurID. In contrast, Oracle's Secure Network Servicesnow supports fingerprint recognition in its SQL*Net data access middleware. Most middleware products offer no guarantee that authentication will bedone securely. Instead, user names and passwords move between client/serverin open text. Anyone with a network analyzer could compromise your security.Beyond authentication, data encryption is usually not offered. Contrast this stark reality with the enhanced functionality of some middlewareproducts. DCE RPC-compatible applications can flip a switch to turn on dataencryption. Microsoft SQL Server 6.0's new DCE RPC-based DB-Library supportsboth per node and centralized enforcement. While SQL Server 6.0 uses theNT domain services and not the DCE directory and security services, authenticationis still secure if you choose either Named Pipes or DCE RPC transport connections. Creating applications that access resources separately controlled by differents ecurity systems (DCE, RDBMS, NOS, mainframe and so on) can make thingscomplex. The different systems must be separately integrated or gatewayedby the middleware or the application. Otherwise, users must log in to thoseresources separately. Oracle's SQL*Net/DCE provides single system logonusing DCE directory and security while running over the DCE RPC transport.Open Horizon's Connection offers database access this way, but to more thanjust Oracle databases. Novell, in contrast, has not decided if its Net2000security services based on NDS will gateway to DCE or NT domain security.So far, it has only said it'll synchronize directories with those systemsin the future. Most middleware products still expect the developer to make security decisionsand address those concerns outside the middleware. Moreover, security controlmay need to be focused at many levels: the conversation, socket or transportlevel (Kerberos, Netscape's SSL); the document or message level (SHTTP,secure e-mail solutions like S/MIME and P EM); or even the transaction level(DTP products, EDI). A lot still has to be decided as networked applicationsmove from being deployed over relatively controlled private networks intopublic networks where full security is a requirement. Middleware Fault Tolerance Services Some middleware is focused squarelyon offering high availability and fault tolerant support for networked applications.For example, Tandem/ISIS offers fault tolerant message-oriented solutionsfor reliable messaging, while Teknekron's similar publish/subscribe mechanismdoes not. Beyond specifically nonstop systems lies middleware designed to assure transactionintegrity despite failures, but without making the application do all theextra work. An update may not be made, but at least the middleware makessure that complex transactions are fully carried out, or completely backedo ut. DTP products offload clients from the two-phase commit processing thatdata access products require, and let an event-oriented application get on with other tasks while complex transaction processing is taking placeelsewhere. DTP products are used more often than data access middlewarewhen high performance and complete reliability are paramount. By dependingon more middleware services, applications can be smaller. Distributed fault tolerant solutions require a naming or full directoryservice to provide location transparency for service providers. Client applicationscan't have hard-coded service names or network addresses. They will breakwhen a service is moved to another machine. Some middleware solutions, suchas PeerLogic Pipes and ISIS, automatically start additional services onnew machines if loads get too high on one server, or for fail-over if aserver becomes unavailable. For multiple instances of a duplicated service, most middleware systemswill provide some load balancing across them. However, mechanisms vary fromnothing (in PeerLogic Pipes) to a DTP product's careful analysis of resourceplatform load. While some of t hese differences can seem subtle, if you're driving the applicationson your network, it will pay to understand how to exploit, deploy and maintainthese middleware services. Not only will you gain a better understandingof how applications impact your network, you'll be able to steer your applicationdevelopers down the right service roads. n Bruce Robertson can be reached at brucer@metagroup.com. January 15, 1996