RECENT ADVANCES IN SYSTEMS, COMMUNICATIONS & COMPUTERS, Selected Papers from the WSEAS Conferences in Hangzhou, China, April 6-8, 2008 Analytical Comparison of Distributed Object Components USHA BATRA DEEPAK DAHIYA and SACHIN BHARDWAJ Department of CSE&IT, Institute of Technology and Management, Gurgaon 122017, India Abstract: - The Distributed object computing is a paradigm that allows objects to be distributed across a heterogeneous network, and allows each of the components to interoperate as a unified whole. This paper compares the layered architectures of various platforms such as COM/DCOM, RMI, CORBA, SOAP supporting distributed computing. While the fundamental structure of each is similar, there are differences that can profoundly impact an application developer or the administrator of a distributed simulation exercise. This paper compares the features of these distributed technologies and provides a more desirable support for distributed computing, as compared to rest of the object or component technologies. Key-Words: - COM, DCOM, RMI, CORBA, SOAP (Distributed Component Object Model) and COM+, the main standard in the world of object languages was C++. COM was designed as a runtime specification. COM provides the component technology for Microsoft Windows Distributed interNet Applications (Windows DNA) architecture, which enables developers to integrate Web-based and client-server applications in a single, unified architecture. Using COM, developers can create distributed components that are written in any language and that can interact over any network. The Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. Based on C++, COM is a complete specification at binary level and nothing prevents other languages from producing or calling COM objects. Developing COM components is fairly complicated. The web services require a protocol which supports characteristics that DCOM does not have, thus DCOM huge failure to be used on web. COM does not offer a suitable modern flexible infrastructure that supports business object system for web services type applications that require rich run time with a real garbage collector allowing object/ relational mapping. The Common Object Request Broker Architecture (CORBA) is a non-commercial venture, created at the beginning of the 90s by the Object Management Group (OMG), an imposing consortium of over 800 members. It is the oldest and perhaps the most mature architecture of its time. CORBA is an extremely large and complex collection of specifications and protocols, and in a brief paper 1 INTRODUCTION The Distributed object computing is a paradigm that allows objects to be distributed across a heterogeneous network, and allows each of the components to interoperate as a unified whole. The overall technical goal of distributed object computing is to advance distributed information technologies so that they may be more efficient and flexible, yet less complex. The benefits of distributed objects are indeed solutions to the problems with existing monolithic client / server paradigms. Web Services [1,2] present another alternative distributed computing infrastructure that is being promoted to the use of distributed object components such as RMI or CORBA and SOAP. Web Service implementations support different client-side application programmer interfaces; client code may work by constructing “call” objects that are dispatched to the server , or may use a higher level interface that hides the communication level entirely through the use of client-side stub objects with an operational interface that mimics that of servers. The client-stub approach results in code that is very much similar to Java-RMI, CORBA or SOAP clients. Each of these three architectures for distributed computing has a fundamental world view that affects the structure of its architecture. This paper compares the features of these three important technologies. 2 COMPONENT BASED DEVELOPMENT When Microsoft designed COM[3,4] (Component Object Model) , which serves as a basis for DCOM ISBN: 978-960-6766-61-9 254 ISSN: 1790-5117 RECENT ADVANCES IN SYSTEMS, COMMUNICATIONS & COMPUTERS, Selected Papers from the WSEAS Conferences in Hangzhou, China, April 6-8, 2008 such as this, we can only touch on its most salient features. CORBA 2.0 specifies that an object can have only one interface. However, for CORBA 3.0 there are proposals to support multiple interfaces as (shown in fig. 1), Attributes correspond to instance variables and are used to represent data. An operation corresponds to a method. A method is identified by a name, signature, and return type. IDL to Java compiler translates the IDL definitions for java interfaces(see figure 2). The rules for translation are called the java programming language binding. This language binding defines some standardization and CORBA vendors are required to use same mapping for IDL constructs to a particular programming language. 3 JAVA IDL AND CORBA The Common Object Request Broker Architecture (CORBA) is an emerging open distributed object computing infrastructure being standardized by the Object Management Group. CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshalling and demarshalling; and operation dispatching. Sun refers to CORBA as ‘Java IDL (Interface Reference Language)’, a language to describe the class interface. intf.idl The steps to implements CORBA object: • Write the interface using IDL to specify that how the object works. • Using the IDL complier for the target language, generate the needed stub • Implement the server object using the language of your choice. • Registering the server object using CORBA naming service similar to rmiregistry. • Write a client program that locate and invokes the server object. • Start the naming service and the server program on the server and start the client program. interface intf{String abc();}; Fig 2: Translation of IDL to Java Compiler IDL compiler also generates a number of other files and stub classes such as Interface definition, the interface that contains actual operations, CORBA specific interfaces, holder class for out parameter, stub class for communicating with ORB Now at the server side, we can code the program in C++ or in java that does the following: • Start the ORB • Create an object and register it with ORB so that a client can use it • Use the name server to bind the object to a name • Wait for invocation from a client At the client side, the program does the following: • Start the ORB • Locate the naming service by retrieving an initial reference to ‘NameService’ and narrowing it to a NamingContext reference. • Locate the object to call it’s method using resolve method of NamingContext. • Cast the returned object to the correct type and invoke your methods with the help of narrow() method. Interface Definition Language One of the essential features of CORBA[4,5,15,16] is that it sits at a high level of abstraction; for example, the various frameworks and services are specified not using a particular programming language, but via an IDL (Interface Definition Language). An IDL has four basic elements: modules, interfaces, operations and attributes. A module is a namespace that contains one or more interfaces. An interface is a collection of attributes and operations that correspond to an object. ISBN: 978-960-6766-61-9 idlj intf.idl(Java interface intf{string abc();} IDL Figure 1: Multiple Interfaces of CORBA 3.1 intf.java 255 ISSN: 1790-5117 RECENT ADVANCES IN SYSTEMS, COMMUNICATIONS & COMPUTERS, Selected Papers from the WSEAS Conferences in Hangzhou, China, April 6-8, 2008 4 REMOTE METHOD INVOCATION 4.1 RMI 3-Tire Layered Architecture Beginning with the Java Development Kit 1.1 (JDK1.1), the Java programming language has included Remote Method Invocation[6,7,15,16] as part of the standard Java libraries( Javasoft, 1997). RMI[3] allows client Java objects to invoke methods in server Java objects, no matter if they reside in the same JVM or even in the same host. RMI can be thought of as the object-oriented type of Remote Procedure Call (RPC). It is quite natural way of implementing distribution when all participants are written in Java, because no extra burden of additional communication protocols or handling of underlying connection mechanisms (like sockets) is needed in the distributed objects themselves but they can invoke the remote objects almost like local ones. Remote method invocation allows applications to call object methods located remotely, sharing resources and processing load across systems. Unlike other systems for remote execution which require that only simple data types or defined structures be passed to and from methods, RMI allows any Java object type to be used - even if the client or server has never encountered it before. RMI allows both client and server to dynamically load new object types as required. There are three processes that participate in supporting remote method invocation. The Client is the process that is invoking a method on a remote object. The Server is the process that owns the remote object. The remote object is an ordinary object in the address space of the server process. The Object Registry is a name server that relates objects with names. Objects are registered with the Object Registry. Once an object has been registered, one can use the Object Registry to obtain access to a remote object using the name of the object. There are two kinds of classes that can be used in Java RMI. A Remote class is one whose instances can be used remotely. An object of such a class can be referenced in two different ways: Within the address space where the object was constructed, the object is an ordinary object which can be used like any other object. Within other address spaces, the object can be referenced using an object handle. While there are limitations on how one can use an object handle compared to an object, for the most part one can use object handles in the same way as an ordinary object. For simplicity, an instance of a Remote class will be called a remote object. A Serializable class is one whose instances can be copied from one address space to another. ISBN: 978-960-6766-61-9 Client Server Stub Skeleton Remote Reference Layer Remote Reference Layer Transport Layer Transport Layer Figure 3: RMI 3-tire layered architecture To the programmer, the client appears to talk directly to the server. In reality, the client program talks only to a stub object that stands in for the real object on the remote system (as shown in figure 3). The stub passes that conversation along to the remote reference layer, which talks to the transport layer. The transport layer on the client passes the data across the Internet to the transport layer on the server. The server's transport layer then communicates with the server's remote reference layer, which talks to a piece of server software called the skeleton. The skeleton communicates with the server itself. (Servers written in Java 1.2 and later can omit the skeleton layer.) In the other direction (server-to-client), the flow is simply reversed. Logically, data flows horizontally (clientto-server and back), but the actual flow of data is vertical. The goal of RMI is to allow your program to pass arguments to and return values from methods without worrying about how those arguments and return values will move across the network. In reality, the client is only invoking local methods in a stub. The stub is a local object that implements the remote interfaces of the remote object; this means that the stub has methods matching the signatures of all the methods the remote object exports. In effect, the client thinks it is calling a method in the remote object, but it is really calling an equivalent method in the stub. Stubs are used in the client's virtual machine in place of the real objects and methods that live on the server; you may find it helpful to think of the stub as the remote object's surrogate on the client. When the client invokes a method, the stub passes the invocation to the remote reference layer. The remote reference layer carries out a specific remote reference protocol, which is independent of the specific client stubs and server skeletons. The 256 ISSN: 1790-5117 RECENT ADVANCES IN SYSTEMS, COMMUNICATIONS & COMPUTERS, Selected Papers from the WSEAS Conferences in Hangzhou, China, April 6-8, 2008 remote reference layer is responsible for understanding what a particular remote reference means. Sometimes the remote reference may refer to multiple virtual machines on multiple hosts. In other situations, the reference may refer to a single virtual machine on the local host or a virtual machine on a remote host. In essence, the remote reference layer translates the local reference to the stub into a remote reference to the object on the server, whatever the syntax or semantics of the remote reference may be. Then it passes the invocation to the transport layer. The transport layer sends the invocation across the Internet. On the server side, the transport layer listens for incoming connections. Upon receiving an invocation, the transport layer forwards it to the remote reference layer on the server. The remote reference layer converts the remote references sent by the client into references for the local virtual machine. Then it passes the request to the skeleton. The skeleton reads the arguments and passes the data to the server program, which makes the actual method call. If the method call returns a value, that value is sent down through the skeleton, remote reference, and transport layers on the server side, across the Internet and then up through the transport, remote reference, and stub layers on the client side. In Java 1.2 and later, the skeleton layer is omitted and the server talks directly to the remote reference layer. Otherwise, the protocol is the same. Since RMI is Java based, it may only interact with non-Java applications via. Java Native Interface (JNI). 5 SIMPLE PROTOCOL OBJECT description regarding data types in WSDL (xml schema) will be converted into java classes. JWSDP (Java Web Services Developer Pack) is freely available which contain the tools to convert the descriptor files into java class files.SOAP also works as CORBA or RMI i.e. the client program calls a local method on the proxy object and the proxy connects to the server to invoke the method. Of course this is all very well, but SOAP is still just an RPC, calling low-level functions and leaving pretty much everything to developers. In order to make it easier to use, there is a format for describing services that can be invoked by SOAP-WSDL. WSDL can be seen as a complement to SOAP, as it facilitates interoperability between web services. Like IDL (Interface Definition Language), which acts as a service describer with CORBA, WSDL (Web Service Development Language) is an XML syntax to describe web services. The specifications for WSDL come from a joint initiative by Microsoft, IBM and Ariba. 6 COMPARISONS There are a number of disparities between the various approaches to distributed objects and components. 6.1 ACCESS Simple Object Access Protocol also known as SOAP is a communication protocol. Communicating with SOAP can be viewed either as XML based remote procedure calls, or as a way of submitting XML documents to remote endpoints. These two different perspectives represent RPCcentric and message-centric. In Java RPC-centric model has become the primary model for SOAP APIs. The Java APIs representing the two different perspectives are JAXM[8] (Java API for XML messaging) and JAX-RPC[9] (Java API for XML based RPC) SOAP[10,11,12,13,15,16] is an XML protocol for invoking remote methods. Like IDL in CORBA, here WSDL (Web Service Description Language) provide the interface for the web service. The WSDL descriptor describes the service in a language-independent manner. The description can be easily converted into java for example: a ISBN: 978-960-6766-61-9 RMI vs. CORBA vs. SOAP This section will compare the relative features of RMI and CORBA[7] and SOAP [10,14] that might effect on selecting a specific distribution mechanism. CORBA and RMI take similar approaches to enabling distributed computing and have roughly analogous mechanisms for object interface language, object manager( for security) and naming service. Both CORBA and RMI use specific communication protocol for network transmission. RMI uses TCP/IP, the most common internet protocol, whereas CORBA uses Internet Inter-Orb Protocol(IIOP) that buildson TCP/IP. RMI being a Java based technology is essentially not cross language at all. Interoperability to nonJava programs must be done through JNI and has no common interface, as with CORBA. However, Java’s inherent cross-platform capabilities substantially increase the number of platforms on which distributed applications may run. An advantage of RMI over CORBA involves security. The RMISecurityManager ensures that no holistic code can have access to local resources. These are classes in JDK that implement encryption and digital signatures. 257 ISSN: 1790-5117 RECENT ADVANCES IN SYSTEMS, COMMUNICATIONS & COMPUTERS, Selected Papers from the WSEAS Conferences in Hangzhou, China, April 6-8, 2008 6.1.1 RMI Advantages • • • • • Portable across many platforms Can introduce new code to foreign JVMs Java developers may already have experience with RMI (available since JDK1.02) Existing systems may already use RMI - the cost and time to convert to a new technology may be prohibitive • • Disadvantages • • • • Tied only to platforms with Java support Security threats with remote code execution, and limitations on functionality enforced by security restrictions Learning curve for developers that have no RMI experience is comparable with CORBA Can only operate with Java systems - no support for legacy systems written in C++, Ada, Fortran, Cobol, and others (including future languages). 6.1.3 SOAP Advantages • • 6.1.2 CORBA Advantages • • • • • • Language neutral services can be executed on many different platforms, with an interface definition language (IDL) mapping. With IDL, the interface is clearly separated from implementation, and developers can create different implementations based on the same interface. CORBA supports primitive data types, and a wide range of data structures, as parameters CORBA is ideally suited to use with legacy systems CORBA is an easy way to link objects and systems together CORBA systems may offer greater performance • • • • • • • Implementing or using services require an IDL mapping to your required language writing one for a language that isn't supported would take a large amount of work. IDL to language mapping tools create code stubs based on the interface - some tools may not integrate new changes with existing code. ISBN: 978-960-6766-61-9 SOAP may have stronger support from the open source community (but CORBA is quite strong here too), and stronger support for recent programming languages that people will be using more now and in the near future. SOAP’s greatest advantage and disadvantage at the same time, is its lack of standard above it and below it. SOAP is as simple as the implementer of the middleware wants it to be. SOAP may be nasty and complex but flexible when using tool A, but very easy (though inflexible) when using tool B. The SOAP community has the possibility to happily construct some SOAP XML and send it out on the net, then listening for an answer. Using simple (and free!) script tools this can be easily done, so the barrier to use SOAP appears to be very low. Disadvantages Disadvantages • CORBA does not support the transfer of objects, or code.The future is uncertain - if CORBA fails to achieve sufficient adoption by industry, then CORBA implementations become the legacy systems. Some training is still required, and CORBA specifications are still in a state of flux. Not all classes of applications need realtime performance, and speed may be traded off against ease of use for pure Java systems. Elaborate coding required at a low level of abstraction Lack of interoperability, i.e. many competing SOAP implementations Saturation of firewall port 80 (HTTP) Lack of performance due to the requirement to parse and transport XML Lack of compile time type checking; harder debugging 7 CONCLUSIONS Now the question is, “what’s the bottom line?” Which technology is the best to use? DCOM, Java RMI, or CORBA[7,8] ?The answer to this question really depends on the needs and existing infrastructure. In fact, the listed technologies are not the only options. If the system will run completely on Windows machines, then DCOM might be a 258 ISSN: 1790-5117 RECENT ADVANCES IN SYSTEMS, COMMUNICATIONS & COMPUTERS, Selected Papers from the WSEAS Conferences in Hangzhou, China, April 6-8, 2008 good solution. If the system will run completely on Java machines, then Java RMI is an option. However, any heterogeneous system will probably work better with CORBA. While DCOM has good roots in COM, the network integration is still immature. In addition Windows NT servers with DCOM enabled are vulnerable to denial of service attacks because of a bug. Thus, any DCOM infrastructure must stay within a firewall. Assuming that in the future this bug does not exist, then DCOM as an infrastructure is a lot more feasible since it contains packet level encryption. Development tools for DCOM are the best out of all these technologies, and probably will be for a long time. This is because of Microsoft’s commitment to DCOM as well as its huge market share of compilers and desktop operating systems. However, DCOM support outside of Windows should be taken with a grain of salt, and tools on those platforms will definitely not be mature. In the long run, the hype about Web Services will diminish (as all hypes do), and CORBA and Web Services will both have their place. Just as CORBA and COM, and for that matter RMI, coexist. When necessary, bridges will be used to tie everything together. It looks like we’re going to use SOAP to talk to the outside world, and we’ll be using CORBA in the inside. In the short term, it will take a number of years for SOAP to mature, and the missing pieces to be defined. 8 http://www.techmetrix.com/trendmarkers/tmk0 101/tmk0101-4.php3. [2] W3C Organizations Web Services definitions, http://www.w3.org, 2008. [3] http://www.microsoft.com/com/default.mspx, 2008. [4] Philippe Mougin & Christophe Barriolade, Orchestra Networks. “Web Services, Business Objects and Component Models”. July 2001 available, online www.xml.org/xml/feature_articles/orchestra_w ebservice.pdf [5] CORBA: Common Object Request Broker Architecture, http://www.omg.org, 2008 [6] Java: Remote Method Invocation; http://java.sun.com/j2se/1.4.2/doc/guide/rmi/in dex.html, 2008 [7] Java RMI & CORBA A comparison of two competing technologies. Available online http://www.javacoffeebreak.com/articles/rmi_c orba/index.html, 2008 [8] N. Kassem, A. Vijendran, and Rajiv.Mordani, “Java API for XML Messaging (JAXM),” Sun Microsystems, available online http://java.sun.com/xml/downloads/jaxm.html, 2008 [9] R. Chinnici, “Java API for XML-Based RPC (JAXRPC),”Java Community Process, Tech. [10] Elfwing, R., Paulsson, U., and Lundberg, L, Performance of SOAP in Web Service Environment Compared to CORBA, In Proceedings of the Ninth Asia-Pacific Software Engineering Conference, IEEE, 2002. [11] Davis, D., and Parashar, M., Latency Performance of SOAP Implementations, In Proceedings of 2nd IEEE/ACM. International Symposium on Cluster Computing and the Grid, IEEE, 2002. [12] http://www.xs4all.nl/~irmen/comp/CORBA_vs _SOAP.html#2, 2008. [13] Sun Microsystems, “SOAP with Attachments API for Java (SAAJ),” Sun Microsystems, Tech. Rep., 2004, available online SCOPE FOR FUTURE WROK There are several issues for future work. The layered architecture of middleware platforms (such as CORBA, SOAP, and RMI) is a mixed blessing. On the one hand, layers provide services such as demarshaling, session management, request dispatching, quality-of-service (QoS) etc. In a typical middleware platform, every request passes through each layer, whether or not the services provided by that layer are needed for that specific request. This rigid layer processing can lower overall system throughput, and reduce availability and/or increase vulnerability to denial-of-service attacks. As a future research work in this area we can further make improvements in throughput by implementing bypass in the middleware layers [16] using Aspect Oriented approach. http://java.sun.com/xml/downloads/saaj.ht m. [14] Jay Ongg “An Architectural Comparison of Distributed Object Technologies” Available online http://web.mit.edu/profit/PDFS/OnggJ.pdf, 2008 [15] http://www.wrox.com/, 2008. [16] Cay S. Horstmann, Gary Cornell,Core Java 2, Volume II-Advanced Features, Seventh Edition, Pearson Education, 2007. References: [1] The Rise of Web Services: Completing the Picture, Johann Dumser & Jean-Christophe Cimetiere, TrendMarkers, Vol. 3 Number 1, TechMetrix Research. ISBN: 978-960-6766-61-9 259 ISSN: 1790-5117