OODBMS-6.Distributed Object Oriented Systems Standards(OMG&CORBA)

January-2004 [31]
2. a) Discuss the main concepts of ODMG object model. Give an example to illustrate each of the concepts. [8]
The ODMG Object Model is intended to allow portability of applications among object database products. It provides a common model for these products by defining extensions to the OMG object model that support object database requirements. In particular, the ODMG model extends the OMG core to provide for persistent objects, object properties, more specific object types, queries and transactions.

1. Basic Concepts : The basic concepts are objects, types, operations, properties, identity and subtyping. Objects have state (defined by the values of their properties),behavior (defined by operations) and identity. All objects of the same type have common behavior and properties.

Types are objects so may have their own properties. A type has an interface and one or more implementations. All things are instances of some type and subtyping organizes these types in a lattice. A type definition can declare that an extent (set of all instances) be maintained for the type.

2. Objects

Objects are instances of a type, and as such have state, behavior and identity. All objects are of type Denotable Object. An object can be mutable(instance of type "object") or immutable (instance of type "literal").The remainder of this note will use the term object to refer to mutable objects.

Objects and literals can be atomic or structured. The identity of objects is represented by OIDs; typically literals are identified by their value. Objects may also have meaningful name(s) in addition to identity (properties of objects include "has_name?" and "names").

2.1 operations

Operations are defined on types. The interface of a type includes operation signatures: argument names and types, possible exceptions, result types. The first argument of an operation is distinguished.

Operation names may be overloaded; dispatching is based on the most specific type of the first argument of the operation call. Operations may have side-effects; an operation with only side-effects can return a nil value. The model assumes operations will be executed sequentially.

Object behavior is modeled through operations. An operation signature (part of a type specification) specifies argument types, result types and exceptions that can be raised. "There is no formal specification of the semantics of an operation"

2.5 methods (including multi methods and method combinations)

Operations (declared in the interface) are implemented by methods defined in the type implementation. Each operation is implemented by a method, plus there may be additional methods defined.

2.6 state

State is modeled by the properties of an object. A property can be an attribute or a relationship. The attributes and relationships of an object are defined as part of the type interface. Attributes take literals as their values; relationships can only be defined between two non literal object types.

2.8 behavior/state grouping

ODMG specifies a classical object model: each operation has a distinguished argument.
2.9 communication model

The model assumes operations are executed sequentially, although it does not preclude concurrent or parallel operations. The model supports nested transactions, where the commit of a nested transaction is dependent on the containing parent transaction's commit. Type Transaction defines operations to begin, commit, abort and checkpoint a transaction. A transaction obtains standard read and write locks with pessimistic concurrency control.

3. Binding
The model supports run-time binding of methods to objects based on thefirst argument type

4. Polymorphism
The model supports polymorphism implicit in subtyping, as well as parameterizedcollection types.

5. Encapsulation
All objects are instances of a type which specifies the interface foraccessing the object. There is only one interface for a type.

6. Identity, Equality, Copy
All denotable objects have an identity. For literals this identity is" typically the bit pattern that encodes its value". For objects, identity "uniquely distinguishes the object from all other objects within the domain in which the object was created" and is independent of any state of the object.

Operation Equal? is defined for type Denotable_ Object.

In order to copy objects, copy operations must be defined as part of the object's type. For Collection object types, the copy operation is a shallow copy - returning a new collection with the same elements as the copied collection. For object type Structure, the copy operation is alsoa shallow copy.

Literals are copied by assignment. "Assignment of an object of type Structured_ Literal, or any of its subtypes, to another object will create a (logical) copy of the literal"

7. Types and Classes
A type is a specification; it can have one or more implementations.All types are instances of type Type. A class is the combination of a typespecification and a specific implementation. The model is strongly typed.

The set of all instances of a type is the 'extent' of the type. 'Abstracttypes' are not instantiable - they specify characteristics that can beinherited by subtypes but do not define any implementations.

Two objects are compatible if they are instances of the same declaredtype or if one is an instance of a subtype of the other. Two structuredliterals have the same type if they have the same structure at every leveland the corresponding atomic types are the same. Subtyping for structuredliterals requires the same structure at each level and the type of eachsubobject of the subtype to be the same as, or a supertype of, the correspondingsubobject of the supertype. No implicit conversions are given for eitherobjects or structured literals. Some explicit conversions are given inthe object query language specification.


