Directions for Web Computing

Giuseppe Attardi

Dipartimento di Informatica

attardi@di.unipi.it

1        Introduction

Web computing involves the definition of a suitable object model. We survey some current proposals, including WebBroker, Infospheres and Jini. We also discuss the issue of object communication protocols, in particular CORBA IIOP, Jini RMI, HTTP-ng.

This memo collects the results of the discussion after the seminars by Stefano Sanna, Tito Flagella and Giuseppe Attardi, held in July 1999 at CRS4.

2       Distributed Object Models

2.2          WebBroker

While CORBA uses its own protocols for object communication, in particular IIOP, which is based on TCP, WebBroker is based on the standard Web native standards: HTTP, XML, URI.

WebBroker tries to solve the architecture incompatibilities that separate CORBA and COM.

WebBroker uses XML for:

·         marshalling of parameters in method invocation

·         description of object types in interfaces.

The WebBroker architecture is interface-based and allows objects to call objects in separate machine transparently, according to the following model:

·         a proxy is present on machine X

·         a skeleton is present on machine Y

·         proxy and skeleton appear at ends of virtual connection

·         B's proxy has the same interface as object B

·        proxy and skeleton do the work of moving the request and response over the network as XML documents

Block diagram of two objects, a proxy, and a skeleton

Figure 1 WebBroker architecture

Interface-based communication + axiomatic set of primitive data-types and their representation on the wire, allows objects to communicate in a language independent fashion. Suitable DTD’s are used for:

·         defining the message contents

·        describing the interfaces

For instance, here is an example of a DTD for defining the syntax of IDL-like interfaces, consisting of an interface name and a series of methods:

 

<!ELEMENT interface(interfaceName, methods)>

<!ELEMENT methods (methodDef*)>

<!ELEMENT methodDef (returnType, methodName, parameters?, throws?)>

2.2.1           Transport

For the transport of data on the wire, WebBroker uses only HTTP. WebBroker introduces a notification mechanism based on client-side HTTP listeners (no SNMP).

WebBroker extends HTTP with a new INVOKE method, maintaining though the stateless nature of the protocol. Stateful services can be built on top of HTTP.

The only addressing mechanism is URI (in particular urn:UUID for use with CORBA/COM).

WebBroker uses XML syntax.

2.2.2           Serialization

CORBA/COM send data unnamed on wire, assuming that sender and receiver know what to expect. WebBroker introduces a coding for anonymous data, capable of expressing any sequence of data-types. It uses data-types defined in XML-Data and provides a DTD for primitive data-typed and arrays. For instance, arrays appear as follows:

<intArray length=“2”> <int>123</int><int>0</int></intArray>

The notation is quite verbose but the proposers claim that a more compact notation would be of marginal benefit.

2.2.3           Interface Definitions

The InterfaceDef DTD (and the related DTDs ModuleDef, ExceptionDef, TypeDef) are used to define the software component interface and the messages which can pass between them.

InterfaceDef are similar to MS TypeLibs, i.e. they consist of a collection of related type definition documents.

For client simplicity, WebBroker allows method parameters to only be marshaled in. The effect of out parameters is achieved by returning a struct.

2.3          Infospheres

The Infospheres project at Caltech is a “research on compositional ways of obtaining high confidence in dynamically-reconfigurable scalable distributed systems.” The project has produced a prototype system in Java, used for some student experiments, but very little technical information is provided about its architecture. A few applications have been built (a distributed calendar, and a game of poker) in ashort time, proving the effectiveness of the tool. The project team seems to have a background and an orientation on parallel processing. Most of the project papers discuss the long-term goals of the project, which aims at building a framework consisting of:

·         Processes

·         Personal networks

·         Sessions

·         Tasks (fluid, adaptive)

Personal networks are an intriguing idea: they specify processes arranged in a topology, with a specified cooperative behavior. For instance, a person in Nevada may have a emergency notification personal network that incorporates processes for medical monitoring devices in her parents home in Florida, security systems in her home in Reno, a Nasdaq stock ticker tape, etc.

