Topic 5: CORBA RMI Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine

5.1 CORBA RMI The Object Management Group (OMG)I: OMG introduced the Object Request Broker (ORB). ORB is a distributed object model component with a role involving: Locating a object. Activating the object. Passing the client request to the object which executes it and send a reply. The aim was to enable: Distributed objects to be implemented in any programming language. And for such objects to communicate with each other.

5.1 CORBA RMI The Object Management Group (OMG)I: For that to be achieved, an independent interface language which is dependent of any specific implementation language need to be used. The Common Object Request Broker Architecture (CORBA) was introduced in 1991 CORBA RMI is a specification for an ORB and includes the following components: An Interface Definition Language (IDL). An architecture. Common Data Representation (CDR) which defines a common representation of data types that can be used as arguments and return values in CORBA’s remote method invocation.

5.2 Internet Inter-ORB Protocol Internet Inter-ORB Protocol (IIOP): Under communication between CORBA clients and CORBA services, method calls are passed to Object Request Brokers (ORBs). These ORBs communicate via the Internet Inter-ORB Protocol (IIOP). IIOP transactions can take place over TCP streams, or via other protocols (such as HTTP), in the event that a client or server is behind a firewall. The IIOP also defines a standard way to represent remote object references. The following diagram shows a client and a servant communicating. CORBA client sends a request through its local ORB to a remote ORB's servant CORBA servant sends back a response to a remote ORB RMI vs CORBA

5.3 CORBA IDL – Whiteboard Example

5.4 The IDL Compiler The Java language can be used as the technology to implement a CORBA-based system. The idltojava interface compiler is applied to the IDL interface and generates the following: The equivalent Java interfaces, e.g. the Java interface for Shapelist shown below. The server skeletons for each IDL interface. The names of skeleton classes end in ImpBase. The proxy classes for each IDL interface. The names of these classes end in Stub. A Java class to correspond to each of the structs in the IDL interfaces. These classes contain instance variable for each field in the corresponding struct plus a pair of constructors. Helper classes for each of the types defined in the IDL interface. A helper class contains a narrow method, which is used to cast down from a given object reference to the class to which it belongs.

5.5 IDL Generation of Java Interfaces

5.5 The ShapeListServant Class

5.5 Server Class

5.5 Client Class

5.4 The main components of the CORBA architecture client

5.4 The main components of the CORBA architecture client CORBA architecture is designed to support the ORB role enabling clients to invoke methods in remote objects independent of the language of implementation. The architecture is shown on the previous slide. It can be seen that it is similar to the RMI implementation shown on previous topic with the addition of three components: The object adapter. The implementation repository. Interface repository.

5.4 The main components of the CORBA architecture client The main components of the CORBA architecture are reviewed next. ORB Core: Role similar to that of the communication module in the previous topic. Object Adapter: Bridges the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant classes. Its role covers the remote reference module and the dispatcher in the previous topic. It creates remote object references for CORBA objects. It dispatches each remote method invocation to the skeleton (to be passed then to the remote object servant). An object adapter gives each CORBA object a unique object name. Each CORBA object is registered with its object adaptor which keeps a remote object table, mapping CORBA object names to servants. Each object adaptor has a name which is can be generated automatically by the CORBA framework. It forms part of all the object references it manages.

5.4 The main components of the CORBA architecture client Skeletons: Generated in the language of the server using an IDL compiler. Passes remote method invocations to the appropriate servant (remote object). Unmarshals the invocation input parameters and marshals the results and exceptions in the invocation return. Proxies: Generated by the IDL compiler in the client language. Marshals and unmarshals the input parameters and returns to method invocations. Implementation Repository: Responsible for activating registered objects on demand and locating servers that are currently running. A table is maintained in the implementation repository which maps names of object adaptors to the path names of files containing object implementation. Object implementations and object adaptor names are registered with the implementation repository when server programs are installed. Not all CORBA object need to be called on demand, such objects do not use the implementation repository.

5.4 The main components of the CORBA architecture client Interface Repository: Its role include providing information about registered IDL interfaces to clients and servers including method details. If a client receives a remote object reference and it does not have a proxy for it, it can ask the interface repository about the methods of the objects by enquiring its interface. The IDL compiler assigns a unique type identifier for each type in the IDL file. This identifier is used to register type interfaces uniquely in the interface repository.

5.5 Type of invocation in CORBA There are two type of invocations in CORBA: Static: which is used when the remote object reference is known at compile time, thus skeletons and proxies are generated at an early stage. Dynamic: which is used when the remote object reference is acquired at run time. Applications that use static invocations do not need to use the interface repository.

5.6 Java RMI VS. CORBA Comparing RMI and CORBA doesn't reveal an optimum solution - one is not "better" than the other. The properties of these two technologies lend themselves to different situations. A comparison of RMI and CORBA helps to highlight individual strengths and weaknesses, but the applicability of one technology over the other depends largely on the purposes for which it is to be used, the experience of the developers who will design, implement and maintain the distributed system, and whether non-Java systems are intended to access the system now or in the future.

5.7 Java RMI pros and cons Remote method invocation has significant features that CORBA doesn't possess - most notably the ability to send new objects (code and data) across a network, and for foreign virtual machines to seamlessly handle the new objects. Remote method invocation has been available since JDK 1.02, and so many developers are familiar with the way this technology works, and organizations may already have systems using RMI. Its chief limitation, however, is that it is limited to Java Virtual Machines, and cannot interface with other languages. Pros: 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

5.7 Java RMI pros and cons Cons: 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++, Fortran, Cobol, and others (including future languages).

5.8 CORBA pros and cons CORBA is gaining strong support from developers, because of its ease of use, functionality, and portability across language and platform. CORBA is particularly important in large organizations, where many systems must interact with each other, and legacy systems can't yet be retired. CORBA provides the connection between one language and platform and another - its only limitation is that a language must have a CORBA implementation written for it. CORBA also appears to have a performance increase over RMI, which makes it an attractive option for systems that are accessed by users who require real-time interactio

5.8 CORBA pros and cons Pros: Services can be written in many different languages, executed on many different platforms, and accessed by any language 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, and to ensure that applications written now will be accessible in the future. CORBA is an easy way to link objects and systems together CORBA systems may offer greater performance

5.8 CORBA pros and cons Cons: Describing services require the use of an interface definition language (IDL) which must be learned. 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. 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 real-time performance, and speed may be traded off against ease of use for pure Java systems.