8. Inheritance and Delegation

The model defines type inheritance only (i.e., subtyping). If S is asubtype of T, then S inherits all operations and properties of T, and Smay define new operations and properties applicable to its instances. Inother words, objects of type S have all the characteristics (and more)of type T. A subtype can specialize the properties and operations it inherits,but there are no rules given to indicate what kinds of refinement are correct.

A type can inherit from multiple supertypes, but must rename same-namedinherited operations or properties.

9.1 relationships
Relationships are a kind of property defined between two mutable object types. Relationships are not objects.

A relationship can be one-to-one, one-to-many or many-to-many. Relationships are defined in the interface(s) of the object type(s) involved in the relationship as a "traversal path" from one type to another. A two-way relationship will have a name in each type interface, and an inverse" clause in each path declaration.

9.2 attributes
Attributes are a kind of property defined on a single object type. Attributes take literals as their values. Attributes are accessed by get_value and set_value operations; they are defined as part of the type interface -there are no implications about the implementation of the object type. Attributes are not first class objects (they cannot have properties orbe subtyped), however the built-in get_ and set_value operations can be overridden.

9.3 literals

Literals are immutable objects - either atomic (integer, float, Boolean,character) or structured. Structured_literals have two subtypes - Immutable_Collection(bit strings, character strings, and enumerations are built-in) and Immutable_Structure(date, time, interval). Additional subtypes can be defined, but operationson the built-in literal types cannot be redefined. The literal types areexpected to directly map to types in the programming language. If the language does not have an analog for one of the literal types, the type must be defined in a library provided as part of the language binding.

9.5 aggregates

Structured objects (aggregates) can be of type Structure or type Collection. Structures are records with named slots which can be filled by objects or literals of different types. Collections are homogeneous (modulo subtyping)groupings of elements that may or may not be ordered.

Built-in collection types are set, bag, list and array. Sets and bags are unordered collections; lists and arrays are ordered. Arrays are variable length (although an initial size is specified at creation) and can contain nil values.

Collection types are instances of parameterized types. They can be parameterized by any subtype of Denotable_Object. There are two subtypes of collections: predicate_defined and insertion_defined. A type extent is a predicate_defined collection.

Mutable collections (subtype of Structured_Object) have intentional semantics. Immutable collections (subtype of Structured_Literal) have extensional semantics.

Iterators can be defined to traverse collections. Type Collection alsodefines predicate-based select operations. Query operations apply to any collection (extents, user-defined). The result of a selection is a subcollection of the same type as the collection queried. Each of the more specific collection types defines appropriate query operations. Of course, the literal collection types do not define update operations (insert, delete, replace).

9.6 other
Type Exception is provided by the object model, and may be subtyped. Operation signatures can indicate exceptions that can be raised. When an exception is raised it is handled by the exception handler in the closest scope and transactions within that scope are aborted.

10. Extensibility

See under 8 Inheritance and Delegation for a discussion of subtyping in the model. New types can be defined as subtypes of existing types.

10.3 Introspection
Type "Type" is a subtype and an instance of type Atomic_object.The meta-data can be accessed using the interface for type instances, andcan be queried using the standard query language.
11. Object Languages
ODMG specifies an object definition language (ODL) that supports the ODMG object model and is compatible with OMG's IDL. The ODL is programming language independent. C++ and Smalltalk ODL bindings are defined in [ODMG,1994].

ODMG also specifies an SQL-like object query language (OQL) that provides declarative access to objects. Queries can be posed to any denotable object, starting with an object name or with a language expression yielding the object.

b) Discuss the salient differences between static and dynamic service invocations mechanisms In CORBA? [5]
7.c)State the difference between static and dynamic service invocation mechanism in CORBA. [6]
6. a) Discuss the salient differences between static and dynamic service invocations mechanism in CORBA? [7]

