| Previous | Table of Contents | Next |
A second area where early use of the MOF is likely is in the representation and management of the various kinds of type information
used by the expanding array of CORBA infrastructure services.
The CORBA Interface Repository (IR) is the most central type-related service in CORBA. The IR serves as a central repository
for interface type definitions in a CORBA-based system. The current IR essentially provides access to interface definitions
that conform to the implied information model of CORBA IDL. While the IR interfaces are tuned fairly well to read-only access,
there is no standard update interface and no way to augment the interface definitions in the IR with other relevant information,
such as behavioral semantics.
Given a simple MOF-based development environment (as described above), it would be easy to describe the implied information
model for CORBA IDL using a notation for the MOF Model. The resulting CORBA IDL model could then be translated into the IDL
for a MOF-based replacement for the CORBA IR. While this replacement IR would not be upwards compatible with the existing
IR, the fact that it was MOF-based would provide a number of advantages. The MOF-based IR would:
• Support update interfaces.
• Be extensible in the sense that it would be feasible to extend the CORBA IDL model specification by (MOF Model) composition and inheritance. This ability would help smooth the path for future extensions to the CORBA object model.
• Make it easier to federate multiple IR instances and to represent associations between CORBA interface types and other kinds of type information.
• Automatically include links to its own meta-information definition expressed using MOF meta-objects.
2. The MOF meta-model has specific requirements (e.g., model simplicity and support for automatic IDL generation) that are
not generally applicable. As a consequence, it is unreasonable to expect the MOF metamodel design to be suitable for all kinds
of object modeling.
Other candidates for use of MOF-based technology among existing and forthcoming infrastructure services include:
• Trader: The CORBA trader service maintains a database of “service offers? from services in a CORBA-based distributed environment. These offers have associated service types that are represented using the CosTradingRepos::ServiceTypeRepository interface. (A trader service type is a tuple consisting of a type name, an interface type, and a set of named property types. Service types can be defined as subtypes of other service types.)
• Notification: At least one initial submission for the forthcoming Notification service includes the notion of an event type. (An event type is a tuple consisting of a type name, a set of named property types, and a set of supertypes.)
In both cases, a MOF-based type repository would have the advantages listed previously for the MOF-based Implementation Repository.
Looking to the future, there are a number of other possible uses for MOF-based type repositories in infrastructure services.
For example:
• Service interface bridges: As CORBA matures and there is large-scale deployment as part of enterprise-wide computing infrastructures, it will become increasingly necessary to cope with legacy CORBA objects; that is, with objects that provide or use out-of-date service interfaces. In situations where statically deployed object wrappers are not a good solution, one alternative is to provide an ORB-level service that can insert an interface bridge between incompatible interfaces at bind time. Such a service would depend on types that describe the available bridges and the mechanisms used to instantiate them.
• Complex bindings: RM-ODP supports the idea that bindings between objects in a distributed environment can be far more complex than simple RPC, stream or multicast protocols. RM-ODP defines the notion of a multi-party binding involving an arbitrary number of objects of various types, in which different objects fill different roles in the binding. A CORBA service to manage complex bindings would be based on formally described binding types that specify the numbers and types of objects filling each role and the allowed interaction patterns (behaviors) for a given binding.