Object Services and Consulting, Inc.
 

Scaling Object Service Architectures to the Internet

FINAL REPORT

September 28, 1998
 
Principal Investigator: Craig Thompson
 Team:  Tom Bannon, Gil Hansen, Frank Manola, Mark Palmer, Paul Pazandak, and Venu Vasudevan
 
Contract:  DAAL01-95-C-0112, AO C366
September 29, 1995 - September 28, 1998
 
OBJS Document:  http://www.objs.com/OSA/Final-Report.html
 

Executive Summary

Web technology and distributed object technology need to be better integrated to realize the benefits of both. The Web is already moving beyond documents to provide distributed applications.  Without an architectural framework, the web environment will build services parallel to but different from the object middleware community, and enterprise architects will be forced to make idiosyncratic tradeoffs in constructing systems that need to use both architectures together.

The overall thesis of our project is that an Internet Services Architecture (ISA) can help to unify both Web and ORB architectures.  During the life of the project, we developed the broad outline for a general ISA architecture and explored its utility in the virtual office and command and control domains.  We then focused on an instantiation of the general ISA which we call an Intermediary Architecture (IA), which provides a new family of ways to add middleware services into Web architectures by inserting component middleware between Web client and server.  We constructed a series of prototypes to demonstrate parts of the IA architecture.

Background

Object Services Architectures (OSAs) are distributed software backplanes with plug-in component object services.  OSAs promise vast improvements over conventional stovepipe software architectures in reducing software life cycle costs and providing modular software design. The Object Management Group (OMG) Object Management Architecture (OMA) (partly based on our previous DARPA research) is an important OSA because it is backed by a consortium of over 800 companies, is developed by an open process, and is being adopted into large-scale industry and DoD enterprise-critical systems and standards profiles including DoD AITS-JTF/ATD, NIMA, DMSO HLA, and DII COE.

Problem Statement

Today the Web consists of thin clients, which provide universal browser interfaces, and web servers, which provide back-end access to global information resources (that's where the data is).  Meanwhile OSAs provide access to suites of middleware services (that's where the system management and application extensibility mechanisms are).  As important as OSAs are becoming, they are a new kind of software architecture and industry still lacks theory and experience in scaling OSA systems to levels to support large-scale, world wide operations like command and control.  At present, OSAs are not well connected to control access to web data sources.  Without better integration, the web community will build protocol extensions (e.g., W3C WEBDAV) parallel to but different than the OSA community, and enterprise architects will be forced to make idiosyncratic tradeoffs in constructing systems that need to use both architectures together.   Furthermore, even if we can unify these two sorts of architectures, there is still a question of what new Internet services might be useful that are not already identified by OMG, how to compose these, and how to federate them in large WAN environments (many of these questions are still unanswered for pure ORB architectures).  Another problem is the kind of object model that is appropriate for both Web and ORB.  Finally, there is the problem of how enterprises can deal with the incredibly complex Internet environment where technologies change daily.

Objective

There is a family of architectures for composing ORBs and the Web.  Together, these architectures open up a wide new spectrum of services and facilities that can enable a broad class of future architectures.  We call this class of architectures an Internet Services Architecture (ISA) by analogy with the OMG Object Services Architecture.  The overall thesis of our project is that an Internet Services Architecture can help to unify both Web and ORB architectures. Some approaches for instantiating ISA architectures are already known (developed over the last three years):  e.g., the three tier architecture where Web servers access ORBs via CGI scripts; the approach pioneered by Visigenic and Netscape of downloading an ORB client via an applet; and the recent W3C HTTP-NG project where HTTP is re-implemented on a distributed object backplane.  Our project focused on another variant ISA that appears to be broadly useful, which we called an Intermediary Architecture because it inserts middleware services between Web client and server.
 

Technical Accomplishments

In this section, we divide our main technical accomplishments into three layers of description corresponding roughly to the three years of the contract.

Internet Tools Survey and the Virtual Office

In FY96 we organized Object Services and Consulting, Inc. (OBJS) as a virtual office (distributed office), dependent on Internet, Web, database, distributed object, and related infrastructure technologies.  Our main focus that year was on identifying, describing, and installing a large family of software that constitutes the core of Internet, Web, and distributed object technology for virtual enterprise computing.  A main contribution that year was the Internet Tools Survey, described in the Technology Transition section below.  The Internet Tools Survey provided a detailed look at many technologies needed to Internet-enable applications but that so far did not clearly fit into an overarching software architecture and were then beyond the realm of OMG middleware concern.  To change that situation, we began to move OMG in the direction of a rendezvous with Internet and Web technologies by co-chairing the OMG Internet Special Interest Group.