The key is to understand that CORBA, like SQL, provides both static and dynamic interfaces. Let's first review how CORBA works on the client side.
Client IDL stubs provide the static interfaces to object services. These precompiled stubs, generated by the IDL compiler, define how clients invoke corresponding services on the servers. With dynamic invocation APIs, on the other hand, you can (at run time) discover a service that you want to invoke, obtain a definition of it, issue a parameterized call to it, and receive a reply from it.
Static invocations are easy to program, fast, and self-documenting. Dynamic invocations, while harder to program, offer maximum flexibility and are essential when applications must discover services at run time.
Static and Dynamic Invocation
The CORBA ORB in the BEA Tuxedo product supports two types of client/server invocations: static and dynamic. In both cases, the CORBA client application performs a request by gaining access to a reference for a CORBA object and invoking the operation that satisfies the request. The CORBA server application cannot tell the difference between static and dynamic invocations.
When using static invocation, the CORBA client application invokes operations directly on the client stubs. Static invocation is the easiest, most common type of invocation. The stubs are generated by the IDL compiler. Static invocation is recommended for applications that know at compile time the particulars of the operations they need to invoke and can process within the synchronous nature of the invocation. Figure 1-1 illustrates static invocation.
Figure 1-1 Static Invocation

While dynamic invocation is more complicated, it enables your CORBA client application to invoke operations on any CORBA object without having to know the CORBA object's interfaces at compile time. Figure 1-2 illustrates dynamic invocation.
Figure 1-2 Dynamic Invocation

When using dynamic invocation, the CORBA client application can dynamically build operation requests for a CORBA object interface that has been stored in the Interface Repository. CORBA server applications do not require any special design to be able to receive and handle dynamic invocation requests. Dynamic invocation is generally used when the CORBA client application requires deferred synchronous communication, or by dynamic client applications when the nature of the interaction is undefined. For more information about using dynamic invocation, see Using the Dynamic Invocation Interface.

January-2005 [18]
4. a) Describe in brief, the need of formulating middleware standards like (CORBA) in distributed object-oriented systems. [6]
CORBA offers many benefits to a networked environment.
1. Object reuse - CORBA allows wide-spread use of existing components.
2. Flexibility - CORBA allows developers to choose, for each component of their system, the:
• operating system
• execution environment
• programming language
3. Processing speed - By directly invoking methods on a server, a client can pass parameters using precompiled stubs or can generate them dynamically using CORBA's invocation services.
4. Scalable server-to-server infrastructure - The CORBA ORB communicates with pools of server business objects, dispatching requests to the first available object. This provides a load balancing function for the incoming client requests.

b) Explain in brief the architecture of CORBA with special reference to ORB, IDL and protocols.
The ORB communication functions are central to how CORBA works, so let's look at how the ORB works before we get to the details of CORBA.
First, ORB basics.
The ORB manages all communication between components. Notice the levels of architecture in Figure 2.

Figure 2, "Distributed Object Computing with CORBA,
The OMG ORB model can be divided into two main parts:
1. Application oriented components
o Application Interfaces
o Domain Interfaces
o Common Facilities
2. System oriented components
o Object Request Broker
o Object Services
Regardless of the type of client application, domain, or facilities, the ORB can translate the request to the appropriate object services.
CORBA Architecture
The pivotal component of CORBA is the ORB which is responsible for the communication of requests, passing requests from the client to the correct object. The details of the CORBA architecture are shown in Figure 3.

"Distributed Object Computing with CORBA
The parts of this figure can be explained as follows. As described by the OMG, "The Client is the entity that wishes to perform an operation on the object and the Object Implementation is the code and data that actually implements the object."2 The Client requests services through the IDL Stub or (dynamically) through the Dynamic Invocation Interface (DII). A General Inter-ORB Protocol (GIOP) is defined to support interoperability of different ORB products. A specification of the GIOP on TCP/IP connection is defined as the Internet Inter-ORB Protocol (IIOP). With the help of the Object Adapter, the ORB Core then passes the request through an IDL Skeleton or (dynamically) through the Dynamic Skeleton Interface (DSI) to the Object. The service is encapsulated by the object. The Interface Repository provides at runtime, both: persistent objects with IDL information, and help in identifying the interface and operations of objects. The Implementation Repository stores the information that ORBs use to locate and activate implementations of objects.
CORBA Overall Architecture
The overall architecture of CORBA is divided into three layers as illustrated in Figure 4.

