1. Distributed Systems Session 5: Common Object Request Broker, (CORBA)
Christos Kloukinas
Dept. of Computing
City University London
Last session we have investigated different communication primitives that are extensively used in distributed systems.
This session we shall compare two different infrastructures for constructing distributed systems. The purpose of these infrastructures is to raise the level of abstraction application programmers have to worry about to the ISO/OSI application layer. The infrastructures we are going to compare are remote procedure calls (RPCs) and OMG/CORBA. This comparison will provide guidelines for the selection of an infrastructure when a distributed system has to be constructed.
RPC was developed by Sun Microsystems in the early 80s as part of their SunOS operating systems. It was included in what was called at that time the Open Network Computing Architecture (ONC). Many other vendors of UNIX workstations have taken Sun´s ideas and developed their own RPC products. The result was quite a substantial heterogeneity and lack of interoperability between the different systems. The Open Software Foundation has remedied the problem by standardising RPCs within their Distributed Computing Environment (DCE), which is at the moment heavily used in industry to build distributed systems. With the wide spread of Java, Sun added RMI (remote method invocation) which is orthogonal to RPC.
CORBA has been developed in the early 90s by the Object Management Group with the vision of using object technology to achieve heterogeneous and distributed also on other platforms than UNIX workstations. The OMG has learned the lessons from the OSF and thus CORBA can be considered as a second generation distributed computing infrastructure.

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 Safe and Secure
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
In order to compare RPCs and CORBA in a systematic way, we need to think about a conceptual framework for this comparison in the first place. This framework will highlight the different features that builders of a distributed systems expect from such an infrastructure.
We are then able to assess RPCs against these requirements. This assessment will explain how RPCs work and how they can actively be used by students in the lab sessions.
In the second part of this lecture, we shall then review those features of CORBA that have not been discussed so far.
The comparison will then reveal the strengths and weaknesses of RPCs and CORBA. The main result is that CORBA provides more sophisticated support for an application builder who wishes to construct a distributed system. The builder, however, has to be prepared to pay a price as in general RPCs will outperform CORBA implementations and also RPCs are much cheaper (at least on UNIX workstations) than CORBA implementations.

10. Remember: Conceptual Framework
Architecture.
Accessing components from programming languages.
Interfaces to lower layers.
Component identification.
Service invocation styles.
Handling of failures.
In the conceptual framework that we use for the comparison of the two infrastructures we first take an architectural perspective. This will identify the different modules that are involved in a distributed system based on the respective infrastructure.
This architectural perspective then enables us to consider the way how the different modules of the architecture are derived and how they interface with modules that are coded by the application developer.
We then review how the infrastructures interface to implementations of lower layers of the ISO/OSI reference model.
We then review how the different infrastructures support the identification of distributed components. A major criterion here is how the infrastructures achieve location transparency.
After that we discuss the primitives that are available in the infrastructure for the invocation of services that are offered by remote components.
Finally, we consider what can go wrong during the invocation of a service and review how the infrastructures cope with these failures.

11. CORBA Object management architecture. Accessing remote objects.
ORB interface.
Object identification
Activation strategies.
Request vs. notification.
Handling of failures.
The instantiation of our conceptual framework for CORBA is sketched by the outline of the third part of this session.
First, we outline the object management architecture as it has been suggested by the OMG. We shall see that the core of CORBA is an object request broker and services, facilities and application objects are constructed on top of it.
We are then going to give an overview of the different modules that are involved in handling an operation execution request. We will see that with client stubs and server skeletons CORBA has an equivalent to the RPC/RMI client and server stubs. CORBA, however, provides additional modules for more advanced functionality. We will then sketch how object operations defined in IDL are accessed from remote clients. There is again a dynamic and a static way of defining these accesses.
The equivalent to the RMI/RPC interface is the ORB interface.
We then discuss how objects are identified and sketch the primitives that are available for finding them.
CORBA defines a number of activation strategies for objects. These determine how object implementations are made available and how multiple object requests are handled.
CORBA not only supports synchronous operation requests that are similar to remote procedure calls, but also facilitates notifications that are handled in a non-synchronous way.
Finally we shall see that failures are handled in terms of exceptions rather than with a null pointer returned from an operation.

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.
OMG Hopes to define a single architecture using object technology, for distributed application integration, guaranteeing;
reusability of components
interoperability & portability
basis in commercially available software
Consensus based approach

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(COTS) 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)
Java
Client
Cobol
Object
C++
CORBA/IIOP

