Introduction

• Computation model.
• Architecture.
• Interface Description Language.
• Dynamic interfaces and implementations.
• Interoperability

A Large Scale OO Approach

• An object-oriented computational model (Object model).
• A common interface language (OMG IDL).
• A networking and distribution infrastructure (Object Request Broker).
• Standard component interface libraries (CORBA Services and Facilities).

The CORBA Model

• Application developers design application (or business) objects.
• Objects have a server role, as they offer services, defined by object interfaces. Objects often have a client role too, as they use other objects, but usually the term ``object'' refers to the server role.
• A client application accesses an object through an object reference. The operations defined by the object interface are called through the reference, and they are independent of the object's physical location and the communication infrastructure.

Execution Semantics and Synchronization

• At-most-once: if an operation request returns successfully, it was performed exactly once; if it returns an exception indication, it was performed at-most-once.
• Best-effort: a best-effort operation is a request-only operation (i.e., it cannot return any results and the requester never synchronizes with the completion, if any, of the request).
• At-most-once operations are synchronous by default, but may also be invoked in deferred-synchronous mode, where the caller continues execution while the target object is processing of the request, and can later poll the target for the results.
• The deferred-synchronous mode is possible for requests issued through the Dynamic Invocation Interface.

The CORBA Architecture (1)

• provide clients with (server) object references;
• intercept requests (operation invocations) on object references;
• translate them into network messages and send them to the ``real'' (usually remote) objects.
• receive results from objects, re-format them and deliver them to the client application.

The CORBA Architecture (2)

• locate target objects (or create, or activate them if necessary);
• translate network messages back to operation invocations on objects;
• obtain results from objects;
• translate them into network messages and send them to the client application.

CORBA Architecture (3)

CORBA Architecture (4)

Objects, Servants, and Servers

• An object is really an abstract entity: a set of services described by an interface.
• An object is implemented by a servant, a piece of code whose execution provides the object's services. Often the term `object' is used when `servant' is meant.
• A server is a computer program that executes one or more servants. We think of objects as ``residing'' in servers.

Object Adapter

• Generation and interpretation of object references.
• Method invocation.
• Security of interactions.
• Object and implementation activation and deactivation.
• Mapping object references to the corresponding object implementations.
• Registration of implementations.

The Adapter pattern

The POA

• Enables portable (across different ORB's) object implementations.
• Supports either persistent or transient objects.
• Enables multiple object identities per servant.
• Enables multiple adapters per server.

Interface Description Language (1)

• IDL has no procedural statements (total implementation hiding!).
• IDL is (obviously) an OO language, with multiple inheritance.
• IDL is statically typed, but has a universal type any.
• Specification of exceptions (system- and user-defined) is supported.
• Language mappings provide a safe dynamic downcasting operation.

Interface Description Language (2)

• All CORBA components (ORB, CORBAservices, etc.) appear as objects defined by IDL interfaces. These objects are available as library modules.
• Application designers define objects in IDL.
• An IDL compiler generates, for each IDL interface, stub and skeleton source code, to be compiled and linked with the client and, respectively, the server code.
• It generates also a translation of the interface in the required programming language.

Example: banking

// account.idl

interface Account {
    void deposit( in unsigned long amount );
    void withdraw( in unsigned long amount );
    long balance();
};

interface Bank {
    Account create();
};

Banking: C++ mapping

/*  MICO --- a free CORBA implementation
 *  Copyright (C) 1997-98 Kay Roemer & Arno Puder */

// account.h

class Account : virtual public CORBA::Object {
public:
    virtual void deposit( CORBA::ULong amount ) = 0;
    virtual void withdraw( CORBA::ULong amount ) = 0;
    virtual CORBA::Long balance() = 0;
    // ...
};

Banking: client-side mapping

// Stub for interface Account
class Account_stub : virtual public Account {
public:
    void deposit( CORBA::ULong amount );
    void withdraw( CORBA::ULong amount );
    CORBA::Long balance();
    // ...
};

Banking client (C++)

main (int argc, char *argv[])
{ CORBA::ORB_var orb =
       CORBA::ORB_init(argc, argv, "mico-local-orb");
  // Connect to the Bank
  CORBA::Object_var obj = orb->bind("IDL:Bank:1.0");
  Bank_var bank = Bank::_narrow(obj);
  // Open an account
  Account_var account = bank->create();
  // Deposit and withdraw some money
  account->deposit(700);
  account->withdraw(450);
  printf("Balance is %ld.\n", account->balance ());
}

Banking client (UML)

Banking: server-side mapping (1)

class Account_impl : virtual public POA_Account {
public:
    void deposit (CORBA::ULong);
    void withdraw (CORBA::ULong);
    CORBA::Long balance ();
    // ...
};

Banking: server-side mapping (2)

class Bank_impl : virtual public POA_Bank {
    PortableServer::POA_var mypoa;
public:
    Bank_impl(PortableServer::POA_ptr);
    Account_ptr create();
};
Account_ptr Bank_impl::create()
{
    CORBA::Object_var obj =
         mypoa->create_reference("IDL:Account:1.0");
    Account_ptr aref = Account::_narrow(obj);
    return aref;
}

Banking server (C++) (1)

main (int argc, char *argv[])
{
  CORBA::ORB_var orb =
       CORBA::ORB_init(argc, argv, "mico-local-orb");
  // Obtain a reference to the RootPOA and its Manager
  CORBA::Object_var poaobj =
       orb->resolve_initial_references("RootPOA");
  PortableServer::POA_var poa =
       PortableServer::POA::_narrow(poaobj);
  PortableServer::POAManager_var mgr =
       poa->the_POAManager();
  // more POA setup...

Banking server (C++) (2)

  // more POA setup...
  // Create a Bank
  Bank_impl* micocash = new Bank_impl(mypoa);
  // Activate the Bank
  PortableServer::ObjectId_var oid =
      poa->activate_object(micocash);
  // Activate both POAs and start serving requests
  mgr->activate();
  orb->run();
}

Banking server (UML)

Dynamic Invocation Interface

• The interface of an object may not be known at compile time.
• A client may find out the details of an interface at run-time.
• The client may then use the Dynamic Invocation Interface to assemble a request ``on the fly'' and send it to the object.
• Dynamic invocations may be made in deferred synchronous mode: the caller executes in parallel with the target's processing of the request. The caller can later poll for the results.

Dynamic Skeleton Interface

• The Dynamic Skeleton Interface allows object requests to be delivered to objects whose interface is unknown to the (sever side) ORB at compile time.
• The DSI is particularly useful for gateways towards non-CORBA environments.
• The DSI is called by the Object Adapter.

Interface Repository

• The Interface Repository is a database containing IDL interface definitions.
• The IR may be dynamically accessed by ORB components, by clients, by object implementations, and other components, such as the IDL compiler.

Interoperability and Protocols

• The General Inter-ORB Protocol specifies the message formats and data representation used by communicating ORB's.
• GIOP can be implemented on top of various reliable connection-oriented transport protocols, such as Systems Network Architecture (SNA), Xerox Network Systems Internet Protocol (XNS/ITP), and Asynchronous Transfer Mode (ATM).
• The Internet Inter-ORB Protocol (IIOP) is the TCP/IP-based implementation of GIOP.
• Environment-Specific Inter-ORB Protocols (ESIOP) are built on top of existing environments, such as OSF DCE, and are optimized towards them.