CORBA Alegria Baquero

Introduction CORBA  Common Object Request Broker Architecture A project of Object Management Group (OMG) CORBA is an OO distributed communication middleware Mediates the communication between distributed objects ORB  the object-oriented version of a RPC An object is an encapsulation of data and functionality

What is CORBA for? Invoking methods on objects in a local or remote host (in the same or in different machines) Make autonomous applications communicate with each other Connects objects across a network Objects can live on different platforms (OS) calls on objects, not to a server process

CORBA and component heterogeneity Objects can be written in different languages Mappings available for many languages

What are CORBA’s strengths? Simplifies programming of distributed systems Can support a large number of clients invoking an object method Location transparency It is not necessary to know in what language an object or CORBA service is written

What are CORBA’s strengths? Easy integration with other technologies (e.g. legacy systems) Wide platform and language support Scalability  able to manage an unlimited number of objects Efficient transmission over the network by converting programming language to a binary buffer

CORBA in more detail No strict differentiation between client and server. A computer can be both client and server. Client  calls object; Server  contains object Every object instance has a unique reference to be able to communicate with it. IOR (Interoperable Object Reference)  a common format for object references exchanged over IIOP IOR contains one or more profiles. Profile describes how a client can send requests to an object using a particular protocol. One profile is IIOP.

CORBA in more detail It a synchronous way of communication CORBA has a collection of services (libraries) that provide functionality to extend basic CORBA Uses the Internet Inter-ORB Protocol (IIOP) for distributed programs to communicate over the internet. IIOP  Connects ORB with ORB

The architectural style The constraints that CORBA enforces belong to the “distributed objects” architectural style Distributed objects is a mix of object-oriented style with client-server style One of these constraints is the serialization of parameters for an effective communication

GIOP (General Inter-ORB Protocol) IIOP (Internet Inter-ORB Protocol) Protocol by which ORBs communicate IIOP is a GIOP specific for TCP/IP communication GIOP + TCP/IP = IIOP Common misconception  IIOP is something separate that the developer needs to write. An ORB already incorporates IIOP IIOP  defines a set of data formatting rules  Common Data Representation (CDR)

GIOP (General Inter-ORB Protocol) IIOP (Internet Inter-ORB Protocol) CDR  tailored to the data types supported in the CORBA Interface Definition Language With CDR  IIOP defines a set of message types that support ORB semantics defined in the CORBA core specification

What is an IDL and what is it for? Interface Description Language  a specification language to describe component’s interfaces Defines the public application programming interface (API) to access objects in a server For each object an IDL interface is defined, and it represents a contract to invoke methods on the object IDL is language independent, but can be mapped to many languages like C, C++ or Java An IDL compiler translates IDL into the equivalent in the chosen programming language languages supported: C, C++, Java, Smalltalk, Ada, COBOL, PL/I, LISP, Python IDL – similar to a Java interface IDL definitions  struct, union, sequence

where does IDL stand... The client thinks it is invoking the object instance on the server, but it is actually invoking the IDL stub Stub uses inter-process communication mechanisms like TCP/IP sockets to transmit the request and receive a reply

more on IDL… IDL language-independence enables interoperability and transparency An IDL interface can include operations and attributes (getters and setters) IDL code is compiled into client stubs and object skeletons which serve as proxies (acting in behalf of something) Stubs and skeletons are as well created by the IDL compiler

more on IDL… Skeleton  receives incoming requests and translates to the application domain When a method is called on the object, the calling parameters are serialized (transformed into binary data) to cross the network. To create an object in a different server, the client needs to invoke a function in the server which creates the object. How to reference an object? A “naming service” maintains a directory of objects to call the up by name. The skeleton receives it, rebuilds the request and makes the call on the object. Strong data type system to prevent errors.

Java RMI RMI  Remote Method Invocation Is an alternative option to using IDL Uses also IIOP to implement a CORBA

Portable Object Adapter (POA) Is a mechanism to connect a request with to the code to process it Is a standard component defined by the CORBA specification Goal  build objects that can be supported in different ORBs Assists an ORB in delivering client requests to server object implementations (servants) Generates and interprets object references Portability achieved by standardizing skeletons classes that are generated by the IDL compiler Deactivates idle objects' servants; activates them when needed

ORB vendors Orbix (IONA)  Enterprise CORBA Orbacus (IONA)  small footprint, embeddable CORBA Visibroker (Borland)  for Java, C++, C#. MICO (ObjectSecurity)  available as GNU open source software ORBexpress (Objective Interface Systems)  a real-time ORB ORBit (GNOME) for C, C++ and Python OmniORB  for C++ and Python opalORB  for Perl JacORB for Java OmniBroker  for non-commercial use. C++ and Java

References www.omg.org Common Object Request Broker Archictecture, OMG, July, 1995. www.wikipedia.org http://www.ciaranmchale.com/corba-explained-simply/ Taylor et. al. (2008). Software Architectures: Foundations, Theory and Practice. java.sun.com Pyarali, I. (1998). An overview of the CORBA portable object adapter. StandardView, 6(1), 30-.