(Figure 1)
651N: Lan Lab using Novell Netware, Fall 1997
Sriram Chandramouli / sriram@gl.umbc.edu
Table of Contents
Distributed computing environment (DCE) and Common object request broker architecture (CORBA) support construction and distribution of client-server applications across distributed environments regardless of the computing environment. The intent of this paper is to provide the main features of DCE and CORBA concerning its maturity in specification, capabilities, and how it satisfies the organization distributive computing goals. The paper also focuses on the future scope that is yet to be exploited by these competing standards in the distributed realm. Ongoing projects in the computing industry utilize the distributed services of these technologies for mission critical applications. These are highlighted towards the later part of the paper to evaluate the kind of future they promise.
Open software foundation (OSF) DCE and Object management group (OMG) CORBA support construction and distribution of client-server applications across distributed environments, regardless of the computing environment. Both the standards define interfaces to objects (both remote and local), through a contractual interface called the Interface definition language (IDL). While DCE-IDL is based upon the C programming language, CORBA-IDL is based upon the C++ programming language. The latter provides seamless integration of distributed objects towards Object oriented (OO) architecture. By following an OO paradigm, an organization can achieve software reuse, maintainability of code, extendibility of functionality (to accommodate future needs), etc. The interface defined through IDL is compiled to produce client stubs and server skeletons used for establishing the underlying messaging architecture, between a remote client, and a server implementing the interface.
The transmission of service requests and responses between clients and servers are handled transparently by DCE runtime and the CORBA runtime (the Object request broker, ORB). This enables the client applications be least bothered about where the object is located (location transparency), the programming language used to implement the object (language independence), Operating system (OS) -- the client and the server application runs, and the networking protocols used for establishing the communication.
According to Tom Provost, manager of communication systems and services from Schlumberger, DCE seems to be the most powerful technology that can be utilized in critical areas of computing like security, distributed objects and Intranet/Internet computing. CORBA offers some unique services that address issues like security, location transparency through Naming and trading server’s etc. The specification seems to be pretty much stable, as it has been championed by companies like Sun, Oracle, Netscape and IBM. These corporations seem to have recognized the common problems while developing n-tier applications -- hence, a CORBA stereotype. I would like to present this paper with a little bit of bias towards CORBA, as I seem to have understood their specification a little more clearly than DCE.
According to Brado from Mitre Org., DCE supports integration and construction of C-based client-server applications in heterogeneous distributive environments. The underlying network protocol used by the clients and server becomes Remote procedure calls (RPC) that operate over the native OS. The DCE core insulates the clients requesting remote services, the details about the location of remote servers, the OS over which they execute, the network protocol used in communication and the data representations between the client and the server platforms. A variety of services like directory services, time services, security services, etc., operate over the DCE core that provides administrative functions, synchronization of clocks across hosts and authentication/authorization of clients requesting services.
DCE security specification uses the concept of authentication (by authenticator, ator) and authorization (by authorizer, azor). Azor allows a specific client to bind to a remote server using access control lists (ACL, typically a user-id and a password). Ator, on the other hand, assures message integrity and user identification. While azor verifies the legitimacy of clients requesting services, ator verifies the validity of those requested services.
DCE also supports threading within clients requesting services. Such thread based client paradigm introduces an additional burden in the server to handle requests concurrently. Hence, an event based messaging architecture is set up between clients and remote servers to request or reply, requests or services in an asynchronous fashion.
DCE also supports the notion of extended file services where it implements distributed file services (DFS). DFS supports distribution of a logical file system across machine boundaries. DFS not only supports location transparency of files, but also provides fault tolerant capabilities by distributing them across networks.
CORBA is an architecture for creating distributed Object oriented framework. This is achieved through an Object request broker (ORB), that allows developers to define objects that can be accessed across the network through clearly defined, high level interfaces. These interfaces are defined through IDL, that abstract the underlying programming language, Operating system, network protocols and the implementation language.
Due to the maturity of this technology, and the benefits that big corporate reap out of it, there has been an enormous number of ORB vendors in the market like IONA, Visigenic, Expersoft, Hewlett Packard (HP), Sun, etc. (to name a few.) The management is eventually is in a dilemma, to select the appropriate ORB to support its business objectives. There are growing concerns in the market with respect to the interoperability among Orb’s, should they wish to utilize the services of a free domain object. Porting a huge project across a different ORB also seems to be a daunting task. These concerns were greatly alleviated by the OMG, by defining an underlying protocol called Internet Inter-Orb protocol (IIOP) -- the de facto protocol for communication across ORB boundaries. IIOP is also the protocol used for communicating between objects that a proprietary ORB launches. With the advent of CORBA 2.0 specifications, the OMG dictates an encoding format for every object as a string, known as Inter operable reference (IOR). IOR defines the interoperability across Orb’s, by stringifying an object reference they launch. Access to this remote object can be obtained by destringifying this remote operable reference.
JAVA, Sun Microsystems’s new Object-oriented programming language, offers significant help to CORBA through its ability to "write-once, run-everywhere." JAVA applets that reside on web servers, extend the capability to execute over variety of web browsers, through the JAVA virtual machine (JVM), a browser embeds. Subsequently, CORBA objects can be downloaded as JAVA applets, and interoperate with variety of servers that define well-defined services. Applets (CORBA clients) communicate with remote servers inside a firewall through a technique called http tunneling and wonderwall. This additional layer is necessary, as firewalls open up only well defined port for http, smtp, etc. to flow through. The wonderwall sits on top of a firewall and opens up a unique port for IIOP traffic to flow through. Gatekeeper packet IIOP inside http, and requires server side functionality to decode the IIOP packets. It is beyond the scope of this paper to discuss such details at a greater length, and the reader is encouraged to look at IONA’s Wonderwall, and Visigenic Gatekeeper for a thorough explanation.
CORBA also offers variety of services that are essential for implementing objects. This paper provides a cursory overview regarding these services, and the reader is encouraged to look at OMG’s web-site for a detailed specification on these services.
1) CORBA Naming Service (COSS Naming), is analogous to white pages in a telephone directory, where client applications can look up objects offering specific services (servers) through their names. Naming context are set up similar to DNS, and objects are assigned within a particular object. This prevents object implementation having the same name across the Internet.
2) CORBA Trading services (COSS Trading), are similar to yellow pages in a telephone directory, where client applications can look up objects offering specific services through categories. The system administrators of local site administer federated traders.
3) A Concurrency control service protects the integrity of the object data, when multiple requests to an object are processed simultaneously.
4) An Event service introduces the notion of consumers and suppliers through a push-pull mechanism. Accordingly, suppliers automatically notify consumer who expresses interest in specific events on the channel, when such an event pops up in the channel.
5) Life cycle services support creating, moving, copying and destroying objects.
6) A persistent object service support persisting an object's state beyond the transient process that created the object in the first place. This is typically achieved by storing the object and the related object's state in an Object oriented database management systems (OODBMS), or flattening the state information into relational tables.
Even though there are variety of services offered by OMG, only few services are provided by vendors confirming to OMG’s specification. OMG is currently in the process of ratifying the CORBA 3.0 specification that supports the Portable object adapter (POA), replacing the current Basic object adapter (BOA). BOA is an ORB adapter that glues an object implementation to the proprietary ORB. Activation of objects and location of objects was primarily done through BOA. BOA suffers a major limitation concerning interoperability, as they have full control over the objects that a proprietary ORB launches. With the advent of POA, the objects can freely interoperate over a variety of ORB’s through a well-defined application-programming interface (API). Also, CORBA facilities are in the process of being ratified by the OMG that are useful for constructing applications across a wide range of application domains. They are typically more user oriented and some of them support specific application domains.
High Level Architectures of DCE and CORBA:
Figure 1 shows a conceptual framework of the CORBA architecture.
(Figure 1)
This represents the conceptual framework of an ORB. It can be seen that a client can request object services hosted by an ORB through an IDL interface or a Dynamic invocation interface (DII) offered by the ORB. DII gives an additional facility to an application programmer, to query the run-time repository for interfaces and methods defined using an IDL, and select an appropriate object offering the right kind of services. On the other hand, static client stubs require an application programmer to compile the requests for remote services before an invocation can be made. An Object adapter at the server end acts as a native bridge to integrate the ORB and the Object Implementation. The Object adapter also dictates invocation policies of the remote objects.
Figure 2 shows how a request trickles down from a client end to a remote server offering the services.
(Figure 2)
Figure 3 shows the DCE prototype at a conceptual level.
(Figure 3)
This shows how a request from a JAVA applet gets through to the
remote DCE server that renders remote services to the requested applet.
Applets are loaded from a web-server that is capable of servicing
http requests from remote web clients. The request for the remote services
is embedded within a JAVA Applet and loaded through a web server. Middleware
software (similar to gatekeeper/http tunneling) sits on top of the web
server and intercepts the http traffic for DCE requests. On receiving a
remote request, the Middleware routes it to the appropriate DCE server
for further action.
Differences between DCE and CORBA:
The fundamental difference between DCE and CORBA relates to the software engineering paradigm used to develop or deploy distributed applications across the Internet. While DCE relies primarily on a functional paradigm, CORBA relies on Object oriented paradigm. Object orientation scores over its functional counterpart in its ability to;
1) Encapsulate data and define contractual interface to the external world to manipulate the data. This prevents objects in explicitly interfering or changing the object's state.
2) Abstraction of common features into classes that generalize the methods or data shared across all its subtypes.
3) Inheritance of interfaces (interface inheritance -- defining an abstract picture), and implementation (defining a concrete generalization), to provide software reuse. According to Martin Gross from HP, large-scale reuse and a systematic change roadmap are of tremendous help in systematically and effectively dealing with a forced march towards a rapidly decreasing market time.
Beyond these CORBA supports late-binding of operation invocations, that allows clients to interoperate without regard to the type of objects they manipulate. CORBA also allows clients to inspect the interface repository at run-time for operations supported by server objects, and to invoke them without regards to their types at compile time.
DCE does not support abstraction or inheritance, but allows encapsulation in a very loose way. It partitions the data and interface that manipulates them across multiple servers, and distributes them across multiple hosts. However, such approach does not prevent the data in getting directly accessed by the clients.
DCE can select the servers at run-time for specific services, but the interface defined by them has to be fixed during compile time. The DCE core also generates a Universally unique identifier (UUID) for the resources it manages, and client’s request these services by specifying an UUID. This is valid across operating system, network operating system and hardware boundaries.
CORBA run-time (ORB), provides a richer set of object invocation mechanism through the BOA. These can be the following;
1) Shared activation mode -- a server process is launched for possibly many client processes.
2) Unshared activation mode -- a server process is launched for every client invocation.
3) Server per method -- a server process is launched for every method invoked on the server.
Individual capabilities of DCE and CORBA:
CORBA supports data type called octet that is extremely useful for transferring binary data across networks. Since CORBA clients and servers can reside on any ORB, the octet data type is not mangled during data transmission, as mangled binary data could lose its integrity. However, there is no corresponding data type in DCE to transfer binary data.
DCE streamlines data processing on the server side by allowing larger chunks of data to be partitioned into smaller blocks. A similar effect can be obtained in CORBA by defining a larger number of operations that might clutter an object contractual interface.
DCE supports context that is useful for maintaining or representing the Server State. When an operation is invoked, the context can be passed back and forth between clients and the servers, which would enable clients to evaluate the Server State before issuing a request. CORBA offers a similar facility, but are geared more towards carrying user or client preferences to the server objects. This may overwhelm servers with client requests.
DCE core performs transparent marshaling of data types represented by pointers, by marshaling the value addressed by the pointers in the client address space, and resurrecting the pointers back at the server end. CORBA-IDL does not support pointer data types, and it is the user responsibility to manage the data addressed by the pointers.
CORBA supports ‘any’ data type that allows clients and servers to compile IDL stubs and skeletons without knowing the run-time data type of the value that were being passed to methods. A typecode object is queried to determine the run-time data type of any.
DCE IDL does not support interface inheritance. OMG IDL data type (user-defined) can be extended for greater reusability. This results in an interface repository being created and maintained by the ORB, for clients to query them and select an appropriate method to execute.
Bootstrapping the server is essential to DCE. CORBA’s BOA permits automatic launching of servers in different modes to client invocations.
Finally, CORBA offers a much richer set of services than DCE providing the developer a much richer set of capabilities to build.
Conformant products and real life implementations:
OMG defines only the skeleton interfaces that all conformant ORB’s should support. This results in the nitty-gritty of the ORB core under-specified, thereby allowing vendors to come up with proprietary solutions. Hence, interoperability becomes the key issue among conformant ORB’s. On the other hand, DCE specifications are a whole lot functionally complete, leaving vendors little or no leeway towards introducing proprietary solution. CORBA 2.0 addresses these interoperability issues. With the advent of 3.0 specification, POA defines the interoperability among conformant ORB’s. Some of the leading CORBA vendors in the market are;
1) IONA's Orbix
5) HP ORBPlus etc.
JAVA promotes clients (in the ORB world) to be downloaded as applets, which in-turn talks to a remote CORBA server, that may run on the same or different box as the web server. Since this achieves the goal of OMG by allowing ORB objects to be location transparent, the binding of contractual interface to JAVA can have a significant impact on their interoperability. If JAVA mappings across compliant ORB’s are not the same, then applets will have a tough time in trying to seamlessly integrate with a remote CORBA server. This is due to the fact that ORB core sets up the remote protocols through the clients and the servers through IDL generated stubs and skeletons. With the adoption of a standardized JAVA language binding (released as of today), this issue has been solved.
Following these hyper-links, one can see some of the real life implementations of CORBA;
It has been established that DCE and CORBA primarily differ only in their programming paradigms; DCE supporting procedural and CORBA supporting an Object oriented paradigm. The benefits in deploying Object oriented architecture far outweighs its procedural counterpart. Several papers, journals, projects etc. have continuously demonstrated this undeniable fact to the management. If a business chooses to deploy DCE as their underlying distributed framework, they can be well off in deploying Object oriented DCE (OODCE) like Hewlett Packard OODCE or DEC’s DCE++. This will enable smoother transition to CORBA in the near future.
CORBA is becoming a commonplace these days, as OMG is perpetually refining its CORBA specification to accommodate future business needs. Javasoft Remote method invocation (RMI) specification (once believed to challenge CORBA), cannot achieve language independence as it provides a distributed framework only over Java objects. With the latest press release, announcing distributed RMI JAVA objects interoperating over IIOP (CORBA’s default protocol), one could see a tighter coupling between these technologies in future.