Transcript CORBA Overview ORB - Portable Object Adapter

Distributed Systems
CORBA Part I
A RMI case study
Karsten Schulz Terp-Nielsen
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
Agenda
 Object Managment Group (OMG)
 Corba Overview
–
Architecture
–
OMG IDL
–
ORB
–
Object Model
–
The Interoperability Architecture
–
Language mappings
 J2SE 1.4 support for CORBA
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
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
Copyright Karsten Schulz Terp-Nielsen
interface specifications for the objects in the application
®
Distributed Systems
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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
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
Two interfaces
having
the same operations
are not substiCopyright Karsten Schulz Terp-Nielsen
the CoreObject
Model)
tutable as
they problably don’t have the same semantic
®
Distributed Systems
Object Management Group (OMG)
OMA Reference Model
The OMA Reference Model categories objects into four application areas
Domain objects
Common facilities
Mobile Agents,
MOF, Data
Interchange
Your CORBA
objects!
Tele, Health
Care, Manufacturing etc.
Naming, Notification,
Security, Trading etc.
Object ervices
OMA defines the interfaces for the objects and leave the implementation
to software vendors
OMA is OMGs vision for a software component environment where all their
work fits
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
CORBA
 Introduction
 Architecture
 OMG IDL
 ORB
 Object Model
 The Interoperability Architecture
 Language mappings
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Introduction
 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Introduction
 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)
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Introduction
In other words……………..
CORBA allow programs from any vendor,
on almost any computer, operating
system, programming language, and
network, to interoperate with a CORBAbased program from the same or another
vendor, on almost any other computer,
operating system, programming
language, and network
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Architecture
ORB
client
client proxy
program for A
implementation
repository
ORB
core
or dynamic invocation
server
interface
repository
Request
IIOP
Reply
object skeleton
adapter
ORB
core
Servant
A
or dynamic skeleton
The Orb core equals the Communication Module in the generic RMI architecture
The ORB can be implemented in many ways; stand-alone, distributed
To the programmer the ORB is a pseudo-object; interface to library functions
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Architecture
 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
OMG 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
OMG 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
OMG 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
OMG IDL - Example
struct Rectangle{
long width;
long height;
long x;
long y;
};
interface Shape {
long getVersion() ;
GraphicalObject getAllState() ;
};
1
struct GraphicalObject {
string type;
Rectangle enclosing;
boolean isFilled;
};
2
3
// returns state of the GraphicalObject
typedef sequence <Shape, 100> All;
interface ShapeList {
exception FullException{ };
Shape newShape(in GraphicalObject g) raises (FullException);
All allShapes();
// returns sequence of remote object references
long getVersion() ;
};
4
5
6
7
8
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
OMG IDL - Example
The following are generated by the idl2java (ORBACUS: jidl) compiler
public interface ShapeList extends org.omg.CORBA.Object {
Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
Shape[] allShapes();
int getVersion();
}
+ 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.java
Rectangle.java, RectangleHolder.java, RectangleHelper.java
AllHelper.java, AllHolder.java
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB
 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Components
 Implementation Repository (optional)
 Interface Repository
 Client Stubs
 Server Skeletons
 Portable Object Adapter (POA)
 Dynamic Invocation Interface (DII)
 Dynamic Skeleton Interfaces (DSI)
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Components diagram
The Implementation
Repository and the
Interface Repository
are not shown here
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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 running
Implementation Repository: Jupiter:8080
POA1
\bin\server\startPOA1
TestHost:8888
The ORBcus IMR
console is an ex.
of GUI adm. of the
IMR
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Client stubs/proxy example
hello.idl
Generated HelloOperations.java
interface to use for the Skeleton
interface Hello
public interface HelloOperations
{
{ //
string say_hello();
// IDL:Hello/say_hello:1.0
void shutdown();
//
};
/***/
String say_hello();
Generated Hello.java
interface to use for the Stub
//
// IDL:Hello/shutdown:1.0
public interface Hello extends HelloOperations,
//
org.omg.CORBA.Object,
/***/
org.omg.CORBA.portable.IDLEntity
{
void shutdown();
}
}
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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()) {
Create output stream
org.omg.CORBA.portable.OutputStream out = null;
org.omg.CORBA.portable.InputStream in = null;
Marshall arguments
try {
out = _request("say_hello", true);
in = _invoke(out);
String _ob_r = in.read_string();
return _ob_r;
Create input stream as a
Result of the invocation
Un-Marshall result, out, inout
} catch(org.omg.CORBA.portable.RemarshalException _ob_ex)
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
…..
Skeleton code
for hello.idl
produced by
IDL2Java
compiler from
ORBACus
-jidl
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();}
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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();
Skeleton code
continued
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)
{
….
}
}
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter
The component in the ORB architecture that maps the abstract concept of
a CORBA Object onto concrete concepts provided by a specific prog. lang.
 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
