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

Index

• Introduction
• To Do List
  • Process, Perception and Reality, OMG Immaturity
  • IDL Object Model Challenges
  • Extensions to ORB, CORBAservices, and CORBAfacilities
  • Global Organized Information Space

Introduction

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 f_i that complete the equation:

• Today's OMA + {f₁, f₂, ..., f_N} = OMA scaled to the Internet and WWW

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,

• High Availability of Published Specifications Needed. Putting OMG specifications on the web would solve the problem of making them highly available.
• Reference Implementations Needed. One area OMG may need to make organizational changes is in developing additional architectural and organizational principles for insuring that there are "reference implementations" (or even approximate reference implementations) of OMG services and that these are modular and can mix-and-match so that an industry of componentware can develop. So far, ORB vendors that provide basic services do so on their own platform and these are not sold separately with any guarantee of working on other ORB platforms.
• Borrow process from others - The Open Group and IETF. It might be valuable to build even stronger liaisons with these groups or at least borrow some of the ways they do business. IETF's requirement that there must be multiple interoperating implementations before a protocol becomes a standard gives time to improve specifications, and its marketplace philosophy allows some unsuccessful standards to die more naturally than does OMG's approach. There is value in the OSF philosophy of building reference implementations like DCE. (But there are tradeoffs too, if the community had to wait for a mandated reference implementation, that would cause other problems.)

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:

• Converge OMG IDL and Java - Java's object definitions and IDL are not far apart but the differences should be made as small and inconsequential as possible so OMG and the Java community can inherit each other's benefits. If this means some changes to IDL, then so be it - view the changes as a midcourse correction in mainstreaming OMG. At the same time we could try to make OMG the de facto Java standards body (complementing the new ISO SC22 Java Study Group). Adoption of Java would give OMG a much needed "scripting language" and access to a mobile code and mobile objects story. Arguments that OMG IDL is a specification language and Java a programming language are weakened when the class definition facilities in each are approximately equally expressive. [Of course, we know this is controversial.] Failing all of the above, OMG needs a Java strategy beyond Java as another programming language.
• Converge OMG IDL and MIME - Is the right type system for the Internet something as weak as a type token in MIME or as strongly typed as IDL. What can we learn from MIME-enabled scripting languages such as Safe-Tcl? We'll come back to this question below. Should there be MIME - IDL mappings?
• Converge OMG IDL so it becomes the object model in ODMG/SQL"3" - the opportunity is to use the same type model for distributed sharable data and persistent sharable data. This is probably now a lost cause, and, if so, then we will soon need an IDL to SQL ADT mapping. We probably also need a simple standard Relations to IDL mapping. And we need to look carefully at how to connect OMG technology to Microsoft OLE DB, which provides some interesting support for structuring data and some fine-grained openness in its specification.
• HTML to IDL Mapping - so HTML tags can be made available as objects at runtime in a standard way.
• Naming issues
  • interoperability of OMG and web naming (e.g., OIDs and URLs)
  • federation of namespaces when IDL names in one environment clash with the same names in another.
  • typed links so web objects can be strongly typed.
• Converging other communities - the bullets above list challenges that would unify large communities. Even partial success in any of these areas would decrease the arbitrary representation boundaries that surround many of our worst large-scale representation interoperability problems. There are other similar challenges (e.g., COM/DCOM, PDES/STEP EXPRESS) where work on mappings is in progress.

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:

• call by value or the ability to move state around
• asynchronous dispatch - we do need to decide that is wanted here or if deferred synchronous is enough. What is the status on the Asynchronous RFP?
• optional additional guarantees like isochronous delivery
• programmable dispatch - several ORB implementations have hooks to allow software to be invoked at various points during the dispatch process (both client and server side). Should we provide some standards here? It's possible that the security service's general Interceptor specification is what we want. If it is, then it is buried in the wrong place in documentation. Filters that provide before and after methods in a uniform way are needed.
• Speaking of rearranging documentation, the CORBA specification is really two specifications in one: IDL and distribution. These should be separate specifications.
• modular quality of service - so QoS can be included at several levels of a composition hierarchy, not just at the communications layer
• migration management - for controlling and load balancing
• media streams for varying media types, not just audio and video but radar data, etc.
• compiling down to an IP + bytecoded methods level - do we need to do this?
• near-term mechanisms for handling firewalls in acceptable ways and longer term security mechanisms for supporting access control based clusters to replace firewalls.

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

• Caching Service - if we can move state, we'll need caching. Needed in compositional OODBs and/or compositional Web Servers as well as in many other higher level systems. Should caching be hierarchical?
• Replication Service - based on groups (as in ISIS)
• Generalized Indexing Service - supports having one or more indices (in the DBMS sense of access paths) to the elements of collections (or possibly other objects). Subkinds of index objects might be Hash, B-tree, KWIC, ...
• Parsing Service - for structuring flat representations. There are presumably many kinds of parsers and many kinds of representations parse. It might be convenient to have a FileType predicate that can examine a file and assign a representation type to it.
• Translation Service - for converting one representation to another. Is this the same as the Data Interchange Service?
• Change Management Services - these might include version service (for capturing derivation histories or alternatives), configuration service (for capturing and manipulating compositions), and dependency service (for tracking how changes to one object affect other related objects). This service is already described in the OMG OSTF Object Services Architecture.
• Event-Condition-Action Rules Service - the NIIIP Consortium has been lobbying for this at the last two OMG meetings.
• Event Logging Service - today done differently by every event management tool

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:

