Distributed Systems

1
Distributed Systems

• Session 5
• Common Object Request Broker, (CORBA)
• Christos Kloukinas
• Dept. of Computing
• City University London

2
0.0 Review RMI

• RMI Remote Method Invocation
• RPC in Java Technology and more
• Concrete programming technology
• Designed to solve the problems of writing and
  organizing executable code
• Native to Java, an extension of core language
• Benefits from specific features of Java
• Object serialization
• Portable, downloadable object implementations
• Java interface definitions

3
0.1 RMI Benefits

• Invoke object methods, and have them execute on
  remote Java Virtual Machines (JVMs)
• Entire objects can be passed and returned as
  parameters
• Unlike many other remote procedure call based
  mechanisms requiring either primitive data types
  as parameters, or structures composed of
  primitive data types
• New Java objects can be passed as a parameter
• Can move behavior (class implementations) from
  client to server and server to client

4
0.2 RMI Benefits

• Enables use of Design Patterns
• Use the full power of object oriented technology
  in distributed computing, such as two- and
  three-tier systems (pass behavior and use OO
  design patterns)
• Safe and Secure
• RMI uses built-in Java security mechanisms
• Easy to Write/Easy to Use
• A remote interface is an actual Java interface
• Distributed Garbage Collection
• Collects remote server objects that are no longer
  referenced by any client in the network

5
0.3 RMI Implementation
6
0.4 Developing RMI

• Define a remote interface
• define a remote interface that specifies the
  signatures of the methods to be provided by the
  server and invoked by clients
• It must be declared public, in order for clients
  to be able to load remote objects which implement
  the remote interface.
• It must extend the Remote interface, to fulfill
  the requirement for making the object a remote
  one.
• Each method in the interface must throw a
  java.rmi.RemoteException.

7
Developing RMI

• Implement the remote interface
• Develop the server
• Create an instance of the RMISecurityManager and
  install it
• Create an instance of the remote object
• Register the object created with the RMI registry
• Develop the client
• First obtain a reference to the remote object
  from the RMI registry

8
Developing RMI

• Running the application
• Generate stubs and skeletons - rmic
• Compile the server and the client - javac
• Start the RMI registry - rmiregistry
• Start the server and the client

9
Outline

• 1.0 The Object Management Group and Introduction
• 2.0 Object Management Architecture
• 3.0 CORBA Communication
• 4.0 Implementation, Hello World Example
• 5.0 RMI vs CORBA Comparison

10
Remember Conceptual Framework

• Architecture.
• Accessing components from programming languages.
• Interfaces to lower layers.
• Component identification.
• Service invocation styles.
• Handling of failures.

11
CORBA

• Object management architecture.
• Accessing remote objects.
• ORB interface.
• Object identification
• Activation strategies.
• Request vs. notification.
• Handling of failures.

12
1.0 The Object Management Group

• The OMG is a non-profit consortium created in
  1989 with the purpose of promoting theory and
  practice of object technology in distributed
  computing systems to reduce the complexity, lower
  the costs, and hasten the introduction of new
  software applications.
• Originally formed by 13 companies, OMG membership
  grew to over 500 software vendors, developers and
  users.
• OMG realizes its goals through creating standards
  which allow interoperability and portability of
  distributed object oriented applications. They do
  not produce software or implementation guidelines.

13
1.1 CORBA (Common Object Request Broker
Architecture)

• Specification by OMG of an OO infrastructure for
  Distributed Computing.
• Defines Object Request Broker and IDL
• Enables Software interoperability across
  languages and platforms
• Applicable to legacy, commercial-off-the-shelf(COT
  S) integration and new software development
• CORBA is just a specification for creating and
  using distributed Objects, it is an integration
  technology NOT a programming language

14
1.2 CORBA A Specification

