Managing Complexity: Middleware Explained Andrew T
Total Page：16
File Type：pdf, Size：1020Kb
DISTRIBUTED COMPUTING Managing Complexity: Middleware Explained Andrew T. Campbell, Geoff Coulson, and Michael E. Kounavis sk a network designer what middle- in a distributed environment can be a nightmare. ware is, and he’ll characterize it as part For instance, to provide basic communication of the application.Ask an application services, programming languages support sock- designer what it is, and she’ll say it’s ets, which are end points in two-way communica- Apart of the OS.Which one is it? tion links between two programs running on a Traditionally, most definitions seeking to char- network. Sockets require client and server to acterize middleware suggest that it is the software engage in application-level protocols to encode that facilitates remote database access and systems and decode messages. Designing such protocols transactions. More recently, the term has come is cumbersome and can be prone to error. to be associated—somewhat Middleware is basically an alternative to sock- Middleware lets limitingly—with distributed ets; it abstracts the communication interface to platforms like the Open the level of method invocations. Instead of work- you manage the Software Foundation’s Dis- ing directly with sockets, you call a method— complexity and tributed Computing Environ- rather, you have the illusion of calling a ment (DCE) and the Object method—on a local object.The arguments of the heterogeneity of Management Group’s Com- call are in fact packaged up by your middleware mon Object Request Broker and shipped off to the call’s remote target. In this distributed- Architecture (CORBA). And case, as in others, middleware provides the isolat- computing some have loosely applied it ing layer of software that shields you from the to systems as diverse as work- complexities of a heterogeneous environment. environments. flow support environments Here’s an and even to the Web itself. MIDDLEWARE FOR THE MASSES We believe the essential Several distributed object platforms have re- overview of the role of middleware is to man- cently become quite popular. These platforms middleware age the complexity and het- extend earlier distributed systems technologies— erogeneity of distributed like the Open Group’s DCE, Sun’s remote pro- world. infrastructures and thereby cedure call (RPC) interface, and Novell’s provide a simpler program- ming environment for dis- tributed-application developers. It is therefore Inside most useful to define middleware as any software layer that is placed above the distributed system’s A Technical Look at infrastructure—the network OS and APIs—and below the application layer. CORBA in Action In the distributed-computing model, your enter- Middleware Market Will Grow prise moves applications and data to where they can operate most efficiently: to desktop worksta- A Glossary of tions and to LAN, Web, or remote servers. But Middleware Terms dealing with the different protocols and interfaces 22 IT Pro September ❘ October 1999 1520-9202/99/$10.00 © 1999 IEEE NetWare—that weren’t object based. The characteristics of the new platforms include A Technical Look at CORBA in Action • masking heterogeneity in the underlying infrastructure by cloaking system specifics; We can best see how CORBA operates by exam- • permitting heterogeneity at the application level by ining the sequence of actions that take place when a allowing the various components of the distributed client application invokes a method in a remote application to be written in any suitable language; object.The sequence of actions begins when • providing structure for distributed components the client application somehow obtains an by adopting object-oriented principles; Interoperable Object Reference (IOR)— • offering invisible, behind-the-scenes distribution perhaps from a name server or as the return as well as the ability to know what’s happening value of a previous remote invocation. The behind the scenes; and client binds to this IOR and, as a result, is • providing general-purpose distributed services given access to a stub—a small software rou- that aid application development and deploy- tine—through which it can invoke the remote ment. object associated with the IOR. The client application sees the stubs as Prime examples of such platforms include OMG’s proxies for remote objects. In other words, CORBA, Microsoft’s Distributed Component they have a language-specific interface that Object Model (DCOM), and Sun’s Java remote corresponds to the IDL from which they were method invocation (RMI) system. generated. The function of stubs is to map— the term in CORBA is marshal—the argu- OMG’s CORBA ments and return values of method calls into Of the three major middleware technologies, CORBA and out of communications buffers, which can be sent is the most comprehensive in scope, largely because OMG across the network by the Generic InterORB Proto- explicitly addresses both the general- and vertical-market col (GIOP). aspects of middleware’s potential uses. Simply stated, On the server side, the implementer of an IDL pro- CORBA allows applications to communicate with one vides a language-specific implementation of the inter- another no matter where they are located or who designed face and registers instances of this implementation them. with the ORB so that their presence can be adver- The Object Request Broker (ORB) is the CORBA mid- tised. A standard interface—called the Portable dleware that establishes the client-server relationships. Object Adapter (POA)—provides object imple- Using an ORB, a client can transparently invoke a method mentations with a standard environment. on a server object, which can be on the same machine or The server implementation is interfaced to the across a network. The ORB intercepts the call and is underlying ORB by skeletons in much the same way responsible for finding an object that can implement the as clients are interfaced to the ORB by stubs.That is, request.The client does not have to be aware of where the skeletons are responsible for unmarshalling requests, object is located, what language it’s written in, or what OS passing the resulting arguments to the target object it uses. By intercepting these requests, ORBs can provide implementation and marshalling any results into interoperability between applications on different ma- GIOP reply messages. chines in heterogeneous distributed environments and can This description assumes that applications have seamlessly connect multiple object systems. their stubs and skeletons prelinked with their exe- In fielding typical client-server applications, developers cutables, which is the usual implementation provided use their own design or a recognized standard to define by most ORBs. There is, however, an alternative in the protocol to be used between devices. How they define the shape of dynamic invocation and dynamic skele- the protocol depends on the implementation language, ton interfaces. network transport, and a dozen other factors. ORBs sim- Dynamic interfaces are useful for applications such plify this process. With an ORB, the protocol is defined as browsers and databases in which it would be impos- through the application interfaces via a single implemen- sible to link all possible stub and skeleton classes stat- tation of a language-independent specification called the ically. The downside of this feature is that each Interface Definition Language (IDL). (See the sidebar “A invocation must be preceded by long and laborious Technical Look at CORBA in Action.”) sequences of code that are required to build the ORBs let you choose the most appropriate operating appropriate request. system, execution environment, and even language to use for each component under construction. And they allow September ❘ October 1999 IT Pro 23 DISTRIBUTED COMPUTING from the client and forwarding them Figure 1. OMG’s Object Management to the component in another process. Functionally and technologically, Architecture (OMA) reference model, in DCOM is similar to CORBA. For which CORBA figures prominently as example, both define an IDL and both ORB implementations. provide support services such as per- sistence,security,and transactions.But there are significant differences, the Application Domain Common foremost of which is that CORBA is an interfaces interfaces facilities open specification,while DCOM is not. Being a closed specification main- tained by only one company has one major advantage: DCOM has the ORB potential to evolve at a much faster rate than CORBA because there are no time-consuming politics involved in generating the next version of the Object services specification. But having many inter- ested parties working on CORBA Object services are domain-independent interfaces used by distrib- means it can be deployed far more uted-object applications. For example, a naming service would allow widely than DCOM. clients to find objects based on names. Currently, CORBA runs in most Application interfaces are developed specifically for a given applica- current OS environments, while tion. Because they are application-specific, and because OMG does not DCOM is deployed almost exclusively develop applications, these interfaces are not standardized. in the Windows environment. Fur- Domain interfaces play roles similar to object services and common thermore, porting DCOM to a wider facilities but are oriented toward specific application domains. One of range of environments is problematic the first domain interfaces was for the manufacturing industry. precisely due to the fact that there is Common