"DCOM and CORBA Side by Side, Step by Step, and Layer by Layer," http://www.bell-labs.com/~emerald/dcom_corba/Paper.html
In the top layer (Basic Programming Architecture) a client may request an object and invoke its methods. The server responds by creating an object instance and making it available to the client. The middle layer (Remoting Architecture) makes it seem as if the client and server are in the same address space. Sending data across different address spaces requires a standard format for packing and unpacking the transmission. Marshaling is the term used when a method call's parameters are packed at a client's space or when return values are packed at a server's space. Unmarshaling is the unpacking of the standard format to a data presentation appropriate for the address space of the receiving process. The ORB serves as the object bus. The Object Adaptor connects the Object to the ORB. The Libraries on the client-side and server-side are linked at compile time. The bottom layer (Wire Protocol Architecture) is where the wire protocol is specified for the support of a client and a server on different machines. [6]
c) What are the roles of stubs and skeletons? What is object marshalling? [6]
Stub : Stub is client-side proxy representing remote object.It looks like local object on client.Role of stub is marshalling as well as demarshalling.
2. Skeleton: Skeleton is the server-side construct that interface with server & server-side remote reference layer.
Stubs and skeletons represent the interface between the RMI system and the application programs.
The stub is a proxy at the client side for a remote object. The skeleton represents information about the client at the server side.
Responsibilities of the stub
The client side stub representing a remote object does the following:
• initiating remote calls
• marshaling arguments to be sent
• informing the remote reference layer that a call should be invoked on the server
• unmarshalling a return value (or exception)
• informing the remote reference layer that the call is complete
Responsibities of the skeleton
On the server, the skeleton,
• unmarshals incoming arguments
• calling the actual remote object implementation
• marshaling return values for transport to the client. When objects in memory are to be passed across a network to another host or persisted to storage, their in-memory representation must be converted to a suitable out-of-memory format. This process is called marshalling, and converting back to an in memory representation is called demarshalling.In marshalling, several things must occur. Objects must be respresented with enough information that the destination host can understand the type of object being created. The objects’ state data must be converted to the appropriate format. Complex object trees that refer to each other via object references (or pointers) need to refer to each other via some form of ID that is independent of any memory model.
In web services, objects are typically marshalled by converting them to an XML representation according to a standard such as SOAP. Objects can also be serialzed into a binary format, which in turn can be wrapped in a SOAP header. However, such formats run the risk of being too proprietary or platform specific to be useful for all potential clients . During demarshalling, the destination host must reverse all that and must also validate that the objects it receives are consistent with the expected object type (i.e. it validate that it doesn’t get a string where it expects a number).
July-2005 [14]
4. b) State the functions of ODMG object definition and object management languages. [8]

* Object Model. This was based on the Object Management Group's Object Model. The OMG core model was designed to be a common denominator for object request brokers, object database systems, object programming languages, etc. The ODMG designed a profile by adding components to the OMG core object model.
* Object Specification Languages. The ODMG Object Definition Language (ODL) was used to define the object types that conform to the ODMG Object Model. The ODMG Object Interchange Format (OIF) was used to dump and load the current state to or from a file or set of files.
* Object Query Language (OQL). The ODMG OQL was a declarative (nonprocedural) language for query and updating. It used SQL as a basis, where possible, though OQL supports more powerful object-oriented capabilities.
* C++ Language Binding. This defined a C++ binding of the ODMG ODL and a C++ Object Manipulation Language (OML). The C++ ODL was expressed as a library that provides classes and functions to implement the concepts defined in the ODMG Object Model. The C++ OML syntax and semantics are those of standard C++ in the context of the standard class library. The C++ binding also provided a mechanism to invoke OQL.
* Smalltalk Language Binding. This defined the mapping between the ODMG ODL and Smalltalk, which was based on the OMG Smalltalk binding for the OMG Interface Definition Language (IDL). The Smalltalk binding also provided a mechanism to invoke OQL.
* Java Language Binding. This defined the binding between the ODMG ODL and the Java programming language as defined by the Java 2 Platform. The Java binding also provided a mechanism to invoke OQL.
January-2006 [18]
4.a) What is OMG? Explain in brief. [3]
OMG has been an international, open membership, not-for-profit computer industry consortium since 1989. OMG Task Forces develop enterprise integration standards for a wide range of technologies, including: Real-time, Embedded and Specialized Systems, Analysis & Design, Architecture-Driven Modernization and Middleware and an even wider range of industries etc. OMG’s modeling standards, including the Unified Modeling Language™ (UML®) and Model Driven Architecture® (MDA®), enable powerful visual design, execution and maintenance of software and other processes, including IT Systems Modeling and Business Process Management. OMG’s middleware standards and profiles are based on the Common Object Request Broker Architecture (CORBA®) and support a wide variety of industries.

