![](OBJS.GIF)
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:
-
to benefit application developers by making it much easier for developers
to build large-scale, industrial strength applications from a widely available
toolkit of standard components, and
-
to benefit end-users by providing a common semantics that goes far beyond
the notion of a common look-and-feel in today's desktop applications.
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:
-
Object Request Broker: The OMG Common Object Request Broker Architecture
specification (CORBA 1.1 and 2.0) provides a message passing bus
for transporting requests and responses in a distributed environment (that
is, an object RPC mechanism). The CORBA specification also defines IDL
(Interface Description Language), a language neutral object model with
separately specified mappings to C++, Smalltalk, Ada, (so far) and COBOL
and Java (coming) as well as a specification for a standard Interface
Repository for IDL meta data and a specification for Interface Type
Versioning. All object services (basic object services, common facilities,
domain interfaces, and application objects) have IDL interfaces and communicate
with each other via CORBA. CORBA 2.0 extends CORBA to require that all
CORBA implementations be interoperable and support Internet Interoperability
Protocol (IIOP, a wire protocol based on TCP/IP) and optionally DCE
transport as transport protocols. The COM/CORBA Interworking RFP
consists of two parts, part A addressing the current Microsoft COM
and part B focusing Microsoft's future distributed Network COM.
Current work includes IDL Type Extensions, Common Secure IIOP,
Multiple Interfaces and Composition. Future possible work includes
passing objects by value, templates for IDL, replication service, synchronization
service, group broadcast dispatch, asynchronous dispatch, messaging queuing,
additional language bindings, monitoring, and other services. See What
is CORBA?
-
Basic Object Services: The OMG Object
Services Architecture (postscript document) defines a collection
of basic object services called CORBAservices that most applications
need. Detailed specifications for many of these services are complete,
including OMG Object Services Task Force (OSTF) RFP1 services (Life
Cycle, Events, Naming, Persistence), RFP2 services (Externalization,
Concurrency, Transactions, Relationships), RFP3 (Security Services,
Time), RFP4 services (Object Queries, Properties, Licensing),
RFP5 (Collections, Trading, Startup), and RFP6 (Asynchronous
Messaging. Potential future services include schema evolution, archive,
backup/restore, implementation repository, installation and activation,
and threads.
-
Common Facilities: The OMG Common
Facilities Architecture (postscript document) describes a second
collection of object services (called CORBAfacilities) that provide
general purpose capabilities, useful in many applications. Common Facilities
Task Force (CFTF) RFP1 covered compound documents presentation and interchange
resulting in a Distributed Document Component Facility based on
OpenDoc. Other CFTF RFPs include RFP2 (Time Operations and Internationalization),
RFP3 (Data Interchange and Mobile Agents), RFP4 (Business Object
Facility), RFP6 (Printing Facility) ), as well as a System
Management RFC (from X/Open). Other facilities on the CF roadmap include:
Asian Input, Meta-Object Facility, Workflow RFC, Task Management and Desktop,
Instance Configuration and Change Management, Automation and Scripting,
Rendering/Imaging, Rule Management, and Security Management. CFTF also
recently issued an RFI on repositories as well as some domain specific
RFIs now moved to the new Domain Technical Committee.
-
Domain Interfaces: Recently, OMG reorganized and created a Domain
Technical Committee to oversee the work of a new series of Task Forces
in domain vertical areas. Most of these are in the RFI issuing stage. These
include: Finance TF, Manufacturing TF, Healthcare TF, Business Objects
TF, Analysis and Design TF, Telecom TF, GIS SIG, Multimedia and Electronic
Commerce SIG.
-
Application Objects: These are specific to particular end-user applications
and are not subject to standardization.
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 object service interfaces shall have precise descriptions. Specifications
shall be complete. There must be no magic required.
-
OMG service interfaces shall be object-oriented and shall be described
in OMG's IDL.
-
Any part of a service that is viewable as an object shall be viewed that
way and shall be given an IDL interface description.
-
Any requirements that a service places on general objects shall be defined
in IDL. For example, a security service might define what a securable object
is in IDL.
-
Operation sequencing shall be specified where applicable. Behavior and
sequencing of operations shall be part of the specification of a service.
-
Service specifications shall not contain implementation descriptions. Maximum
implementation flexibility should be preserved.
-
Data and process management services must support cooperative protocols
that facilitate logically distributed control in scaleable, heterogeneous
environments. Data and process managers that support local centralized
environments must bridge to the logically distributed environment by support
of the cooperative protocols in addition to supporting their local centralized
protocol.
-
Independence and modularity of services: It should be possible to separately
specify and implement each service. Monolithic systems must be viewable
as a collection of independent services.
-
Services shall be factored for reuse. Factoring shall minimize duplication
of functionality (the Bauhaus principle).
-
To facilitate modularity, independence, and reuse, functionality should
belong to the most appropriate service (not bundled).
-
Legacy systems shall be accessible via IDL wrappers.
-
Services shall interoperate when there are dependencies.
-
Interfaces and behaviors should be specified sufficiently well so that
implementations can be replaced and the parts will still work together
-
Different services should be able to work together.
-
Services should be extensible through an iterative process. It should be
clear how extensions can be defined (e.g., via multiple inheritance, delegation,
etc.).
-
It should be possible to define new services without having to re-design
a system that uses existing services.
-
Integrity, reliability, and safety of services: safeguards should be provided
to guard against corrupting services and the objects they manage.
-
Services should be designed to accommodate portability of implementations
across a wide range of platforms
-
Interfaces to services should be designed with performance tradeoffs in
mind. Services and compositions of services must provide adequate performance.
-
Scalability: services should be specified with the goal that there may
be many implementations that are optimized for different environments.
IDL and a language mapping can make remote services look like local object
invocations. Most services have a possible implementation across a spectrum
from a shared library to a remote server. The user of a service should
not have to care which variety is being used, unless interested.
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)
-
adopted
-
CORBA 2.0/IIOP Specification PTC/96-08-04
-
Reference: http://www.omg.org/corba/corbiiop.htm
-
Object Model
-
CORBA Overview
-
OMG IDL Syntax
-
Dynamic Invocation Interface
-
Dynamic Skeleton Interface
-
Interface Repository
-
Basic Object Adapter
-
Interoperability Architecture
-
General Inter-ORB Protocol
-
DCE ESIOP
-
C Language Mapping
-
IDL to C++ Mapping
-
IDL to Smalltalk Mapping
-
orbos/96-06-20: Common
Secure IIOP
-
95-05-16: IDL to
Ada
-
orbos/96-10-01: IDL
to COBOL Mapping
-
in progress
OMG CORBAservices
CORBAfacilities PTF
OMG Internet SIG
-
homepage
-
RFI response recommendations
- influence ORBOS and Common Facilities roadmaps
-
working on semantic/object file system (OTAM)
-
working on composition and federation of services and facilities
Simulation SIG
-
issue is CORBA w simulations on top vs. time-aware CORBA
-
strong ties to DMSO High Level Architecture (HLA)
-
working on white paper on simulation - analysis simulations, virtual simulations,
engineering simulations
Business Objects DTF
Electronic Commerce DTF
Finance
OA&D DTF
Manufacturing
Telecom DTF
-
in progress Notification RFP
-
in progress Topology RFP
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?).
-
OMA plus properties - scaleable to the Internet, safe, seamless,
survivable, fault-tolerant, evolvable, secure, configurable, standard parts,
customizable, simple, open - these are all guarantees needed by some or
many OMG installations.
-
Interoperability with WWW - the sooner the OMG and Web communities
can integrate object and web technology, the better. See our coming Internet
survey section on ORB/Internet Interoperability.
-
CORBA dispatch mechanism closed - currently the interface to trapping
a message before dispatch and inserting new behaviors is not specified.
At present, distribution is the only behavior handled in this way but persistence,
replication, versioning, modular security, and other behaviors could be
handled by such a mechanism.
-
Better support for interlanguage sharing - currently there are one-way
mappings from IDL to various programming languages. But legacy code in
C++ or Smalltalk needs mappings to IDL to make it easier to do interlingual
applications.
-
Support for Call by Value - today CORBA works by reference.
Also supporting a call by value semantics makes it more efficient
to transport objects between address spaces. (An RFP is proposed on this.)
-
Support for Scripting - to support languages like Java.
-
Composition of Services - beyond inheritance there is little guidance
from OMG OMA on how to compose services. Thus, if one wants to compose
an OODB-RDBMS or Workflow Engine or KBMS or Repository from OMG services,
it is not clear how to do so. This could be done by a variety of binding
glues and mechanisms including delegation, before-and-after methods, or
rules. Being able to compose dissimilar services into larger wholes constitutes
a dimension of scaling that OMG OMA has not yet demonstrated.
-
Federation of Services - Current work on CORBA-CORBA interoperability
and traders is part of the answer to scaling since it accounts for the
need to transparently cross CORBA gateways to get services in another CORBA
domain. But there is a parallel need for many object services to federate,
that is, interoperate in tandem so that a message to one may result in
messages to others, at least semi-transparently. This is true for homogeneous
name services, transactions, queries, security, and several other services.
It is also true for federating heterogeneous policy domains (different
security policies).
-
Service portability - at present, many ORB vendors do not deliver
object services and there is not yet a booming "services" industry for
building services that port across ORB implementations. In fact, today
most services implementations are not portable and, even within one vendor,
services may be standalone and not composable with each other. A moral
of this story is that implementation orthogonality is difficult to achieve
so some OMG design principles are not achieved and, as a consequence, some
of the benefits of an OMG architecture are not available to developers.
-
Application portability across Services - applications should be
portable across different implementations of services. This is in part
due to underspecified specifications which allow implemented APIs to vary,
making application portability difficult to achieve, also in variance to
the OMG design principles.
-
Boundary between OA&D, MOF, and BOF. How much real value
is there in a 4 tier metameta model-metamodel-model-instance MOF -- does
it really help map across various object model boundaries? Similarly,
isn't OA&D a different object model more powerful that IDL and if so
what happens if programmers use its 80 or so concepts and generate code.
Will they then be locked into more complex MOF and be less portable to
other ORBs that might not support the MOF they started with? And
finally BOF -- what is its scope? does it contain all the functions
of an OODB and more? can you compose it into a collection of services
or is it a particular monolith?
-
Semantics. How can you usefully add the ability to specify
semantics.
-
inserting QoS and real-time into OMG specs.
-
Simulation, Planning, Scheduling. It is time we created SIGs
in these areas since all three are central to many large enterprises.
-
Java. Since IDL and Java are similarly representationally
adequate, the only advantage IDL had over Java is that it has standard
mappings to programming languages (in one direction, IDL to X, which means
the mapping works best for green field and not legacy code). But
Java has huge momentum and supports mobile code which OMG does not do and
also externalization (via RMI) which OMG is just doing (and how well? --TBD).
It could make sense to map all OMG specifications to Java once and for
all and do all work in Java - a radical suggestion but one that would reduce
interoperability problems we are creating for ourselves a few years down
the line.
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