Lecture 5

Advanced CORBA Topics

Object Adapters, Revisited In the 2.x specification, client side CORBA code was highly portable Server Side: Basic Object Adapter

– interfaces the world of “objects” to that of “servants”

– Underspecified and non portable server side code

– ORB vendors had to implement vendor-specific methods and naming• skeleton base class naming convention

• object registration with the ORB (_obj_is_ready, obj_is_ready, etc.)

• activation policies

What’s a CORBA object again?– A CORBA object is an abstract entity with an:

• identity

• interface

• implementation

Portable Object Adapter– Accepted by the OMG in 1997 as part of CORBA 2.2

The Portable Object Adapter Specified to fix a number of the problems with the BOA Like the BOA, mainly concerned with interactions of objects and servers Each ORB is associated with a root POA A POA is a composite object which can create and contain other POAs The Object key (of the IOR) contains:

– the name of the managing POA

– Object ID: identifies a specific object implementation relative to the POA in the Object Key

The BOA supported only early binding, when an IOR was created, the object’s servant was instantiated

The POA supports late binding--the separation of the IOR from the servant instantiation process

The binding between a servant and a CORBA object can be per request (via a Servant Locator) or not per request, which uses a Servant Activator.

POA continued

Defined new category object called servant managers– new focus on objects rather than server processes

– manages object implementations, incarnates and etherealizes associations between objects and servants on demand

– CORBA objects are activated and deactivated

– Servants are incarnated and etherealized

– supports persistent objects

– supports ForwardRequest exception for indirection

– supports single thread model as well as POA-managed multithreading

– supports transient objects

– supports multiple instances of the POA• each POA manages a group of object implementations

General Inter-ORB Protocol (GIOP)

A transport-independent communication protocol GIOP Goals and Motivations:

– Two ORBs must be able to communicate without any knowledge of the other’s internal mechanisms

– The transport protocol must provide support for all CORBA functionality

– The transport protocol must support the ORB-specific integrity of content and semantics of one ORB in the communication with another ORB

GIOP has three core elements:– Common Data Representation (CDR)

– Message Formats

– Transport Assumptions

Common Data Representation GIOP specifies that Network Byte Order will default to that of the sender, and it is the responsibility

of the receiver to make any modifications that are necessary

– In contrast to XDR, which forces a big endian ordering

– GIOP tags a message with the network byte ordering of the sender (0 = BE, 1 = LE)

– NBO is encoded in a byte in a GIOP 1.0 header, in a bit in a byte in GIOP 1.1 GIOP specifies that all data is aligned on the sender’s natural boundaries.

– 1: char, octet, boolean

– 2: short, unsigned short

– 4: long, unsigned long, float, enumerated types

– 8: long long, unsigned long long, double, long double

– Data is padded with spaces (0x20) as neccesary

– Complex types are aligned according to their members (modulus alignment):

• struct s { char c; double d; };

• c is in byte 1

• followed by 7 spaces (0x20)

• followed by the double d

– Strings are encoded with a 4-byte unsigned long which indicates the length of the string plus the terminating null, followed by the chars in the string, followed by a NUL byte (0x0).

CDR encodings are NOT self-describing, but IDL-described

GIOP Message Formats

There are 8 message formats defined:

Message Type Originating Agent

Request Client

Reply Server

CancelRequest Client

LocateRequest Client

LocateReply Server

CloseConnection Server (or Client in GIOP 1.2)

MessageError Client or Server

Fragment (Flag) Client or Server (GIOP 1.1 & 1.2)

Message Fragmentation was introduced in GIOP 1.1 and allows for more efficient marshaling by allowing the sender to send data in a single request and have that fragmented into several packets without forcing the sender to buffer and marshall the data in advance

GIOP Transport Assumptions

The transport is connection-oriented Connections are full-duplex

– allows receiver to reply to sender over the same connection without having to know the socket address of the sender

Connections support symmetric closure (GIOP 1.2)

– either end can close the connection The Transport is reliable (basic TCP assumptions)

– messages will never be delivered more than once

– message will be delivered in order The Transport supports an unmarshaled byte-stream delivery

– receiver sees data as a continuous byte stream rather than some structured data element

The transport supports orderly error reporting on connection loss

– both parties receive error notifications in the case of failure

Internet Inter-ORB Protocol

GIOP, while it has assumptions, is independent of any particular transport protocol

The Internet Inter-ORB Protocol specifies a TCP transport for GIOP IIOP supplies the notion of an IOR

– The Repository ID (most derived-type of Object implementation)

– The endpoint information (socket for server or OAD)

– The Object Key (the POA as well as the object servant ID)

IIOP defines how this information is encoded into an IOR IIOP 1.1 adds support for tagged components, which allow specification in

transports (codeset support, ORB-specific info, security info, etc.)

