OMA segments
Application Oriented - the OMA characterizes Interfaces and Common Facilities as solution-specific components that rest closest to the end user.
System Oriented - Object Request Brokers and Object Services are concerned with the system or infrastructure aspects of distributed object computing and management.
Vertical Market Oriented - Domain Interfaces are vertical applications or domain-specific interfaces.
OMA Components
Object Request Broker - commercially known as CORBA. It provides an infrastructure allowing objects to converse, independent of the specific platforms and techniques used to implement the objects. Compliance with the Object Request Broker standard guarantees portability and interoperability of objects over a network of heterogeneous systems.
Object Services - these components standardize the life-cycle management of objects. Interfaces are provided to create objects, to control access to objects, to keep track of relocated objects, and to control the relationship between styles of objects (class management).
Common Facilities - Common Facilities provide a set of generic application functions that can be configured to the specific requirements of a particular configuration. These are facilities that sit closer to the user, such as printing, document management, database, and electronic mail facilities.
Domain Interfaces - Domain Interfaces represent vertical areas that provide functionality of direct interest to end-users in particular application domains. They are designed to perform particular tasks for users within a certain vertical market or industry.
Application Objects - The Application Interfaces represent component-based applications performing particular tasks for a user.
Common Object Request Broker Architecture
Common Object Request Broker Architecture (CORBA) is a system definition specification that allows applications to communicate with one another regardless of their location and developer. Together with the Interface Definition Language (IDL) and Application Programming Interfaces (API) that were defined by the Object Management Group, CORBA 2.0 enables client/server object interaction and interoperability by specifying how ORBs from different vendors can interoperate. One of the recent implementation of this kind of architecture is the Inter-Language Unification (ILU), a system developed by Xerox PARC that adheres to CORBA IDL.
Structure of the Object Request Broker Interfaces
The (ORB) is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems. With an ORB, the protocol is defined through the application interfaces via a single implementation language-dependent specification, the IDL. In an ORB-based solution, developers simply model the legacy component using the same IDL they use for creating new objects, then write "wrapper" code that translates between the standardized bus and the legacy interfaces.
A request being sent through the Object Request Broker
Significance of CORBA
Since the release of CORBA 1.0 in 1991, the promise to provide out-of-the-box multi-vendor interoperability among ORB implementations was never realized. The CORBA 1.2 specifications had many vague areas to allow a wide range of implementations, but caused problems with interoperability. The problem was finally resolved by CORBA 2.0 with the definition of a single wire-format which specifies how detailed information representing a CORBA request is laid out on a network transport. The wire-format to be adopted was:
CORBA also standardizes:
However, until conformance becomes commonplace, porting between different platforms, applications from ORB to ORB will remain limited.
CORBA provides a distributed object-oriented approach to integrating new as well as legacy applications and enables the developers to write an object wrapper to encapsulate the system. With CORBA, the developer writes a description of the service provided by the system using IDL, then writes code which invokes the appropriate set of actions in the system when one of the object wrapper's method in invoked.
CORBA Limitations
While the interoperability issue has been tackled in CORBA 2.0, the security aspects have not been sufficiently addressed, and this falls on the shoulders of the OMG Object Security Service Specification. These have been the major obstacles to serious and mission-critical applications development, particularly those who still employ legacy systems.
As a technology, CORBA is maturing rapidly and its specifications has received broad industry support. However, OMG technology has had only slow acceptance as OMG/CORBA technology is an object/oriented technology for distributed computing, an area where many users are not technically ready to apply and deploy in real environments. With the recent popularity of the Internet, the future of CORBA lies greatly in its use in open distributed tools and and services. This depends on both the publicity efforts on the part of OMG in encouraging software and system vendors to use CORBA and on CORBA's technical merits in enabling true compatibility among different platforms and other internet programming languages and applications.
Relevant External Research
Externally there are software and development efforts that we should follow closely, as they might be able to take CORBA to the next level of usage and acceptance. These include JYLU -- ILU for JAVA which is being developed at Stanford Digital Library Testbed Development. Basically, Jylu is an attempt to implement the ILU 1.8 runtime kernel completely in the Java language. Version 0.5 of JYLU works, both as a client and as a server. But it can only marshal Cardinals, Strings, Record, Sequences, and Objects right now and has limited support, in the areas of TCP transport, sunrpc protocol, request-level threading.
Ernest Friedman-Hill at Sandia National Laboratories is also developing JIDL -- a CORBA IDL compiler which promises to enable Java applets running in Java-enabled Web browsers to manipulate CORBA objects on remote servers as if they were local Java objects. A document stating the mapping of CORBA IDL to Java is accessable. However, a working prototype is not yet available for downloading.
Short Presentation of Summary
Back to Index
Modified: February 23, 1996
Feedback: Francis Chan
(fchan@ic.eecs.berkeley.edu)