CORBA Distributed Software

It is tempting to look at CORBA and quickly determine that it is simply a network transport layer for building software.
Or put another way, that CORBA answers the question: how will application component XYZ talk with component ABC?
While this is true and of significant value, it is nice to have a debugged, optimized tool that allows easy creation of distributed applications - CORBA is actually much more. As we explore CORBA we will see that the specification provides a sophisticated framework for both object and application level services that is designed to be as open as possible at every level. This focus on openness is CORBA's greatest strength. As we move forward, we will repeatedly take the time to ask "Why CORBA?" The Common Object Request Broker Architecture (CORBA) [OMG:95a] is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as

1. object registration,
2. location, and
3. activation.

Other functions that Corba fulfilles are

1. request demultiplexing,
2. framing and error-handling,
3. parameter marshalling and demarshallin, and
4. operation dispatching.

The major advantages of using CORBA to build distributed applications with C++ are

1. Interoperability across programming languages and operating systems
2. Open standardization of CORBA
3. Vendor independence
4. Legacy integration
5. Location transparency
6. Programmer productivity
7. Reusing CORBA services and facilities

At this point, it's important to realize why the (OMG) Object Management Group got involved. Methodologists like to think that they are important. But I do not think that the requirements would even be heard by the OMG. What got the OMG involved were the requirements of tools vendors, all of which were frightened that a standard controlled by Rational would give Rational tools an unfair competitive advantage. As a result, the vendors energized the OMG to do something about it, under the banner of CASE tool interoperability. This banner was important, as the OMG was all about interoperability. The idea was to create a UML that would allow CASE tools to freely exchange models.

CORBA exists as a standardized way to create distributed software systems. CORBA allows the components of an application to exist across a network of computers, while still allowing the components to interact as a whole. The general concept, as depicted below, is often called distributed computing.

1. Naming Service: The CORBA naming service provides a naming structure for remote objects.
2. Event Service: Another COS that provides a supplier-consumer communication model that creates asynchronous communication between the objects via an Event Channel. The flow of data into the Event Channel is handled by supplier objects, while the flow of data out of the event channel is handled by consumer objects. The Event Service supports both the push and pull model. In the push model, supplier objects control the flow of data by pushing it to consumers and in the pull model, consumer objects control the flow of data by pulling data from the supplier. Instead of directly communicating with each other, the supplier and consumer can each obtain a proxy object from the Event Channel and communicate with it. Supplier objects obtain a consumer proxy and the consumer objects acquire a supplier proxy.
3. Life Cycle Service: The Life Cycle Service defines conventions for creating, deleting, copying and moving objects. Because CORBA-based environments support distributed objects, life cycle services define services and conventions that allow clients to perform life cycle operations on objects in different locations.
4. Persistent Object Service: The Persistent Object Service (POS) provides a set of common interfaces to the mechanisms used for retaining and managing the persistent state of objects.
5. Transaction Service: The Transaction Service supports multiple transaction models, including the flat (mandatory in the specification) and nested (optional) models.
6. Concurrency Control Service: The Concurrency Control Service enables multiple clients to coordinate their access to shared resources. Coordinating access to a resource means that when multiple, concurrent clients access a single resource, any conflicting actions by the clients are reconciled so that the resource remains in a consistent state.
7. Relationship Service: The Relationship Service allows entities and relationships to be explicitly represented. Entities are represented as CORBA objects. The service defines two new kinds of objects: relationships and roles. A role represents a CORBA object in a relationship. The Relationship interface can be extended to add relationshipspecific attributes and operations. In addition, relationships of arbitrary degree can be defined. Similarly, the Role interface can be extended to add role-specific attributes and operations.
8. Externalization Service: The Externalization Service defines protocols and conventions for externalizing and internalizing objects. Externalizing an object is to record the object state in a stream of data (in memory, on a disk file, across the network, and so forth) and then be internalized into a new object in the same or a different process. The externalized object can exist for arbitrary amounts of time, be transported by means outside of the ORB, and be internalized in a different, disconnected ORB. For portability, clients can request that externalized data be stored in a file whose format is defined with the Externalization Service Specification.
9. Query Service: The purpose of the Query Service is to allow users and objects to invoke queries on collections of other objects. The queries are declarative statements with predicates and include the ability to specify values of attributes; to invoke arbitrary operations; and to invoke other Object Services.
10. Licensing Service: The Licensing Service provides a mechanism for producers to control the use of their intellectual property. Producers can implement the Licensing Service according to their own needs, and the needs of their customers, because the Licensing Service does not impose it own business policies or practices.
11. Property Service: Provides the ability to dynamically associate named values with objects outside the static IDL-type system
12. Time Service: 1) Enables the user to obtain current time together with an error estimate associated with it. 2) Ascertains the order in which "events" occurred. 3) Generates time-based events based on timers and alarms. 4) Computes the interval between two events.
13. Security Service:The security functionality defined by this specification comprises:
    
    1. Identification and authentication of principals (human users and objects which need to operate under their own rights) to verify they are who they claim to be.
    2. Authorization and access control - deciding whether a principal can access an object, normally using the identity and/or other privilege attributes of the principal (such as role, groups, security clearance) and the control attributes of the target object (stating which principals, or principals with which attributes) can access it.
    3. Security auditing to make users accountable for their security related actions. It is normally the human user who should be accountable. Auditing mechanisms should be able to identify the user correctly, even after a chain of calls through many objects.
    4. Security of communication between objects, which is often over insecure lower layer communications. This requires trust to be established between the client and target, which may require authentication of clients to targets and authentication of targets to clients. It also requires integrity protection and (optionally) confidentiality protection of messages in transit between objects.
    5. Non-repudiation provides irrefutable evidence of actions such as proof of origin of data to the recipient, or proof of receipt of data to the sender to protect against subsequent attempts to falsely deny the receiving or sending of the data.
    6. Administration of security information (for example, security policy) is also needed.
