Response from
Object Services and Consulting, Inc.
to the
OMG Internet Services Request for Information

Craig Thompson
Object Services and Consulting, Inc.

14 October 1996

Posted 28 October 1996

© Object Services and Consulting, Inc. 1996

Object Services and Consulting, Inc. grants to OMG staff the right to make unlimited copies of this document for the purpose of distributing these to OMG member companies and for OMG internal use and further grants OMG member companies a limited copyright waiver to make up to fifty (50) copies for OMG review purposes only.



With the recent announcement of OMG Internet Inter-ORB Protocol (IIOP) soon to be available in Netscape clients and servers, one of the promising approaches to scaling the OMG Object Management Architecture to the Internet is going to be realized, and we can soon expect OMG technology to become available pervasively. Instead of deployment of OMG distributed technology in LANs with 40 distributed nodes, we will see Intranets and the Internet using OMG technology to connect together upwards of 40M nodes. There are new opportunities and challenges for OMG technology in this suddenly mainstream large-scale environment. Not all OMG technology created to date is fully scaleable and new technology will be needed.

This response to the OMG Internet Services Request for Information (ORBOS RFI#1, OMG Document # ORBOS/96-06-18) from Object Services and Consulting, Inc. represents some of our ideas on what OMG will need to do to move forward to meet the challenge of "objects for the masses" and fully realize some of the goals of providing a widely useful middleware framework for future enterprise and global computing.

At recent meetings of the OMG Internet SIG, we cast the problem as follows: identify functions fi that complete the equation:

The remainder of this response is a listing of suggested changes and additions to the OMG suite of technologies to meet the challenges ahead. Some are specific suggestions for new components; others are thoughts on changes in direction; some are mundane, others controversial. For simplicity, this response is structured as a "to do" list and not quite an architecture but we imagine that this and other responses to the Internet Services RFI might provide enough new ideas to develop an Internet Services Architecture extension to the OMG Object Management Architecture.

To Do List

Process, Perception and Reality, OMG Immaturity

Outside the OMG community and even within OMG, there is a basic perception that OMG is principally developing an object RPC mechanism. The CORBAservices, CORBAfacilities, and domain objects have made little community impact and so far industry does not yet view OMG as the place to develop some of its standards. OMG might need to make some mid-course corrections if it is to grow up to be the one-stop-shopping center for an open suite of mix-and-match, plug-and-play distributed object technology standards. In particular,

Object Model Challenges

A deep question we've been asking ourselves is, "What is the right type model for the Internet?" It is clear that there will always be many different representation schemes including many different object models; the X3H7 Features Matrix provides an understanding of the variety of kinds of representation primitives that make up different useful type systems. But if OMG IDL becomes pervasive, it might be useful to a wide variety of communities that currently use other type systems and some changes or additional mappings might be needed. The following is a list of some key challenges for OMG in this area:

ORB, CORBAservices, and CORBAfacilities

Immaturity-what's wrong? As mentioned above, a problem with OMG today is maturity with respect to CORBAservices. Tomorrow, with IIOP on the desktop, it sure would be nice if CORBAservices were there too. One puzzle is that, while OMG services and facilities provide API specifications, they say nothing about other interfaces a component/service may need to at least optionally publish. In particular, some form of uses specification is needed. This specification is probably a relationship between an implementation and another specification so it is optional. But without it, one cannot think in terms of the mix-and-match ability to replace a service with another implementation.

New ORB capabilities needed. CORBA supports "reference at a distance" and simple blocking synchronous dispatch. Several ongoing efforts are in place or at least talked about to extend the scope of CORBA's distributed semantics coverage:

New Basic Object Services needed. Object services we do not yet have are needed to scale to the large:

Composition of Basic Object Services. OMG OSTF did a good job of teasing apart a collection of basic object services specifications. But there is not yet clear evidence that those services can be recomposed to form compositional services. It has always been thought that Common Facilities were "higher level" than Basic Object Services but just how has not been specified in OMG's OMA architecture. The new Madrid OMA indicates that Common Facilities may be built using Basic Object Services and ORB capabilities. But the Common Facilities adopted so far do not really seem to be compositions of Basic Object Services in any direct way. So far, the only facility that seems to use the Basic Object Services is the Business Object Facility, which has as one goal to hide many of the composition details so end users can use a whole system and not be involved in toolkit aspects of the composition process. It is instructive to look at some of the BOF submissions and consider which functionalities make up a BOF, and whether we need Basic Object Services or derive any benefit from them in this composition.

Are there interesting Common Facilities in the narrower sense of being built on Basic Object Services? It might reasonably be supposed that an OODB Facility could be composed from Persistence, Naming, Transactions, Security, and a few other basic object services; and an OODB-RDBMS hybrid could be composed from those services with the addition of Collections and the Query Service. But is this directly the case or will OMG end up adopting ODMG compliant OODBs or SQL compliant relational DBMSs that are only loosely related to OMG basic services?

Therefore, we propose that the following composed systems be placed on the Common Facilities Roadmap:

At the same time, we believe there will be value in attempting to deconstruct existing systems into Basic Object Components and subsystems with IDL interfaces. This Common Facilities "exercise" will inform the OMG community about the value of the services provided to date and will identify other needed services. Examples of "legacy systems" we could deconstruct include:

Multiplicity and Federation of Service and Facility. In the beginning there was CORBA. Then we realized different CORBA implementations would have to interoperate so we developed specifications for CORBA Interoperability and IIOP. Meanwhile we busily developed a collection of Object Services. Now, we are about to enter a time when IIOP is standard inside Web browsers. In single site CORBA implementations, we might have assumed that for one ORB there was one copy of each object service. Now, in the large, we must assume there are many, many copies of each service - we call this service multiplicity. Service multiplicity leads to another collection of composition problems we loosely call federation, or the need for like basic object services and common facilities to compose. Examples of the federation pattern at the basic object services level include: federated namespaces, nested transactions, distributed queries, traders talking to other traders, and federation of caches and indices. But we can also imagine federated common facilities like federated repositories, federated DBMS systems, federated KBMS systems, federated workflow systems, and federation of web search engines. This leads to the suggestion for one or more Federated Services RFPs that extend current specifications to be able to connect together in a leggo-like way possibly using some sort of common federation pattern.

Theory needed. Systems composed from components by composition or federation suddenly appears to promise some scaleability in middleware that we have not yet seen. This will raise several questions we cannot yet answer:

The above suggestions are near term and some careful architectural thinking should go into them to insure that we do not end up with a wide variety of unnecessarily differing components (like rules systems), facilities (like OODBs), or composition primitives.

The following section provides a longer view of what might be possible if objects are pervasively integrated with the web.

Global Organized Information Space

The wonder of the Web is that it hooks together information sources so that there begins to be some coherency of content on a massive, global level. Object technology seems to naturally provide part of the answer. But more structuring primitives appear to be needed to begin to view the object/web as a global knowledge base. Certainly, the simplistic analogy to 1980's AI KBMS systems is weak because most of those systems were single user, very complex, and favored rules as a primary means of representation whereas we probably need a much nicer multi-paradigm representation (objects, rules and constraints, other TBD).

So what sorts of "layers" might appear in a new age global organized information space? Several of these layers are definitely beyond the current scope of OMG and there is a five year agenda in the above sections just to scale the middleware to Internet size. But it is worth thinking that there is a higher level target and this section outlines steps beyond leggo middleware that we might be able to get to.