15. 1.3 CORBA Concepts
CORBA’s 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. Not a programming language
Extremely simple; no complex issues like control flow, memory management, functional composition, etc.
interface : A set of named operations and the parameters to those operations, IDL describes interfaces only, not implementations

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
The core of the object management architecture is an object request broker. It enables an object to request an operation execution from another distributed object. The objects can be very heterogeneous in the sense that they can be running on different hardware platforms with different operating systems.
Objects that use an ORB are classified into application objects, CORBAservices objects and CORBAfacilities objects.
A number of problems occur in almost any distributed system. Examples of these problems are naming, trading, migration of components, concurrency control, transactions and the like. Object based solutions to these problems have been standardised by the OMG within the framework of the CORBAservices. It is expected that every vendor of an object request broker provides implementations for these services. This will accomplish portability and interoperability of application objects.
The OMG has started to define a number of component interfaces that may be useful but will not necessarily be needed in every distributed system. These component interfaces are defined as CORBAfacilities. It is not mandatory for ORB vendors to provide these components.
Objects that are specific for a particular application are considered as application objects. They can use or customise CORBAservices or CORBAfacilities objects and so leverage and reuse the solutions the OMG has defined and ORB vendors have implemented.
CORBA services

22. 2.1 OMA Model
CORBA is based on the object model, derived from the abstract core object model of OMG’s OMA (Object Management Architecture)
OMA groups objects into four categories
CORBAservices
CORBAfacilities
CORBAdomain
Application object O M A
CORBA
OMA is a high-level vision of a complete distributed environment.
Of these parts Object Request Broker is the one which constitutes the foundation of OMA and manages all communication between its components. It allows objects to interact in a heterogeneous, distributed environment, independently of the platforms on which these objects reside and techniques used to implement them.
In performing its task it relies on Object Services which are responsible for general object management such as creating objects, access control, keeping track of relocated objects, etc. Common Facilities and Application Objects are the components closest to the end user, and in their functions they invoke services of the system components

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.
These are domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain. Two examples of Object Services that fulfil this role are:
The Naming Service -- which allows clients to find objects based on names;
The Trading Service -- which allows clients to find objects based on their properties.
There are also Object Service specifications for lifecycle management, security, transactions, and event notification
CORBA Facilities
Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications.
An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document

24. 2.3 OMA model Domain (Vertical) CORBAfacilities Application Objects
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
These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains.
For example, one of the first OMG Request for Proposals (RFP) issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.

25. 2.4 CORBA Architecture Client Object Implementation Dynamic Invocation
Stubs
ORB
Interface
Server
Skeleton
Object
Adapter
ORB Core

26. CORBA Architecture Object Request Broker (ORB)
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)
There are two important things to note about the CORBA architecture and its computing model:
Both the client and the object implementation are isolated from the ORB by an IDL interface
All requests are managed by the ORB. This means that every invocation (whether it is remote) or local of a CORBA object is passed to an ORB. In the case of a remote invocation the invocation passed from the ORB of the client to the ORB of the object implementation as shown in the slide
IIOP
Request
Request from a client to an object implementation