CORBA Services Naming Service (Object Location by Name - “White Pages”) Trader Service (Object Location by service category - “Yellow Pages”) Event Service (Distributed Messaging) Transaction Service, OTS (Distributed Transactions) Concurrency Service (provides controls for concurrent access of objects and transactions

by concurrent threads) Security Service (provides user authentication and object access control) Life Cycle Service (Factory for creating, deleting, copying, and relocating objects) Licensing Service (Provides access control services for licensing objects) Time Service (service for getting the time, and manipulating time values - span(), etc.) Query Service (service for querying collections of objects) Persistence Service (Service for persisting the state of objects, interfaces with Object

Adapters for instantiation) Relationship Service (allows for CORBA objects to be related by design - role,

cardinality, etc., as in UML) Property Service (allows property sets to be associated with objects)

Naming Service Service provides a client with the ability to locate an object implementation’s IOR by

well known name (WKN) The Naming Service maintains a database of bindings between WKNs and IORs. The Naming Service is often thought of as a kind of UNIX directory structure

– root

• EasternUS

– Massachusetts

» BostonNorthEnd

Hanover StreetLa Piccola

Venezia Each branch in the tree is called a NamingContext Each name in the naming service is a NameComponent Getting the root naming service:

– Object nameRef = orb.resolve_initial_references(“NameService”);

– NamingContext nc = NamingContextHelper.narrow(nameRef);

The Naming Context

The NamingContext is an IDL interface that supports the following methods:

Method Activityvoid bind(Name, Object) associates a name and object within a NamingContextvoid rebind(Name, Object) does the same thing as bind, but doesn’t throw an

exception if name is already boundvoid bind_context(Name,NamingContext)

binds a name to a NamingContext

void rebind_context(Name,NamingContext)

same as bind_context, but doesn’t throw an exception ifname is already bound

Object resolve(Name) matches the name with a NamingContext, and returns theassociated IOR

void unbind(Name) unassociates a name with a NamingContextNamingContext new_context() returns an unbound NamingContextNamingContextbind_new_context(Name)

returns a bound NamingContext bound to the Name

void destroy() deletes a NamingContextvoid list( how_many,BindingList, BindingIterator)

allows iteration through a sequence of bindings within aNamingContext

The NameComponent

