Common Object Request Broker Architecture

Basic Terms with CORBA

OMG

Object Management Group

Interface Definition Language Object Request Brokers Internet Inter ORB Protocol

IDL

ORB IIOP

: :

Object Management Group

CORBA specification was developed by the Object Management Group (OMG).
The OMG is an international, not-for-profit group consisting of approximately 800 companies and organizations defining standards for distributed object computing They are also behind other key object oriented standards such as UML (Unified Modeling Language).

Object Request Brokers

Responsible for all communication between clients

and objects Data Exchange between objects Interpretability of distributed objects Two ORB Technologies: CORBA Microsoft COM

Interface Definition Language

Defines public interface for any CORBA server.
C++ like syntax Client and Server implementation Defined mappings for:
C, C++, Java, COBOL, Smalltalk, ADA, Lisp, Python, and IDLscript

Internet Inter ORB Protocol

Critical part of CORBA
Used to communicate over the Internet Independent of location other than Service and name Assume Client-Server Model of Computing

Remote Interprocess Communication

Benefits Of Corba

Language Independence.
Operating System Independence. Freedom From Technology. Strong Data Typing.

High Tune Ability.

Freedom From Data Transfer Details.

Problems and Criticism

Fundamental flows: CORBAs notion of location transferancy has been criticised i.e. Objects residing in the same address space and accessible with simple function are treated as object residing elsewhere. This, indicates that all local accesses became complex as access to remote objects. Firewalls: CORBA uses binary formats to transmit data which is more efficient then textual format but it is difficult to get binary messages through firewalls, it is even difficult to force implementation to use a single standard port they tended to use making random ports.

 Design and process deficiencies:

CORBA standard is designed by a committee. The design committee is composed by number of vendors for standard implementation. Thus, this standard was created by taking unions of the features in all proposals. These made the specification long complex and expensive and due to interpretability computation increase and needs lead to movement between alternative implementations. This lead to political fighting within the committee and frequent releases of CORBA standard which were impossible to use without proprietary extensions.

Problems with implementation:

Working implementations of CORBA have been very difficult to acquire in the past but much easier to find now some poorly designed implementations are complex, slow, incompatible and incomplete. Some commercial versions can be very expensive. The advent of Java, soon after CORBAs introduction become a problem in CORBA implementation. Since Java has been the hot item, new systems could be developed in java alone and thus RMI could be used exclusively.

CORBA vs. RMI

CORBA interfaces are defined in IDL and RMI

interfaces are defined in java. RMI-IIOP allows you to write all interfaces in java. CORBA supports in and out parameters, while RMI does not since local objects are passed by copy and remote objects are passed by reference.

 CORBA was designed with language independence in

mind. Therefore CORBA is an ideal mechanism for bridging islands between different programming languages where as RMI was designed with single language, where all objects are written in java.
CORBA objects are not garbage collected where as RMI

objects are garbage collected automatically.

CORBA2.0: The Inter-ORB Architecture

1. GIOP: General Inter-ORB Protocol

It specifies the set of messages of formats and common data representations for communications between ORBs. It was specially built for ORB-ORB interactions. It was designed to work directly over any connection-oriented transport protocol. GIOP defines seven messages formats that cover all the ORB request/reply semantics.

 In most cases, clients send a request to objects

immediately after they open a connection. The Common Data Representation(CDR) maps data types defined in OMG IDL into flat, networked message representation. CDR takes care of inter-platform issues such as byte ordering (no byte swapping is needed) and memory alignments.

2.IIOP: Internal Inter-ORB Protocol It specifies how GOIP messages are exchanged over a TCP/IP network. The IIOP makes possible to use the internet itself as backbone ORB through which other ORBs can bridge. It was designed to be simple and provide out-of-thebox interoperation for TCP/IP based ORBs.

 Both the IIOP and DCE/ESIOP have built-in

mechanisms for implicitly transmitting context data that is associated with the transaction or security services. The ORB takes care of passing these requests without your applications involvement.

3. ESIOPs: Environment Specific Inter ORB Protocol Is used for out-of-the-box interoperation over specific networks. CORBA 2.0 specifies DCE as the first of many optional ESIOPs. The ESIOP provides a robust environment for mission critical ORBs.

 It includes advanced features like Kerberos security,

cell and global directories , distributed, time, and authenticated RPC. It also let you transmit large amount of data efficiently. You can use both connection and connection-less protocols for your ORB communications.

CORBA SERVICES
1- naming service provides the ability to bind a name to an object relative to a naming context (like a telephone directory) 2- event service provides asynchronous interactions between anonymous objects 3- notification service it enhances the event service by supplying not only the event features but also structured types and varying degree of control over the quality of service that an event channel provides 4-life cycle service it deals with life,death and relocation of objects.

5-the persistent object service(pos) allows objets to "persist" beyond the application that creates the object or the client that use it. 6- object transaction service(OTS) defines interface that allows multiple, distributed objects to cooperate in order to provide atomicity 7- concurrency control service enables multiple clients to coordinate their access to shared resources

8- relationship service allows components and objects that know nothing of each other to be related
9- externalization service defines protocols and conventions for externalizing and internalizing objects. externalization an object is to record the object state in a stream of data , which can then be internalized into a new object in the same or different process 10- licensing services provides a mechanism for producers to control the use of thier intellectual properties

11- query service allows users and objects to invoke queries on collections of other objects several query languages can be used (eg:- SQL) 12-property service provides the ability to dynamically associate named values with objects outside the static IDL-type system (eg:- to add an archive property to an existing document at run time and mark the document as ready to be archived. this archived information is associated with the object bit is not part of the object's type) 13- time service enables users to obtain current time together either an error estimate associated with it 14- trader service allows users to discover objects based on the services they provide (eg:- like yellow pages)

15- collection service allows the user to manipulate objects in a group 16- security service comprises the following services: identification and authentication authorization acces control security of communication etc

CORBA FACILITIES - corba facilities are collection of IDL defined framework that provides services of direct use to appication objects - two categories of commmon facilities are:a) horizontal b) vertical - they define the rules of engagement that business components need to effectively collaborate - in oct 1994 ,OMG issued the common facilities request for proposal 1 - in march 1996, OMG adopted open doc as its compound document technology - the common facilities that are currently under construction include mobile agents, data interchange, business object framework and internationalization

- this work will continue until corba provides IDL interface for virtually every networked service

CORBA pros and cons

CORBA is gaining strong support from developers, because of its Ease of use, Functionality, and Portability across language and platform . It is particularly important in large organizations, where many systems

must interact with each other, and legacy systems can't yet be retired. another - its only limitation is that a language must have a CORBA implementation written for it. it an attractive option for systems that are accessed by users who require real-time interaction.

It provides the connection between one language and platform and

It also appears to have a performance increase over RMI, which makes

PROS:
Different languages Different Platforms Any language with an IDL(Interface Definition Language) With IDL, the interface is clearly separated from implementation, and

developers can create different implementations based on the same interface.

Supports primitive data types, and a wide range of data structures, as

parameters

CORBA is an easy way to link objects and systems together which may

offer greater

performance.

CONS:
X

Writing one for a language that isn't supported would take a large amount of work. Integrity Issue: IDL to language mapping tools create code stubs based on the interface - some tools may not integrate new changes with existing code. CORBA does not support the transfer of objects, or code. The future is uncertain - if CORBA fails to achieve sufficient adoption by industry, then CORBA implementations become the legacy systems. Some training is still required, and CORBA specifications are still in a state of flux.