• CORBA - An Introduction
• CORBA Basics
• CORBA Components
• Location of CORBA Objects
• CORBA's Object Adapter (OA)
• CORBA for Real-Time Systems
• CORBA-based Load Balancing
• The CORBA Transaction Service
• Summary

CORBA - An Introduction

In recent years, we have witnessed the remarkable growth of the Internet and a substantial progress in Internet-related technologies. These trends made global electronic networked services feasible and provided truly global information sharing and inexpensive remote access for clients world wide. In particular, various middlewares and object request brokers (ORBs) have been developed with the aim of easing the design of distributed applications and allowing client objects to access remote services in heterogeneous settings. Among the currently available middlewares, CORBA is one of the most promising standards for building object-oriented distributed applications.

There are a number of fundamental challenges in the distributed application domain. The key challenges include - addressing the impact of latency, detecting and recovering from partial failures of networks and hosts, load balancing and service partitioning, and consistent ordering of distributed events. To help address this set of challenges, the Object Management Group (OMG) has been specifying the Common Object Request Broker Architecture (CORBA). CORBA is a set of industry standards for distributed object-based computing that is designed to facilitate reliable, platform-independent execution of object-oriented software in wide- and local area network environments. Its main goal is simplifying distribution by automating - object location and activation, parameter marshaling, demultiplexing and error handling. Its main challenge is to develop distributed applications whose components collaborate efficiently, reliably, transparently, and scalably. Thus CORBA is a robust distributed object framework.

The ORB is the main mechanism for simplifying the development of CORBA standard applications. The simplification is a result of three properties: location independence, platform and language interoperability.

Location independence means that an ORB treats all objects it is aware of as local objects, even if they exist on remote systems. Clients and objects are not directly aware of each other's locations within a network, allowing relocation of one or both with no impact on the other. This is the benefit of CORBA object references. Since the object reference is an opaque data type, the client is unaware of and unconcerned with the actual contents. The content, however, is the location of the remote object in the network. Because of this, the CORBA architecture provides the benefit of location transparency of CORBA objects. If a CORBA object and its containing server application are moved to a different host in the network, it is only necessary to update the CORBA object's object reference in the object location mechanisms that are discussed below. The next time a client application obtains the object reference, it will pick up the new object reference and use it just as it did the previous one

Platform interoperability means that objects created on one hardware/software computing platform (for example, those generated on a Pentium-based Windows NT system) can run on any other CORBA-equipped platform (may be Sparc-based Sub Workstation). Due to the platform-independence of the CORBA architecture and support from many different vendors, CORBA-compliant products and frameworks exist for most operating systems and hardware platforms, allowing CORBA applications to span many different types of systems, from small, handheld devices to mainframes.

Language interoperability means that objects written in one language can interact with applications written in another, thanks to CORBA's interface definition language (IDL) and the availability of mapping between the programming languages and IDL. IDL is a contractual language that defines the interfaces to objects, but not their implementations. Objects themselves can be written in any common language COBOL, C, C++, Smalltalk, Java and still work on non-native systems.

CORBA also includes mechanisms for communication among objects across a network. The general inter-ORB protocol (GIOP) specifies message formats and data representations that ensure object interoperability among ORBs. The inter-ORB protocol (IIOP) defines the specific details for using GIOP over TCP/IP.

The OMG also has defined a set of object services that are commonly used within distributed object systems. This set of services is called the CORBA Services.

Every object, residing within an application, has to provide access to its functionality through its interface. The object's interface is simply the collection of public methods and attributes that the object implements to expose its functionality to clients. Any client that makes use of the object will do so through its interface, by invoking the object's public methods and accessing the object's public attributes.

CORBA clients obtain references to objects and invoke operations on them to perform application tasks. Objects can be remote or collocated relative to the client. Ideally, a client can access a remote object just like a local object. Some of the CORBA components transparently transmit remote operation requests from client to object.

In CORBA, an object is an instance of an OMG IDL interface. Each object is being identified by an object reference, which specifies one or more paths through which a client can access an object on a server. An object ID associates an object with its implementation or servant and is unique within the scope of an object adapter. Over its lifetime, one or more servants can implement an object's interface. In object-oriented languages, such as C++ and Java, servants are being implemented using one or more class instances. In non-OO languages, such as C, servants are typically implemented using functions and structs. A client never interacts with servants directly, but always through objects identified by object references.

The CORBA model contains several key components, including client, object, servant, ORB, OMG Interface Definition Language (IDL), stubs and skeletons, IDL compiler and object adapter. The most important element of CORBA technology is the