The project also aims at studying collaboration patterns between people.

Unfortunately very little detail is provided about their distributed object model.

2.4          HTTP-ng

HTTP-ng is proposing a new architecture for the Web infrastructure for evolving HTTP onto a generic distributed object system analogous to CORBA, DCOM, and Java RMI. The work on HTTP-ng concentrates on the definition of two new layer of protocols, WebMux and W3ng Messaging Layer, as a foundation for Web applications. In particular WebMux addresses the issue of developing a multiplexing protocol able to deliver multiplexed bi-directional ordered message streams over a bi-directional reliable ordered byte stream protocol (such as TCP).

The HTTP-ng Architectural Model defines a simple model for HTTP-ng, based on true classes (on the server) and surrogate classes (on the client). The MUX layer would provide multiple connections over a single TCP connection, for callbacks and message-marking. An RPC layer will provide a simple object-oriented method invocation protocol, providing also a distributed garbage-collection facility. HTTP-ng provides a type system for object types.

2.5          JINI

JINI is an infrastructure that enables spontaneous networking and simplifies the access and delivery of network services. More details are provided in the appendix: here we just summarize how communication is setup in a Jini network.

Figure 2 Discovery.

Figure 3 Join.

Figure 4 Lookup.

Figure 5 Service Invocation.

Communication with the lookup service is based on RMI. The Service Object is a Java object that requires a JVM on the client or at least the ability to talk to a proxy providing such facility. The communication between the Service Object and its service could be in any protocol.

Jini is usually presented as a mechanism allowing to access devices directly from the network, rather than hooking them to a computer through a physical port and a device driver. There is a hot debate about the real significance of this approach: in practice a computer which exports disks and peripherals acts in part as a lookup service, except for the auto discovery and the downloading of the driver; the computer also remains an intermediary in all communications between client and service.

3       COM

COM consists of classes and servers. A COM class is a body of source code that implements COM interfaces. It provides real functions in any supported programming language for each interface method it supports. Each COM class has a unique identifier (CLSID). A client asks COM to create an object and return interface pointer. Client applications interact with COM objects through interface pointers. A client is not dependent on implementation details of COM

COM servers can be either:

·         in-process server: DLL loaded into client process calls go directly to object created in the client's process

·         out-of-process server: separate executable, either on same machine as a client or on remote machine; calls go first to an in-process proxy which uses RPC; in the server, stub object receives each incoming call and dispatches to appropriate COM object

ActiveX controls are in-process COM server objects.

The creation of an object entails: finding the server, loading its DLL or launching its EXE, retrieve the Class Factory and ask the Factory to create the object.

The relation between Interfaces, Classes and Factories is illustrated in the following figure.

 

3.1           Other Object Models

W3C is working on an object model within the group XML-schema.

Planet 7 Technologies proposes XML application Server.

