Object Management Group (OMG)

[Note: this page is maintained by OBJS and not OMG. It is meant to provide a quick one-stop-shopping technical status on OMG. This information is included in this survey because OMG is the leading open forum for defining a broad collection of interoperable component object specifications and it is important to know what specifications are currently available.]

Table of Contents

About OMG

The Object Management Group (OMG) is an international non-profit organization supported by information systems vendors, software developers and users. OMG was founded in 1989, now has over 600 member organizations, and meets bi-monthly. OMG provides a widely supported framework for open, distributed, interoperable, scaleable, reusable, portable software components based on OMG-standard object-oriented interfaces. Objectives of the OMG architecture are: Most work occurs in between meetings but decisions are made in key OMG committees: OMG Architecture Board, Platform and Domain Technical Committees, various Task Forces, Special Interest Groups, and Subcommittees, which all report to Architecture Board. Task Forces typically issue Requests for Information (RFI) to help define a part of OMG's overall Object Management Architecture, then define an architecture and roadmap and finally issue a series of Requests for Proposals (RFPs) to industry for interfaces to object services (software components) that populate the architecture. RFP respondents provide candidate interface specifications and promise conformant commercially available implementations. >From RFP issue to technology adoption is typically one year; commercial implementations are typically available a year after that.

There are currently two Platform Technical Committee (PTC) task forces: the newly combined Object Request Broker/Object Services TF (ORBOS) and the Common Facilities TF. The Internet SIG reports to the PTC. There are currently several (relatively new) Domain Technical Committee (DTC) task forces and SIGs: Financial TF, Manufacturing TF, Health Care TF, Business Objects TF, Analysis and Design TF, GIS SIG, Multimedia and Electronic Commerce SIG, and End User (mirroring OMG's potential for providing industry-specific object standards). There are currently two standing subcommittees: Policies and Procedures and Liaison, the latter concerned with insuring that OMG builds and maintains close liaisons with other industry groups and standards development organizations.

The OMG OMA Reference Model

This section provides a brief overview of OMG's software architecture. The OMG Object Management Architecture Guide (available on line:  OMA Reference Model) was completed in 1990 and updated in 1995 and serves as an overall architecture for OMG standards development. It describes OMG's standard reference architecture as shown in Figure 1. In the OMG OMA Reference Model, a main purpose of the categorization of objects into Object Services, Common Facilities, Domain Objects, and Application Objects is to set the standardization strategy for the OMG.

An OMG object service (used generically here to include basic object services and common facilities) defines the interfaces and sequencing semantics to support building well-formed applications in a distributed object environment. In non-object software systems, a system's Application Program Interface (API) often is defined by a monolithic interface. The OMG Object Services API is modular; particular objects may use a few or many Object Services. By being object-oriented, the OMG Object Services API is extensible, customizable, and subsettable; applications only need to use services they require.

The operations provided by Object Services are made available through the IDL Interface Definition Language (as defined in the OMG CORBA specification) or through proposed extensions to IDL compatible with the OMG Object Model.

While OMG requires an IDL interface for each object service, it is worth noting that since OMG adopts existing technology, it may be the case that implementations of object services may not themselves be object-oriented and that, in addition to an IDL interface, non-object-oriented interfaces may continue to be supported for compatibility with an existing product's API or with non-OMG standards. Such interfaces will not however be part of OMG specifications. Also note that objects do not have to use the implementation of basic operations provided by Object Services nor do objects have to provide all basic operations. For example, an object may provide its own data storage or meta data access.

Figure 1: OMG Object Management Architecture

The OMG OMA architecture consists of components, interfaces, and protocols which decompose an object system into four areas, classified as follows:

OMG Architectural Principles

The OMG architecture is distributed, open, and non proprietary. It is being built on existing and emerging industry standards, exploits object-oriented technologies, and creates a plug-and-play environment to embrace both new and legacy applications. OMG object services obey a collection of architectural principles. Respondents to OMG RFPs must indicate how their proposed specifications satisfy these architectural requirements, helping to insure a consistent overall architecture.

OMG List of Documents

OMG Specifications

The OMG Board recently voted to make all adopted technology specifications freely available in electronic form. Meanwhile, until that happens, OMG specifications and meeting minutes are available to members and many are currently public. The web page Information Resources on CORBA and the OMG is a good resource listing many of the important specifications as well as several CORBA implementations.

ORB specifications (as of summer 1997)

OMG CORBAservices

CORBAfacilities PTF

OMG Internet SIG

Simulation SIG

Business Objects DTF

Electronic Commerce DTF

Finance

OA&D DTF

Manufacturing

Telecom DTF

CORBAmed

OMG OMA - Next Steps

[Note: this section suggests that extensions are needed to the OMG OMA Reference Architecture and reflects our current understanding of that architecture and its implementations. We will be glad to hear if some of these perceived problems are non-problems. Please contact us.]

This section briefly lists some perceived roadblocks and extensions needed to the OMG Object Management Architecture. Extending OMA in these ways would constitute a next generation more broadly useful and scaleable OMA (OMA-NG?).

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, 1997 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.

This page was written by Craig Thompson. Send questions and comments about it to thompson@objs.com.

Last updated: 06/30/97 PM

Back to Internet Tool Survey -- Back to OBJS