Object Request Broker (ORB), which acts as a software bus managing access to and from objects in an application, linking them to other objects, monitoring their function, tracking their location and managing communications with other ORBs. The ORB is the CORBA software product that is used when constructing distributed application components. The ORB's primary responsibility is to facilitate the creation and transmission of request and reply messages that occur between clients and objects. Also the ORB is a standard CORBA component responsible for connection and memory management, data transfer, endpoint demultiplexing and concurrency control. The ORB also exposes an interface directly to the client and object for ORB initialization, bootstrapping of commonly used services such as the Naming Service, and manipulation of CORBA object references. The ORB is usually implemented as a set of libraries or packages included within each distributed application client and object server. In addition, some ORB implementations also include daemon processes that are used for object location and/or launching of remote server processes.

For objects executing remotely, a CORBA-compliant ORB core communicates through the Internet Inter-ORB Protocol (IIOP), which runs atop the TCP transport protocol. IIOP is being used by ORBs to send messages back and forth between clients and objects. Since IIOP is a vendor-independent protocol, any two ORB products that are version 2.0 compliant can communicate with each other. This feature is known as interoperability, which allows a client using one ORB product to use objects running within a different ORB product. That is, clients and objects running within different vendor's ORBs can communicate just as if they were located within the same ORB.

Interface Definition Language (IDL) is the language that is used to declare interfaces to distributed objects. It strongly resembles C++ class declarations. IDL is being used to declare the data structures and methods available for use via CORBA in the application. IDL is programming-language independent, meaning that an interface defined in IDL does not require that a specific programming language, such as Java or C++, be used when implementing clients that use this interface and objects exposing it.

In conjunction with IDL, the OMG has defined IDL-to-language mappings, allowing an IDL interface to be mapped into a particular programming language. Once an IDL interface has been defined, the interface is compiled using an IDL to language compiler, generally provided by the ORB vendor, to generate the stub and/or skeleton in the target programming language. With these mappings, a given IDL interface can be compiled using an IDL compiler to generate client stubs and server skeletons in a target programming language. Using IDL compilers for different target languages, interfaces defined in IDL along with the IDL-to-language mappings permit clients written in one programming language to access objects written in different programming languages.

IDL Stubs and Skeletons - To create distributed objects in an n-tier application, we need to separate our objects from the client applications that contain them. Most distributed object frameworks use the same approach to enable this separation, which is based on the object's interface. Using the interface of the object, two new pieces of code are generated. A stub or client stub used in place of the object in the client application. A skeleton or server stub included in a new server-side application that the programmer will create to contain the object. The new code sites between the clients and objects and pass invocations on the object's interface back and forth between the client application and the new server application.

On the client side, the stub exposes the same interface as the original object. As a result, the client is unaware that the object now resides in a different process. When the client interacts with the stub through the interface, the stub takes the details of the interaction such as the method invoked and the parameters provided, packages them into a message, called a request, and sends it across the network to the skeleton. The stub then waits for a return message, called a reply, from the skeleton.

On the client side, the server skeleton receives the request message and extracts the details of the client's interaction with the stub. Once this is complete, the skeleton invokes the correct method on the object, passing the parameters that were extracted from the request message. Any return values or exceptions thrown from the object are packaged into a new message, the reply. The reply is then sent back to the client stub. The stub extracts the information from the reply message and returns it back to the client application. The key to the success of the interaction is that the client stub and the object expose the same interface. This allows the stub and skeleton to process any method invocations that the object can handle, passing the correct parameters. This allows the skeleton and stub to return the correct return types and possible exceptions that the client is expecting.

Both glue the client and servants to the ORB. Stubs implement the Proxy pattern and provide a strongly typed, static invocation interface (SII), which marshals application parameters into a common message-level representation. Conversely, skeletons implement the Adapter pattern and demarshal the message-level representation.

The IDL compiler transforms OMG IDL definitions into stubs and skeletons, which are generated automatically in an application programming language, such as C++ or Java. In addition to providing programming language transparency, IDL compilers eliminate common sources of network programming errors and provide opportunities for automated compiler optimizations.

