Introduction To OMG Specifications

On this page, you'll find brief summaries of all OMG's specifications. You can click on the topics at the top of this page to scroll down to a particular summary, or read straight down the page if you prefer. Clicking on the link within each summary will bring you to a FAQ or resource page about that specification, where you can study its usage and technical details (once we've finished writing them!). We suggest that you read this entire page once first, to see how everything fits together.

We'll start with the Model Driven Architecture (MDA) which became the base architecture for OMG standards in September, 2001:


The MDA - OMG's Model Driven Architecture - is a new way of writing specifications and developing applications, based on a platform-independent model (PIM). A complete MDA specification consists of a definitive platform-independent base UML model, plus one or more platform-specific models (PSM) and interface definition sets, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support. 

MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology or technologies in which it will be implemented. MDA divorces implementation details from business functions. Thus, it is not necessary to repeat the process of modeling an application or system's functionality and behavior each time a new technology (e.g., XML/SOAP) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once. Mapping from a PIM through a PSM to the supported MDA platforms is defined by OMG specifications which are then implemented by tools, easing the task of supporting new or different technologies.

UML - OMG's Unified Modeling Language™ - is a graphical language that expresses application requirements analysis and program design in a standard way. Methodology-independent, UML is used by dozens of analysis and design (A&D) tools on the market, making it OMG's most widely used specification. 

UML standardizes four types of structural diagrams:

  • Class diagram
  • Object diagram
  • Component diagram
  • Deployment diagram

Also five types of behavioral diagrams:

  • Use Case diagram
  • Sequence diagram
  • Collaboration diagram
  • Statechart diagram
  • Activity diagram

And three types of model management diagrams:

  • Package diagram
  • Model diagram
  • Subsystem diagram

Standardization allows design tools to interchange models using XMI, discussed below. 

The MOF, or MetaObject Facility, standardizes a meta-model - the concepts that you use to build your application model. UML models, which are built from the MOF metamodel, interchange easily because of this commonality. Another part of the MOF specification defines a repository for metamodels and models. It's a great place to store your UML models, but useful for other metadata too - such as the definitions of data types in your data warehouse.


XMI®, for XML Metadata Interchange, is a stream format for interchange of metadata including the UML models that you create during your analysis and design activities. It's useful for transferring the model from one step to the next as your design and coding progress, or for transferring from one design tool to another. Because XMI streams models into XML datasets, it also serves as a mapping from UML to XML. The MDA will take advantage of this when it defines the mapping from a PIM to XML-based platforms. 


CWM™ - the Common Warehouse Metamodel - standardizes a basis for data modeling commonality within an enterprise, across databases and data stores. Building on a foundation metamodel, it adds metamodels for relational, record, and multidimensional data; transformations, OLAP, and data mining; and warehouse functions including process and operation. CWM maps to existing schemas, supporting automated schema generation and database loading. This makes it the basis for data mining and OLAP across the enterprise. 

CORBA is the acronym for Common Object Request Broker Architecture. CORBA is OMG's open, vendor-independent specification for an architecture and infrastructure that computer applications use to work together over networks. Interoperability results from two key parts of the specification: OMG Interface Definition Language (OMG IDL), and the standardized protocols GIOP and IIOP®. These allow a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, to interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

CORBA applications support the enterprise: The compute engine behind your website could be a huge CORBA server, running load-balanced on a roomful of machines and supported by OMG's standard fault tolerant architecture. Smaller servers can run on a single machine, or even a handheld or small embedded device, and still interoperate with all other CORBA clients and servers over OMG's standard protocol, IIOP.

To go to our CORBA FAQ, click here. 

Applications - even if they perform totally different business tasks - share a lot of common functionality: objects notify other objects when something happens; object instances are created and destroyed and new objects' references are passed around; operation must be made secure and transactional. Beyond this, applications within a business domain (transportation, banking, whatever) share even more functionality.

The OMA abstracts out this common functionality from CORBA applications into a set of standard objects that perform standard, clearly-defined functions, accessed through (you guessed it) standardized OMG IDL interfaces. OMG standardizes the IDL interfaces and specifies what the objects do; software vendors implement and sell implementations of these objects that perform the specified services.

Applications benefit three ways from using the OMA:

1. Coding is quicker, so applications can be deployed sooner: Since your crew doesn't have to write as much code, development happens faster.

2. Applications designed around discrete services have better architecture: Good architecture divides applications into modules or object groups based on functionality. By designing around the OMA, which is itself based on this principle, your application gets a head start on its own sound architecture.

3. Many OMA implementations have enterprise characteristics built in: they're robust, and they scale: Providers know where you're going to deploy your applications with their OMA products, so they compete to meet your enterprise's needs. Scalable nameservers, transaction services, and other services have proved their worth in enterprise deployments for years already!


Most of the CORBAservices provide basic functionality - performing, for your distributed object applications, the kind of services that system library calls do in systems such as UNIX. A few larger services - transactions, security - go beyond this but their close tie-in with the ORB infrastructure requires their placement in this category.

CORBAservices in the first category include the Naming service, Object Trader service, and new Persistent State service. [We'll write descriptions of these services and link to them as soon as we can. Please bear with us!] The technical section for the CORBAservices [Yes, there's a link coming here too] lists all of the services.


The Horizontal CORBAfacilities sit between the CORBAservices and Application Objects (described below). Unlike the Domain CORBAfacilities (describe next), these facilities are potentially useful across business domains. There are only four horizontal CORBAfacilities: The Printing Facility, the Secure Time Facility, the Internationalization Facility, and the Mobile Agent Facility. This is the only category in the OMA that lacks a Task Force of its own at the OMG.

The Domain CORBAfacilities are where the most exciting work is happening at OMG. IDL is a great way to define standard interfaces for standard objects that every company in an industry can share. Companies in so many industries approached OMG for support in this kind of effort that the organization established the Domain Technology Committee in early 1996 to coordinate this effort. Now (in early 2000) nine industries have their own OMG Task Forces, with more on the way.

Application Objects are at the topmost part of the OMA hierarchy. Since they are typically customized for an individual application and do not need standardization, this category identifies objects that are not affected by OMG standardization efforts.