Life cycle
managment
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter
 Terminology
–
Servant: Implementation object providing the runtime 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter - high-level architecture
Server Application
Dispatch with
help from skeletons
Request
ORB
Core
POA
Manager
POA
Servants
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter – POA Manager
POA Manager state transitions
Creation
Holding
Hold_requests
Hold_
requests
Deactivate
Active
Deactivate
Active
Inactive
Active
Discard_
requests
Discard_requests
Deactivate
Discarding
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter – POA overview
import org.omg.CORBA.*;
import org.omg.PortableServer.*;
Server code when using
rootPOA with default policies
// Initialize ORB and POA
ORB orb = ORB.init (args, props);
POA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA"));
// Get a reference to the POA manager
POAManager manager = rootPOA.the_POAManager();
// Create a servant and activate it
HelloWorldImpl hwImpl = new HelloWorldImpl();
HelloWorld hw = hwImpl._this (orb);
// Wait for incoming requests ("run the implementation")
manager.activate();
orb.run();
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Object Reference
(with Object Key)
CORBA Overview
Distributed Systems
ORB - Portable Object Adapter – POA
overview
request
from a client
ORB
extract POA name
from Object Key
Default Servant
POA
find
POA
extract Object Id
from Object Key
Active Object Map
incarnate
servant
Object ID
Servant
or
or
Object ID
or
Servant
Object ID
call Adaptor
Activator if
POA not found
create POA
Adaptor Activator
update
map
Servant
Activator
create
servant
Servant
Locator
Servant Manager
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter – Life cycle managment
Problem spec. Concepts
are defined from the
realized concepts
OOD
A conceptual model
is made for the
Problem domain
We find elements that
model phenomenos
and concepts from
the problem
domain/conceptual
model
Modeling
Problem spec.
concepts
Realized
Concepts
OOA
Abstraction
Phenomenons
Problem domain
Abstraction
OOP
Machine lang.
System model
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
CORBA Overview
Distributed Systems
ORB - Portable Object Adapter
– Life cycle managment
CORBA Object State diagram
Remember when the CORBA Object
does not exist, the system entity can
exist in terms of fx. a row in a db table
All transitions are triggered
by operations on a POA
CORBA Object non-existent
CORBA Object existent
activate
CORBA Object
activated
destroy
deactivate
activate
create
reference
CORBA Object
deactivated
When activating an CORBA
object immediately - the
corresponding remote ref
doesn’t have to be created
right away; it can done
anytime later
When creating an remote
object ref - an ObjectID and
a remote object reference is
associated; activation can
be done later!
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter – Life cycle managment
Object activation with servant
Remote reference creation without servant
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 create_reference (in CORBA::RepositoryId intf)
raises (WrongPolicy);
Object create_reference_with_id (in ObjectId oid,
in CORBA::RepositoryId intf)
raises (WrongPOlicy);
CORBA object activated
CORBA object exist
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);
Servant manager registration
Default servant registration
Copyright Karsten Schulz Terp-Nielsen
®
CORBA Overview
Distributed Systems
ORB - Portable Object Adapter – Life cycle management
Object Reference
Methods on the POA
Only if RETAIN policy
ObjectId reference_to_id (in Object ref)
raises (WrongAdapter, WrongPolicy);
Object id_to_reference (in ObjectId oid)
raises (ObjectNotActive, WrongPolicy);
Object Id
Servant reference_to_servant (in Object ref)
raises (ObjectNotActive, WrongAdapter, WrongPolicy);
Object servant_to_reference (in Servant serv)
Plus UNIQUE_ID
raises (ServantNotActive, WrongPolicy);
Or IMPLICIT_ACTIVATION
And not active
ObjectId servant_to_id (in Servant serv)
raises (ServantNotActive, WrongPolicy);
Servant id_to_servant (in ObjectId oid)
raises (ObjectNotActive, WrongPolicy);
Plus UNIQUE_ID
Or MULTIPLE_ID
And not active
activated
Servant
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter - Policies
Each POA maintain a Active Object Map
(AOM) that map object IDs to servants
POA
Client
AOM
IOR Object Reference
……
…..
OBJID:1
Servants
POA1,OBJID:N
.
.
OBJID:N
OBJID:N+1
It can however be disabled
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter - Policies
 LifespanPolicy