Toshiba Bee-gent (http://www2.toshiba.co.jp/beegent) is a development framework, which is a 100% pure agent system. Bee-gent completely "Agentifies" the communication that takes place between software applications. The applications become agents, and all messages are carried by agents.
In JINI, the services are mainly for hardware currently. On the other hand, the ACL (Agent Communication Language) is a conversation language for problem solving by cooperation of agents that are system components, and can be used as a way of using software services available on each occasion or even using unknown software services.

Microsoft Millennium (http://www.research.microsoft.com/sn/Millennium) is considered as an alternative to Jini. Just as Windows runs one computer, Millennium would run a whole network, telling one computer to store the data and the next two or three to run different parts of the program, and so on. This way, a huge network, conceivably as big as the entire Internet, could function as an extension of the computer at the user's desk. The details of how the system works would be invisible to the user, just as you can't see the operating system reading the hard drive, but the jump in s  peed and capacity would be hard to miss. Millennium is currently working on projects: cojgn (www.research.microsoft.com/sn/Millennium/coign.htm), to automatically split applications into client/server and continuum (www.research.microsoft.com/sn/Millennium/continuum.htm), to distribute the Windows API to create a single system image across multiple computers.

CORBA has produced a new version 3.0, which includes mechanisms for transactions and persistence of objects. There is also a proposal for a minimumCORBA (www.omg.org/cgi-bin/doc?orbos/98-08-04.pdf), with reduced functionality and footprint for use in embedded systems. MinimumCORBA supports the full IDL, but removes features like dynamic invocation and skeleton interfaces, dynamic Any, Interface Repository, Construction Policy, most of the Portable Object Adaptor, Interceptors. A minimumCORBA implementation (like the one in TAO, www.cs.wustl.edu/~schmidt/TAO.html) reduces the size by 25% (from 860KB to 640 KB).

Some disappointment on the complexity of CORBA has been manifested by users and in particular about the complexity of the mapping to languages like C++. People working on MICO (mico-devel@vsb.informatik.uni-frankfurt.de) are suggesting to work on a new C++ mapping based on easy-to-port wrappers, to be developed as open source and submitted later to OMG.

4       Discussion

Both WebBroker and HTTP-ng address the issue of a Web object model at the protocol level, by extending or revising HTTP. We believe that the issue of protocols is an orthogonal issue and the design of the Object Model can assume the availability of a suitable such protocol.

In practical terms, it seems that RMI is not a proper choice, since it imposes a programming model tied to Java and requires the ability to migrate classes over the network. RMI itself has now been mapped to CORBA IIOP for several reasons, including the ability to cross firewalls: firewall proxies for IIOP are becoming widespread. IIOP is a more mature protocol than RMI. CORBA and IDL have been extended to include value types for allowing supporting RMI. Value types allow data to be copied in method invocations: this allows Java objects to be transferred over IIOP as required by RMI. More details on the issue of RMI versus IIOP are presented in an appendix.

One further reason to discard RMI is that RMI-IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces. If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible.

There are an increasingly large number of services built with CORBA to make interoperability with CORBA quite important, and similarly for COM.

Another issue is whether Jini is relevant as an infrastructure for Web computing. The major novelty in Jini appears in the fact that the proxy (Service Object) is downloaded dynamically on request, rather than having to be linked (either statically or dynamically) with the client application. Some people have argued that the dynamic downloading provides a mean to extend the communication protocols: even though the implementation of the protocol can change and each provider of a service may supply its own different implementation, the client must know the methods provided by the interface, or else it will be unable to use them. Therefore the protocol itself, as defined by the interface, does not change.

4.1           Component Framework

Objects can be composed into applications within a component framework: a component framework exploits the design interface of software objects to customize their properties, link them to other objects and compose and save the application. The architecture of a component framework establishes the guidelines for the design interface and composition of objects. CORBA does not provide a component framework. COM defines a component framework, which is implemented by any OLE/ActiveX container. JavaBeans is the component model for Java.

The design interface for objects can be implemented through a specific interface or through introspection. All COM objects must implement the IUnknown interface, through which one can retrieve the interfaces and methods supplied by the object. JavaBeans instead support introspection. 

4.2          Introspection

Introspection through reflection is a useful general mechanism since it automatically allows both exposing the interface of an object and providing necessary information for serialization.

4.3          Persistence

Persistence of objects can be achieved by supplying a specific serialization method produced by the developer tool for each class (as in MS DevStudio) or by a method derived by introspection by the Java compiler.

Persistence of an application built by composition can be achieved by a specific file format for multiple objects as in OLE, or by applying serialization of the composed object. Finally, if the composed application is expressed in a scripting language (JavaScript, VBScript, perl) persistence can be achieved by storing the script file. In particular for scripting languages embeddable in HTML, the HTML source just needs to be stored.

4.4          Embedding Context

An object needs to establish a relationship with its container to access its services and to participate in a nested hierarchy of containment.

5       Proposed Model

The object model we are proposing for Web computing should enable user to compose applications than run within Web browsers and interact with objects over the net. The composition should be possible with a simple editor, possibly a visual one. The remote objects could be implemented in different programming languages, as long as they support the interfaces and data serialization protocol of the model.

The model is interface-based. The interfaces will be based on IDL, extended with a simple template mechanism, like that of GJ. Suitable compilers for IDL will produce stubs for servers in the various languages and proxies in various languages including Java. We could start from the MICO IDL compiler, for which we already have some experience. Given certain simplifications in the IDL and CORBA, we could also provide a better and simpler binding for C++. The MICO IDL compiler has already been extended by M. Di Giorgio in Pisa to provide COM compatibility.

One particular simplification could be in providing a garbage collector to avoid all the hassles of reference counting and of smart pointers.

The model will provide an automatic download and link mechanism, so that a client can link to the service interface dynamically. Downloading the proxy code to the client requires either the ability by the server to supply native code for the platform of the client, or by platform independent code (like Java).

The simplest possible scenario at the moment is to use Java proxies and CORBA servers.

A visual component framework could be built by extending the Mozilla sources for Netscape Composer. A textual component framework instead is provided by a Web browser with JavaScript. Within this framework an application can access the services of a remote object, with a sequence of step like these:

 

interface Service { String getname();}

 

Service = Class.forName(“Service”, true, new URLLoader(“service.jar”));

x = new Service();

x.getname();

 

The code here defines the interface for the requested service (called Service), then loads dynamically the class Service from an URL, instantiates the class and then calls one of its methods (getname).

Notice that the interface itself is known by the client: in principle it also could be downloaded dynamically. Secondly, the class behaves like a factory: the new operator creates an instance of the class, which may be local or remote, depending on the class. Contrast this with CORBA, which only allows connecting to a remote service and does not provide an object creation interface. COM instead provides a factory pattern, since the server returns a factory object which supplies the method CoCreateInstance().

5.1           An Example

Consider an agent specializing in supporting risk management. It shows that such an agent would use its knowledge of risk assessment, its role in supporting this process and historical data to examine various data feeds in order to compose a risk exposure picture.

Inputs:

·         Market Data Feeds (Reuters, Dow Jones, …)

·         Proprietary Trading (Derivatives desks, …)

·         Counter Party Credit (Settlement Process, Credit Allocation, …)

Task Knowledge:

·         Risk Assessment

·         Organizational

·         Historical

Outputs:

·         Consolidate Instrument/Market Exposure

·         Consolidate Counter Party Exposure

·         Consolidated Capital Adequacy

A financial trader may create his own risk management support application, running within his Web browser, by connecting to the various services providing inputs, then filtering data with a filtering applet parametrized to his needs, sorting filtered data according to some precedence criteria, passing data to another service for consolidation and finally displaying the results through a grapher service.

The application could run on different machines even of different processing power, since the services can be accessed remotely. In an extreme case of a small portable device, even the grapher service could be performed remotely, sending to the PDA just the final graph image.

Appendix I Jini overview

JINI is an innovative initiative that enables spontaneous networking and simplifies the access and delivery of network services. Simply put, it is connect anything at anytime, anywhere. We look at the problem that JINI tries to solve, its architecture, assumptions, limitations, and its competitors in the market.

The Problem. Even though significant breakthroughs have been achieved in most aspects of computing – for example, the speed of computation, operating systems, storage capacity, and application software – the computing network has remained like an antique. This network over time has become more complex, more centralized, and more dependent on network administrators with limited or no flexibility to add, remove, or use existing or new network resources.

What is JINI and what does it bring in? JINI is a set of guidelines that enable a federation of Java Virtual Machines (JVM) to work together to make a more powerful network. The dream of the JINI system is to arrive at an architecture that can provide spontaneous networking, device-independent/location-independent networking, device sharing, simplification of network interactions, and reduction in the cost of ownership. In short, JINI brings to the network the facilities of distributed computing, network-based services, seamless expansion, reliable smart devices, and ease of administration.

JINI’s Assumptions/Limitations. The following environmental assumptions are made while architecting JINI:

1.       Existence of a network with at least 10 mbps speed with reasonable network latency.

2.       Each JINI-connected device has some memory and processing power. For devices without processing power or memory, a proxy exists that contains both processing power and memory.

3.       Each device is equipped with a JVM. 4. Service components are implemented using Java to facilitate the ability to dynamically download and run code. The above assumption does not mean that JINI is “Java language-centric;” it is “Java application-centric,” which means implementation can be done in any language as long as it has a compiler that produces Java-compliant bytecode.

JINI’s Architecture. The JINI system consists of three parts:

1.       an Infrastructure component, which enables building a JINI federation

2.       a programming model, which consists of a set of interfaces that enable the construction of reliable distributed services

3.       services, which are the living entities and the offered functionality within the federation.

Even though the system is categorized into three parts, the boundary between each part is blurred. In other words, all three parts collaborate with each other to achieve the system objective. The JINI system extends the Java application environment from a single VM to a network of VM. Thus JINI is more like an extended Java solution and utilizes most of the core Java technologies such as RMI, Java beans, and JTS while extending it to meet the distributed/network nature of the system.

Infrastructure Component. The Infrastructure components provide mechanisms for devices, services, and users to discover, join, and detach from the network. The above objective is achieved through:

·         a Discovery protocol (which defines the way a service becomes a part of federation)

·         extended RMI (the distributed structure that enables services to communicate)

·         distributed Security Model (which provides the concept of security within the network by introducing the concept of principal and an access control list for object interaction)

·         lookup service (which serves as a repository of services and help for members to find the services available on the network).

Services Component. The Services component represents an important concept within JINI architecture and it denotes the entities that could be used by any network citizens. The entity could be hardware such as a printer or video camera; or it could be storage, software, or another user. The services live as objects within the system. Each service has an interface, which defines the operations that can be requested of that service. The initial Java service consists of:

·         JavaSpaces (which acts as a storage space for the objects to live)

·         transaction manager (which enables a group of objects to participate in a transaction).

Programming Model Component. The programming model defines a set of interfaces, which enable the implementation of Infrastructure and Services components within the JINI system. The programming model supports the following interfaces:

1.       Lease Interface, which extends Java language by adding time to the notion of holding a reference

2.       Event-Notification Interface, which extends Java beans and Java event model of event-delegation

3.       Transaction Interface, which allows the system to handle object-oriented transaction handling.

How are These Components Linked? The Infrastructure component relies heavily on the programming model. For example, the Lookup service makes use of leasing and event interfaces; JavaSpaces utilizes leasing, event, and transaction interfaces. The Service component on the other hand is not required to implement the interfaces by itself, but is required for the interaction with the infrastructure. As most of the service component uses the lookup service, it therefore is indirectly bounded to the programming model.

JINI in Practice: Step-by-Step. The following steps describe the way the JINI works in practice:

Step 1: When a JINI-enabled device is plugged into the network, it drops a discovery packet on to the network, with a reference back to itself.

Step 2: JINI lookup listens on the well-known port for the discovery packet to return

Step 3: When the network is discovered, the device joins the network by uploading all its characteristics. In other words, a proxy for the service is loaded into the lookup service. The service is now available for any other client hooking onto the network using discovery and join protocol.

Step 4: The client, which needs a service, looks for the service on the lookup service based on its type (Java interface).

Step 5: Once the service is found, the client invokes the service, which involves moving the proxy code on to the client. Now the client can perform any operation on the service by supplying its attributes.

This movement of the code between the lookup service and the client gives the service provider greater freedom in the communication pattern and the integrity of the proxy code as the code is supplied to the lookup service by the service provider itself.

 

Is JINI a Lonely Player? Microsoft, AT&T, IBM and Lucent are working on their own research initiatives. Microsoft’s research initiative, dubbed “Millennium,” is described as a “new self-organizing, self-tuning, self-monitoring distributed system.” Microsoft is rumored to already have two working systems, one called “Coign,” which distributes conventionally written applications on the fly; the other called “Borg,” which creates a distributed version of the Java Virtual Machine. The other players – including Lucent with a project called “Infospheres,” Larry Ellison’s effort on “network computer scheme,” AT&T’s “GeoPlex,” IBM’s “TSpaces” and Linda’s “TupleSpace,” – are pursuing the same distributed computing dream.

 

Appendix II Object Communication protocols (D. CUrtis, Inprise)

When Java first met CORBA, the outcome proved advantageous for both communities. The OMG/ CORBA community pounced on Java as a cleaner, more tractable, and ultimately more cost-effective way to build many more CORBA applications than C++; it offered Java programmers a robust distributed object infrastructure that leveraged battle-tested investments in CORBA technology and a clean way to exploit non-Java legacy assets.

Simultaneously, RMI (Remote Method Invocation) was emerging as a way to build distributed object systems in pure, native Java. Architecturally, RMI is similar to CORBA: It makes remote invocations on objects through established interfaces, using automatically generated proxies and skeletons to manage the marshalling and communication transparently.

In other details, RMI is quite different: it uses Java's native type system to describe remote interfaces and their parameters, whereas CORBA uses a programming ­language-independent IDL (Interface Definition Language). A Java/RMI programmer identifies an interface intended for remote access by defining the interface as an extension of the appropriate remote base interface. Remote methods can take parameters of virtually any Java class (specifically, it must be serializable). In contrast, CORBA operations had a more limited palette of data types. Because it was inherently cross-language, any CORBA-defined data type must have had an equivalent representation in a variety of programming languages (including C++ and COBOL).

Although some level of competition was inevitable, both Sun and the OMG community (Sun being one of the founding and most active members of the OMG) understood implicitly that a three-way battle among DCOM, RMI and CORBA would certainly lead to mutual failure (or at best, a Pyrrhic victory). The real question was how do these technologies coexist and cooperate, and what role should each have in a combined solution?

5.2          Coexistence or Cooperation?

The simplistic answer was something along these lines: Use RMI when you're developing new Java distributed applications; use CORBA when you need to access existing non-Java applications. It may be pointed out that the amount of IT budget allocated for maintaining and integrating non-Java production systems was, and remains for the foreseeable future, many times larger than that spent on new development in any language.

In any event, this answer (being little more than a statement of the superficially obvious) was not satisfactory to a large number of IT customers who had already made a significant investment in CORBA technology, but who also badly wanted to do new development in Java. At the time, RMI had its own completely separate infrastructure, sharing essentially nothing with CORBA infrastructure. It had its own messaging protocol (JRMP), its own registry mechanism, and was developing its own set of services that were similar to, but not compatible with, existing CORBA services. Corporate IT organizations aren't particularly enthusiastic about being forced to maintain and support two gratuitously different infrastructures. A clear (and harshly worded) message was delivered to both communities: We want to program in Java, using both CORBA and RMI programming models where appropriate, but we don't want two infrastructures. Make that happen!

The result became known as "RMI over IIOP." Understanding what this really means hinges on understanding the relationship between distributed programming models and their underlying protocols. More specifically, how programming models and protocols are simultaneously independent of, and interdependent upon, each other.

5.3          Programming Models and Protocols

5.3.1           RMI Programming Model

RMI is a programming model. When a Java programmer writes an application that uses RMI, he has a certain set of techniques available for use, design decisions to make, and constraints to observe. As mentioned earlier, a remotely accessible interface must be specifically designed and built as one, extending a particular base interface, and observing certain constraints on method signatures.

For example, all methods must throw certain exceptions, and all parameters must be serializable. Most of the mechanical work is done by the Java compiler and the RMI post-processor, producing proxies and skeletons that automate binding to servers, marshalling requests, and managing communication. Implementing and using a remote object takes slightly more work than simply constructing a local object and invoking its methods. A client must obtain a reference to the object from the RMI registry or JNDI directory. The implementation class must perform some bookkeeping rituals, including registering instance references or publishing them in the directory. Both client and server must also be designed to accommodate the basic issues of distributed computing: 1) requests typically take milliseconds instead of microseconds; 2) there are a lot of news things that can go wrong over a wire, and 3) there is a great deal of uncertainty about what may or may not have happened on the other end of the wire.