28. 2.6 CORBA Architecture CORBA is composed of five major components;
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 object’s 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 client’s perspective, the stub acts like a local call- it’s 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 object’s interface type.
You compile your IDL into client stubs and object skeletons, and write your object and a client for it.
Stubs and skeletons serve as proxies for clients and servers, respectively. 
Because IDL defines interfaces so strictly, the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled into different programming languages, or even running on different ORBs from different vendors.
The ORB interface consists of a few APIs to convert object references to a string, and vice versa. These calls can be very useful if you need to store and communicate object references

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
Lets you discover methods to be invoked at run time. CORBA defines standard APIs for looking up the metadata that defines the server interface, generating parameters, issuing the remote call, and getting back the results.
Compare with: Java Reflection

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)
Purpose:interface an object’s implementation with its ORB
Primary way that an object implementation accesses services provided by the ORB.
Sits on top of the ORB’s 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
This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

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
This slide displays the various modules that are involved in accessing a server object from a client.
Client stubs and server skeletons in CORBA fulfil the same role that client and server stubs play in RMI/RPCs: They perform marshalling of operation parameters, transform them into a common format and manage the synchronisation between client and server.
Client stubs are used for statically defining operation invocation requests at compile time. A dynamic invocation interface can be used to define operation invocation requests dynamically at run-time.
Both client and server objects get access to ORB functionality through the ORB interface. They need it, for instance, to initialise themselves properly and to get access to CORBA services.
The object adapter implements different object activation strategies. These strategies control the allocation of multiple or single objects to processes and determine whether objects are always available or only started on demand.
The ORB core is in charge of implementing session, transport and network layers and to hide these concerns from the other modules.
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
The general inter-orb Protocol (GIOP) specifies a set of message formats and common data representations for communications between ORBs. The GIOP was specifically built for ORB-to-ORB interactions. It is designed to work directly over any connection-oriented transport protocol. GIOP defines seven message formats that cover all the ORB request/reply semantics. No format negotiations are needed. In most cases, clients send a request to objects immediately after they open a connection. The Common Data Representation maps data types defined in OMG idl INTO A FLAT , NETWORKED message representation. The CDR also takes care of inter-platform issues such as byte ordering and memory alignments
Internet Inter-Orb Protocol IIOP specifies how GIOP messages are exchanged over a TCP/IP network. IIOP makes it possible to use the internet itself as a backbone protocol through which other ORBs can Bridge.

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. ORB interoperability
CORBA 2.0 Compliant ORBs are able to interoperate via the internet inter-ORB Protocol IIOP
All clients will be able to communicate with the server written for a different ORB from a different vendor

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 IDL definition
idl
load
Example Servant
Client IDL Stub
Server Skeleton
Interface repository
is used by
Implement Client
Implement Servant
Object Adapter
Define your server interfaces using the Interface Definition Language (IDL)
Bind the interface definitions to the interface repository (in OrbixWeb you can use the command putidl)
Run the IDL compiler (In OrbixWeb: idl; In JAVA ORB coming with JDK1.2b3: idltojava). The IDL compiler generates the stubs and skeletons
Implement the servant, I.e. the IDL specification
Compile the code (javac)
Register the runtime-objects with the implementation repository (In OribxWeb: putit)
Instantiate the object on the server
Implement the client code
Compile and run the client code
javac
instantiates
javac
Start client
Implementation repository
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.*;
import org.omg.CosNaming.NamingContextPackage.*;
import 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("NameService");
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("NameService");
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.
The static way of invoking a remote operation can only be used if the IDL interface is available at the point in time when the client is being developed. This is because the client stubs that are derived from the IDL interface are to be linked with the client program.
This is, however, not always applicable. There are application domains where generic clients are built before specific server objects become available. An example would be an object browser that can display an object´s attributes.
The dynamic invocation interface provides facilities for objects to define requests at run-time. A request can be created for any object. Then a name of an operation to be executed can be determined and the operation parameters can be set. After that the operation request can be issued and the operation results can be obtained from the request.
A disadvantage of this dynamic invocation interface is that it is not type safe. The interface itself does not provide any guidance as to the operations and attributes that are available for an object or the numbers and types of their parameters.
Clients can limit the unsafeness of dynamic invocations by using an interface repository. The interface repository keeps information about the interfaces of an object and can be used to query which operations and attributes an object supports and can be used to find out about their types and parameters. Entries into the interface repository are made by the IDL compiler during stub generation.