• Takes care of cross-language issues automatically
• Uses OMG IDL (Interface Definition Language
• Runs over IIOP
  (Internet Inter-Orb
  Protocol)

15
1.3 CORBA Concepts

• CORBAs theoretical underpinnings are based on
  three important concepts
• An Object-Oriented Model
• Open Distributed Computing Environment
• Component Integration and Reuse
• CORBA Provides
• Uniform access to services
• Uniform discovery of resources and object names
• Uniform error handling methods
• Uniform security policies

16
1.4 . The OMG Object Model

• The OMG Object Model defines common object
  semantics for specifying the externally visible
  characteristics of objects in a standard and
  implementation-independent way.
• In this model clients request services from
  objects (which will also be called servers)
  through a well-defined interface.
• This interface is specified in OMG IDL (Interface
  Definition Language). A client accesses an object
  by issuing a request to the object.
• The request is an event, and it carries
  information including an operation, the object
  reference of the service provider, and actual
  parameters (if any).

17
(No Transcript)
18
(No Transcript)
19
1.5 About CORBA Objects

• CORBA objects differ from typical objects in 3
  ways
• CORBA objects can run on any platform.
• CORBA objects can be located anywhere
• CORBA Objects can be written in any language that
  has an IDL mapping
• A CORBA object is a virtual programming entity
  that consists of an identity, an interface, and
  an implementation which is known as a Servant.
• It is virtual in the sense that it does not
  really exist unless it is made concrete by an
  implementation written in a programming language

20
1.6 Objects and Applications

• CORBA applications are composed of objects.
• Typically, there are many instances of an object
  of a single type - for example, an e-commerce
  website would have many shopping cart object
  instances, all identical in functionality but
  differing in that each is assigned to a different
  customer, and contains data representing the
  merchandise that its particular customer has
  selected.
• For other types, there may be only one instance.
  When a legacy application, such as an accounting
  system, is wrapped in code with CORBA interfaces
  and opened up to clients on the network, there is
  usually only one instance. 

21
2.0 Object Management Architecture (OMA)
Application Objects
CORBA facilities
Object Request Broker
CORBA services
22
2.1 OMA Model

• CORBA is based on the object model, derived from
  the abstract core object model of OMGs OMA
  (Object Management Architecture)
• OMA groups objects into four categories
• CORBAservices
• CORBAfacilities
• CORBAdomain
• Application object

O M A
CORBA
23
2.2 CORBAservices

• CORBAservices
• Provide basic functionality, that almost every
  object needs
• Naming Service-name binding ,associating names
  and references
• Event Service- asynchronous event notification
• Concurrency Control Service-mediates simultaneous
  access
• CORBA facilities (sometimes called Horizontal
  CORBAfacilities)
• Between CORBAservices and Application Objects
• Potentially useful across business domains
• Printing, Secure Time Facility,
  Internationalization Facility, Mobile Agent
  Facility.

24
2.3 OMA model

• Domain (Vertical) CORBAfacilities
• Domain-based and provide functionality for
  specific domains such as telecommunications,
  electronic commerce, or health care.
• Application Objects
• Topmost part of the OMA hierarchy
• Customized for an Individual application, so do
  not need standardization

25
2.4 CORBA Architecture
Client
Object Implementation
Dynamic Invocation
Client Stubs
ORB Interface
Server Skeleton
Object Adapter
ORB Core
26
CORBA Architecture
Object Implementation
Client
(Servant)
Dynamic
Static
Object
Skeleton
Skeleton
Adapter
Dynamic
ORB
Stub
Invocation
Interface
Object Request Broker (ORB)
Interface identical for all ORB implementations
Up-call interface
There maybe multiple object adapters
There are stubs and skeletons for each object
type
Normal call interface
ORB-dependent interface
27
2.5 CORBA Architecture

• A general CORBA request structure

A request consists of

• Target object (identified by unique object
  reference)
• Operation.
• Parameters (the input, output, and in-out
  parameters defined for the operation maybe
  specified individually or as a list
• Optional request context
• Results (the results values returned by operation)

IIOP
Request
Request from a client to an object implementation
28
2.6 CORBA Architecture

• CORBA is composed of five major components
• ORB,
• IDL,
• Dynamic Invocation Interface (DII),
• Interface Repositories (IR),
• Object Adapters (OA),
• Inter-Orb Protocol (IIOP)
• CORBA provides both static and dynamic interfaces
  to its services
• Happened because two strong proposals from
  HyperDesk and Digital based on a Dynamic API
  from SUN and HP based on a static API. Common
  stands for a two-API proposal

29
2.7 Object Request Broker, ORB

• Core of CORBA, middleware that establishes the
  client/server relationship between objects
• This is the object manager in CORBA, the software
  that implements the CORBA specification,
  (implements the session, transport and network
  layers), provides object location transparency,
  communication and activation, i.e
• Find object implementation for requests (provide
  location transparency)
• Prepare the object implementation to receive
  request
• Communicate the data making up request.
• (Vendors Products ORBIX from IONA, VisiBroker
  from Inprise, JavaIDL from javasoft)

30
2.8 CORBA Architecture ORB

• On the client side the ORB is responsible for
• accepting requests for a remote object
• finding the implementation of the object
• accepting a client-side reference to the remote
  object (converted to a language specific form,
  e.g. a java stub object)
• Routing client method calls through the object
  reference to the object implementation
• On the Server side
• lets object servers register new objects
• receives requests from the client ORB
• uses objects skeleton interface to invoke the
  object activation method
• Creates reference for new object and sends it
  back to client.

31
2.9 CORBA Architecture Stubs,Skeletons

• Client Stub
• provides the static interfaces to object
  services. These precompiled stubs define how
  clients invoke corresponding services on the
  server. From a clients perspective, the stub
  acts like a local call- its a local proxy for a
  remote server object. Generated by the IDL
  compiler (there are as many stubs as there are
  interfaces!)
• Server Skeleton
• provides static interfaces to each service
  exported by the server. Performance
  unmarshalling, and the actual method invocation
  on the server object
• ORB Interface
• Interface to few ORB operations common to all
  objects, e.g. operation which returns an objects
  interface type.

32
2.10 CORBA Architecture Servant Clients

• Object -- This is a CORBA programming entity that
  consists of an identity, an interface, and an
  implementation, which is known as a Servant.
• Servant -- This is an implementation programming
  language entity that defines the operations that
  support a CORBA IDL interface. Servants can be
  written in a variety of languages, including C,
  C, Java, Smalltalk, and Ada.
• Client -- This is the program entity that invokes
  an operation on an object implementation.
  Accessing the services of a remote object should
  be transparent to the caller. Ideally, it should
  be as simple as calling a method on an object.
  The remaining components help to support this
  level of transparency.

33
2.11 CORBA Architecture DII

• Dynamic Invocation Interface (DII)
• Static invocation interfaces are determined at
  compile time, and they are presented to the
  client using stubs
• The DII allows client applications to use server
  objects without knowing the type of objects at
  compile time
• Client obtains an instance of a CORBA object and
  makes invocations on that object by dynamically
  creating requests.
• DII uses the interface repository to validate and
  retrieve the signature of the operation on which
  a request is made

34
2.12 CORBA Architecture DSI

• Dynamic Skeleton Interface (DSI)
• Server-side dynamic skeleton interface
• Allows servers to be written without having
  skeletons, or compile time knowledge for which
  objects will be called remotely
• Provides a runtime binding mechanism for servers
  that need to handle incoming method calls for
  components that do not have IDL-based compiled
  skeletons
• Useful for implementing generic bridges between
  ORBs
• Also used for interactive software tools based on
  interpreters and distributed debuggers

35
2.13 CORBA Architecture IR

• Interface Repository
• allows YOU to obtain and modify the descriptions
  of all registered component interfaces(method
  supported, parameters i.e method signatures)
• It is a run-time distributed database that
  contains machine readable versions of the IDL
  interfaces
• Interfaces can be added to the interface
  repository
• Enable Clients to
• locate an object that is unknown at compile time
• find information about its interface
• build a request to be forwarded through the ORB

36
2.13 CORBA Architecture OA

• Object Adapter (OA) e.g (Basic-BOA or
  Portable-POA)
• Purposeinterface an objects implementation with
  its ORB
• Primary way that an object implementation
  accesses services provided by the ORB.
• Sits on top of the ORBs core communication
  services and accepts requests for service on
  behalf of server objects, passing requests to
  them and assigning them IDs (object references)
• Registers classes it supports and their run-time
  instances with the implementation repository
• In summary, its duties are
• Object reference generation, and interpretation,
  method invocation, security of interactions, and
  implementation of object activation and
  de-activation

37
2.14 Implementation Repository

• Provides a run-time repository of information
  about classes a server supports, the objects that
  are instantiated and their IDs
• Also serves as a common place to store additional
  information associated with implementations of
  ORBS
• e.g. trace information, audit trails and other
  administrative data

38
2.15 Summary of CORBA Interfaces

• Interface and Implementation Repositories

• All objects are defined in IDL by specifying
  their interfaces

• Object definitions (interfaces) are manifested as
  objects in the interface repository, compiled to
  stubs and skeletons

Accesses
Decsribes
includes
includes

• Descriptions of object implementations are
  maintained as objects in the implementation
  repository

39
2.16 Accessing Remote Objects
Client
Object Implementation
Dynamic Invocation
Client Stubs
ORB Interface
Server Skeleton
Object Adapter
ORB Core
40
2.17 Client Side
Clients perform requests using object references
Clients May issue requests through object
interface stubs (static) or dynamic invocation
interface (Dynamic)
Client
Clients may access general ORB services

• Interface Repository
• Context management
• List Management
• Request Management

Dynamic Invocation
Client Stubs
ORB Interface
41
2.18 Implementation Side (Server side)

• Implementations receive requests through
  skeletons (without knowledge of invocation
  approach)

The object Adapter provides for
Object Implementation

• Management of references
• Method invocation
• authentication
• implementation registration
• activation/deactivation

ORB Interface
Server Skeleton
Object Adapter
42
3.0 CORBA Communication

• CORBA Spec Neutral w.r.t network protocols
• CORBA specifies GIOP, a high level standard
  protocol for communication between ORBs
• Generalized Inter-ORB Protocol (GIOP) is a
  collection of message requests an ORB can make
  over a network
• GIOP maps ORB requests to different transports
• Internet Inter-ORB Protocol (IIOP) uses TCP/IP to
  carry the messages, hence fits well into Internet
  world
• Environment Specific Inter-ORB Protocol (ESIOP)
  complements GIOP enabling interoperability with
  environments not having CORBA support

43
3.1 CORBA Communication

• GIOP contains specifications for
• Common Data Representation (CDR)
• Message formats (Reply, Request, LocateReply,
  LocateRequest, CancelRequest, etc)
• Message transport assumptions
• Connection-Oriented
• Reliable
• A Byte Stream Protocol

44
3.2 Communication Inter-Orb Architecture
CORBA IDL
Object Request Semantics
General Inter-ORB Protocol (GIOP)
Transfer and Message Syntax
Internet Inter-ORB Protocol (IIOP) TCP/IP
Others for example OSI and IPX/SPX
Transports
Internet
45
(No Transcript)
46
3.3 Other Features

• CORBA Messaging
• CORBA 2.0 provides three different techniques for
  operation invocations
• Synchronous The client invokes an operation, then
  pauses, waiting for a response
• Deferred synchronous The client invokes an
  operation then continues processing. It can go
  back later to either poll or block waiting for a
  response
• One-way The client invokes an operation, and the
  ORB provides a guarantee that the request will be
  delivered. In one-way operation invocations,
  there is no response

47
3.4 New Features

• Two newer, enhanced mechanisms are introduced
• Callback The client supplies an additional object
  reference with each request invocation. When the
  response arrives, the ORB uses that object
  reference to deliver the response back to the
  client
• Polling The client invokes an operation that
  immediately returns a valuetype that can be used
  to either poll or wait for the response
• The callback and polling techniques are available
  for clients using statically typed stubs
  generated from IDL interfaces (not for DII)

48
4.0 Implementation
Implementation
49
4.0 How to Write CORBA Applications
Create IDLdefinition
idl
load
Example Servant
Client IDL Stub
Server Skeleton
Interface repository
is used by
Implement Client
Implement Servant
Object Adapter
javac
javac
instantiates
Start client
Implementationrepository
Start server
Server
Client
50
4.1 Example Hello world ID

• module HelloApp
• interface Hello
• string sayHello()

51
4.2 Example Hello World Server
import HelloApp. import org.omg.CosNaming. imp
ort org.omg.CosNaming.NamingContextPackage. impo
rt org.omg.CORBA. class HelloServant extends
_HelloImplBase public String sayHello()
return "\nHello world !!\n"
public class HelloServer public static
void main(String args) try
// create and initialize the ORB
ORB orb ORB.init(args, null) //
create servant and register it with the ORB
HelloServant helloRef new
HelloServant() orb.connect(helloRef)
// get the root naming context
org.omg.CORBA.Object objRef
orb.resolve_initial_references("NameServic
e") NamingContext ncRef
NamingContextHelper.narrow(objRef)
// bind the Object Reference in
Naming NameComponent nc new
NameComponent("Hello", "")
NameComponent path nc
ncRef.rebind(path, helloRef) //
wait for invocations from clients
java.lang.Object sync new java.lang.Object()
synchronized (sync)
sync.wait() catch
(Exception e)
Servant
Server Skeleton
Binding
ORB interface
52
4.3 Example Hello World Client
import HelloApp. import org.omg.CosNaming.
import org.omg.CORBA. public class
HelloClient public static void main(String
args) try ORB orb
ORB.init(args, null) // create and
initialize the ORB // get the root
naming context org.omg.CORBA.Object
objRef orb.resolve_initial_references("NameServi
ce") NamingContext ncRef
NamingContextHelper.narrow(objRef)
// resolve the Object Reference in Naming
NameComponent nc new NameComponent("Hello",
"") NameComponent path nc
Hello helloRef HelloHelper.narrow(ncRef.
resolve(path)) // call the Hello
server object and print results
String hello helloRef.sayHello()
System.out.println(hello) catch
(Exception e)
Casting
Service Request
53
4.4 Static vs. Dynamic Invocation

• Static invocation IDL operations must have been
  defined before client can be developed.
• Does not suit every application (Example?)
• Dynamic invocation interface enables clients to
  define operation invocations at run-time.
• Interface repository can be used to ensure that
  calls are type safe.

54
4.5 ORB Interface

• Object type Object.
• Initialisation of object request broker.
• Initialisation of client / server applications.
• Programming interface to interface repository.

55
4.6 Object Identification

• Objects are uniquely identified by object
  identifiers.
• Object identifiers are persistent.
• Identifiers can be externalised (converted into
  string) and internalised.
• Identifiers can be obtained
• from a naming or a trading service,
• by reading attributes,
• from an operation result or
• by internalising an externalised reference.

56
(No Transcript)
57
(No Transcript)
58
4.7 Activation Strategies
A
A Shared Server B Unshared Server C Server per
method D Persistent server
D
B
C
Process
Object
Registration
Activation
59
3.5 Request vs. Notification

• IDL operations are handled synchronously.
• For notifications, it may not be necessary to
  await the server, if operation does not
• have a return value,
• have out or inout parameters and
• raise specific exceptions.
• Notification can be implemented as oneway
  operations in IDL.
• Client continues after notification is delivered.

60
3.5 Notification (Example)

• / person.idl /
• enum sex_type
• FEMALE, MALE
• struct Person
• string first_name
• string last_name
• sex_type sex
• string city

• interface PersonManager
• oneway void print(in Person)
• long store(in Person pers)
• Person load(in long pers_id)

61
3.6 Failures

• CORBA operation invocations may fail for the same
  reasons as RMIs.
• Exceptions give detailed account why an operation
  has failed.
• System vs. application specific exceptions.

62
CORBA AND JAVA

• 1997 RMI Introduced with JDK1.1
• 1998 JavaIDL with JDK1.2 Java ORB supporting
  IIOP. ORB also supports RMI over IIOP ? remote
  objects written in the Java programming language
  accessible from any language via IIOP
• CORBA provides the network transparency, Java
  provides the implementation transparency

63
4 Comparison

• RMI architecture lacks interface repository (but
  has reflection).
• IDL and RMI allow for
• inheritance,
• attributes and
• exceptions. (These three are missing in RPC)
• IDL has multiple standardised language bindings.
  RMI is part of JAVA, RPC goes with C and C

64
4 Comparison (contd)

• RMIs are lightweight.
• Component identification is reflexive in IDL and
  RMI, as opposed to RPC.
• Basic object adapter provides more flexible
  activation strategies.
• Oneway operations can be used for asynchronous
  notifications.

65
4 Comparison (contd)

• RMIs may be more efficient than CORBA operation
  invocations.
• RMI comes with JAVA, whilst you would have to
  obtain a CORBA product (open-source ones exist).

66
6.1 RMI vs CORBA

• RMI is a Java-centric distributed object system.
  The only way currently to integrate code written
  in other languages into a RMI system is to use
  the Java native-code interface to link a remote
  object implementation in Java to C or C code.
  This is a possibility, but complicated.
• CORBA, on the other hand, is designed to be
  language-independent. Object interfaces are
  specified in a language that is independent of
  the actual implementation language. This
  interface description can then be compiled into
  whatever implementation language suits the job
  and the environment.

67
6.2 RMI vs CORBA (ctd.)

• Relatively speaking, RMI can be easier to master,
  especially for experienced Java programmers, than
  CORBA. CORBA is a rich, extensive family of
  standards and interfaces, and delving into the
  details of these interfaces is sometimes overkill
  for the task at hand.

68
6.3 RMI vs CORBA (ctd.)

• CORBA is a more mature standard than RMI, and has
  had time to gain richer implementations. The
  CORBA standard is a fairly comprehensive one in
  terms of distributed objects, and there are CORBA
  implementations out there that provide many more
  services and distribution options than RMI or
  Java. The CORBA Services specifications, for
  example, include comprehensive high-level
  interfaces for naming, security, and transaction
  services.

69
6.4 The Bottom Line

• So which is better, CORBA or RMI? Basically, it
  depends. If you're looking at a system that
  you're building from scratch, with no hooks to
  legacy systems and fairly mainstream requirements
  in terms of performance and other language
  features, then RMI may be the most effective and
  efficient tool for you to use.
• On the other hand, if you're linking your
  distributed system to legacy services implemented
  in other languages, or if there is the
  possibility that subsystems of your application
  will need to migrate to other languages in the
  future, or if your system depends strongly on
  services that are available in CORBA and not in
  RMI, or if critical subsystems have
  highly-specialized requirements that Java can't
  meet, then CORBA may be your best bet.