5.3.2           CORBA Programming Model

CORBA also presents users with a stylized programming model (or perhaps, models, given the variations that exist across different language mappings). The designer/programmer defines distributed interfaces in a separate IDL. An IDL compiler generates proxies and skeletons (much like those generated by the RMI post-processor) in a particular programming language, according to standardized rules called language mappings, defined by the OMG.

Until recently, the data types usable as operation parameters were limited to the usual primitive types, plus a small set of constructed types such as structs, unions, arrays, and sequences. The details of the CORBA programming model are largely determined by the programming language being used for the application and the IDL mapping defined for that language.

5.4          Programming Model and Protocol Semantics

In general, programmers using RMI or CORBA are not directly aware of the underlying protocol being used to make remote requests. The whole point of an abstract distributed object model is to make low-level issues such as communications transparent to the programmer. This is particularly true of the underlying transport protocol; it's pretty obvious that an application using a high-level abstraction such as an ORB doesn't know or care whether the messages are being exchanged over TCP/IP or SPX, because the transport protocol's job is simply to move bytes.

But RMI and CORBA both define messaging protocols, called (respectively) JRMP and IIOP. In general, such messaging protocols are not as independent of the programming model as the transport layer. A messaging protocol necessarily embodies the semantics of the programming model it implements. For example, messaging protocols for distributed object systems specify how object references are used to locate and identify specific instances, directly reflecting (or in some cases, defining) the concept of object identity for the object model. These protocols must also support the information model inherent in requests and replies, including what parameter data types may be exchanged and how they are encoded, what kinds of exceptions may be returned, whether any implicit context (such as a thread-associated transaction context or principal identity) is transmitted with the request and how, and so on.