54. 4.5 ORB Interface Object type Object.
Initialisation of object request broker.
Initialisation of client / server applications.
Programming interface to interface repository.
Among other things, the ORB interface defines the object type Object, the root of the object type hierarchy. Object defines a number of operations for object identification purposes that are explained on the next slide.
The ORB interface provides an operation to startup the object request broker.
Also the ORB interface standardises the way clients register themselves with the ORB and servers to obtain an identifier of the object adapter to register the server with the object adapter.
Finally, it provides a programming interface to the interface repository that can be used to traverse and query the set of object types.

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.
Objects are uniquely identified by object identifiers. They are the principle way to access object attributes and to execute an object’s operations. Hence object identifiers achieve location transparency.
Object identifiers are persistent, i.e. once an object identifier has been assigned to an object the object will retain that identifier throughout its lifetime, irregardless whether ORB or object server are stopped.
Object identifiers can be externalised (converted into a character string) by means of operations exported from type Object. This is needed, for instance, to transmit an object identifier to a remote component through communication outside the ORB.
There are many different ways how object identifiers of remote components can be obtained.
The principle way is to use a naming or trading service. Naming is a technique that maps external names to object identifiers (like the white pages of a telephone directory) and trading is a technique that enables clients to find objects by the services their operations implement (similar to the yellow pages). Naming and trading will be subject of the lectures in session 6.
Object identifiers can be obtained by reading an attribute whose type is a subtype of Object.
Object identifiers can be obtained as a result of an operation execution, or through an out or inout parameter of an operation if these types are subtypes of Object.
Finally, object identifiers can be obtained by internalising an externalised object reference.