Interoperable Object Reference (IOR) - When a client wants to invoke methods on the remote object, it first obtains an interoperable object reference, also called an IOR or simply an object reference, for the remote object, also known as a CORBA object. The object reference will be represented within the client as a local object, that is, as an instance of a class in the client's programming language containing data that is used by the ORB to locate the remote object in the network. The data within the object reference is considered opaque, meaning that its format and value is unimportant to the client's application-level code. The actual contents and format of the object reference data is defined by the OMG to ensure that an object reference is interoperable, meaning that an IOR can be used to access the remote object from within any ORB framework, regardless of where the IOR was created. As mentioned above, the actual type of the object reference is defined in the client's programming language within the IDL client stub. The object reference will expose an interface that maps directly to the interface defined in the IDL using the IDL to language mapping.

It may be helpful to think of an object reference as a proxy object for the remote object. Once obtained, the client application can invoke methods on the object reference, that is, proxy object, just as if it was the actual object.

Before we can invoke operations on our CORBA object, our client must first obtain the CORBA object's reference. The CORBA architecture provides several mechanisms that CORBA objects and their server applications can use to make their object references available to potential clients, namely:

1. Using an object location service, such as the CORBA Naming Service
2. Recreating an object reference from its stringified format
3. Receiving an object reference from another CORBA object commonly referred to as a factory object.

An object location service is a software product that provides the ability to publish and retrieve object references. The most commonly used object location service is the OMG-defined CORBA Naming Service.

CORBA Naming Service - The Naming service is a repository for storing CORBA object references. When a server application inserts an object reference into the Naming service, it is required to provide a name that will be used to identify that object reference. The object reference-name association is called a binding. Once the object reference is bound, client application can query the Naming service, providing a name and receiving the associated object reference.

The server application that contains the CORBA object is responsible for inserting its object reference into the Naming Service. To do this, the server application must first obtain reference of the Naming Service's root context. It does this using a bootstrap mechanism of the ORB, namely the 'resolve_initial_references' method. Using this method, the server can object object references to several CORBA object services including the Naming service. The actual object references returned are determined within the configuration of the ORB product. The client also use the same bootstrap mechanism to obtain the object reference of the Naming service's root context and go ahead to look up the object reference of its intended target CORBA object.

The Naming service stores its object reference bindings in naming contexts. A naming context is a CORBA object that maintains a collection of zero or more object reference bindings and zero or more naming contexts. The recursive nature of the naming context allows the creation of a hierarchy of naming contexts, much like the directory structure of a file system where each directory can contain files and additional directories. By creating new naming contexts within existing contexts, it allows developers to segment the global object namespace, helping to alleviate the problem of name collisions. To begin with, the Naming Service contains a single naming context, called the root or initial context. When we first obtain an object reference for the Naming service, it is actually the object reference of the root context. From there, additional contexts and object reference bindings can be added. When querying the Naming service for an object reference, we will provide a list of names describing the navigation through the hierarchy of naming contexts of names, the last name in the list being the name of the object.

CORBA Federated Naming Service - Actually the ORB can provide bootstrapping capability to a single Naming service. If access to additional Naming services, which are running on different host machines, is needed, the root naming context or some sub-context of each of these additional Naming services must be bound within the original Naming service to which our client application can access. This is called federation of Naming services.

There have come some enhancements to the originally specified Naming service. The latest version of CORBA has introduced a new Interoperable Name Service that will provide a URL based method of accessing defined services on remote hosts. For instance, a client application intending to use a service like the Naming service, which is running at http://www.peterindia.com/, can obtain its object reference by specifying the following URL: iioploc://ww.peterindia.com/NameService. Alternatively, queries can be made to a remote Naming Service directly through a second URL format. For example, to obtain the IOR of an object named Checking Account from the Naming service running on http://www.peterindia.com/, client applications can specify the following URL: iiopname://www.peterindia.com/Checking Account.

Storing CORBA Object References in Stringified Format - The second method to publish and retrieve object references is to store our CORBA object's object references in a data store in their stringified format. An object reference's stringified form is the contents of its internal data serialized into a string data type. An object reference is stringified using a method in the ORB's interface called 'object_to_string()'. Once stringified, the object references can be stored in some form of data storage, such as a database record or file. When adding the object reference to the data store, it should be associated with some sort of a label, making it possible to retrieve it by querying the data store for that label. When a client needs an object reference, it can obtain the object reference from the data store using the label and reconstruct the object reference from the string using another method of the ORB's interface, 'string_to_object()'.

Stringified object references are most commonly used to convey the object reference of a particular CORBA object from one application to another. Since these applications may not be coded using the same programming language, the actual objects instantiated in the applications may not be the same. Thus the goal of stringification of an object reference is to ensure that an object instantiated within another application should reference the same CORBA object.