JRMP was designed to support RMI's semantics. Likewise, IIOP was designed to support CORBA's semantics. It is a non-trivial problem to efficiently support the semantics of one programming model with a messaging protocol designed for a different programming model. Besides mismatches in data typing systems (which are the most obvious problems), there may be some basic differences in request semantics. For example, a particular protocol may (or may not) support certain capabilities that indirectly surface in the programming model as, for example, quality-of-service features or the ability to participate in distributed transactions.

5.5          RMI and CORBA Semantic Differences

The biggest difference between RMI and CORBA, which manifests itself as differences between JRMP and IIOP, occurs in the types that can be used for remote operation parameters. CORBA has constrained itself to relatively simple types in order to remain consistent between languages and guarantee no loss of information when requests are made between different languages.

RMI, however, was under no such design constraint. It supports the ability to pass instances of arbitrary Java classes as parameters by value. This means that the remote request passes the complete state of the parameter object to the destination, where a new instance of the class is created with the same state in the local address space of the destination. The important difference is that the parameter embodies both state and behavior (in that the parameter object has methods that you can invoke).

At the time, CORBA operations could pass only pure state by value, in the form of structs, sequences, etc. CORBA and RMI operations can pass object parameters by reference, meaning that the object is not duplicated in the destination address space–the destination receives a handle for the object by which it can make remote invocations. This limitation in CORBA reflects its language-independent design. It isn't particularly meaningful to try to pass a Java object to a C++ or COBOL application.