14. Object Trader Service: The Object Trader Service provides a matchmaking service for objects. The Service Provider registers the availability of the service by invoking an export operation on the trader, passing as parameters information about the offered service. The export operation carries an object reference that can be used by a client to invoke operations on the advertised services, a description of the type of the offered service (i.e., the names of the operations to which it will respond, along with their parameter and result types), information on the distinguishing attributes of the offered service
15. Object Collections Service: Collections are groups of objects which, as a group, support some operations and exhibit specific behaviors that are related to the nature of the collection rather than to the type of object they contain. Examples of collections are sets, queues, stacks, lists, binary, and trees. The purpose of the Collection Object Service is to provide a uniform way to create and manipulate the most common collections generically.

You are probably familiar with applications that perform work using other distributed computing models, but that do not make use of CORBA. In fact, the entire World Wide Web is a perfect example. Common Object Request Broker Architecture (CORBA) is an architecture and specification for creating, distributing, and managing distributed program objects in a network. The architecture allows programs at different locations and developed by different vendors to communicate in a network through an "interface broker." CORBA was developed by a consortium of vendors through the (OMG) Object Management Group, which currently includes over 500 member companies. Both International Organization for Standardization (ISO) and X/Open have authorized CORBA as the standard architecture for distributed objects (which are also known as components). CORBA 3 is the latest level.

• Other Distributed Computing Models
  How does CORBA fit other distributed computing models? Programming with sockets is a much lower level activity than CORBA development. A socket basically consists of two endpoints, usually two computers connected across a network. Those that have done it will tell you that it has a steep learning curve, requires working at the data buffer level, and can be difficult to debug and optimize.

Remote Procedure Calls (RPCs) emerged as a way for the software industry to harness the power of sockets programming while building distributed applications at a higher abstraction level. RPCs established the foundational client-server model, enabling a client to request services from a server across a network. In this model, remote code on the server executes in response to a procedure call from the client. The key innovation of RPCs was their ability to abstract the complexities of sockets, providing developers with a more intuitive interface. CORBA, for instance, builds on the RPC model, aiming to make the process more open and interoperable. In distributed computing, an RPC allows a procedure to execute in a different address space, often on another machine on the same network, while appearing to the programmer as a local procedure call. This eliminates the need for explicit coding of the remote interaction details, allowing developers to write nearly identical code whether the procedure is local or remote. RPCs represent a form of client-server communication where the caller acts as the client, and the server executes the request. Typically, this interaction relies on a request-response message-passing system. In object-oriented programming, RPCs have an analog in Remote Method Invocation (RMI). The RPC model introduces a degree of location transparency, meaning the process of invoking procedures is similar regardless of whether they are local or remote. However, differences remain: remote calls are generally much slower and less reliable than local calls, making it essential to distinguish between the two. As a form of inter-process communication (IPC), RPCs facilitate communication between processes with distinct address spaces. On the same machine, these processes operate in separate virtual address spaces within a shared physical memory. On different machines, both virtual and physical address spaces are separate. Over the years, various technologies, often incompatible, have been used to implement RPCs, reflecting their versatility and complexity in distributed computing.

• Data Access Libraries and Client/Server Development Tools
  In addition to sockets and RPCs, many database vendors and third party tools vendors have created development tools that allow database access and other forms of distributed computing. The primary weakness in these tools is that they only interoperate with tools from the same vendor and tend to make it very hard to allow distributed applications to keep up with changing business processes. This problem does not exist in CORBA-based systems.