b) What is an ORB and what are its functions? [3]
What is an ORB?
For objects to be used across a network, a client/server relationship must be established. The middleware that makes this happen is called the Object Request Broker (ORB). It is the ORB's job to:
• intercept a call from the client
• find the correct object
• pass it the parameters
• invoke its method
• return the results to the client
Because the ORB can make this transaction happen between applications on different machines in heterogeneous distributed environments, this process seems transparent to the client. ORBs provide the flexibility of communication between different operating systems, environments, and languages. They allow existing components to be used by developers far and wide.
c) What is CORBA? Give a brief explanation about the CORBA arid its architecture. [6]

CORBA allows applications to communicate with one another no matter where they are located or who has designed them." 1 This standard also defined the Interface Definition Language (IDL) and the Application Programming Interface (API) that makes client/server object interactions work in a specific implementation of an ORB.

d) What are CORBA services? Explain with some example. [6]

A set of system services for objects that were developed for the programmer. These services, defined in OMG IDL by the OMG, can be used to create objects, control access to objects, track objects and object references, and control the relationship between types of objects. Programmers can call object service functions instead of writing and calling their own private object service functions.
There are several CORBA services. Here is a one line description of most of the services:
Service Description
Object life cycle defines how CORBA objects are created, removed, moved, and copied
Naming defines how CORBA objects can have friendly symbolic names
Events decouples the communication between distributed objects
Relationships provides arbitrary typed n-ary relationships between CORBA objects
Externalization coordinates the transformation of CORBA objects to and from external media
Transactions coordinates atomic access to CORBA objects
Concurrency Control provides a locking service for CORBA objects in order to ensure serializable access
Property supports the association of name-value pairs with CORBA objects
Trader supports the finding of CORBA objects based on properties describing the service offered by the object
Query supports queries on objects
July-2006 [12]
3.a) Explain how object management group standard (OMG) – CORBA allows object to communicate in distributed heterogeneous environment, providing transparency across network, operating system and programming language boundaries. [12]

CORBA offers many benefits to a networked environment.

1. Object reuse - CORBA allows wide-spread use of existing components.

2. Flexibility - CORBA allows developers to choose, for each component of their system, the:

* operating system
* execution environment
* programming language

3. Processing speed - By directly invoking methods on a server, a client can pass parameters using precompiled stubs or can generate them dynamically using CORBA's invocation services.

4. Scalable server-to-server infrastructure - The CORBA ORB communicates with pools of server business objects, dispatching requests to the first available object. This provides a load balancing function for the incoming client requests. To top of page



July-2004 [16]
1.
d) Discuss the main concepts of ODMG object model. [4]
The ODMG Object Model is intended to allow portability of applicationsamong object database products. It provides a common model for these productsby defining extensions to the OMG object model that support object databaserequirements. In particular, the ODMG model extends the OMG core to providefor persistent objects, object properties, more specific object types,queries and transactions.
1. Basic Concepts
The basic concepts are objects, types, operations, properties, identityand subtyping. Objects have state (defined by the values of their properties),behavior (defined by operations) and identity. All objects of the sametype have common behavior and properties.
Types are objects so may have their own properties. A type has an interfaceand one or more implementations. All things are instances of some typeand subtyping organizes these types in a lattice. A type definition candeclare that an extent (set of all instances) be maintained for the type.




c) Discuss the role of OMG in forming standards in OOP technology. [5]
Object Management Group (OMG) is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling (programs, systems and business processes) and model-based standards. OMG tried to create a heterogeneous distributed object standard. The goal was a common portable and interoperable object model with methods and data that work using all types of development environments on all types of platforms. OMG set out to create the initial Common Object Request Broker Architecture (CORBA) standard. OMG has also developed a core set of standards adapting CORBA for embedded and real-time systems. Implementations of real time CORBA are widely used in control systems in ships and aircraft. Data Distribution Service for real-time systems (DDS) is a specification of a publish/subscribe middleware for distributed systems created in response to the need to augment CORBA with a data-centric publish-subscribe specification.
ADM
ADM is the reverse of MDA. It also means Architecture Driven Modernization. ADMTF is an OMG group similar to ADTF with high potential.