5.5.1           IDL Value Types

In order to use IIOP as the messaging protocol for RMI programs, IIOP needed to support the semantics of RMI that did not at that time exist in CORBA, primarily the ability to pass objects by value. The OMG did precisely this, not by extending IIOP directly but by extending the basic CORBA typing system to include the ability to define value types (i.e., local programming objects) in IDL and pass them by value as parameters in requests. Value types were designed to express Java objects, but are not limited to that. Value types are language independent. At present, value type language mappings exist for Java and C++ and are being developed for other languages.

Using value types in non-Java languages poses some difficulties. Value types (such as class types in object-oriented programming languages) support inheritance and polymorphism, meaning that I can pass a parameter object whose actual type is more derived than the formal type declared in the operation signature. There is no guarantee that the destination of the request (or reply) knows what that type is or has the code that implements that type available locally. In Java programs, the destination can download the correct implementation on the fly. This is, for all practical purposes, impossible in programming languages that execute as native binary code. CORBA value types partially solve this problem by allowing derived value types to be truncated (i.e., the information that constituted the more derived type is thrown away) to a base type, at the discretion of the programmer. In cases where no implementation is available and the type can't be truncated, the request throws an exception.

5.6          RMI over IIOP: RMI/CORBA Unification

In the process of defining a new IDL type, the rest of the CORBA specification was updated to accommodate value types, including the IIOP specification. Consequently, IIOP version 1.2 (the version of IIOP included as part of CORBA 2.3) supports the semantics required for its use as a messaging protocol for RMI.

