 The magazine of the Melbourne PC User Group An introduction to Object Resource Brokers Tilmann Rabich and Noel Craske |
As businesses develop and use computers to solve problems, new problems emerge. For example, how do users share information that they have accumulated on different systems? Today, the variety of software applications running on different hardware platforms complicates the task of establishing communication across a Local Area Network (LAN) or a Wide Area Network (WAN).
In December 1991 we saw a graphic example of this sort of problem, when the Commonwealth Bank took over the State Bank of Victoria and the two banks' computer systems needed to be integrated. It took a long time to develop and implement the solutions that enabled the new Commonwealth Bank to take advantage of the old State Bank's information.
To do this, the banks needed to design and implement applications that could integrate systems initially designed for different software and hardware configurations. Custom solutions naturally take a long time to design and implement. Development costs can be substantial and the solutions themselves are often inflexible and costly to maintain.
The Object Management Group (OMG) developed the Common Object Request Broker Architecture (CORBA) as a way of solving just this sort of problem.
The OMG, located in Framingham Massachusetts (USA), has more than 500 members, including IBM, DEC, Novell USG, Hewlett-Packard, and NCR [1]. A notable absentee is Microsoft. Instead of joining the OMG, Microsoft decided to create its own version of an Object Broker System--called the Component Object Model (COM)--which works within Microsoft's Object Linking and Embedding (OLE) technology. By going its own way, Microsoft made the goal of achieving a unified, universal standard much more difficult.
CORBA was designed to simplify programming and facilitate the distribution of portable applications that could work across a diverse range of platforms and networks. CORBA can be used to solve problems encountered when integrating legacy applications and systems, and to provide the flexibility necessary in rapidly changing business environments.
The CORBA philosophy
Fundamental to CORBA's development was the premise that it is more efficient to have smaller, more robust applications that run on (and communicate between) workstations and file servers than to have large mainframe applications that communicate with dumb terminals.
These smaller applications are called by various names - applets, distributed objects, software components, etc. CORBA is the underlying architecture (or standard) that makes it possible to implement these software components across networks [1].
Because CORBA-based applications are designed to be portable, they make life easier for developers. With CORBA developers have a standardised set of facilities to retrieve or manipulate data on host machines. Because the facilities are standardised, the users (and their applications) need not be aware of the tasks required to locate, retrieve or manipulate information from different databases and data files on one or more hosts.
With CORBA, access to any database is achieved with equal ease. A user doesn't need to know, for example, that some of the information is held in an Oracle database and some in a Sybase database. Using CORBA interfaces are standardised and integrating applications is easier.
CORBA is based on a combination of two existing methodologies--distributed client-server computing and object-oriented computing. The result is distributed object computing, which enables applications across networks to access and share objects. This means that these distributed objects become common to all applications that implement CORBA.
Distributed client-server computing is economical, because it enables the sharing of expensive resources. For example, printers and other computer resources can be shared by everyone on a network, thus saving the cost of buying individual resources for each user. Another benefit is increased efficiency, because the computing workload can be distributed and applications can be placed on the most suitable machines.
There are many benefits from designing and building object-oriented software. Systems have attributes and behaviours based on real world models. Systems are designed so that objects within them can perform only certain procedural tasks--called operations or methods. Every object and operation must be clearly defined and this results in fewer errors on implementation. Relationships between objects and the resulting interactions are also defined and the resulting software is highly modular.
These software components (objects) can be built more independently and, because the same software objects can be used in different applications, this method eventually leads to lower cost and faster development of applications.
The marrying of these two methodologies to produce the CORBA architecture was done to bring together the benefits of distributed client-server computing and object-oriented software.
As a result, the next generation of software, produced under a CORBA implementation, should be reusable, simple to use and understand, and naturally compatible with any hardware platform. [2]
CORBA (simplified)
CORBA incorporates the concept of using a broker, called the Object Request Broker (ORB)--as a sort of intermediary--to handle messages (called requests) that flow between clients and servers in the system. The broker has the ability to choose the server(s) that best fill the clients' requests and separates the interface that the clients see from the implementation of the server. This means that it is possible to switch or modify servers--provided you do not modify the interface or the way it behaves--without changing clients. The ORB resides on the host between the data and the application layer. This is one level lower than the application layer, which is level 7 in the OSI model [1].
The ORB incorporates many aspects of object-oriented programming, for example, polymorphism, data encapsulation and data inheritance.
- Polymorphism means that different objects (with their associated data sets) are independent and reusable by different applications.
- Data encapsulation means that client applications know nothing about the data they accesses. As far as a client application knows, it simply requests objects through the ORB, and the object retrieves the requested data.
- Data inheritance means that if one interface was designed to interface with an ORB, then any object derived from that parent object will keep the parent object's interface.
After writing and compiling IDL definitions for the interfaces, the ORB knows about the interfaces to the objects. The IDL information is stored in a dynamic listing called the interface repository. Because the ORB knows about other objects residing in different host systems, it can match the requested data object to its interface repository. The ORB then attempts to send a message to the object. If the data object or its server is not running, the ORB will obtain the reference for how and where to communicate with the object in the implementation repository or associated database. When the ORB receives a correct reference, it will attempt to communicate with that object by sending the original message. If the process fails or the ORB does not know the requested object, the ORB returns an appropriate error message to the calling application or object.
CORBA's competitors
Microsoft decided to go its own way rather than participating in the OMG development of CORBA. Microsoft concentrated on its own OLE-based Component Object Model (COM) which is essentially an ORB for OLE. Practical applications for OLE include editing graphics images inside a word processing document and embedding sound files into a database file. These tasks are also possible using CORBA.
The major difference between CORBA and COM is that CORBA's object model allows multiple inheritance, which allows for highly customised components. COM is also a single-machine ORB, compared with CORBA's network enabled ORBs [4]. However, Microsoft is moving towards distributing its OLE over networks through its Network OLE. Microsoft's distributed OLE components will be able to access other network-accessible OLE components as if they existed locally. The new version of Visual Basic 4.0 incorporates an early version of this Network OLE [5].
Microsoft's COMs and OMG's ORBs aren't the only players out there. There's also Sun Microsystem's Java programming language. As the most accessible of the three main players in the distributed object battle, Java has generated a great deal of interest and discussion in computing circles. Some people have gone so far as to say that Java could bring about Microsoft's demise [6]. Java code works in any environment where Java has been implemented, CORBA compliant applications are also platform independent, so that's not Java's point of differentiation. But the delivery system for Java is the Internet.
If the Java language evolves to the point where software components can be distributed securely across the Internet, and these applications can be used to "plug and play," producing larger, customised systems--component by component--then it's easy to understand why some people predict hard times for large software vendors, such as Microsoft.
You may come across an example of Java if you are using a 32-bit web browser, such as Netscape v2.0 or higher. Right now, the main use of Java code on the web is to enhance graphics images on web pages--producing animation and effects such as fading and scrolling. As a language, Java is a close relative of C++, but as an interpreted language it executes about ten times slower than native C++ [6]. However because Java is object based and platform independent it has become popular for building software components that can be sent and used anywhere via the Internet.
The future of CORBA
You may have heard of or read about OpenDoc, a programming environment in which developers can create multi-platform applications. In an effort to fight off Microsoft and its distributed OLE, in March 1996 the OMG announced that it had adopted OpenDoc's distributed compound document-formatting facilities as part of its CORBA architecture [7].
That decision paved the way for applications with the ability to call OpenDoc components through CORBA 2.0-compliant ORBs. Now the OMG has a product to compete directly with OLE. However, no matter how good the OpenDoc standard is, the fact that OLE has become something of an industry standard, may make it difficult to steal market share back from OLE.
Apple has adopted OpenDoc to implement on its Macintosh computers and IBM plans to have OpenDoc out by the end of 1996. IBM shipped OS/2 and AIX versions of OpenDoc in 1995 [8]. This augurs well for the future of CORBA as the computing industry and consumers of distributed-object-based technology make their choices based on the backing of large companies, to which they will look for the support necessary to drive the technology. Because the OMG comprises some 500 members of well known computing companies there is no doubt about its backing.
CORBA technology, and its underlying object-oriented architecture, is well suited to deliver the means to seamless integration between distributed objects. As such it can provide for the development of many projects that require connecting applications across a network, for example, complex Object-Oriented Database Systems that store complex data structures with ease. These sorts of projects could only have been dreamt of a short time ago.
|
References [1] Gabriel Minton, Programming with CORBA, UNIX Review, April 1996, v14:4 p29. [2] Joshua Kerievsky, Will an ORB light your network? Object request brokers, PC Magazine, March 26, 1996, v15:6 p36. [3] Randy Otte, Paul Patrick, Mark Roy, Understanding CORBA: The Common Object Request Broker Architecture, Prentice Hall, p2-2. [4] Michael A. Foody, OLE and COM vs. CORBA, UNIX Review, April 1996, v14:4 p43. [5] David S. Linthicum, Consider the Component Object Model, PC Magazine, March 26, 1996, v15:6 p10. [6] Robert Richardson, Java picks up steam, LAN Magazine, April 1996, v11:4 p79. [7] Martin Marshall, OMG challenges Microsoft's OLE with OpenDoc's compound documents, Communications Week, March 25 1996, 602 p12. [8] Frank Hayes, OMG picks OpenDoc, puts users in quandary, CompterWorld, March 25 1996, v30:13 p16. |
Reprinted from the October 1996 issue of PC Update, the magazine of Melbourne PC User Group, Australia
