Objects destined for the enterprise
CORBA 2.0 defines bridge linking objects from different suppliers.
September 1995
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Objects destined for the enterpriseCORBA 2.0 defines bridge linking objects from different suppliers.
|
September 1995
|
Object developers see opportunity in the enterprise by creating highly interoperable, OLE-compliant, highly reliable programmatic nuggets.
 Mail this article to a friend |
Since the dawn of mainframes, programmers have dreamed of easier ways of writing large, enterprise-wide applications. A chief problem with developing traditional applications is the programmer has to plan for every contingency when writing the program. That implies omniscient programmers foreseeing every business issue users may face.
Another difficulty is producing network-aware applications. Code jockey cognoscente assemble distributed applications today using remote procedure calls (RPCs) or otherwise writing to special APIs. While these approaches work, the developer is still mired in hardware and programmatic issues, besides solving the underlying business problem.
Consequently, for these and other reasons, creating large and network-aware applications are a time-consuming chore. Many mission-critical applications can take two years or more to carry out fully, which means the business environment in which the company operates may have changed completely.
In 1989, the Object Management Group (OMG) was formed to develop an object-oriented standard for writing network-based applications. Since then, a Who's Who of more than 500 vendor and user organizations have been working on the Common Object Request Broker Architecture (CORBA). Microsoft, which is flogging a proprietary approach called Object Linking and Embedding (OLE), is also an OMG member, though is not on the verge of selling any CORBA-compliant products.
The dream driving CORBA is the hope that someday programmers will quickly assemble applications from programmatic nuggets that talk to each other using a common standard for communicating and delivering services.
For example, in a banking application, traditionally, a programmer would specify all of the actions that a bank teller might perform as a set of unrelated subroutines in a program. As a bank's needs change, it must rewrite parts of the program, and hope the changes won't result in unwanted effects on other parts of the application.
With object-oriented programming, the programmer merely creates a teller object, and specifies all of the things the teller can do. When the bank needs to change a teller's duties, the programmer merely modifies the teller object. Since the programmer only needs to deal with a very small piece of code relating to the teller object, he can modify and debug it in a matter of hours or days, as opposed to months or years.
|
|
|
|
|
The reality of CORBA now is that many vendors make components for creating and running applications on multiple platforms using CORBA as middleware. However, products from different vendors are only interoperable at the most basic level. Features important for enterprise computing, like security and fault tolerance, are only available from a few vendors, and are not necessarily compatible with each other.
One thing CORBA lacks is support for Microsoft's OLE. As Don DePalma, a senior researcher at Forrester Research pointed out, "The fundamental problem is that OLE is something visible through 90 or 100 million desktops and it is hard to argue with that many desktops compared to CORBA implementations, which you can measure in hundreds or thousands. There has to be some level of interoperability with OLE. That is something that OMG and Microsoft are working on. But, when something will work is unclear."
However, the OMG recently released a Request for Proposals to provide interworking between Microsoft's COM/OLE and CORBA. Geof Lewis, Object Product Business Development Manager at SunSoft in Mountain View, CA, said that we could start seeing some interoperability by the end of the year. "When it happens, Microsoft customers will be able to get networked solutions two years ahead of what Microsoft will provide."
Complying with CORBA
There are several components to CORBA computing. The object request
broker (ORB) provides an interface for servers and workstation to
connect to the CORBA environment. There needs to be a repository for
maintaining and developing new applications. An object repository, or
object oriented database management system (ODBMS) is required to store
and manage all of the objects. A relational database often handles
real-time, transaction processing types of data. Object-oriented
development tools create the applications. An object management system
monitors and manages the flow of objects across the network.
CORBA compliance is generally used by companies to mean they support the Object Request Broker standard specified in CORBA. The first ORB standard was released in CORBA 1.1 in 1991. Unfortunately, none of the ORB tools from different vendors talked to each other.
Earlier this year, OMG published the specifications for CORBA version 2.0. This standard defines a bridge to which companies can write a CORBA-compliant ORB. A number of companies have announced ORBs or plans to deliver them in the near future, including Teknekron Software Systems, Digital Equipment Corp., Expersoft, IBM, Iona Technologies, Isis, NeXT Computer and Post Modern Computing.
However, as Raj Mashruwala, senior director of Enterprise Applications at Teknekron, based in Palo Alto, CA, explains, "The CORBA 2.0 standard is not directly interoperable. The only thing that CORBA 2 says is you can build a bridge. The bridges don't cause a performance hit, but translation problems. I will not be able to use all of the features of some of the vendors."
"The point is that I cannot quickly assemble things, because now if I use five vendors ORBs then I need five bridges, not one. Writing it is not a big deal, but from an application developers standpoint you cannot just put a library together. You have to say 'I want module ABCD and then bridges 2 and 3 because I need to transfer between multiple ORBs.' It is not that the standard is crippled. but it has not gone to the place it needs to because there are too many vested interests."
On top of the basic ORB are a number of services to support network computing. Eleven have been accepted so far. However, ORB vendors are not required to implement any of them in order to be considered CORBA compliant.
For CORBA vendors, the services provide a mechanism for adding value to their products and making them more attractive than the competition. Mike Parker, director of marketing at San Diego-based Expersoft, noted, "We are really concerned about the tools and services that go on top of the base-level platforms, and there are lots of opportunities in that."
Expersoft is leading the way in terms of offering services on top of its ORB. It recently announced the release of PowerBroker 4.0, which supports the development of CORBA-compliant applications. Included in the package are five of the CORBA services (Naming, Events, Persistence, Externalization, and Lifecycle).
In addition PowerBroker includes object management capabilities for monitoring distributed applications in action. It runs on Solaris 1 and 2, HP-UX, IBM AIX, SGI IRIX, DEC Alpha, and Microsoft Windows 3.1 and NT.
Building high reliability with CORBA
CORBA has not yet defined any services for ensuring that the network is
fault-tolerant. However, several vendors have begun addressing
reliability by adding features to their ORBs. Expersoft uses a
replication scheme to distribute services to multiple servers. Post
Modern Computing has announced that it plans to work with Hitachi to
deliver an object-based transaction processing monitoring system by
mid-1996. The product will be based on Post Modern's existing CORBA
2.0-compliant ORB, and Hitachi's TP monitoring software.
Post Modern's ORB uses agents on each LAN to listen for clients and servers coming onto the network. When the client has a request, it sends it to the agent. If the server has gone down, the agent will seek another one.
Isis Distributed Systems, based in Marlboro, MA, and Iona Technologies, based in Dublin, Ireland, has developed what the company calls a highly reliable ORB optimized to support mission-critical applications. Its first product, called Orbix + Isis, is based on Iona's existing ORB technology and new code Isis developed for reliable computing.
Orbix + Isis includes a class library for managing the communications between client applications and two or more servers, which are kept in synchronization automatically. If the primary server goes down, the backup is available for handling the request immediately.
The network takes a performance hit when writing the same update messages to multiple servers. However, Orbix + Isis can make up for it when applications only need to read data, because they can be routed to the closest, or least-loaded server.
Larry Sherman, director of marketing at Isis noted, "There is some hit in performance. Simply the fact that you are doing the work for updates on two pieces of hardware is a significant overhead. The counter argument is that since Isis runs on various flavors of commodity hardware that is significantly less expensive than a fault-tolerant machine, you can afford to buy more of them."
Another feature that Isis brings to CORBA is asynchronous communications, which enables applications to send requests without having to wait for the reply. Standard CORBA only supports synchronous communications between objects in which one object sends a request, and then waits for the response before sending the next request. This can add significant delays, especially if the application is operating over a wide area.
Some CORBA developers support pseudo asynchronous communication by having the server return a fake reply immediately (so that the client can continue) and then the real reply once the server has generated it. Since this is a kludge, the CORBA community frowns on its inelegance.
Isis uses a publish-and-subscribe communications system. Objects subscribe to certain kinds of messages, such as a request for service. When an application publishes a method, it is sent to all the subscribers that requested it, where it can be processed. This enables developers to efficiently deliver messages, without having to worry about the location of all of the objects.
Simplifying global networking
An element missing from CORBA is the ability to manage the location of
objects. CORBA expects a directory somewhere, but none is defined. The
programmer could create a static directory. This works well in the LAN
environment, but when the applications begin to scale the enterprise,
static directories become too difficult to manage.
Teknekron has developed the ObjectBus ORB, which maintains a global directory automatically by using a publish-and-subscribe technique with intelligent agents. When a server first comes up, it registers with a local ObjectBus daemon. These daemons all subscribe to the messages that ask for information on objects. When a client requests a particular object, it is published across the enterprise to all of the daemons. If a daemon recognizes a request for a local object, it sends back a response.
Beyond providing an easy way of finding objects, ObjectBus can also help automatically distribute files to allow load balancing, or fault tolerance. In addition, developers can write an algorithm to decide the cost of a given service to a client. The cost could be based on such things as the server load, network load, and the distance between client and application, and change as the loads change. The client can be programmed to obtain service from the cheapest source.
Teknekron has also developed an enhancement to CORBA, which provides a system for distributing applets much like Sun's Java. CORBA uses a language called the Interface Definition Language (IDL), which enables the programmer to specify the location of an object that needs to be accessed. For many applications, the objects are hard-coded into the program. If the company updates its algorithms, it needs to update every copy of the program. This can be difficult, especially if those algorithms are encoded into applications on the user's desktop.
Teknekron's Mashruwala explained, "With IDL you can only send a reference to it. You can tell them to use a certain algorithm. But, you can't say which implementation to use. This is important for version control. If you have 5,000 credit analysts and you change the algorithm and let the file stand, it is not modified, because you are only sending the name, no one knows you are still using the old algorithm.
"If you are local you can put the object on a local server. But if you are global and you have 5,000 managers at each branch, you don't want this to be in a central server because all of those connections have to be up all the time. If it was in one campus, storing the methods locally is not a problem. In larger environments you cannot assume the linkages will always be up."
Teknekron has developed the Teknekron Definition Language to work on top of ObjectBus for delivering applets to applications as they are required. The applets can be distributed on servers throughout the enterprise. Then, when they are called, they can be delivered from the closest server. The object bus also makes it easy to update all these objects. When a new version is released, all of the remote copies can be automatically upgraded with minimal human intervention. Mashruwala said that they were working with the OMG to incorporate TDL into version 4.0 of the CORBA standard.
Middleware alternatives
Several companies will use CORBA to provide interoperability between
their middleware products and other applications. One example is NeXT
Computer, based in Redwood City, CA. It recently announced version
4.0 of its PDO distributed object model will support CORBA 2.0 when it
ships in mid-1996. NeXT will bring a whole host of tools for managing
objects throughout the enterprise, including support for distributed
OLE across the network.
Taligent Inc. based in Cupertino, CA, is planning on making its next release of CommonPoint, its object-oriented architecture, CORBA compliant. Dipak Basu, senior software engineering manager at Taligent said, "One of the reasons we did not support CORBA in the current release was because the CORBA 2.0 spec was not done, and CORBA 1.0 is not very useful. You could use Taligent today to get a first class distributed application. But the question I always get is 'will you also support CORBA so I can support other activities?'"
There is another effort afoot to develop a version of CORBA 2.0 that supports the Distributed Computing Environment (DCE). DCE supports many services required for enterprise wide applications, such as security, which are missing from CORBA. CORBA brings to DCE an environment that should make it easy to develop and manage applications using object-oriented technology.
Hewlett-Packard, IBM and DEC have all announced plans to develop CORBA 2.0-compliant applications, which also support DCE. DEC has already developed a line of CORBA 1.1 ORBs that run on everything from IBM mainframes to Sun workstations and PCs running Windows 95 or NT. It is planning to upgrade these to CORBA 2.0 compliance in the first quarter of 1996.
Hewlett-Packard plans to ship a new version of Distributed Smalltalk, which will support CORBA 2.0 in October. This will support the creation of CORBA and DCE applications. The OMG recently approved of C++ bindings for CORBA, which HP will support in its ORB Plus, which will ship in early 1996.
Jerry Boorez, Distributed Smalltalk product manager at Hewlett-Packard noted, "The biggest thing to be gained is the ability to mix and match complete applications or pieces of applications in a three-tier architecture where one piece is in C++ for performance and another might be written in Smalltalk for productivity gains."
Sun Microsystems has been a key driver of the CORBA standard. Sun created a reference implementation for CORBA 2.0 last March and worked with the OMG to put it on their server on a royalty-free basis.
Sun's Lewis said, "The OMG specs are essential to enable an open systems approach to distributed applications in the industry. We contributed most of the core specifications of OMG and nine out of the 11 services. What we submitted reflected our future products. At any given point based on things at OMG and what we are developing -- our goal is to be fully compliant as best we can."
The future of CORBA
CORBA is making steps toward its goal of seamless interoperability
between applications. However, now only a basic lowest common
denominator exists between products from different vendors. Although
the CORBA standard is evolving to take advantage of additions and new
services, it will be several years before they become part of the
standard. Meanwhile, CORBA vendors' advantage will come from the value
they add to their CORBA products for supporting things like
security and fault-tolerant computing.
|
|
Resources
About the author
George Lawton (glawton@best.com) is a computer and telecommunications consultant based in Brisbane, CA. You can visit his home page at http://www.best.com/~glawton/glawton/
Reach George at glawton@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright95.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-09-1995/swol-09-corba.html
Last modified: