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

BR 10/05

CORBA

BR 10/05

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
• rganizations (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 Interfaces Object Services Domain Interfaces Object Request Broker

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

Client

OBJ REF

Object (Servant)

in args

• peration()
• ut args +

return

DII IDL STUBS ORB INTERFACE IDL SKEL DSI Object Adapter ORB CORE GIOP/IIOP/ESIOPS

BR 10/05

Remote Object Invocation

Server Object Stub interface (dynamic or IDL-generated) Object Request Broker (ORB) Object Adaptor Object Request Broker (ORB) Skeleton interface (dynamic or IDL-generated) Client Application

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

• bjects 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),