58. 4.7 Activation StrategiesD
A Shared Server
B Unshared Server
C Server per method
D Persistent server B C
CORBA standardises the operations of the basic object adapter (BOA). A BOA implementation has to be provided by any CORBA compliant object request broker.
The BOA defines four different object activation strategies, which define how objects are allocated to processes.
With the shared server strategy (A) one process or thread accommodates multiple objects. Operation execution requests are queued while the process performs an operation of one of the objects.
With the unshared server strategy (B) each object is executed in its own process or thread. Operation execution requests only have to be queued if another operation of the same object is currently being executed.
With the server per method strategy (C) each method of each object is executed in its own process or thread. Requests only have to be queued if the method of that object is currently being executed.
With all these three strategies, the basic object adapter starts the processes/threads as soon as the ORB has transferred a request. Implementations therefore have to be registered with a so called implementation repository. Processes and threads are deactivated by the BOA as soon as no requests are to be handled anymore.
The persistent server strategy (D) gives up this assumption and activation is done outside the ORB, for instance manually by an administrator or automatically through the operating system. The process would then run until it is stopped explicitly.
Process
Basic
Object
Adapter
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.
The IDL operations that we have seen so far, are handled as requests in the same way as RPCs, i.e. the client awaits the completion of the operation on the server and the quality of service is at most once.
For notifications where the semantics of the client is fully independent of the result of the operations, it is not be necessary to wait until the server has handled the notification. This is the case if operations do not
have return values (i.e. their return value is void),
have out or inout parameters and
do not raise specific exceptions.
In these cases the semantics of the further execution of the client does not depend on the server and the client may continue immediately after the ORB has accepted the request from the client. Then, however, only a maybe quality of service can be achieved.
The ORB cannot decide itself, whether to execute an operation as a request or a notification, because it does not know the quality of service an object implementation wants to achieve. Therefore IDL has a language construct oneway that can be used to declare that the operation is executed as a notification.

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); };
This slide displays the IDL for person management.
The operation that prints a person record on the server is declared as oneway. This is possible, because it has a void return type, has no inout and out parameters and does not raise exceptions.
A client that invokes print would then not have to wait until the server has printed the record, but would be able to continue immediately. On the other hand, the client would not necessarily get to know failures that may have occurred.

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.
The invocation of a remote operation through an object request broker may fail for exactly the same reasons for that RMI/RPCs may fail: servers may collapse, request or reply messages may be lost.
Failures in CORBA and RMI, however, are handled in a fundamentally different way than those in RPCs. A client is informed about a failure in terms of an exception. The exception gives a very precise account as to why an operation execution request has not been handled properly.
Clients may exploit this knowledge to decide whether they want to retry the operation execution request or to report the failed request to an administrator or to the user.
CORBA distinguishes between generic and application specific failures. Recall that generic failures are defined in the CORBA standard and application specific failures are defined through exceptions in IDL.
The different programming language bindings for IDL will have to deal with exceptions and enable programmers of both servers and clients to deal with exceptions.
Server programmers will have to determine in object implementations when to throw exceptions.
Client programmers must be able to catch both application specific and generic 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++
The comparison of OMG/CORBA and RMI/RPCs is now done on the basis of the conceptual framework that we have established in the first part of this session’s lecture.
We note that the RMI/RPC architecture does not have an equivalent to the CORBA interface repository. Therefore, clients cannot check the type safeness of RMI/RPCs dynamically defined at run-time (unless they use reflection).
While the definition of remote components in IDL is generally easier than the a definition in RPCL, RMI - being tightly connected to JAVA - is the easiest to use. CORBA’s IDL and JAVA as basis of RMI are generally more expressive, since RPCL does not have counterparts for the IDL concepts of inheritance, attributes and application specific exceptions.
Accessing remote components specified in IDL can be achieved through standardized programming language bindings for JAVA, OO-Cobol, C, C++, Smalltalk and Ada-95. RPCs, however, can only be accessed using C or C++ and RMI goes only together with JAVA

64. 4 Comparison (cont´d) 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.
CORBA (RMI) objects can return identifiers of other CORBA (RMI) objects. They only have to define operations whose return type or (in)out parameters are subtypes of Org.omg.object (RemoteObject) They can even dynamically create new CORBA (RMI) objects. Hence, identification of components is reflexive in CORBA’s IDL (RMI). This is not true for RPCL. An RPC program cannot directly have operations that return other RPC programs.
The basic object adapter of CORBA provides more ways to activate a CORBA object than the strategies available for RPCs.
CORBA oneway operations can be used to implement asynchronous notifications. This provides for increased concurrency between clients and servers in many occasions. RMI/RPCs however, are always executed synchronously.
The approach of handling failures is much better in CORBA/RMI than it is with RPCs. Exceptions are more elegant and more informative for a client than a null pointer.

65. 4 Comparison (cont´d)
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).
Some CORBA products implement operation invocation requests on top of RPCs. Hence it can be expected that these products perform less efficient than RPCs. However, there are also UDP based CORBA implementations which outperform TCP based RPCs.
RPCs (RMI) have the advantage that they are just there after you have installed a UNIX operating system (JDK) . If you run Linux on your PC at home, it will have RPCs on it (even though you may not have noticed yet) and you are encouraged to toy around with them. To be able to use CORBA, however, you will have to obtain a CORBA implementation, as well.
RPCs are only available on UNIX but CORBA and RMI implementations are also available for other platforms. There are implementations for PCs running all forms of Windows, Macintosh, all Unix platforms, IBM VM/MVS, OpenVMS, Tandem and many others.
RMI/RPCs have the advantage that they are very lightweight. The RPC library that implements the RPC interface only consists of a small number of operations and the stubs that are generated are fairly small. CORBA applications tend to be much bigger.

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.