corba part i a rmi case study
DESCRIPTION
CORBA Part I A RMI case study. Karsten Schulz Terp-Nielsen. Agenda. Object Managment Group (OMG) Corba Overview Architecture OMG IDL ORB Object Model The Interoperability Architecture Language mappings J2SE 1.4 support for CORBA. Object Management Group (OMG) CORBA/OMG. - PowerPoint PPT PresentationTRANSCRIPT
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA Part IA RMI case study
Karsten Schulz Terp-Nielsen
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Agenda
Object Managment Group (OMG) Corba Overview
– Architecture– OMG IDL – ORB– Object Model – The Interoperability Architecture– Language mappings
J2SE 1.4 support for CORBA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Object Management Group (OMG)CORBA/OMG
CORBA is the acronym for Common Object Request Broker Architecture
CORBA is OMG's open, vendorindependent specification for an architecture and infrastructure that computer applications use to work together over networks
OMG is the world’s largest computer industry consortium with over 800 members ( year 2000 figure)
OMG began its work in 1989 The goals of OMG are
– promotion of the object-oriented approach to software engineering
– development of a common architectual framework for writing distributed object-oriented applications based on interface specifications for the objects in the application
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Object Management Group (OMG) OMA
Besides CORBA OMG also controls the Object Management Architecture (OMA) specification and other specifications in the area Analysis and Design (XMI, UML etc.)
OMA is the framework which all OMGs adapted technology fits
OMA consists of two main parts– Core Object Model– The Reference Model
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Object Management Group (OMG) OMA Core Object Model
Defines concepts that allow distributed application development to be facilitated by an ORB
– Contains abstract definitions
The goals of the Core Object Model are – portability (design portability - to be able to
create components that don’t rely on existence and location of a particular object implementation)
– interoperability (to be able to invoke operations on objects regardless of where they are located, on which platform they execute, or in which programming language they are implemented
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Object Management Group (OMG) OMA Core Object Model
The Core Object Model is a classic object model (actions performed by invoking operations on objects)
– Objects (entities or concepts, identity represented by an object reference)
– Operations: signatures, parameters, return values, exceptions
– Nonobject types (data types), Not specified by the core model, CORBA does
– Interfaces, grouping of operations– Substitutability
When two interfaces can act as substitutes to each other (only substitution through inheritance are acceptable in the CoreObject Model)
Two interfaces having the same operations are not substi-tutable as they problably don’t have the same semantic
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Object Management Group (OMG) OMA Reference Model
OMA defines the interfaces for the objects and leave the implementationto software vendors
OMA is OMGs vision for a software component environment where all theirwork fits
The OMA Reference Model categories objects into four application areas
Your CORBAobjects!
Naming, Notification,Security, Trading etc.
Mobile Agents,MOF, DataInterchange
Tele, HealthCare, Manu-facturing etc.
Domain objects Common facilities
Object ervices
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewCORBA
Introduction Architecture OMG IDL ORB Object Model The Interoperability Architecture Language mappings
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewIntroduction
CORBA builds on the OMA Core Object Model and provides
– syntax and semantics for IDL– A framework for interoperability: two specific
protocols– a set of language mappings from IDL to
prog.lang.
CORBA is operating with transparency– Location transparency– Programming Language transpareny– Platform/vendor transparency– Network HW/SW transparency
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewIntroduction
The key to Location transparency is the Object Request Broker (ORB)
The key to Programming Language Transparency is an implementation neutral Interface Definition Language called OMG IDL that provides separation of interface and implementation
The key to Platform transparency and Network HW/SW transparency is GIOP/CDR (Common Data Representation)
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewIntroduction
In other words……………..
CORBA allow programs from any vendor, on almost any computer, operating system, programming language, and network, to interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewArchitecture
client server
proxy
or dynamic invocation
implementation repository object
adapter
ORBORB
skeleton
or dynamic skeleton
client program
interface repository
Request
Replycorecore for A
Servant A
The Orb core equals the Communication Module in the generic RMI architecture
The ORB can be implemented in many ways; stand-alone, distributedTo the programmer the ORB is a pseudo-object; interface to library functions
ORB
IIOP
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewArchitecture
Compared to the Generic RMI architecture there is only 3 new modules
– Object Adapter– Implementation Repository– Interface Repository
The communication protocol used by CORBA is based on the GIOP (General Inter-ORB Protocol) specification
IIOP (Internet Inter-ORB Protocol) denotes the implementation of GIOP over TCP/IP
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewOMG IDL
OMG IDL is a declarative language for defining the interfaces of CORBA objects
OMG IDL is language independent OMG IDL is used by ORB-specific IDL
compilers to generate stubs, skeletons and interface code in a given programming language in compliance with the IDL mapping specification for that programming language
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewOMG IDL
The syntax of OMG IDL is drawn from C++ but it contains different keywords for stuff
OMG IDL doesn’t contain programming statements as its only purpose is to define interface signatures
The following constructs are available– Constants– Data type declarations (IDL types)– Attributes
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewOMG IDL
– Operations Parameters are marked as either in, out or inout
– Interfaces Group data type, attribute and operation
declarations Exceptions can be defined Support for multiple inheritance – name collision
not allowed– Valuetypes
Group data type, state and operation declaration When client invokes methods -> local method
invocation– Modules
Name space separation
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewOMG IDL - Example
struct Rectangle{ 1long width; long height;long x;long y;
} ;
struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;
};
interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject
};
typedef sequence <Shape, 100> All; 4interface ShapeList { 5
exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;
};
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewOMG IDL - Example
public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();
}
The following are generated by the idl2java (ORBACUS: jidl) compiler
+ ShapeListHolder.java, ShapeListHelper.java, ShapeListOperations.java, ShapeListPOA.java, _ShapeListStub.java, ShapeHolder.java, ShapeHelper.java, ShapePOA.java, _ShapeStub.java, Shape.java, ShapeOperations.java, FullException.java, FullExceptionHolder.java, FullExceptionHelper.java, GraphicalObject.java, GraphicalObjectHolder.java, GraphicalObjectHelper.javaRectangle.java, RectangleHolder.java, RectangleHelper.javaAllHelper.java, AllHolder.java
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB
The ORB is particular responsible for – making the location transparency ie. routing
the request from a client to object and routing the reply to destination
– management of the Interface Repository; a distributed database of IDL definitions
– Client side services for converting remote object references to and from strings
– Client side dynamic invocation of remote objects
– Server side resource management that is activation and deactivation of objects
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Components
Implementation Repository (optional) Interface Repository Client Stubs Server Skeletons Portable Object Adapter (POA) Dynamic Invocation Interface (DII) Dynamic Skeleton Interfaces (DSI)
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Components diagram
The ImplementationRepository and theInterface Repositoryare not shown here
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Implementation Repository
ORBs also often communicate with a ORB deamon process which is a Implementation Repository
Implementation Repository is a database of object implementation information which the ORB can use for locating the server housing the object implementation
Implementation Repository is a server activator Example: Java IDL in Java 1.4
– ORBD
Example: Orbacus fra IONA– Imr
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Implementation Repository
An Implementation Repository is responsible for locating and activating on demand registered CORBA servers
An Implementation Repository stores a mapping from names of Object Adapters to servers address (host:port) along with scripts/batch files for starting the server if not runningImplementation Repository: Jupiter:8080
POA1 \bin\server\startPOA1 TestHost:8888
The ORBcus IMRconsole is an ex.of GUI adm. of theIMR
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Interface Repository
The Interface Repository stores information about registered IDL Interfaces to clients and servers
– names of methods– for each method the names and types of arguments
and exceptions– the key is a IDL compiler generated unique identifier
which is generated for each IDL type it compiles
The Interface Repository is the fundament for reflection in CORBA
The Interface Repository and the Dynamic Invocation Interface adds the power of reflection to CORBA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Interface Repository
The Interface Repository can be access by both clients and servers
The Interface Repository is often a autonom server/process which contain command line commandos for feeding interface definitions into and deleting interface definitions from the Repository
Example: ORBacus– irserv, irfeed, irdel
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Client stubs/proxy
Generated from an OMG IDL compiler to the client language of choise
Acts as a local proxy for the remote object Aggregates the IOR Marshals data to be send;Unmarshal result
– Data send is typically Object key, name of operation and in and inout parameters
There exists one client stub instance per instance of remote object
Can’t be downloaded at run-time as in JavaRMI
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Client stubs/proxy example
interface Hello
{
string say_hello();
void shutdown();
};
public interface HelloOperations
{ //
// IDL:Hello/say_hello:1.0
//
/***/
String say_hello();
//
// IDL:Hello/shutdown:1.0
//
/***/
void shutdown();
}
hello.idlGenerated HelloOperations.java interface to use for the Skeleton
public interface Hello extends HelloOperations,
org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity
{
}
Generated Hello.java interface to use for the Stub
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Client stubs/proxy example
public class _HelloStub extends org.omg.CORBA.portable.ObjectImpl
implements Hello
{
private static final String[] _ob_ids_ = { "IDL:Hello:1.0", };
….
// IDL:Hello/say_hello:1.0
public String say_hello() {
while(true) {
if(!this._is_local()) {
org.omg.CORBA.portable.OutputStream out = null;
org.omg.CORBA.portable.InputStream in = null;
try {
out = _request("say_hello", true);
in = _invoke(out);
String _ob_r = in.read_string();
return _ob_r;
} catch(org.omg.CORBA.portable.RemarshalException _ob_ex)
Create output stream
Create input stream as a Result of the invocation
Marshall arguments
Un-Marshall result, out, inout
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Skeleton
Generated from an OMG IDL compiler to the server language of choice
Unmarshals request data; Dispatch request to servant; Marshals reply data
Servant is the actual CORBA object implementation in a chosen programming language
Skeletons are used by the POA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Skeleton example
public abstract class HelloPOA extends org.omg.PortableServer.Servant
implements org.omg.CORBA.portable.InvokeHandler, HelloOperations
{
static final String[] _ob_ids_ = { "IDL:Hello:1.0",};
public org.omg.CORBA.portable.OutputStream _invoke(String opName,
org.omg.CORBA.portable.InputStream in,
org.omg.CORBA.portable.ResponseHandler handler) {
final String[] _ob_names = { "say_hello","shutdown" };
….
//Find index for operation
…..
switch(_ob_index) {
case 0: // say_hello
return _OB_op_say_hello(in, handler);
case 1: // shutdown
return _OB_op_shutdown(in, handler);
} throw new org.omg.CORBA.BAD_OPERATION();}
Skeleton codefor hello.idl produced byIDL2Javacompiler fromORBACus-jidl
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Skeleton example continued
private org.omg.CORBA.portable.OutputStream
_OB_op_say_hello(org.omg.CORBA.portable.InputStream in,
org.omg.CORBA.portable.ResponseHandler handler)
{
org.omg.CORBA.portable.OutputStream out = null;
String _ob_r = say_hello();
out = handler.createReply();
out.write_string(_ob_r);
return out;
}
private org.omg.CORBA.portable.OutputStream
_OB_op_shutdown(org.omg.CORBA.portable.InputStream in,
org.omg.CORBA.portable.ResponseHandler handler)
{
….
}
}
Skeleton codecontinued
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter
An Object Adapter is responsible for – Generation and interpretation of IORs– Carrying out method invocations– Security on interactions– CORBA Object/implementation
activation and deactivation– Mapping of IORs to corresponding
object implementations– Registration of object implementations
The component in the ORB architecture that maps the abstract concept ofa CORBA Object onto concrete concepts provided by a specific prog. lang.
Life cycle managment
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter
Terminology– Servant: Implementation object providing the run-
time semantic of one or more CORBA objects– ObjectID: An identifier, unique within a POA, that a
POA uses to identify a CORBA Object– AOM: A table of Associations between ObjectIDs
and servants– Incarnate: The action of providing a running
servant to serve requests associated with a particular ObjectID The POA will keep the association in AOM if
configurated to do that
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter
– Etherealize: The action of destroying the association between an ObjectID and a servant
– Activated: When a CORBA Object has been associated with a servant incarnating the object
– Deactivated: When a CORBA Object has no incarnating servant
– Default Servant: An object for which all incomming requests for ObjectIDs not in AOM are dispatched to Only if configurated to do that
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter
An Object Adapter provides a public interface to object implementations
An Object Adapter provides a private interface to the Skeleton
An Object Adapter is build upon a private ORB-dependent interface to the ORB Core
There are a variety of possible Object Adapters but it preferrable to use a few as possible as the object implementation is dependent upon them
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - high-level architecture
ORBCore
POAManager POA
Server Application
Servants
Dispatch withhelp from skeletonsRequest
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – POA Manager
Represents an transport endpoint (host-port for TCP/IP)
Associated with a POA when the POA is created - cannot be changed
Acts as a gate and controls the flow of requests into one or more POAs
A default POA Manager exists for all server processes
The developer can create custom POA Managers
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – POA Manager
Active
Holding
Discarding
Inactive
Creation
Hold_requests
Active
Active
Hold_requests
Discard_requests
Discard_requests
Deactivate
Deactivate
Deactivate
POA Manager state transitions
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – POA overview
A server process contains one or more POAs
All server processes contains one special POA called the ”rootPOA” which is managed by the ORB
– Developers can use this if default policies are suitable
Additional POAs can be created as children of other POA resulting in a hierarcy with the ”rootPOA” as the root
Advantages: Different policies can be assigned to each POA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – POA overview
import org.omg.CORBA.*;import org.omg.PortableServer.*;
// Initialize ORB and POAORB orb = ORB.init (args, props);POA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA"));
// Get a reference to the POA managerPOAManager manager = rootPOA.the_POAManager();
// Create a servant and activate itHelloWorldImpl hwImpl = new HelloWorldImpl();HelloWorld hw = hwImpl._this (orb);
// Wait for incoming requests ("run the implementation")manager.activate();orb.run();
Server code when usingrootPOA with default policies
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – POA overview
Each POA form a namespace for servants
All servants sharing the same POA share common implementation characteristics determined by the POA’s policies
Each servant has exactly one POA but many servants may share the same POA
The POA manage the relationships between object references, object IDs and servants
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – POA overview
ORBextract POA namefrom Object Key
POAfindPOA
Object Reference(with Object Key)
requestfrom a client
or
Adaptor Activator
call AdaptorActivator ifPOA not found
create POA
extract Object Idfrom Object Key Active Object Map
Object ID
Object ID
Object IDServant
Servant
incarnateservant
Default Servant
or
Servant Manager
or
ServantActivator
ServantLocator
createservant
updatemap
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Adapter Activator
An Adapter Activator is an application object the developer can associate with a POA
The ORB will invoke an operation on an adapter if its processing a request for a child POA that does not currently exist
The Adapter Activator can then create the child POA on demand and the ORB will deliver the request to the newly created POA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
To better understand the activation/passivation mechanism offered by the POA, let’s talk a little bit about Life Cycle management in distributed OO systems
When we make OO development we make a conceptual model of the problem domain consisting of system entities denoted objects categorized in classes
The conceptual model is then mapped to the machine when we make a design model for the application – a model for the system running on a machine
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
Phenomenons
Problem spec.concepts
Abstraction
Machine lang.
RealizedConcepts
Abstraction
Problem domain System model
Modeling
A conceptual model is made for the Problem domain
OOA
Problem spec. Concepts are defined from the realized concepts OOD
We find elements that model phenomenos and concepts from the problem domain/conceptual model
OOP
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
The Implementation Model model the behaviour of the objects in the problem domain
– The application will consist of the implementation model plus objects modeling the functionality and interfaces (UI+integration)
The model register and remember relevant states in the problem domain
– The objects in the implementation model register the behaviour of the objects in the problem domain
– With some delay the state of the implementation model objects are changed according to events happening in the problem domain
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
When done modeling we have one or more implementation objects register relevant state changes for each system entity (problem domain object)
The life cycle of a system entity in the problem domain and the related implementation objects need not be the same
– The difference between system entities and object implementations is the heart of Life Cycle and Persistence
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
Persistence is chiefly concerned with what it means for an system entity to exist when its implementation object(s) does not
Life cycle is chiefly concerned with the life cycle of system entities versus the life cycle of the runtime implementation objects
– System entities: created, activated, deactivated, destroyed
– Runtime instance: instantiated, persistent information loaded, remote reference exported etc.
In CORBA most of the basic life cycle support lies within the POA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
In CORBA persistence is provided through a CORBA service named Persistent State Service
– Likewise is enhanced Life cycle support provided through Life cycle service
In CORBA system entities are implemented/modeled by CORBA Objects
CORBA Objects are identified by remote object references, specified through IDL interfaces and implemented by servants
So CORBA Objects and servants have different life cycle and remember: System entities and CORBA objects have different life cycle
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle management
There is no actual relationship between the life time of a servant and the life time of a CORBA Object
– Only that a servant must exist at the time the CORBA Object is activated
– The servant may have been created before the CORBA Object activation or even before the remote object reference creation
– The servant may exists beyond the time the CORBA Object is active or even exists
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
CORBA Object non-existent
CORBA Object existent
CORBA Object activated
CORBA Object deactivated
activatecreate reference
CORBA Object State diagram
deactivate
activate
All transitions are triggeredby operations on a POA
When activating an CORBAobject immediately - thecorresponding remote refdoesn’t have to be createdright away; it can done anytime later
When creating an remoteobject ref - an ObjectID and a remote object reference isassociated; activation canbe done later!
destroy
Remember when the CORBA Object does not exist, the system entity can exist in terms of fx. a row in a db table
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle managment
Object create_reference (in CORBA::RepositoryId intf)raises (WrongPolicy);
Object create_reference_with_id (in ObjectId oid,in CORBA::RepositoryId intf)
raises (WrongPOlicy);
ServantManager get_servant_manager ()raises (WrongPolicy);
void set_servant_manager (in ServantManager imgr)raises (WrongPOlicy);
Servant get_servant ()raises (NoServant, WrongPolicy);
void set_servant (in Servant serv)raises (WrongPOlicy);
ObjectId activate_object (in Servant serv)raises (ServantAlreadyActive, WrongPolicy);
void activate_object_with_id (in ObjectId oid,in Servant serv)
raises (ServantAlreadyActive, ObjectAlreadyActive, WrongPolicy);
Object activation with servant Remote reference creation without servant
CORBA object activated CORBA object exist
Servant manager registration Default servant registration
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter – Life cycle management
Object Reference
Object Id
Servant
ObjectId reference_to_id (in Object ref)raises (WrongAdapter, WrongPolicy);
Object id_to_reference (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);
ObjectId reference_to_id (in Object ref)raises (WrongAdapter, WrongPolicy);
Object id_to_reference (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);
ObjectId servant_to_id (in Servant serv)raises (ServantNotActive, WrongPolicy);
Servant id_to_servant (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);
ObjectId servant_to_id (in Servant serv)raises (ServantNotActive, WrongPolicy);
Servant id_to_servant (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);
Servant reference_to_servant (in Object ref)raises (ObjectNotActive, WrongAdapter, WrongPolicy);
Object servant_to_reference (in Servant serv)raises (ServantNotActive, WrongPolicy);
Servant reference_to_servant (in Object ref)raises (ObjectNotActive, WrongAdapter, WrongPolicy);
Object servant_to_reference (in Servant serv)raises (ServantNotActive, WrongPolicy);
Methods on the POAOnly if RETAIN policy
Plus UNIQUE_IDOr IMPLICIT_ACTIVATIONAnd not active
Plus UNIQUE_IDOr MULTIPLE_IDAnd not active
activated
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
Each POA maintain a Active Object Map (AOM) that map object IDs to servants
.
.
ServantsAOM
POA
OBJID:1
OBJID:N+1
OBJID:N
IOR Object Reference
POA1,OBJID:N
Client
…… …..
It can however be disabled
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
Each POA is associated with 7 policies when its created – they are not changeable later
The policies are not inherited from parent POA to its children POA upon creation
– Given a set of standard policies
Policies control implementation characteristics of the servants and object references
Examples are– threading model for request dispatch– life time of references
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
LifespanPolicy– Transient object references– Persistent object references
IdAssignmentPolicy– Object id provided by either the
application or the system (USER_ID, SYSTEM_ID)
– Persistent object references usually use IDs generated by the application (fx. Db primary key) uses activate_object_with_id on POAs
– Transient object references usually use IDs generated by the system
Detailed furtherin discussingthe object model
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
IdUniquenessPolicy– How object references are mapped to
servants– one servant for each Corba object
(UNIQUE_ID)– one servant for more Corba objects
(MULTIPLE_ID)..
ServantsAOM
POA
OBJID:1
OBJID:N+1
OBJID:N
.
.
ServantsAOM
POA
OBJID:1
OBJID:N+1
OBJID:N
OBJID:N+2
current
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
– Using MULTIPLE_ID offers you scalability possible slow access to servant state
ImplicitActivationPolicy– Whether newly instantiated servants need be
registered with the ORB (activation) manually or that happen automatically (NO_IMPLICIT_ACTIVATION, IMPLICIT_ACTIVATION)
– Transient object references usually use implicit activation of servants
– Persistent object references usually use explicit activation of servants
Lets you developthe server as ‘Type’based while clientssee it as instancebased!!!!!
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
RequestProcessingPolicy– Whether the POA uses static servant mapping (AOM)
or servants are instantiated dynamically
– Possible values USE_ACTIVE_OBJECT_MAP_ONLY USE_DEFAULT_SERVANT USE_SERVANT_MANAGER
Servant Activator (RETAIN - servant for continues use)
Servant Locator (NON-RETAIN - servant for just the single operation - preInvoke()/postInvoke())
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
ServantRetentionPolicy– Whether the POA keep the servants in memory
all the time (RETAIN) or not (NON_RETAIN)– NON_RETAIN has to be used with
USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER RequestProcessing
– If AOM the POA automatically calls a default servant or a servant manager if the requested object ID isn’t in the AOM
– This policy can be used to create the illusion of all objects running in the server - the default servant or servant manager just creates servants on request and maybe destroys them again
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
ThreadPolicy– Whether the POAs processes request
single threaded or whether the ORB chooses a threading model for request dispatch (ORB_CTL_MODEL, SINGLE_THREAD_MODEL)
– Single-threaded means that all requests for that POA is serialized
– If you choose to let the ORB decide you have to consult your ORBs documentation to see which threading the particular ORB practices
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
ORBaCus provides more threading models
– SingleThreaded Blocking (Client)– SingleThreaded Reactive (Client/Server)– Threaded (Client/Server)– Thread-per-Client (Server)– Thread-per-Request (Server)– ThreadPool (Server)
Java ORB 1.4 doesn’t support SingleThreaded model
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
Default values for the 7 policies for the RootPOA
– transient– system_id– unique_id– retain– use_active_object_map_only– implicit_activation– orb_ctl_model
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
Standard policies for POA creation– transient– system_id– unique_id– retain– use_active_object_map_only– no_implicit_activation– orb_ctl_model
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
Code for creation of policies
......Policy[] tpolicy = new Policy[3];tpolicy[0] = rootPOA.create_lifespan_policy( LifespanPolicyValue.TRANSIENT );tpolicy[1] = rootPOA.create_request_processing_policy( RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY );tpolicy[2] = rootPOA.create_servant_retention_policy( ServantRetentionPolicyValue.RETAIN);POA myPOA = rootPOA.create_POA(”myPOA”,rootPOA.the_POAmanager(), tpolicy);.....
Each policy has its own factory
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter - Policies
When deciding on how to configurate the POA, the following main design factors has to be taken into account
– How many objects will the POA host?– What is the expected request load?– Do objects have persistent state?
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter example
To create a POA based CORBA server application you have to
1) IDL-2-Java compile the interfaces you are going to use -> this produces the following files for IDL interface hello:HelloOperations.java, HelloPOA.java HelloPOATie.java (--tie), HelloHelper.java, HelloHolder.java, _HelloStub.java, Hello.java
2) make a servant class
3) make a CORBA server that instantiates the servant and activate it
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Portable Object Adapter example
To make the servant class – Inherit from the POA skeleton generated by the
OMG Idl-2-Java compiler
– What if I want to servant to inherit from another class? Solution - generate the skeleton as a tie
implementation
– Example Hello (eksempler/hello) Servant class:Hello_impl.java Server class:Server.java
– This program uses the default values for the 7 policies for the RootPOA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Dynamic Invocation Interface (DII)
DII is how you from a client can invoke remote object without having stubs/proxies for them
– As noted earlier; in Java RMI this is done by downloading the stubs/proxies at run-time
The steps involved are– Client obtain interface from the Interface
Repository– Client constructs an invocation by usage of
DII and sends it to the server
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Dynamic Invocation Interface (DII)
DII requests send to server can be of the following types
– Synchronous; blocking call invoke()– Asynchronous; non-blocking call send_deferred returns
without waiting for the invocation to complete to get the result the client can either invoke the blocking
get_response() or poll for completion by poll_response()
– One-way call send_oneway() without reply from server
Multiple requests can also be issued for one-way and asynchronous requests by providing a list of request
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Dynamic Skeleton Interface (DSI)
The Dynamic Skeleton Interface allows an ORB to invoke an object implementation without compile-time knowledge about the interface ie. without a Skeleton class
This allows for writing programs that deal with requests in a generic manner
– look at request and arguments– interpreted the semantic dynamically and
return result
The server is coded normally!
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Dynamic Skeleton Interface (DSI)
class HelloServant extends DynamicImplementation
{ // store the repository ID for the implemented interface
static String[] myIDs = {"IDL:JavaIDL/DSIExample:1.0"};
ORB orb;
// create a reference to the ORB
HelloServant(ORB orb) {
this.orb = orb;
}
// must implement invoke() for handling requests
public void invoke(ServerRequest request) {
try {
System.out.println("DSI: invoke called, op = "+request.op_name());
// create an NVList to hold the parameters
NVList nvlist = orb.create_list(0);
// need an if statement like this for each method name
if (request.op_name().equals("printHelloArgs") == true) {
Example of servantcode using DSI
Essentially - you code the Skeleton code your self!!!
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping
Before a program can use CORBA objects, it must initialize itself
– Create a ORB object– Obtain one or more initial object references,
typically at least a Naming Context in a Naming Service
To create a ORB object the following is done
import org.omg.CORBA.ORB; public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); // code continues
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping
Remeber that the ORB object is just a pseudo-object that can’t be passed around like a normal object
For Applets its special
import org.omg.CORBA.ORB; public void init() { try { ORB orb = ORB.init(this, null); // code continues
Must be upplied so the ORB canretrieve the Applet properties
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping
If there are more ORBs present in the runtime invi-ronment it has to be pointed out which ORB to use
– Some browers contain an ORB– The Java 1.2 SE and up contains an ORB
import java.util.Properties; import org.omg.CORBA.*; public class MyApplet extends java.applet.Applet { public void init() { // Instantiate the Java IDL ORB, passing in this applet // so that the ORB can retrieve the applet properties. Properties props = new Properties(); props.put("org.omg.CORBA.ORBClass", "com.sun.CORBA.iiop.ORB"); ORB orb = ORB.init(this, props); ... }}
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping
To invoke a CORBA object the client must have a reference for it
Four ways to get a reference for a CORBA object
– From a string created from a remote reference– From a Naming Service/Trader Service– From the ORB operation
resolve_initial_references– From the result of calling a remote method on a
CORBA object
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping Stringified object references
ORB implementation independent - the ORB can always convert a CORBA object reference to and from a string
Ensure that the object referred to is in fact accessible from where the client is running
Obtain the stringified reference, perhaps from a file or a parameterObject obj = orb.string_to_object("relfile:/Hello.ref");if(obj == null) { System.err.println("hello.Client:cannot read Hello.ref"); return 1;}Hello hello = HelloHelper.narrow(obj);
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping Stringified object references
The following fragment shows how a server converts a CORBA object reference to a string:
org.omg.CORBA.ORB orb = // get an ORB objectorg.omg.CORBA.Object obj = // create the object referenceString str = orb.object_to_string(obj);// make the string available to the client
This code fragment shows how a client converts the stringified object reference back to an object: org.omg.CORBA.ORB orb = // get an ORB object
String stringifiedref = // read stringorg.omg.CORBA.Object obj = orb.string_to_object(stringifiedref);
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping ORB references to services
The ORB resolve_initial_references is intended for bootstrapping object references into a newly started client
ORB dependent implementation for many services but now specified for the Naming Service
The operation takes a string argument that names one of a few recognized objects; it returns a CORBA Object, which must be narrowed to the type the client knows it to be
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Bootstrapping ORB references to services
Examples of recognized objects are– NamingService, TradingService– RootPOA, InterfaceRepository
public calls NameClient {
public static void main(String args[]) { try { Properties props = new Properties(); props.put("org.omg.CORBA.ORBInitialPort", "1050"); ORB orb = ORB.init(args, props); NamingContext ctx = NamingContextHelper.narrow( orb.resolve_initial_references("NameService")); ...
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewORB - Java CORBA Client example
To create a CORBA based Java client application you do the following
– Implement the client application Bootstrap ORB Get initial reference (NamingService, file etc.) Get remote object reference
– Example: Hello Client: Client.java
uses file to get initial reference which in this case equals the remote object reference
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model
The OMA Core Object Model defines some fundamental definitions of concepts which are extended, made more specific and concrete by CORBA
The class concept does not exist in CORBA as non-Object Oriented programming languages can be used as implementation language
Clients for remote objects are not necessary objects as Client implementation languages also can be non-Object Oriented
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
Remote Object References can be in two forms Session form and Interoperable Object Reference (IOR) form
The session form is a vendor specific format– In session form there is no information that is
meaningful for the client as the ref is only interpreted at the server side
The IOR form is intended for interoperability between different ORBs
– The IOR form can be stringified to enable IORs to be stored, emailed, printed, and retrieved
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
IOR Object Reference
Repository IDTransport Address IIOP:host:port
Object Key
POA Name
Object ID
Identifies Interface Type
Identifies a transport endpoint
Identifies the object within POA
Is in proprietary format for a given ORB
Interoperability is not affectedas the server is the only onelooking in it
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
Object references are opaque - application code isn’t allowed to look inside or make any assumptions about the internals
Remote Object references have a semantics very similar to class pointers in C++ - they can dangle ie pointing at a non-existing or unreachable object
– If the server where the remote object lived is shutdown and started again on another host
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
CORBA distinguishes between transient and persistent object references (LifeSpan policy)
A transient IOR continues to work a long as the corresponding server process where the remote object remains available
– Once the server process is shutdown the IOR is non-functional forever (even if the server process is started again)
IOR Host:port contains the server process information for the POA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
If the server is up and running -> Ok
If the server is down - > OBJECT_NOT_EXIST
If the server is running but not the right adapter ID (check for pseudo-random number) -> OBJECT_NOT_EXIST
If the server is running but not the right ORB (check for vendor specific tag in IOR identifying ORB) ->OBJECT-NOT_EXIST
IOR Object Reference
IDL:MyObject TestHost:8888
Server: TestHost:8888
OBJID:11
OBJID:12
POA1,OBJID:12
OBJID:13
Client
POA1
Pseudo-random number
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
A persistent object reference survives shutdown of the server process - it still denotes the same CORBA object
This works even if the server process is started on another host:port
The persistent object reference has a life cycle independent of the life cycle of the servant
Many ORBs can transparently start server processes and shut them down again after some idle time in order to save resources
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
Persistent object references are implemented by usage of the Implementation Repository
IOR Host:port contains the Implementation Repository server process information
– More host:port occurences allow for replicated Implementation Services
Implementation Repository acts as a level of indirection and delivers at runtime the address of the POA server process to the client
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - remote object references
IOR Object Reference
IDL:MyObject Jupiter:8080
Server: TestHost:8888
OBJID:11
OBJID:12
POA1,OBJID:12
OBJID:13
Client
POA1
Pseudo-random number
Implementation Repository: Jupiter:8080
POA1 \bin\server\startPOA1 TestHost:8888
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewObject Model - Persistent Reference example
To make the Hello object references persistent you do the following
– Create a new Policy the LifeSpanPolicy equals persistent the IDAssignmentPolicy equals user_id for all others default values are used
– Create new POA associated with RooTManager with Policy ‘the new policy’
– Create servant and explicit activate servant– Example hello_imr
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewInteroperability Architecture
The Interoperability Architecture for CORBA contain elements like
– ORB interoperability– Inter-ORB bridge support– GIOPs and IIOPs
An ORB is considered being interoperability compliant when supporting
– GIOP/IIOP– IOR
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewLanguage Mappings
The following language specific OMG IDL compilers are contained in specifications
ADA
C
C++
Java
Smalltalk
CORBA Script
COBOL
LISP
Phyton
Client Server
ADA
C
C++
Java
Smalltalk
CORBA Script
COBOL
LISP
Phyton
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
CORBA OverviewLanguage Mappings - cross language example
To show CORBA is language independent use the IDL2CPP (idl) compiler on hello.idl to generate a interface and a stub
idl --no-skeletons hello.idl
Make a client.cpp implementation and link it to a client.exe
Start the Java ORB based hello server and start the C++ ORB based hello client
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
J2SE 1.4 support for CORBA
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
J2SE 1.4 support for CORBACORBA compliance
JDK 1.4 contains a Java ORB implementation supporting a part of CORBA specification 2.3.1
– http://java.sun.com/j2se/1.4/docs/api/org/omg/CORBA/doc-files/compliance.html
JDK 1.4 contains the following CORBA tools– IDL-to-Java compiler (idlj)– Implementation Repository (orbd)– transient Naming Service (orbd)– persistent Naming Service (orbd)– servertool (cmd line interface tool)– tnamesrv (backward compability)
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
J2SE 1.4 support for CORBACORBA features
GIOP 1.2 (IIOP) POA Portable interceptors
– provides hooks, or interception points, through which ORB services can intercept the normal flow of execution of the ORB
– three types IORInterceptor ClientRequestInterceptor ServerRequestInterceptor
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
J2SE 1.4 support for CORBACORBA features
– The class ORBInitializer facilitates interceptor registration and ORB initialization done through properties
org.omg.PortableInterceptor.ORBInitializerClass.<Service>
where <Service> is the string name of a class which implements
org.omg.PortableInterceptor.ORBInitializer
Interoperable Naming Service– can use corba urls
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
J2SE 1.4 support for CORBACORBA example
Example of using persistent object references and the implementation repository in J2SE 1.4 (javacorba\exservertool)
– start the orbd (startorbd)– start the server tool (startservertool)– register HelloServer and start it up– start the client (startclient)
every 6 seconds the client class the sayHello() on the remote object and shutdown the server
watch in Taskmanager how the server is automatically started up when its shutdown by the client
®
Distributed Systems
Copyright Karsten Schulz Terp-Nielsen
Next TimeCORBA Part II
Summary IDL to Java mapping Corba Communication Models CORBA Services CORBA Naming Service CORBA Transaction Service CORBA Concurrency Service RMI/IIOP CORBA 3.0 - Whats new?