Each Name in a NamingContext is a sequence of NameComponent objects:struct NameComponent {

Istring id; //the name of the componentIstring kind; //a user-defined description};

A NameComponent is a single entry in a pathname, it might represent the “local” in /usr/local/bin.

Binding an Object To bind an object, you do the following:

– get the initial NamingContext via resolve_initial_references()

– narrow the Object result to the more derived NamingContext type using narrow()

– Create a starting NamingContext:NameComponent nc1 = new NameComponent(“EasternUS”, “the good side”);NameComponent nc2 = new NameComponent(“Massachusetts”, “ok state”);NameComponent nc3 = new NameComponent(“Boston”, “now we’re talkin”);NameComponent nc4 = new NameComponent(“NorthEnd”, “only place to go”);NameComponent nc5 = new NameComponent(“HanoverStreet”, “oh yes”);NameComponent nc6 = new NameComponent(“LaPiccolaVenezia”, “aaaahhhh”);NameComponent [] name = { nc1, nc2, nc3, nc4, nc5, nc6 };NamingContext italian = rootContext.bind_new_context(name);ItalianEateryImpl piccolaVenezia = new ItalianEateryImpl(MODERATE_PRICE);italian.rebind(name, piccolaVenezia);

Resolving an Object To locate an object, you do the following:

– get the initial NamingContext via resolve_initial_references()

– narrow the Object result to the more derived NamingContext type using narrow()

– Create a starting NamingContext:NameComponent nc1 = new NameComponent(“EasternUS”, “”);NameComponent nc2 = new NameComponent(“Massachusetts”, “”);NameComponent nc3 = new NameComponent(“Boston”, “”);NameComponent nc4 = new NameComponent(“NorthEnd”, “”);NameComponent nc5 = new NameComponent(“HanoverStreet”, “”);NameComponent nc6 = new NameComponent(“LaPiccolaVenezia”, “”);NameComponent [] name = { nc1, nc2, nc3, nc4, nc5, nc6 };orb.omg.CORBA.Object ior = rootContext.resolve(name);ItalianEatery piccolaVenezia = ItalianEateryHelper.narrow(ior);piccolaVenizia.eat(ItalianEatery.VEAL_EGGPLANT_PARMESAN);

ToolTalk and RPC ToolTalk is a messaging service from SunSoft allowing peers to communicate via

ToolTalk without having to connect directly or know about one another A message is not sent from a peer to another connected peer process, but a client

dispatches a message of a specific type to the ToolTalk service Servers register with the ToolTalk service, and specify what types of messages they are

interested in receiving The ToolTalk service then dispatchs messages from clients to these registered listening

servers according to their type. All this is a lot like System V IPC Message Queues; however ToolTalk ran over RPC

and thus provided one of the first distributed messaging services. ToolTalk is still used today in Sun’s openwin X server communication (view on any

Solaris box):

– /usr/openwin/share/include/desktop/tt_c.h “ToolTalk is perhaps too high level a service to replace RPC as a general-purpose

distributed programming mechanism. Also, its complexity presents a significant learning hurdle. Nonetheless, it is an interesting new paradigm and one which we can expect to see more of in the future.” --Chris Brown, UNIX Distributed Programming, 1994

The CORBA Event Service The COS Event Service allows for decoupled asynchronous message transfer between

CORBA objects The Event Service acts as a well-known intermediary between objects that wish to

communicate, but do not wish to be tightly coupled Senders of events are called suppliers, and receivers of events are called consumers. The COS Event Service implements the Mediator and Proxy Patterns (GoF) The COS Event Service offers what is commonly referred to as the Producer-Consumer

model Messages can be accessed by either a pull or Pull metaphor Message passing takes place asynchronously (non-blocking model) The COS Event Service delivery can be set up to be typed or untyped The COS Event Service will automatically buffer received events, offering semi-

persisted messaging Communication can follow either a pull or Pull model Consumers can either synchronously (Pull) or asynchronously (pull) obtain messages

from the Event Services, or have the Event Service deliver events to them (pull model) A 1-1 correspondence between Producers and Consumers is not necessary

The Connection Process

Regardless of the model, the following steps must be taken to connect to an event channel:

– The client must bind to the Event Channel, which must already have been created by someone, perhaps the client

– The client must get and Admin object from the Event Channel

– The client must obtain a proxy object from the Admin object (a Consumer Proxy for a Supplier client and a Supplier Proxy for a Consumer client)

– Add the Supplier or Consumer client to the event channel via a connect() call

– Transfer data between the client and the Event Channel via a push(), pull(), or try_pull() call

The COS Event Service Design

Suppliers and Consumers each connect to the event service, via a particular channel. Each channel can have multiple consumers and suppliers, and all events delivered by a

supplier are made available to all consumers An event channel can be thought of as a repository of common interest, the Usenet

model is available as a metaphor Suppliers and consumers connect to an event channel, and begin communication through

the channel The Event Channel supports two models of interaction: pull and Pull

– Push Model: The sender initiates the delivery of the message to the recipient

– Pull Model: The recipient initiates the delivery of the message from the sender by request

The Event Channel plays roles on behalf of suppliers and consumers– For consumers, it plays the role of a supplier

– For suppliers, it plays the role of a consumer

Through this role playing, the Event Channel can decouple the communication between the two interested parties

The Pull Model In the Pull Model, the consumer initiates the flow of events from the supplier When a Pull supplier wants to connect to the event channel, the event channel will

“pretend” it is a Pull consumer, by creating a consumer proxy for the supplier to talk to The supplier is none the wiser, and simply delivers messages on request to its

“consumer”, which is a proxy object within the event channel When a Pull consumer wants to connect to the event channel, the event channel will

“pretend” it is a supplier, by creating a supplier proxy for the consumer to talk to.– In the Pull Consumer scenario, the Pull Consumer pulls (or tries to pull) events from the Proxy

Pull Supplier

– In the Pull Supplier scenario, the Proxy Pull Consumer pulls events from the Pull Supplier.

Pull SupplierProxy PullConsum er

Event Channel Proxy Pull Supplier Pull Consum er

The Push Model In the Push Model, the supplier initiates the flow of events to the consumer When a Push Supplier wants to connect to the event channel, the event channel will

“pretend” it is a consumer, by creating a consumer proxy for the supplier to talk to The supplier is none the wiser, and simply delivers messages to its “consumer”, which is

a proxy object within the event channel When a Push Consumer wants to connect to the event channel, the event channel will

“pretend” it is a supplier, by creating a supplier proxy for the consumer to talk to.

– In the Push Consumer scenario, the event channel pushes events out to the consumer via the push supplier proxy

– In the Push Supplier scenario, the supplier pushes events out to the event channel via its push consumer proxy.

Push SupplierProxy PushConsum er

Event ChannelProxy Push

SupplierPush Consum er

The Hybrid Model Push Supplier/Push Consumer: Push suppliers push events onto the channel, which in

turn pushes them out to consumers Push Supplier/Pull Consumer: Push suppliers push events onto the channel, and pull

consumers pull events (or try to pull) from the channel when they need one Pull Supplier/Push Consumer: The event channel pulls events from the Pull Supplier,

and then it pushes these events out to the Push Consumers Pull Supplier/Pull Consumer: The Pull Consumers pull events from the event channel,

which in turn pulls them from the Pull Suppliers.

Pull SupplierProxy PullConsum er

Event Channel

Proxy Pull Supplier Pull Consum er

Proxy PushConsum er

Proxy PushSupplier

Push Supplier Push Consum erEvent D irection through channel