CORBA What is CORBA? CORBA (Common Object Request Broker - PDF document

BR 10/05 CORBA

What is CORBA? • CORBA (Common Object Request Broker Architecture) is a distributed object-oriented client/server platform. • It includes: – an object-oriented Remote Procedure Call (RPC) mechanism – object services (such as the Naming or Trading Service) – language mappings for different programming languages – interoperability protocols – programming guidelines and patterns • CORBA replaces ad-hoc special purpose mechanisms (such as socket communication) with an open, standardized, scalable, and portable platform BR 10/05

The Object Management Group (OMG) • Founded 1989 to create specifications for open distributed computing. • World‘s largest software consortium with 457 member organizations (2005) • CORBA (Common Object Request Broker Architecture) – CORBA 1.0 (1991): Object Request Broker, IDL, C – CORBA 2.0 (1995): Interoperability, C++ – CORBA 3.0 (2002): Components, Scripting, Real-time • UML: Unified Modelling Language • MDA: Model Driven Architecture BR 10/05

What is Client/Server Computing? • A group of clients and servers cooperate in solving a problem • Servers are passive entities,providing a service, and wating for requests from clients • Clients are active entites, requesting a service from the server • Clients and servers run (typically) as operating system processes on different computers • Object-oriented client/server computing adds OO aspects: interfaces, messages, inheritance, and polymorphism. BR 10/05

Advantages & Disadvantages of CORBA • Advantages: – vendor-neutral and open standard, portable, wide variety of implementations, hardware platforms, operating systems, languages – takes the grunt work out of distributed programming • Disadvantages: – no reference implementation – specified by consensus and compromise – not perfect BR 10/05

Heterogeneity CORBA works for homogenous and heterogenous environments. Characteristics of heterogenous environments are: – Language transparency – Location transparency – Service transparency – Implementation transparency – Architecture transparency – Operatingsystem transparency – (Protocol transparency) – (Transport transparency) BR 10/05

The Object Management Architecure (OMA) Application Domain Interfaces Interfaces Object Request Broker Object Services BR 10/05

Objects • Object: encapsulated entity with immutable specific identity, interacts only through well-specified interfaces • CORBA object ≠ Java object(language-specific object) – A single Java object can implement multiple CORBA objects – A CORBA object can successively be implemented (incarnated) through multiple Java objects – Most simple case: one-to-one relationship between CORBA objects and Java objects (servants) BR 10/05

Interfaces • Interface: Set of operations – Object services: Interfaces required in many applications independently from application domain • Horizontal services, infrastructure services – Domain interfaces: standardized interfaces for services specific to an application area • Vertical services – Application interfaces: specific for the application, not standardized • Interfaces are defined using IDL (Interface Definition Language) BR 10/05

ORB: Object Request Broker Object in args Client operation() OBJ (Servant) REF out args + return IDL DSI SKEL IDL ORB DII Object Adapter STUBS INTERFACE ORB CORE GIOP/IIOP/ESIOPS BR 10/05

Remote Object Invocation Client Application Server Object Skeleton interface (dynamic or IDL-generated) Stub interface (dynamic or Object Adaptor IDL-generated) Object Request Object Request Broker (ORB) Broker (ORB) BR 10/05

Request Invocation • Client sends a request: – Client ORB analyses object reference – Connects to server if necessary – Sends request: (target object, operation name, parameters) • ORB receives request: – Activates server (if no server active) – Activates target servant (if no servant active) – Invokes method, waits for completion – Sends reply(if required) • Method semantics: – At-most-once: exception in case of error – Best effort (oneway) BR 10/05

The Object Request Broker and the Object Adaptor • The core of CORBA is the Object Request Broker (ORB) – Each machine involved in a CORBA application must have an ORB running in order for processes on that machine to interact with CORBA objects running in remote processes. – Object clients and servers make requests through their ORBs – the ORB is responsible for making the requests happen or indicating why they can't. • The client ORB provides a stub for a remote object. – Requests made on the stub are transferred from the client's ORB to the ORB servicing the implementation of the target object. – The request is passed on to the implementation through an object adaptor and the object's skeleton interface. BR 10/05

The Skeleton interface • The skeleton interface is specific to the type of object that is exported remotely through CORBA. – provides a wrapper interface that the ORB and object adaptor can use to invoke methods on behalf of the client or as part of the lifecycle management of the object. – The object adaptor provides a general facility that "plugs" a server object into a particular CORBA runtime environment. (BOA vs. POA) • All server objects can use the object adaptor to interact with the core functionality of the ORB, – the ORB can use the object adaptor to pass along client requests and lifecycle notifications to the server object. – Typically, an IDL compiler is used to generate the skeleton interface for a particular IDL interface; this generated skeleton interface will include calls to the object adaptor that are supported by the CORBA environment in use. BR 10/05

Interoperability • IOR: Interoperable Object Reference • CDR: Common Data Representation • GIOP: General Inter-ORB Protocol • IIOP: Internet Inter-ORB Protocol • Alternative protocols: – ESIOP: Environment-specific Inter-ORB protocols • DCE-CIOP – SCCP (Signalling Control Part) IOP – Pluggable Protocols BR 10/05

Object Reference • Every reference identifies exactly one object • Different references may refer to the same object • References may be „nil“ (point nowhere) • References may become invalid ( dangle ): The object referred-to has already disappeared • References are opaque – –Note: „Interoperable Object References“ (IOR) • References are strongly typed. • References allow late binding. • References may be persistent. BR 10/05

Object Services • Naming Service (CosNaming) • Trader (CosTrading) • Property Service (CosPropertyService) • Event Service (CosEventComm, CosEventChannelAdmin) • Notification Service (CosNotification) • ... • (Transactions) • (Persistency) (PSS: Persistent State Service) BR 10/05

Inter-CORBA Communication • CORBA v.2.0 standard includes specifications for inter-ORB communication protocols that can transmit object requests between various ORBs running on the network. – independent of the particular ORB implementations running at either end of the communication link. – An ORB implemented in Java can talk to another ORB implemented in C, as long as use the same CORBA communication protocol. – The inter-ORB protocol is responsible for delivering messages between two cooperating ORBs (method requests, return types, error messages, etc.) – The inter-ORB protocol also deals with differences between the two ORB implementations, like machine-level byte ordering and alignment. • The Internet Inter-ORB Protocol (IIOP) is an inter-ORB protocol based on TCP/IP. – TCP /IP is by far the most commonly used network protocol on the Internet, so IIOP is the most commonly used CORBA communication protocol. – There are other standard CORBA protocols defined for other network environments, however( e.g.; DCE Common Inter-ORB Protocol - DCE-CIOP), BR 10/05