CORBA Middleware Technology A communications layer that allows applications to interact across hardware and network environments OR In the

computer industry, middleware is a general term for any programming that serves to "glue together" or mediate between two separate and often already existing programs. Distributed Applications CORBA products provide a framework for the development and execution of distributed applications. But why would one want to develop a distributed application in the first place? As you will see later, distribution introduces a whole new set of difficult issues. However, sometimes there is no choice; some applications by their very nature are distributed across multiple computers because of one or more of the following reasons: The data used by the application are distributed The computation is distributed The users of the application are distributed Data are Distributed Some applications must execute on multiple computers because the data that the application must access exist on multiple computers for administrative and ownership reasons. The owner may permit the data to be accessed remotely but not stored locally. Or perhaps the data cannot be co-located and must exist on multiple heterogeneous systems for historical reasons. Computation is Distributed Some applications execute on multiple computers in order to take advantage of multiple processors computing in parallel to solve some problem. Other applications may execute on multiple computers in order to take advantage of some unique feature of a particular system. Distributed applications can take advantage of the scalability and heterogeneity of the distributed system. Users are Distributed Some applications execute on multiple computers because users of the application communicate and interact with each other via the application. Each user executes a piece of the distributed application on his or her computer, and shared objects, typically execute on one or more servers. Co-located applications VS Distributed Systems Distributed application developers must address a number of issues that can be taken for granted in a local program where all logic executes in the same operating system process. The following table summarizes some of the basic differences between objects that are co-located in the same process, and objects that interact across process or machine boundaries. The communication between objects in the same process is orders of magnitude faster than communication between objects on different machines. The implication of this is that you should avoid designing distributed applications in which two or more distributed objects have very tight interactions. If they do have tight interactions, they should be co-located. When two objects are co-located, they fail together; if the process in which they execute fails, both objects fail. The designer of the objects need not be concerned with the behavior of the application if one of the objects is available and the other one is not. But if two objects are distributed across process boundaries, the

objects can fail independently. In this case, the designer of the objects must be concerned with each of the object's behavior in the event the other object has failed. Similarly, in a distributed system the network can partition and both objects can execute independently assuming the other has failed. The default mode for most local programs is to operate with a single thread of control. Single threaded programming is easy. Objects are accessed in a well-defined sequential order according to the program's algorithms, and you need not be concerned with concurrent access. If you decide to introduce multiple threads of control within a local program, you must consider the possible orderings of access to objects and use synchronization mechanisms to control concurrent access to shared objects. But at least you have a choice of introducing multiple threads of control. In a distributed application, there are necessarily multiple threads of control. Each distributed object is operating in a different thread of control. A distributed object may have multiple concurrent clients. As the developer of the object and the developer of the clients, you must consider this concurrent access to objects and use the necessary synchronization mechanisms. When two objects are co-located in the same process, you need not be concerned about security. When the objects are on different machines, you need to use security mechanisms to authenticate the identity of the other object. Co-located Communication Failures Concurrent access Secure What is CORBA? CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate. It is not an application/ product of a company but it is a specification for developing distributed applications. CORBA or Common Object Request Broker Architecture is a language-independent object model and specification for a distributed applications development environment. The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers. Advantages of CORBA (Ref. Sem VI Internet Technology book) 1. 2. 3. 4. Language independence : Using IDL(Interface Definition Language) Support for heterogeneous networks / Hardware independence Location transparency : clients and objects are not directly aware of each others locations within the network., allowing relocation of one(or both) with no impact on the other. Interoperability : ORB-to-ORB communication Fast Objects fail together Distributed Slow Objects fail separately Network can partition No

Only with multiple threads Yes Yes

Diagrams in next sections . Developing distributed applications using interface and stub-skel (Ref to Internet Technology book)

Components of CORBA 1. IDL

Language independent interfaces which are mapped to particular language using IDL-to-Language mapping. Different languages support different types data. Their lengths also differ. CORBA also offers data types which are common in all language and takes care of their sizes. (Diagram)

Hello.idl module HelloApp { interface Hello { string sayHello(); }; }; 2. ORB(Object Request Broker)

The Object Request Broker(ORB) software that handles the communication between objects in a distributed computing environment. ORB is the part of the CORBA specification that manages the interaction between clients and servers. The specification defines the architecture of interfaces and services that must be provided by the ORB. (Diagram)