–
–
Detailed further
in discussing
the object model
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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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)
POA
POA
Servants
AOM
OBJID:1
.
.
Servants
AOM
OBJID:1
.
.
OBJID:N
OBJID:N
OBJID:N+1
OBJID:N+1
current
OBJID:N+2
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Portable Object Adapter - Policies
–
Using MULTIPLE_ID offers you
 scalability
 possible slow access to servant state
 ImplicitActivationPolicy
–
–
–
Lets you develop
the server as ‘Type’
based while clients
see it as instance
based!!!!!
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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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())
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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?
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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!
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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) {
Example of servant
code using DSI
Essentially you code the Skeleton
code your self!!!
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) {
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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 can
retrieve the Applet
properties
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - Bootstrapping
 If there are more ORBs present in the runtime invironment 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);
... }}
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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 parameter
Object
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);
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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 object
org.omg.CORBA.Object obj = // create the object
reference
String 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 string
org.omg.CORBA.Object obj = orb.string_to_object(stringifiedref);
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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"));
...
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
ORB - 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object Model - remote object references
IOR Object Reference
Repository ID
Transport 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 affected
as the server is the only one
looking in it
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object Model - remote object references
Pseudo-random number
Client
Server: TestHost:8888
IOR Object Reference
IDL:MyObject
TestHost:8888
POA1
POA1,OBJID:12
OBJID:11
OBJID:12
OBJID:13
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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object Model - remote object references
Pseudo-random number
Client
Server: TestHost:8888
IOR Object Reference
IDL:MyObject
Jupiter:8080
POA1
POA1,OBJID:12
OBJID:11
OBJID:12
OBJID:13
Implementation Repository: Jupiter:8080
POA1
\bin\server\startPOA1
TestHost:8888
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Object 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Interoperability 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Language Mappings
 The following language specific OMG IDL
compilers are contained in specifications
Phyton
Phyton
ADA
ADA
C++
C++
Java
Client
Server
Java
Smalltalk
Smalltalk
COBOL
COBOL
LISP
LISP
C
CORBA Script
C
CORBA Script
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
CORBA Overview
Language 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
J2SE 1.4 support for CORBA
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
J2SE 1.4 support for CORBA
CORBA 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/do
c-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)
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
J2SE 1.4 support for CORBA
CORBA 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
J2SE 1.4 support for CORBA
CORBA 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
J2SE 1.4 support for CORBA
CORBA 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
Copyright Karsten Schulz Terp-Nielsen
®
Distributed Systems
Next Time
CORBA 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?
Copyright Karsten Schulz Terp-Nielsen
®