DBMS, July 1996
Until recently, many implementations of distributed object computing were appropriate only for small-scale or specialized implementations. The Internet, however, is beginning to have an interesting impact on distributed computing technology. In fact, the Internet may help transform the scalability of distributed object computing and give users a much more flexible way to leverage data transparently across organizations and deliver it to their customers and suppliers.
In many ways, the Internet in isolation is really a shallow set of technologies. It includes protocols for moving information, called Common Gateway Interfaces (CGIs); HTTP for downloading Web pages; and HTML, a markup language. Before the Internet can mature, however, it will require a variety of additional technologies ranging from security services to transaction management.
As a distributed computing model, the Internet presumes that applications are designed to be distributed across a variety of clients and servers around the globe. Fat, clunky software won't be able to meet the demand for fast communications and information access. In fact, the Internet itself is a distributed architecture. It is based on a networked backbone of TCP/IP and assumes that users are accessing services from a variety of locations via a set of presentation services. Users have little knowledge of where a service might reside, nor do they have the ability to determine how to get to that service. The Internet's flat hierarchy lets application services move from one server to another more easily.
For the past decade, distributed object computing has allowed organizations to build applications as a series of components or services that could be designed and stored across a network and brought together only when needed to perform a business function. With distributed object computing, component developers and users can locate code without knowing its location in advance.
Object Request Brokers (ORBs) are an important part of the new technology of distributed object computing. Conceptually, an ORB makes distributed data and logic appear local. Objects stored in an ORB can communicate with one another and with an application via messages. With the advent of the Object Management Group's Common Object Request Broker Architecture (CORBA) software, companies are beginning to provide commercial implementations of this distributed object technology.
As implemented in the CORBA specification, an ORB allows systems to be designed with pointers to code that resides on a variety of systems. Because data and rules are distributed, ORBs become a key component of a three-tier approach to providing the messaging middleware. The use of distributed services with an ORB underpinning can have a dramatic impact on application scalability. The current design of most applications is such that, as complexity grows, performance degrades. On the other hand, if an application is written as a set of modular services that can be physically distributed, complexity can be added without affecting performance.
From a corporate computing perspective, an ORB offers failover capability by duplicating replicated name services in several locations. Users do not need to know which copy of an object they are accessing. If one fails, the broker simply points the user to another location. This approach also offers the flexibility of load balancing, a key issue with distributed software. Load balancing is the ability of software to distribute pieces of code across a variety of servers to increase efficiency. With ORB-based implementations, software components can be distributed and code can be moved to the server that can best handle a particular function.
To be scalable, ORB implementations will need the addition of queuing, communication multiplexing, and state persistence. All three of these technologies are available as middleware from a variety of vendors, such as IBM, Seer Technologies Inc., BEA (Tuxedo), PeerLogic Inc., Open Environment Corp., and Teknekron Software Systems. ORBs can be integrated with middleware components through an Internet-oriented implementation.
The good news is that many products exist that give users a good starting point for ORB technology; for example, Digital Equipment's Object Broker, IBM's SOM, Sun Microsystems' SolarisNEO, Hewlett Packard's ORB+, Iona Technologies' Orbix, PostModern Computing Technologies' ORBeline, and Expersoft Corp.'s PowerBroker Distributed ORB (formerly XShell Distributed ORB). Microsoft's Distributed COM architecture, including a planned implementation called Viper, will offer an NT-specific ORB that is oriented toward both synchronous and asynchronous communications. Some third-party software vendors that leverage ORBs include NeXT, I-Kinetics, and DNS Technologies. The objective of all of these technologies is the same: to allow developers to use code and technology across a distributed set of services.
When ORBs are implemented within a distributed computing infrastructure such as the Internet, and are used in combination with sophisticated communication middleware, exciting things start to happen. For example, implementing independent services that will interact only when necessary is more efficient than building redundant functionality into every application. Instead of writing fully integrated applications, developers can write modules of reusable code. Not only does this lead to a more efficient computing environment, but, with the Internet, this model of computing is becoming a requirement.
What does this mean for users who are currently designing a Web page? Distributed software, such as CORBA and ORBs, can have a positive effect on Web-based applications. For example, the typical Web page that utilizes the Universal Resource Locator (URL) as a hard-coded pointer to an IP address and file path uses CGI scripts to link these pointers to Web servers. If a location changes, the user is given an error message that the location cannot be contacted. If a URL has been replaced by an object-request brokering capability, the physical address of the page could have been resolved at runtime. This concept of location transparency or independence can be applied to a wide variety of distributed services that are split among clients and servers. It offers the flexibility of being able to change the client-side environment continually without distributing the ability to locate and use distributed services.
Bringing the Internet together with communications middleware and CORBA implementations could transform the developers' ability to implement distributed computing. Technologies such as ORBs offer enormous potential to make the transparent distribution of data work in a larger context than has ever been possible before. IT organizations should begin to rearchitect key components of application code to simplify the move into the new world of distributed computing. IT managers should begin planning today to discover which application services will help their organizations leverage the Internet more easily.
Getting started may be the hardest part. When companies are fighting fires and worrying about maintaining old code and aging applications, it's hard for them to think about major changes to their application architecture. But it will be worth the trouble in the long run. Following are some good starting points. Learn about the underpinnings of the Internet and CORBA. Experiment with a pilot project involving an ORB. Begin to look at how your existing and new applications can be designed as a set of services. Be adventurous. Moving to a distributed architecture will have long-lasting rewards for your organization.