• OODB Facility - the OODB specification should be a composition of Basic Object Services and it should be possible to replace implementations of component services.
• OODBMS-RDBMS Facility - add Collections and the Query Service into the OODB
• Active DBMS or KBMS Facility - add a Rules Service into an OODBMS-RDBMS
• Workflow Facility - to what extent can workflow be viewed as a composition of Basic Object Services? What additional object services will be needed?
• Upper Middleware for Collaboration and Groupware - what additional services are needed for other forms of groupware?

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:

• Web Servers/Peers - what is the OMG interface for "plug ins"? Should we replace HTTP messaging with IDL? What is the migration path?
• Web Search Engines - to what extent can services like Web Search Services benefit from being modularly architected as OMG object services? What is the value-added from doing this?
• Better Emailers - email better able to use OMG services like query. Also, how does the "agent" paradigm (Telescript, Java Agent toolkits) compare to the "enabled mail" paradigm (Safe Tcl being one implementation)?

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:

• can we vary the binding time of compositions so that we can add new services to existing systems? For instance, can we add the query service to an OODB that formerly only supported navigation? How late can we do this? Design time, system build time, run time.
• can we prove that if a component has a desirable property like safety and that a composition rule preserves that property, then the resulting system will preserve that property? That might allow secure systems to federate with other secure systems into larger wholes.
• can we protect against situations where an undesirable property infects a whole federation?
• can we specialize components or select differing policies that govern their behavior and then still compose them into larger wholes. How would policy composition work and what properties would it preserve.
• can we evolve systems and track the changes; can we rapidly assemble applications from component pieces (many people talk about this but where is the beef?)
• can we solve problems ignoring distribution, persistence, security, versioning, and other services and then later add them in via X-unaware wrappers? Can we demonstrate this for legacy software?
• can we throttle systems so they become more or less distributed dynamically? Possibly governed by QoS or other cost-benefits schemes.

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.

• Semantic or Object File System (OFS). OODBs were invented to persistently store the rich data structures of engineering and other complex data. But OODBs only ended up "owning" 1/N^th of the data in the world. Relational DBMSs did better (owned more data). But still, most data is stored in file systems, a technology we've had for 30+ years that has seen little change. Apple and Microsoft operating systems permit typing of file content; MIME does this for helpers but is limited in providing the typing needed for compound documents. Better support for wrapping file systems to become objects file systems appears to be a useful direction since then it provides a useful uniform information space for file systems and DBMS systems where data is stored persistently and distributed systems where data is stored in transit. Coupling in stream data and the idea of the network-as-computer and you begin to get a uniform web-object space that supports both structured as well as unstructured and semi-structured information.
• Situations, Virtual Rooms, Information Spaces, Security Domains. New metaphors are needed above the OFS-like level. Businesses and governments want to rapidly develop distributed models of situations, for instance, a crisis, building on an evolving organizational knowledge base, possibly using argumentation structures for capturing rationales, and be able to have individuals add value, permit access to much information, restrict access to other information, compute and summarize information, have virtual meetings, collaborate with a changing collection of relevant information providers while maintaining flexible access security including assurance that the mechanisms in place are understandable and still protect the information. It is likely that some pervasive information like geographic information systems (GIS), weather systems, logistics systems would be available at this level for command-and-control decision making and would need to inter-communicate.
• Simulation and Distributed Planning. It appears likely that Distributed Interactive Simulations and Planning will directly benefit from distributed object technology and perhaps this is a good time for OMG to begin to develop Platform Task Forces in these areas. Companies and governments alike would get value by being able to rapidly cross organization boundaries to assemble teams of experts to solve very large problems. In such systems, we'd want continuous re-planning as situations evolve; dependency tracking, traceability, truth maintenance, and pedigree of how decisions were arrived at; views so central authorities can see summaries and details on demand, workers can see details but also the company strategy, and customers or allies can see inside the organization in limited ways to view their work-in-progress and the organization's capabilities to help them; and means of dealing with inconsistencies.
• Modeling Enterprise Architectures. At present, OMG provides standards for distributed middleware but it is moving into vertical domains and it is not quite clear whether the scope of the OMA is bounded and how much it is meant to explain. It may be possible to extend the OMA to model static as well as evolving enterprise architectures, which are today usually modeled in documents as lists of preferred standards and products, sometimes loosely arranged in layers. These enterprise architectures attempt to array a much broader suite of hardware and software standards than the current OMA and attempt to provide interoperation so organizations can manage their software investment strategies. Organizations can be as large as Governments and their allies, as small as small businesses, real or virtual, homogeneous or heterogeneous. Enterprise architectures as well as the OMA must account for evolution.
• Survivability and Understandability. Large scale complex systems built up from the components and layers outlined above may or may not preserve desirable properties like survivability and understandability. If no one can understand them, people may not trust them. If they have points of failure or too much homogeneity, they may fail massively.