3.

IIOP / Inter-ORB Architecture

In distributed computing, GIOP (General Inter-ORB Protocol) is the abstract protocol by which Object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG). IIOP (Internet Inter-Orb Protocol) is the implementation of GIOP for TCP/IP. The Object Management Group defines three parts of GIOP: (i) The Common Data Representation (CDR) - transfer syntax mapping OMG IDL data types into a low-level representation (ii) Interoperable Object Reference (IOR) - define the format of a reference to a remote object. The typical IOR usually contains the protocol version, server address and a byte sequence identifying the remote object (object key). (iii) Defined message formats - messages are exchanged between agents to facilitate object requests, locate object implementations, and manage communication channels. The different types(7)of messages are : request, reply, cancelrequest, closeconnection, fragment etc. There is one more type, Environment Specific IOP that allows to define optimized/specific protocols. This is a protocol-level interoperability standard. ESIOP provide a means for CORBA to interoperate with nonCORBA applications and toolkits. For example, an ESIOP is the DCE (Distributed Computing Environment is the Open Software Foundation's solution to the problems of interconnectivity in a heterogeneous computing environment, standards and security) Common Inter-ORB Protocol(DCE-CIOP). This protocol uses the DCE remote procedure call (RPC) mechanism to transport messages between DCE and CORBA whereas message formatting, marshalling of data etc can be performed by a CORBA ORB. OMA Architecture (Diagram)

1. ORB ( Ref to above notes)

An Object Request Broker (ORB) provides a communication infrastructure for invoking operations on objects transparently with respect to where they are located on the network, the types of hardware and operating system platforms on which they execute, differences in data representations between platforms, the languages in which objects are implemented, and network transports used to communicate with them. CORBA specifies all of the functions that must be provided by an ORB and a set of standard interfaces to those functions. 2. CORBA Common Facilities CORBA Facilities are useful for constructing applications across a wide range of application domains. They are divided into Horizontal CORBA Facilities, which are typically more user-oriented, and Vertical CORBA Facilities, which support specific application domains. The Horizontal CORBA Facilities currently identified by OMG are grouped into four areas:

User Interface Facilities, which include Compound Presentation, Desktop Management, Rendering Management, Scripting, and User Support Facilities. Information Management Facilities, which include Compound Interchange, Data Encoding and Representation, Data Interchange, Information Exchange, Information Modeling, Information Storage and Retrieval, and Time Operations Facilities. System Management Facilities, which include Collection Management, Consistency, Customization, Data Collection, Event Management, Instance Management, Instrumentation, Policy Management, Process Launch, Quality of Service Management, Scheduling Management, and Security Facilities. Task Management Facilities, which include Agent, Automation, Rule Management, and Workflow Facilities.

The Vertical CORBA Facilities currently identified by OMG are: Accounting, Application Development, Computer Integrated Manufacturing, Currency, Distributed Simulation, Imagery, Information Superhighways, Internationalization, Mapping, Oil and Gas Exploration and Production, Security, and Telecommunication. However many of these exist in theory and hardly few have been actually implemented. 3. CORBA Services CORBA Services are services that are essential for implementing objects. The CORBA Services that have been specified thus far by OMG include:

A Concurrency Control Service that protects the integrity of an object's data when multiple requests to the object are processed concurrently. An Event Service that supports the notification of interested parties when program-defined events occur. An Externalization Service that supports the conversion of object state to a form that can be transmitted between systems by a means other than a request broker. Life Cycle Services that support creation, copying, moving, and destruction of objects. A Naming Service that permits object references to be retrieved through associations between names and objects, and for those associations to be created and destroyed. A Persistent Object Service that supports the persistence of an object's state when the object is not active in memory and between application executions. A Query Service that supports operations on sets and collections of objects that have a predicate-based, declarative specification and may result in sets or collections of objects.

A Relationship Service that provides for creating, deleting, navigating, and managing relationships between objects (for example, a containment relationship between a "folder" object and the "document" objects that are considered to be "in" that folder). A Transaction Service that provides support for ensuring that a computation consisting of one or more operations on one or more objects satisfies the requirements of atomicity (if a transaction is interrupted by a failure, any partially completed results are undone), isolation (transactions are allowed to execute concurrently, but the results are the same as if they executed serially), and durability (if a transaction completes successfully, the results of its operations are never lost, except in the event of catastrophe). A Security Service that will support authentication, authorization, integrity, and privacy to degrees, and using mechanisms, that are yet to be determined. A Time Service that will provide synchronized clocks to all objects, regardless of their locations. A Change Management Service that would support the identification and consistent evolution of configurations of objects. A Collection Service that would support the creation and manipulation of collections of objects. A Data Interchange Service that would support the exchange of data between objects. A Replication Service that would provide for the explicit replication of objects in a distributed environment (for the purpose of availability or fault tolerance) and for the management of consistency of replicated copies. A Trader Service that would provide a matchmaking service between clients seeking services and objects offering services.

The difference between CORBA facilities and Services is that the facilities deal with interoperability issues whereas services are focused on enabling capabilities. 4. Application Objects / Business Objects Business objects provide a natural way for describing application-independent concepts such as customer, order, payment, car, patient etc. It represents a recognizable everyday lift entity. In contrast, systemlevel objects represent entities are only meant for information systems and programmers. Business objects are used to design systems that involve the business processes they support. They should be able to bind themselves to appropriate interfaces. It also can be accessed using IDL and can be developed independently. Business objects must have late and flexible binding and well-defined interfaces, so that they can be implemented independently. Business objects can be of 3 types : (i) Business objects : They encapsulate the storage, metadata, concurrency, etc. They also define how the object react to changes in the views or model. (represents Model of MVC pattern) (ii) Business process object : They encapsulate the business logic at the enterprise level (represents Controller in MVC pattern). (iii) Presentation objects : They represent the objects visually to the user Each business object can have multiple representations for multiple purposes(represents view of MVC pattern). Generally, Server contains Business and process objects. Clients have presentation objects. (Diagrams)

Structure/Anatomy of an Object Request Broker The following figure shows a request being sent by a client to an object implementation. The Client is the entity that wishes to perform an operation on the object and the Object Implementation is the code and data that actually implements the object. The ORB is responsible for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect which is not reflected in the object's interface. To make a request, the Client can use the Dynamic Invocation interface (the same interface independent of the target object's interface) or an OMG IDL stub (the specific stub depending on the interface of the target object). The Client can also directly interact with the ORB for some functions. The Object Implementation receives a request either through the OMG IDL generated skeleton or through a dynamic skeleton. The Object Implementation may call the Object Adapter and the ORB while processing a request or at other times. Definitions of the interfaces to objects can be defined in two ways. Interfaces can be defined statically in an interface definition language, called the OMG Interface Definition Language (OMG IDL). This language defines the types of objects according to the operations that may be performed on them and the parameters to those operations. Alternatively, or in addition, interfaces can be added to an Interface Repository service; this service represents the components of an interface as objects, permitting runtime access to these components. In any ORB implementation, the Interface Definition Language and the Interface Repository have equivalent expressive power. The client performs a request by having access to an Object Reference for an object and knowing the type of the object and the desired operation to be performed. The client initiates the request by calling stub routines that are specific to the object or by constructing the request dynamically. The dynamic and stub interface for invoking a request satisfy the same request semantics, and the receiver of the message cannot tell how the request was invoked. The ORB locates the appropriate implementation code, transmits parameters and transfers control to the Object Implementation through an IDL skeleton or a dynamic skeleton Skeletons are specific to the interface and the object adapter. In performing the request, the object implementation may obtain some services from the ORB through the Object Adapter. When the request is complete, control and output values are returned to the client. The Object Implementation may choose which Object Adapter to use. This decision is based on what kind of services the Object Implementation requires. The interface is defined in OMG IDL and/or in the Interface Repository; the definition is used to generate the client Stubs and the object implementation Skeletons. The object implementation information is provided at installation time and is stored in the Implementation Repository for use during request delivery. Client-Side 1. Clients

