Business Object Workshop II

Coda: OMG Rationale for Choosing the Classical Object Model

(Or why there has not been an "insidious shift in OMG aims.")

Andrew Watson

In his OOPSLA '96 position paper for the Business Object Design and Implementation II workshop, Christopher Spottiswoode points out that the views on object models presented in the Object Management Group's top-level architecture document, the Object Management Architecture Guide, have changed between the earlier and later versions. In order to understand how this came about, a few words on OMG's process are probably in order.

OMG is a member-funded and member-run not-for-profit consortium, which currently has something in the region of 700 member companies. OMG has its roots in early attempts within the software industry to deploy the object technology which up until the mid-1980s was mainly to be found in research laboratories. It was clear from this early academic work that object-based software construction could offer great benefits by facilitating re-use of software components and easing the problem of building distributed computing solutions. However, in order fully to realise this potential, cross-industry agreement was needed on a common architecture and infrastructure for object-based software. With this in place, system integrators and end-users would be able to use and re-use software components from many sources. OMG's goal was and continues to be to specify this architectural framework for the benefit of its member organisations and the entire software industry.

OMG itself writes neither software nor specifications. Instead it provides a forum where its member companies can agree on the specifications which they (and others) can then implement. In order to ensure that these specifications will be rapidly implemented and deployed in products, OMG's rules (again, written by its members) insist that the specifications are based on well-understood technology, not paper designs using new and untried design concepts. OMG is not a research organisation.

The first version on the Object Management Architecture Guide was written during the first year of OMG's formal existence, to document the architectural vision. Amongst other things it contained a glossary of terms (to ensure that the members' technical representatives attending OMG meetings shared a common vocabulary), overall technical objectives for the group and a top-level architecture (called the reference model). This top-level architecture served to identify the major components that OMG set out to specify:

*A common middleware component enabling interaction between separate objects potentially written in different programming languages and running on separate machines. The term Object Request Broker (ORB) was coined to name this relatively new concept. The ORB is not itself an object, but is instead the mechanism by which objects transparently communicate with each other.
A number of categories of object components that communicate with each other via the ORB, including application objects, and the so-called Object Services that provide commonly-required functions such as naming, security and transactions.

The first technology specification solicited and then adopted by OMG in 1990/91 was, naturally enough, that of the Object Request Broker. Because it handles all communication between all objects in an OMA-compliant system, the ORB implicitly defines the OMA's object model. Therefore the object model laid out in the first revision of the Object Management Architecture Guide (published in September 1990, and therefore pre-dating the adoption of specific ORB technology) was a placeholder, intended to be revised once the details of the object model were tied down by the selection of an ORB specification.

In the event, all seven initial ORB technology submissions submitted in early 1991 were completely based on a classical Smalltalk-like object model, as was the final CORBA specification adopted by vote of the OMG's membership in late 1991. Once this submission was adopted, the Object Model chapter in the OMA Guide was revised to reflect the adopted classical CORBA object model.

So, in summary, the "insidious shift in the OMG's aims" that Mr. Spottiswoode believes he has identified is in fact nothing of the sort; it is instead merely the replacement of a placeholder with an object model implemented by available technology, selected by the OMG's membership, and in use where-ever CORBA is deployed today. The model is highly compatible with the object models used in OO programming languages such as C++, Smalltalk and Java, and indeed language mappings from all those languages (and others) to CORBA are commercially available from many vendors today.

We do not intend to denegrate the research goals of papers such as those in this workshop; this work is very valuable in advancing our common cause of making software easier to write, more portable and more interoperable. However, OMG is not a research organisation, but is instead devoted to helping the industry deploy object-based software today. Since the classical object model is widely-deployed, proven, and well-understood, that is the model that OMG's member companies (both vendors and end users) have chosen to adopt.