In theory, it would have been possible to define a mapping (i.e., a set of marshalling rules) from the RMI programming model to the new extended IIOP and stop there. It's a good thing that the OMG didn't do that, because the most valuable by-product of this entire exercise would have been lost. Instead of mapping RMI to IIOP, the OMG defined a mapping from Java RMI to IDL. This means that an RMI interface description can be converted into an equivalent IDL interface.

This has profound implications for users of these two technologies. It is now possible to take an application written in Java, using RMI, and add new clients written in some other language without changing any RMI interfaces.

Conversely, it is possible to take the same application and replace object implementations in the server environment with implementations written in other languages. To do this, you need an ORB product that supports the Java-to-IDL mapping. The product (usually in the form of a byte code post-processor) reads the class files that include the RMI remote interfaces and generates equivalent IDL. You can then process this IDL with your normal IDL compiler (assuming it supports value types and other CORBA 2.3 extensions), producing stubs and skeletons for the language of your choice. At runtime, RMI stubs marshal requests into IIOP messages on one end, and the IDL-generated skeleton in, for example, C++, unmarshals the request, instantiating value types from the parameters that were marshalled as Java objects. The non-Java program must have been built to include implementations of value types equivalent to the corresponding Java classes used as parameters.

In essence, the OMG did not just define a means to use IIOP as the protocol for RMI requests. Rather, they defined an interoperability solution for RMI and CORBA, making it possible for programs built with both technologies to communicate directly, without any "impedance mismatch."