A client of an object has access to an object reference for the object, and invokes operations on the object. A client knows only the logical structure of the object according to its interface and experiences the behavior of the object through invocations. Although we will generally consider a client to be a program or process initiating requests on an object, it is important to recognize that something is a client relative to a particular object. For example, the implementation of one object may be a client of other objects. Clients generally see objects and ORB interfaces through the perspective of a language mapping. Clients are maximally portable and should be able to work without source changes on any ORB that supports the desired language mapping with any object instance that implements the desired interface. Clients have no knowledge of the implementation of the object, which object adapter is used by the implementation, or which ORB is used to access it.

2.

Client IDL Stubs

It provides static interface to object services. From the perspective of client, stub is the local proxy for the remote server. It includes code to perform marshalling. It also includes files that enable you to invoke method on server object. Generally, the stubs will present access to the OMG IDL-defined operations on an object. The stubs make calls on the rest of the ORB using interfaces. 3. Dynamic Invocation Interface

It allows you to discover method to be invoked at run time. This interface allows the dynamic construction of object invocations, that is, rather than calling a stub routine that is specific to a particular operation on a particular object, a client may specify the object to be invoked, the operation to be performed, and the set of parameters for the operation through a call or sequence of calls. The client code must supply information about the operation to be performed and the types of the parameters being passed (perhaps obtaining it from an Interface Repository or other runtime source). The nature of the dynamic invocation interface may vary substantially from one programming language mapping to another. 4. Interface Repository