Internet Services Architecture (ISA)

In FY97 we worked with OMG to develop a high level industry roadmap for an Internet Services Architecture to unify both Web and ORB architectures.  The ISA consists of a suite of possible standards that OMG might adopt over a several year period to make Web-ORB integration easier.   The ISA extends the OMG OMA and draws on the strengths of both OSA and Web technologies. OSAs can provide the web with a principled model for composing object services, federating like services with possibly varying policies and implementations, combining these into systems of systems, and controlling binding times of these services so new services can be added to existing systems. Both the OMG and Web communities have sufficient momentum that neither can change instantaneously, making an evolutionary approach the only one with a likelihood of success.

Intermediary Architecture (IA)

In FY97 and FY98 our work focused on a specific instantiation of the Internet Services Architecture that we call an Intermediary Architecture.  The IA splices ORB (or DCOM or other) componentware services in between Web clients and servers to provide a management layer that extensibly allows many new kinds of services to be plugged in.

The Intermediary Architecture is open and flexible and can be used for many purposes including security, versioning, internationalization, query augmentors, shielded pages, rating systems, rerouting, filtering, logging, system management instrumentation, clocking, micropayments, disconnected, intermittent access, tracking URL usage patterns of a community of interest, background indexing of pages you have seen before so you can find them again, indexing streams of audio or video, translingual translation service, closed caption in multiple languages, and augmenting a web page with voice access to URLs.  This makes the Intermediary Architecture an excellent candidate integration harness for testing other DARPA technologies.

Advantages of the Intermediary Architecture are:

 
 
 
The Intermediary Architecture is shown in the above figure.  In its simplest form, it consists of:  The architecture can appear in many variations: The overall claim is that the Intermediary Architecture provides a framework for service insertion, composition, and federation.  We do not claim to have thoroughly explored this space.  There is still much we do not understand though limited prototyping has taught us a fair amount about the Intermediary Architecture.

To learn about the properties of the Intermediary Architecture, we completed a series of separate prototypes of parts of the architecture (each is separately described):

Prototyping involved reuse of a number of state-of-the-art commercial and experimental tools including ORB systems, Web systems like W3C Jigsaw, object DBMSs, and query systems.

Technology Transition Accomplishments

Lessons we learned about the Internet Services Architecture and the Intermediary Architecture were fed back to industry and DoD through our active participation in architecture initiatives, principally the Object Management Group (OMG), the World Wide Web Consortium (W3C), DARPA/ISO Advanced Information Technology Services (AITS) , DARPA Dynamic Database Panel II, the National Industrial Information Infrastructure Protocols (NIIIP) Consortium, MCC Object Infrastructure Project (OIP), and X3H7/ODP as described below.

The following reports were completed under this contract.  All appear on the OBJS public web page to better disseminate the results.  See OBJS Technical Reports and Publications.   Several were presented in workshops, conferences, or journals or at standards meetings where they were used to build consensus for an Internet Services Architecture.

Virtual Office and DoD C4I and Doctrine Application Domains

We identified two broad domains in which to develop application scenarios that would use ISA technologies:  virtual office and command and control.  Both domains require technology support for collaboration-at-a-distance.  We organized Object Services and Consulting, Inc. as a fully geographically distributed virtual office environment, making us our own testbed for collaborationware.   We documented virtual office and collaboration technology requirements and "lessons learned" in provisioning our own virtual office domain. We identified DoD doctrine as a good domain for future application scenarios in command and control. We are not aware of much DARPA work in this area though DoD has spent a substantial effort working to document its doctrine-related practices.

Internet Tools Survey

Defense Information Infrastructure Common Operating Environment (DII COE) is a suite of standards that DoD enterprises build on, but it does not contain as much information on Internet technologies as is needed to Internet-enable future DoD applications.  Mostly in the first year of our contract, we assembled a complementary Internet Tools Survey to provide a description of key technologies we feel must be understood to Internet-enable enterprises, virtual offices, and command and control. New additions after the first year include work on web object models, web-ORB integration architectures, and traders.

Publications

We published the following papers:

Workshops

We organized two industry workshops:

Standards DARPA Reviews Related Technology Transfer Projects.  We provided OSA componentware architecture expertise to DARPA and industry research programs.

Conclusion

We succeeded in advancing the state-of-the-art and the state-of-practice in several ways during the life of the project.  Our main contributions are:

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1996-1998.  Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page.

Send comments about this report to thompson@objs.com.

Last updated: 9/28/98 -- Back to OBJS  homepage.