Factory Object - A client can invoke a method on a special CORBA object that returns the object reference for an intended CORBA object. This special CORBA object is commonly referred to as a factory object due to the facts that it provides object references to other CORBA objects and from the client's perspective, this special object creates objects on demand. This is possible because IDL interfaces can define attributes, parameter types, and return types that are themselves object references. The only problem to be overcome in this way of obtaining object references is the client at the beginning should have obtained the object reference of the factory object through the other methodologies mentioned above.

Apart from these mechanisms, there are some proprietary object location mechanisms available with some ORBs. Though not CORBA-compliant, they are acceptable and easy to use and bring some benefits in some specific situations. Ultimately the source code will become ORB vendor-specific and the portability feature will get affected.

The Object Adapter is a composite component that associates servants with objects, creates object references, demultiplexes incoming requests to servants, and collaborates with the IDL skeleton to dispatch the appropriate operation up-call on a servant. Object adapters enable ORB support of servant types with similar requirements. This design creates a smaller and simpler ORB that can support a wide range of object granularities, lifetimes, policies, implementation styles and other properties.

Portable Object Adapter (POA) - The OMG CORBA specification standardizes several server-side components in CORBA-compliant ORBs. Among these components is the POA, which includes standard interfaces for object implementations (servants) and refined skeleton classes for various programming languages, such as Java and C++. These standard POA features let application developers write more flexible and portable CORBA servers. They also conserve resources by activating objects on demand and generate persistent object references references, which remain valid after the originating server process terminates. Server applications can configure these new features portably using policies associated with each POA. CORBA 2.2 lets server application developers create multiple object adapters, each with its own set of policies.

Real-time system developers are increasingly using off-the-shelf middleware components to lower software life-cycle costs and decrease time to market. CORBA is an attractive choice for several reasons. Firstly, CORBA is highly flexible. CORBA ORBs let clients invoke operations on distributed objects regardless of object location, programming language, OS platform, communication protocols and interconnects, and hardware. Thus CORBA ORBs help improve the flexibility, extensibility, maintainability, and reusability of distributed applications.

Also, because CORBA is not tightly coupled to a particular OS or programming language, it can be readily adapted to niche markets, such as real-time embedded systems that are not well covered by other middleware, such as Java RMI or Microsoft DCOM. CORBA has a distinct advantage over these middleware as RMI is Java-centric and DCOM is restricted to Windows platform and CORBA can be integrated into a wider range of programming languages and platforms. The present set of distributed real-time applications require ORB middleware to provide stringent quality of service support, such as end-to-end priority preservation, hard upper bounds on latency and jitter, and bandwidth guarantees. A few ORBs come with such QoS requirements. Such ORBs integrate highly optimized CORBA middleware with OS I/O subsystems, communication protocols, and network interfaces to guarantee QoS.

The growth of online Internet services during the past decade has increased the demand for scalable and dependable distributed computing systems. E-commerce and online stock trading systems are some examples. These back-end systems concurrently serve many clients that transmit a large number of requests and have stringent quality of service requirements. To protect hardware investments and avoid over-committing resources, such systems have to scale incrementally by connecting servers via high-speed networks.

An increasingly popular and cost effective technique to improve networked server performance is load balancing, where hardware or software mechanisms determine which server will accept and perform each client request. Load balancing helps improve system scalability by ensuring that client application requests are distributed and serviced equitably across a group of servers. Similarly, load balancing improves system dependability by adapting dynamically to system configuration changes that arise from hardware or software failures. It also can ensure all computing resources being used efficiently and if necessary only, new servers will be subjected to process client requests. Thus load balancing improves overall system responsiveness.

Load balancing mechanisms can be provided by network layer, OS layer and at middleware level. It is found that middleware-based load balancing, especially by CORBA middleware brings some spectacular benefits over the load balancing architectures at other layers in a distributed system. Middleware-based load balancing can be used in conjunction with specialized network-based and OS-based load balancing mechanisms. It can also be applied on top of commodity-off-the-shelf networks and OSs, which supports cost reduction. Finally, middleware-based load balancing ;provide semantically rich customization hooks to perform load balancing based on a wide range of application-specific load balancing conditions, such as runtime I/O versus CPU overhead conditions.

