DARPA Project Summary - Scaling OSAs to the Internet (original) (raw)
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:
- it provides a new kind of plug-in and an improved way for third-parties to build extensible web applications;
- it is non-intrusive requiring no change to existing Web infrastructure*; * we did not find this to be 100% true. See below.
- it generalizes many special-purpose efforts to add specific services to Web applications;
- it provides a general framework for reasoning about how to federate and scale Web applications.
The Intermediary Architecture is shown in the above figure. In its simplest form, it consists of:
- an intermediary, also known as an interceptor, that inserts (and composes) service behaviors
- one or more service behaviors
- metadata associated with services (stored in a persistent metadata repository) as well as policy management controls
- a management function for querying, viewing and manipulating metadata and controls The architecture can appear in many variations:
- there are many kinds of services that can be inserted via an intermediary -- see the list above.
- there can be more than one intermediary and different roles can control different intermediaries. For instance, different groups in an organization could manage security, caching, filtering, system management and logging, functions like annotation, the ability to add new functions, etc.
- intermediaries can be implemented as adjunct to the client or to the server or somewhere in between. We can talk about client intermediaries, server intermediaries, and proxy intermediaries.
- more than one service can be inserted via intermediaries. Services can compose in series or in parallel. In general, the area of service composition needs more work since there are many ways to wire up even two services (see lessons learned on the Network Performance Management project where it is possible to capture performance for just user-specified URLs or all GIFs as well).
- services can be inserted dynamically at run-time. One way to do this is via a Trader that provides service discovery. The trader can do this once at the beginning or can be continuously polling to locate new or better service providers or to make the system more robust if some providers fail.
- a given service can store metadata it collects in some repository. If local to the Web client, the service might provide_personal services_ (e.g., personal Web annotations -- see the Annotation Service below). If shared in a group, the service can provide group services (e.g., group annotations). If shared within a community or on the server it can provide public or community services.
- repositories could be federated together to allow more sharing.
- repositories can be different for different services or they could be shared across services (e.g., so that both the performance monitor and the annotations services could share one repository).
- it is important to be able to view and query the metadata.
- federation can appear in many places within this architecture: individual services can be federated, repositories can be federated. 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):
- **Intermediary Architecture Interceptor**- this mechanism is installed at insertion points to provide a way to plug object service components and before-after filters into the communication path between Web client and Web server to enable the installation of new services.
- **Web Object Model**- this project examined how XML, DOM, PIC-NG, Dublin Core, LORE, OMG IDL, Java, and other information and metadata representations can add object model capabilities to the web. An associated prototype is XML to Java Translator - this mechanism provides an easy way to deserialize XML DTD schemas into Java classes and is likely to be widely useful stand-alone.
- Annotation Service - this prototype shows how to use the Intermediary Architecture to plug in a service that downloads annotations on a document, providing a way for third parties to augment web content. Different architectures for the service could yield private, group, or public annotations and voting or rating mechanisms.
- Personal Network Performance Monitor Service - this project shows how to use the Intermediary Architecture to provide network performance and trend data when accessing remote sites. This data can be used as a basis for QoS negotiation in higher level tools.
- **NLI Query Interface**- this project focused on how to use an existing natural language query system to access metadata stored in IA metadata repositories.
- **Trader Service**- this project provides two matchmaking services for service discovery. One implementation is scalable and based on Internet search engine; the other shows how to extend an OMG trader to locate Web resources. 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.
- Virtual Office White Paper, Craig Thompson, Shaun Joseph, January 1997
- Enabling Technologies for the Virtual Office, Frank Manola, January 1997
- Electronic Support for Collaboration and Decision Making in OBJS, David Wells, January 1997
- Initial Use of COTS Tools in the OBJS Virtual Office, Frank Manola, May 1997
- Virtual Office and C4I Scenarios, Frank Manola, January 1997 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.
- Introduction
- Introduction to Internet Tools Survey, David Wells, Craig Thompson, 1996
- Visions: Application and Technology Drivers, Craig Thompson, Frank Manola, January 1997
- Objects and the Web
- Componentware Glossary, Craig Thompson, Frank Manola, January 1997
- Internet Engineering Task Force Overview, Craig Thompson, April 1996
- Object Management Group Overview, Craig Thompson, April 1996, updated July 1997
- Object Models, Craig Thompson, April 1996
- Requirements for OO + Web Integration, Craig Thompson, January 1997
- Current Web Architecture, Craig Thompson, Gil Hansen, January 1997
- Web Programming Languages, Steve Ford, David Wells, Nancy Wells, January 1997. This paper was the cover story for the first issue of WebApps magazine, a new journal edited by the World Wide Web Consortium (W3C).
- Web + DBMS Integration, Craig Thompson, Paul Pazandak, January 1997
- Web + Object Integration, Gil Hansen, Craig Thompson, January 1997 (draft)
- Towards a Web Object Model. Frank Manola, January 1998.
- Some Web Object Model Construction Technologies, Frank Manola, September, 1998.
- Web Object Models, Frank Manola, presentation to OMG Internet SIG, September 1998
- Augmenting OMG Traders to handle Service Composition, Venu Vasudevan, September 1998
- Semantic File Systems, Paul Pazandak, Venu Vasudevan, January 1997
- Wrappers, David Wells, April 1996
- Quality of Service, Gil Hansen, January 1997
- Managing and Using Information
- Hypermedia Systems and WWW Browsers, David Wells, April 1996
- HTML Authoring Tools, David Wells, April 1996
- Searching and Indexing, David Wells, Ansu Kurien, April 1996
- Groupware & Collaboration Support, David Wells, Ansu Kurien, April 1996
- Video Conferencing, Steve Ford, April 1996
- Security
- Authentication, David Wells, April 1996
- Encryption, David Wells, April 1996
- Virtual Private Networks, Steve Ford, January 1997 Publications
We published the following papers:
- Web Programming Languages, Steve Ford, David Wells, Nancy Wells, January 1997. Cover story for the first issue of WebApps magazine, a new journal edited by the World Wide Web Consortium (W3C).
- Intermediary Architecture submitted to ACM Computing Surveys, Special Issue on IC&V, for publication in 1999.
- Towards a Richer Web Object Model. Frank Manola, SIGMOD Record, Volume 27, Number 1, March 1998.
- Technologies for a Web Object Model. Frank Manola, to appear as lead article in the Special Issue on Web Object Models, IEEE Internet Computing, Jan/Feb 1999.
- On Web Annotation: Promises and Pitfalls of Web Infrastructure, Venu Vasudevan and Mark Palmer, to appear in the 32nd Hawaii International Conference on Systems Sciences, January 1999. Workshops
We organized two industry workshops:
- We co-organized the Joint W3C-OMG Workshop on Distributed Objects and Mobile Code held in Boston in 1996. The workshop convened some of the key players interested in making Web + Object integration a reality.
- We organized the OMG-DARPA Workshop on Compositional Architectures held in Monterey, California, in January, 1998. The workshop convened key players from industry, universities, OMG, and DARPA to discuss scaling and other properties of component software architectures and how to splice web and ORB architectures together. We contributed papers on
- Intermediary Architecture: Interposing Middleware Services and Ilities between Web Client and Server, Craig Thompson et. al.,
- Towards a Web Object Model, Frank Manola
- Reference Model for Trading-based Distributed Systems Architectures, Venu Vasudevan, December 1997
- Thoughts on OMA-NG: The Next Generation OMG Object Management Architecture, Thompson, Linden*, Filman*, OMG ORMSC/97-09-01 (*MCC Object Infrastructure Project.) We edited the Workshop Report, which was published in ACM SIGSOFT Software Engineering Notes (SEN). Standards
- OMG. We provided overall leadership in OMG to transition the Internet Services Architecture vision to industry. These technology transfer efforts leveraged our project's technical work by providing a broad forum to test our ideas, one that will materially influence industry directions. At the same time, these forums provide critiquing of our idea base by industry experts and acceleration of acceptance of our architectural proposals. They also provide forums for showcasing related DARPA technologies to industry and universities.
- We organized and co-chaired**OMG Internet Special Interest Group** (1995-present) whose mission is to scale OSA architectures to the Internet. See Mission Statement and Minutes of Meetings.
- We authored an industry-wide OMG Internet Services Architecture Request for Information. We responded to the RFI, analyzed responses, published roadmap recommendations for future OMG RFPs to standardize OMG-compliant Internet services. OMG ORBOS and Common Facilities Task Forces aligned their roadmaps with ISIG recommendations. Several OMG RFPs resulted: Java-to-IDL (Java Reverse Mapping), Firewalls,Component Model,Common Internet Protocols. The first three resulted in OMG technology adoptions.
- We helped form four OMG Internet SIG working groups:
- Object Transfer Access Mechanism - like (a subset of) the DARPA I*3 reference architecture
- Compositional Architectures - focused on next generation OMA
- Computer Supported Cooperative Work - focused on defining a collaboration framework
- Web/OMA Integration Architecture - focused on Web-ORB integration and Web Object Models
- We were lead author of OMA-NG: Next Generation OMG Object Management Architecture, an OMG green paper (architecture paper) written jointly with the MCC OIP project. The paper was presented to OMG Object Model and Reference Model Subcommittee in September 1997 and suggests extensions needed to the OMG object management architecture (OMA) to carry OMG forward for the next several years. Parts are being adopted into the OMA-NG work.
- We completed a **White Paper: DARPA participation in Industry Standard Development Organizations**for DARPA. The white paper makes the case that DARPA needs coordination agents to be actively involved in technology transition of DARPA technology to/from OMG and W3C.
- NCITS X3H7. We completed the primary work item of former ANSI X3H7, which developed a feature matrix to compare object models to show the kinds of interoperation problems that will be experienced when different communities adopt different base object models. See**NCITS H7 (formerly X3H7) Object Model Features Matrix**, Frank Manola (Editor), June 1997.
- Covers: OODBTG Reference Model, OMG Core Object Model, OMG CORBA IDL, ODMG, EXPRESS,Open Distributed Processing (ISO/IEC JTC1/SC21/WG7), Management Information Model (ISO/IEC JTC1/SC21/WG4), SQL3 (H2), Matisse, C++ (J16), OO COBOL (J4),Smalltalk (J20), Eiffel,Emerald, Cecil,SELF, System Object Model (SOM), OLE Component Object Model, Analysis and Design Methods
- We are active in X3H7/X3T3-ODP working on object models and enterprise languages.
- W3C. We joined W3C and closely followed the submission process, which resulted in our papers on Web Object Models listed above in the Internet Tools Survey.
- IETF. We participated in an IETF meeting in December 1995 to discuss how OMG and IETF should liaison, and sent OMG a memo on OMG-IETF Cooperation. DARPA Reviews
- We participated in annual IC&V and I*3/BADD PI meetings and project reviews throughout the life of the project. Related Technology Transfer Projects. We provided OSA componentware architecture expertise to DARPA and industry research programs.
- We co-authored the DARPA_Intelligent Integration of Information (I3) Reference Architecture_(1995).
- We served on John Schill's short-lived DARPA Infrastructure Panel (1995).
- We provided architectural guidance to the DARPA TRP National Industrial Information Infrastructure Protocols Consortium(1995-1997, consulting), working on virtual office technology.
- We participated on the DARPA Dynamic Database Panel (summer 1997, consulting).
- We provide architectural guidance to the MCC Object Infrastructure Project working on fault tolerant, secure OSAs (1997-1998, consulting).
- We currently serve on the review team for the DARPA/ISO Advanced Information Technology Services (AITS) architecture which is developing a unifying architecture for DARPA C4ISR programs JTF/ATD, JFACC, ALP, GENOA, and BADD (1997-1998).
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:
- We developed a new software architecture for Web-ORB integration which we call an Intermediary Architecture because it inserts middleware services between Web client and server. We extensively reviewed the Web-ORB integration architecture literature and, until recently, found little other work on extending the web with intermediaries though there is prior work on Web proxies for use in firewalls and for caching and ORB interceptors for security. We developed prototypes to show how useful this intermediary architecture is and that it provides a generally useful approach for connecting Web and ORB architectures. Lessons learned include the fact that today's web clients are not open enough to directly support this architecture but a universal intermediary could provide this openness in a portable manner.
- The particular prototypes we developed (interceptors, annotations, network performance monitoring, query interface, trader) and the web object model all provide insights into the general architecture and at the same time are interesting and useful in their own right.
- Our work on virtual office scenarios is one of the best documented examples of how to use Internet-based technologies to build small business virtual offices.
- Our architecture and technology transfer activities are making a direct impact on OMG Object Management Architecture and OMG's platform technology roadmap as well as directly benefiting a number of DARPA and industry initiatives: DARPA AITS (ISO) Architecture, NIIIP, and MCC OIP.
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.