SEG3100: Large Scale Software Development Common Object Request Broker Architecture Overview: (OO Middleware) Why CORBA:

CORBA is an OO middleware between an application and the network. Defines a set of Interfaces that an application developer can use in a standard way.

Applicatio n

Network CORBA

Motivation for CORBA:

Apply OO and Software engineering principles to network ( Large Scale) software development . Issues in Network programming: Create systems that are easier to model and build Too many interfaces and protocols: Approach: Abstract away lower-level OS and protocol specific details (Bridge Pattern?) Where things are: Location Transparency ( Broker Pattern) Information Hiding (OO, through Interface Definition Language, IDL) Solution: Use OO middleware: CORB Architecture = { Network related Patterns} + Standard

Advantage: In general, a software that implements CORBA standard shields applications from heterogeneous platform dependencies e.g., Hardware Languages Operating systems Protocols In particular It simplifies development of distributed applications by performing the following activities on behalf of the application. Object Location Connection & memory management. Event & request demultiplexing Error handling & fault tolerance Object/Server activation Concurrency Security Structure of CORBA:

Applicatio n

Network CORBA

Interface Repository

IDL Compiler

Implementatio n Repository

Overall View:

Object Services These are domain-independent interfaces that are used by many distributed object programs
o o

Naming Server -- Allows clients to find objects based on names or properties Event Notification Informs clients of changes to variables as a result of events

Common Facilities These help end-user applications for example, embedding and linking of different types of files, e.g spreadsheet object into a report document. Domain Interfaces: Interfaces for specific application domains: For example, telecommunication, ecommerce, medical, manufacturing. Application Interfaces Application specific interfaces. The OMG does not develop or provide full applications (only their specifications). These interfaces are not standardized.

CORBA ORB Architecture:

The following figure illustrates the primary components in the CORBA ORB architecture.

Figure 2. CORBA ORB Architecture

Client This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args).

Servant An implementation programming language entity for operations corresponding to the IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.

Object Request Broker (ORB) The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.

ORB Interface CORBA specifies an abstract interface for the ORB that can be implemented in various ways (such as one or more processes or a set of libraries).

This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through DII (Dynamic Invocation Interface).

IDL Stubs and Skeletons

CORBA IDL Stubs and Skeletons serve as the ``glue'' between the Client , Server and the ORB. The transformation between IDL definitions and the target programming language is done by the IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons.

Dynamic Invocation Interface (DII)

Applications can use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking (separate send and receive operations) and oneway (send-only) calls.

Dynamic Skeleton Interface (DSI)

This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing.

Object Adapter:

This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

Refs: http://www.omg.org/gettingstarted/ http://www.cs.wustl.edu/~schmidt/tutorials-corba.html

http://www.cs.wustl.edu/~schmidt/PDF/ORB-patterns.pdf