|
This is the place to start learning
about all of OMG's specifications! |
What is each specification - and the products that
implement it - good for?
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:
Top
|
|
|
The Model Driven Architecture® (MDA®) |
|
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.
|
|
|
Analysis and Design Specifications
|
UML® is the
foundation for OMG's Model Driven Architecture.
|
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.
Top
|
| "Meta-data"
sounds esoteric, but this concept can tie your enterprise together in a
fundamental way, giving you a real competitive advantage. |
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.
Top
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.
Top
|
 |
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®: CORBA and the OMA support development and runtime:
|
| OMG IDL™ has been an
ISO International Standard for several years. The GIOP and IIOP protocols
are also (October 2001). |
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.
|
| Our favorite book
about CORBA is "CORBA 3 Fundamentals and Programming", published
by John Wiley. |
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.
Top
|
|
OMG's Object Management Architecture (OMA):
|
|
The OMA - Object Management Architecture
- categorizes objects into four categories: the CORBAservices™,
CORBAfacilities™,
CORBAdomain™ objects, and Application Objects. Here is the classic OMA
diagram:
|
| Some ORB
products include basic CORBAservices in their package, but others
don't. Other companies market only the services, without an ORB! |
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:
|
|
Architecture is the glue that holds your
enterprise applications together. If you're a medium or large enterprise,
you already know either the benefits of having an enterprise architecture
or the costs of not having one. If you're a small but growing enterprise,
you'll find out soon enough! |
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!
Top
|
|
Here's a quick look at each of the four parts of the OMA:
|
| OMG and the US
National Security Agency (NSA) jointly sponsor an international
distributed-object security workshop every year, usually in April. You
don't have to be an OMG member to come. |
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.
|
| Your industry may
have a task force working at OMG already! |
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.
Top
|
| |
Last updated on
02/14/2013 |