5.7          Leveraging Industry Investment

CORBA, including IIOP, has been in widespread development and use for considerably longer that any other distributed object technology. CORBA implementations are available from a large number of vendors. Competition among vendors has led to improvements in IIOP implementations, which in turn have led to new capabilities being added to the CORBA specification itself, including new extensions to IIOP, including:

·         the definition of standards for managing IIOP connections through firewalls, including standards for IIOP proxies, tunnelling, and improved connections in firewall environments

·         a powerful, object-oriented distributed transaction model, including distributed two-phase commit, nested transactions, and integration with standard transactional resources through XA interfaces

·         support for asynchronous, time-independent requests, with the ability to select various qualities of service, such as store-and-forward delivery and specified time-to-live for messages

·         flexible, powerful security mechanisms for distributed authentication and encryption

Even more new capabilities are in progress, including:

·         standards for using the same message formats as IIOP (called GIOP) with new high-speed transports such as ATM, RUDP, and FireWire

·         standards for reliable, fault-tolerant systems using IIOP

·         using multicast transports with IIOP

5.7.1           Integrating with Heterogeneous Systems

Enterprise systems are inherently heterogeneous. Even if IT organizations make concerted efforts to standardize on technologies, they can only do so for limited periods of time. Eventually, even the most disciplined IT organizations accumulate a variety of technologies (operating systems, programming languages, networking technologies, etc.) that must work together. Because of its cross-platform, cross-language nature, CORBA has become the mechanism of choice for integrating disparate technologies.

5.7.2           Eliminating Risk

CORBA systems using IIOP have been deployed for some time in real enterprise systems. IIOP has undergone considerable revision and evolution since its invention, based on experience obtained in real system development and deployment. It has been, so to speak, battle hardened.

5.8          Summary

The integration of Java and CORBA technologies is a response to a strong demand from the user community. The approach taken to integrate RMI and IIOP has benefits that extend far beyond the scope of just the programming model and the protocol. Ultimately, the broad acceptance of Java and EJB is made more promising by the fact that it can exploit years of experience and investment in CORBA technology.