Transcript alegriaCorba

Alegria Baquero

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


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)


Objects can be written in different languages
Mappings available for many languages




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

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




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



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.



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

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)


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

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




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


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.

RMI  Remote Method Invocation

Is an alternative option to using IDL

Uses also IIOP to implement a CORBA

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

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







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-.