Transcript topic 5x

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.