It represents service to support the storage and management of information about interfaces to objects. The services resemble those provided by the data dictionary/repository services in the Data Management service category. It allows you to obtain and modify the descriptions of all the registered component interfaces, the methods they support and the parameters they require. It contains machine-readable versions of the IDL-defined interfaces. The Interface Repository information may be used by the ORB to perform requests. Moreover, using the information in the Interface Repository, it is possible for a program to encounter an object whose interface was not known when the program was compiled, yet, be able to determine what operations are valid on the object and make an invocation on it. In addition to its role in the functioning of the ORB, the Interface Repository is a common place to store additional information(metadata) associated with interfaces to ORB objects. 5. ORB Interface

It consists of a few APIs to local services like converting and object reference to a string. Because most of the functionality of the ORB is provided through the object adapter, stubs, skeleton, or dynamic invocation, there are only a few operations that are common across all objects. These operations are useful to both clients and implementations of objects. Server Side 1. Object Implementations

An object implementation provides the semantics of the object, usually by defining data for the object instance and code for the object's methods. Often the implementation will use other objects or additional software to implement the behavior of the object. A variety of object implementations can be supported, including separate servers, libraries, a program per method, an encapsulated application, an object-oriented database, etc. Through the use of additional object adapters, it is possible to support virtually any style of object implementation. Generally, object implementations do not depend on the ORB or how the client invokes the object. Object implementations may select interfaces to ORB-dependent services by the choice of Object Adapter.

2.

Dynamic Skeleton Interface(DSI)

Normal compiled skeletons are defined for a particular object class and expect a method implementation for each IDL-defined method. Dynamic skeleton Interface provides a run-time binding mechanism for servers that need to handle incoming method calls for components that dont have IDL-based compiled skeletons(or stubs). The dynamic skeleton looks at parameter values in an incoming message to figure out who its for-that is the target object and method. 3. Implementation Repository

It provides a run-time repository of information about the classes a server supports, the objects that are instantiated and their IDs. It also serves as a common place to store additional information associated with the implementation of ORBs. For example, debugging information, administrative control, resource allocation, security, etc., might be associated with the Implementation Repository. 4. Object Adapters

An object adapter is the primary way that an object implementation accesses services provided by the ORB. Services provided by the ORB through an Object Adapter often include: generation and interpretation of object references, method invocation, security of interactions, object and implementation activation and deactivation, mapping object references to implementations, registration of implementations, assigning Ids to objects etc. There are different types of object adapters based on the services that they provide. They are as follows i) Basic Object Adapter (BOA)

The main purpose of BOA is to control the life cycle of an implementation. It provides functions like user authentication, object activation, object persistence etc. ii) Portable Object Adapter (POA)

The problem with BOA is that every ORB vendor has its own interpretation of BOA, which has made the server side implementation non-portable between ORBs. POA replaced BOA to achieve portability at the server end. iii) Library Object Adapter

This object adapter is primarily used for objects that have library implementations. It accesses persistent storage in files, and does not support activation or authentication, since the objects are assumed to be in the clients program. iv) Object-Oriented Database Adapter

This adapter uses a connection to an object-oriented database to provide access to the objects stored in it. Since the OODB provides the methods and persistent storage, objects may be registered implicitly and no state is required in the object adapter.