Advanced CORBA Topics

1
Lecture 5

• Advanced CORBA Topics

2
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
• Whats 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

3
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 objects 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.

4
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

5
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 others 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

6
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
  senders 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

7
GIOP Message Formats

• There are 8 message formats defined

• 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

8
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

9
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.)

10
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)

11
Naming Service

• Service provides a client with the ability to
  locate an object implementations 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
• Boston NorthEnd Hanover Street La 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(N
  ameService)
• NamingContext nc NamingContextHelper.narrow(name
  Ref)

12
The Naming Context

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

13
The NameComponent

• Each Name in a NamingContext is a sequence of
  NameComponent objectsstruct NameComponent
  Istring id //the name of the
  component Istring kind //a user-defined
  description
• A NameComponent is a single entry in a pathname,
  it might represent the local in /usr/local/bin.

14
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 NamingContextNameComponent
  nc1 new NameComponent(EasternUS, the good
  side)NameComponent nc2 new
  NameComponent(Massachusetts, ok
  state)NameComponent nc3 new
  NameComponent(Boston, now were
  talkin)NameComponent nc4 new
  NameComponent(NorthEnd, only place to
  go)NameComponent nc5 new NameComponent(Hanov
  erStreet, oh yes)NameComponent nc6 new
  NameComponent(LaPiccolaVenezia,
  aaaahhhh)NameComponent name nc1, nc2,
  nc3, nc4, nc5, nc6 NamingContext italian
  rootContext.bind_new_context(name)ItalianEateryI
  mpl piccolaVenezia new ItalianEateryImpl(MODERAT
  E_PRICE)italian.rebind(name, piccolaVenezia)

15
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 NamingContextNameComponent
  nc1 new NameComponent(EasternUS,
  )NameComponent nc2 new NameComponent(Massac
  husetts, )NameComponent nc3 new
  NameComponent(Boston, )NameComponent nc4
  new NameComponent(NorthEnd, )NameComponent
  nc5 new NameComponent(HanoverStreet,
  )NameComponent nc6 new NameComponent(LaPicc
  olaVenezia, )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_PAR
  MESAN)

16
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 Suns 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

17
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

18
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

19
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

20
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.

21
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.

22
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.