CST(64)-Object Management Architecture :

The four main elements of the architecture are  Object request Broker  Common Object services  Common facilities  Application Obje...

The four main elements of the architecture are

1.  Object request Broker
2.  Common Object services
3.  Common facilities
4.  Application Objects

The object request broker :

ORB is a bus .It lets objects transparently make a request and to receive responss from other objects which are located globally and locally . ORB is a better alternative for remote procedure call, message oriented middleware.

Benefits of ORB :

1.  The methods can be invoked statically at compile time or dynamically at run time.
2.  The choice of the implementation of the objects of the server is neutral.
3.  It is a self describing system and provides runtime meta data for describing every server interface known to the system. It also helps to generate code on the fly. The metadata is generated automatically so that the method in which the IDL can be generated from a object oriented language.
4.  It can provide a local and remote transparency. An ORB can run in a standalone computer or in a laptop or it can be interconnected to every orb in the universe.
5.  A CORBA programmer need not be concerned with transports , server locations , object activation and platform in which the object is running.
6.  The ORB includes context information on its messages to handle security and transactions across ORB boundaries.
7.  The same function call will have different effects depends on the object it receives.

Anatomy of CORBA 2.0 ORB :
A CORBA object Request Broker is the middleware that establishes the client server relationships with objects. Using ORB the client invokes the server objects transparently. ORB receives the call and makes necessary arrangements for results to be returned.

Client Side of CORBA :

These precompiled stubs provide static interfaces to object services. It is a local proxy to the remote server object. A client must have an IDL stub for each interface it is using. It also includes header files that enables you to invoke the method on the server from a higher level language like C , C++ or small talk.

Dynamic invocation interface :

This lets us to discover methods to be invoked at run time.

Interface repository API :

It allows you to obtain and modify the description of all component interfaces the methods they support and parameters they require . CORBA calls these descriptions method as signatures.

ORB interface :

ORB interface consists of a few API to local services that may be of interest to an application.

Server Side CORBA :

Server IDL stubs :

This provides interfaces to each service exported by the server. It is created by some IDL compilers.

Dynamic Skeleton Interface :

It provides a run time mechanism for servers that need to handle incoming method calls for components that do not have IDL based compiled skeletons.

Object adapter :

It sits on the top of the ORB core communication services and accepts request for services on behalf of the server objects. It provides run time environment for intiating server objects.

Implementation repository :

It provides a run time repository of the information about the classes it supports. The examples are trace information , security and other administrative data.

ORB interface :

It consists of a few API s to local, services that are identical t those provided on the client side.

CORBA object Services :

• A life cycle service defines the operations for creating , copying , moving and deleting components on the bus.
• Persistence service provides a single interface for storing components persistently on a variety of storage servers including object databases.
• The naming service allow components to locate other components on the bus to dynamically register or un register their interest in specific events.
• The concurrency control service provides a lock manager that can obtain locks on behalf of either transactions or threads.
• The transactions service provides two phase commit co ordination among recoverable components.
• Relationship service provides a way to create dynamic associations between components that know nothing of each other.
• Externalizations service provides a standard way of getting data into and out of a component using stream like mechanism.
• The query service provides query operations for objects.
• The licencing service operations for metering the use of components.
• The property service provides operations to let you associate named values with any component
• The timeservice provides interfaces for synchronizing time in a distributed object environment.
• The security service provides a complete frame work for distributed object security.

Security Constraints for Distributed objects :

•  Distributed objects play both server and client role , a server can be trusted and client cannot be.
•  Distributed objects evolve continually because of sub classing and components are composed at runtime without the knowledge of the programmer.
•  Distributed object interactions are less predictable.
•  Distributed object interactions are not well understood of encapsulation.
•  Distributed objects are polymorphic Trojan horses makes things miserable.
•  Distributes object can scale without limit and we cannot fix the access privileges.
• Distributed objects are very dynamic object gets treated automatically and released automatically.