Knowledge Discovery Metamodel (KDM), a common intermediate representation for existing software systems and their operating environments. Knowledge Discovery Metamodel is designed as the OMG's foundation for software modernization and software assurance. Knowledge Discovery Metamodel uses Meta-Object Facility to define an XMI interchange format between tools that work with existing software and an abstract interface for the next-generation assurance and modernization tools.

Abstract Syntax Tree Metamodel (ASTM), a modeling language for fine grained reverse engineering.

Semantics of Business Vocabulary and Business Rules (SBVR) and KDM are designed as two parts of a unique OMG Technology Stack for software analytics related to existing software systems. KDM defines an ontology related to software artifacts and thus provides an initial formalization of the information related to a software system. SBVR is further used to formalize complex compliance rules related to the software.
OMG evolved towards modeling standards by creating the standard for Unified Modeling Language (UML) followed by related standards for Meta-Object Facility (MOF), XML Metadata Interchange (XMI) and MOF Query/Views/Transformation (QVT). These together provide the foundation for Model Driven Architecture (MDA), and related set of standards, building upon the success of UML and MOF.
OMG manages a number of standards for business modeling, including BPMN, the Business Motivation Model (BMM) and the Semantics of Business Vocabulary and Business Rules (SBVR) specification.
Considerable progress has also been made in developing vertical model-based standards in the healthcare, finance, telecommunications, manufacturing, software-defined radio, space/ground systems communications and some dozen other technology areas.
New activities have been initiated to address important concerns of Regulatory Compliance and Software Assurance, building upon the base standards of MDA.
January-2007 [6]
6.c) Describe in brief the need for formulative middleware standard like CORBA in distributed object oriented systems. [6]
CORBA, on its inception, the Object Management Group (OMG) has provided vendor- and language-independent interoperability standards to the enterprise. The CORBA (Common Object Request Broker Architecture) standard has recently been modified for -- and embraced by -- environments that require specialized real-time, fault-tolerant, and embedded systems. The OMG's complementary core modeling specifications include the Unified Modeling Language (UML), the Common Warehouse Meta-model (CWM), the Meta-Object Facility (MOF), and XML Metadata Interchange (XMI).

Now, the OMG is building on the success of CORBA and the UML to take aim at the problems arising from the proliferation of enterprise middleware. Its Model Driven Architecture (MDA) initiative champions the extensibility and reliability of CORBA while acknowledging that enterprises cannot simply abandon their investment in other technologies.
* Organizations will be able to build new MDA-based applications using the middleware of their choice. They will have the security of knowing that the essential semantics of their application have been systematically distilled into a platform-independent model, and that any future migrations they might need to make to different middleware (or even new versions of the same middleware) will be reasonably manageable. In addition, they can produce interoperability bridges and gateways to other MDA-based applications within an enterprise as well as interconnections with customers, suppliers, and business partners in a methodical way, using a consistent architecture and some degree of automatic generation.

* Legacy applications -- the ones that keep your business in business -- will interoperate with an organization's current applications once they wrap them as we described and incorporate their functions into the MDA. They can remain on their established platforms; the MDA will help automate construction of bridges from one platform to another.

* Industry standards for all verticals will include platform-independent models defined in terms of the MDA core models: standard facilities performing standard functions, that you can buy instead of build, with interoperability and evolvability improved by their MDA roots. We'll describe these facilities and their role below.

* As new middleware platforms emerge, the OMG's rapid, consensus-based standardization process will incorporate them into the MDA by defining new standardized mappings. MDA tools will thus be able to target additional platforms for conversion to a platform-independent model. These tools will also be able to support bridges to the new platforms.

* Developers will gain the ultimate in flexibility: the ability to regenerate code from a stable, platform-independent model as the underlying infrastructure shifts over time. ROI will rise from the reuse of application and domain models across the software lifespan, especially during long-term support and maintenance, the most expensive phase of an application's life.

* Models are built, viewed, and manipulated via UML, transmitted via XMI, and stored in MOF repositories.

* Formal documentation of system semantics (through modeling) will increase software quality and extend the useful lifetime of designs (thereby increasing ROI).
CORBA is a foundation of this new architecture. As the only vendor- and language-independent middleware, it is a vital and necessary part of the MDA superstructure; software bridges would be hard to build without it. To give this superstructure maximum extensibility and move the reuse equation up one level, however, we must focus on expressing the architecture completely in terms of modeling concepts.