In the world of distributed objects, a transaction is a unit of work composed of a set of operations on objects. A transaction is an atomic unit or work. It either succeeds or fails as a whole. Thus every enterprise-scale distributed application needs a sort of effective mechanisms to ensure the much-needed transactions accomplished successfully. The CORBA Transaction Service, which was defined by the OMG, enables mission-critical use of distributed applications by providing transactional integrity. It defines IDL interfaces that allow multiple distributed objects to participate in coordinated transactions, and enables a distributed application to handle the various impediments to transaction completion over the Internet and intranets. It provides a complete solution for distributed, transactional CORBA applications. There are a couple of middleware products with this critical service. Inprise's VisiBroker has fully implemented the OMG CORBA Transaction Service and tightly integrated with its ORB. VisiBroker Transaction Service can simplify the complexity of distributed transactions by providing an essential set of services, including a full implementation of the CORBA Transaction Service, recovery and logging services, integration with databases and legacy systems, and administration facilities, within a single, integrated architecture.

The Need for Transaction-Processing Solution - In order to share data and functionality and ensure data integrity across multiple sources, organizations employing the distributed object-computing model must coordinate the activities of multiple objects into transactions. To do so, the IT professionals need a transaction-processing solution that reliably delivers business-critical functions, while ensuring transactional integrity and consistency.

Rapid delivery of business-critical information over the Internet and corporate intranets requires a solution that integrates the functionality of multiple objects, provides these objects with access to multiple data sources, and ensures data integrity, scalability and security across every business transaction. To establish and maintain a competitive IT edge, organizations of today must implement transaction-processing solutions. Even a company with a single data resource needs a transaction processing solution. When an application initiates a transaction, although it may only interact with a single database server, that application requires transaction coordination across the distributed objects that participate in the transaction.

For example, an application that simply transfers money from a checking account to a savings account typically requires separate objects in a distributed, object-oriented environment. For this application, it is most natural to use three objects - one for the transfer function, and one for each of the checking and savings accounts. Even though the data may be stored in a single database, the transaction must be coordinated between the objects. The transfer object begins the transaction, but completion of the transaction is dependent on successfully debiting on the checking account object and crediting the savings account object. If these transactions are not coordinately correctly, wrong data could result. It is found that using a transaction processing solution can handle the complexities of transaction management.

A transaction-processing solution can also bring greater scalability and performance to transactional applications. Some solutions provide connection management enhancements such as multiplexing database connections, which provide fast, reliable, transaction-safe access to multiple databases and can improve performance because a new connection is not opened for every process. A transaction-processing solution that provides ready-made connectivity to popular databases and mainframes saves additional development time and effort.

Global transaction coordination is a necessity in environments with multiple data sources, consisting of database servers, such as Oracle or Sybase, Transaction Processing (TP) Monitors, such as CICS or Tuxedo and messaging systems, such as Progress SonicMQ or IBM MQSeries. Thus when an application uses more than one data source in a transaction, global transaction management is needed to coordinate how the transaction accesses those data sources. In the banking example, the checking and savings account information could be put in different data sources. That is, the savings account is managed by an Oracle database and the checking account is managed by a Sybase database.

Approaches for Transactions in a Distributed Environment - There are some approaches to manage transactions efficiently in a distributed environment. They are being provided by TP Monitors, ORB plus TP Monitor and ORB integrated with Transaction Service. Each approach has been blessed with advantages and drawbacks. TP Monitor approach facilitates transaction coordination using a built-in Transaction Management Component. Other vendors have come with a solution comprised of an ORB plus a TP Monitor to bridge the gap between legacy systems and CORBA applications. Finally there comes a fully integrated CORBA solution that offers a fully compliant CORBA Transaction Service tightly integrated with the underlying ORB. In this approach, the transaction service takes advantage of the power of the ORB to perform multi-threading and handle connections.

Enterprise Information Technology professionals have reached the practical limits of two-tier architectures. Facing growing pressure to deliver broad-reaching application functionality quickly and cost-effectively, IT departments are turning to distributed object computing as the adaptive software architecture on which to build applications that meet these challenging business requirements. With object-oriented computing, It departments can develop applications faster and less expensively by reusing software components, they can adapt quickly to new technology while integrating existing systems, they can flexibly deploy applications across platforms, and they simplify maintenance by isolating volatile code in frequently changed objects.

The explosion of the Internet has fueled this shift to distributed objects. Internet business opportunities require a new breed of IT solutions that are suited to this new, rapidly expanding computing paradigm. The prolific development of these Internet-based applications reinforces the need for a standards-based distributed-object architecture, which enables functionality and data to be shared across applications and over multiple platforms.

CORBA provides solutions for many distributed system challenges, such as predictability, security, scalability, transactions, load balancing and fault tolerance. Thus CORBA has become a solid distributed component architecture commonly used in n-tier applications and has been designed to simplify and standardize distributed object development.