![]() |
[Become a member of the ObjectWeb Consortium! Membership is free for individuals.] | |
OpenCCM
Developers' corner
About OpenCCM
ObjectWeb resources
|
The OMG CORBA Components TechnologyWarning: This is not a full and official description of the Object Management Group's CORBA Component Model, only some of our points of view. For more details, have a look to the latest CCM Tutorial presented during OMG meetings. The CORBA 2.4 specification provides interoperability for objects and applications through OMG IDL, mappings, GIOP, IIOP, and the POA. Some of the goals of the CORBA Component Model are:
The current CCM specification defines the four following models: The abstract modelThe CCM abstract model offers developers to define interfaces and properties of components. The OMG IDL (Interface Definition Language) has been extended to express component interconnections. A component can offer multiple interfaces, each one defining a particular point of view to interact with the component. The four kinds of interfaces are named ports. Two interaction modes are provided: facets for synchronous invocations, and event sinks for asynchronous notifications. Moreover, a component can define its required interfaces, which define how the component interacts with others: receptacles for synchronous invocations, and event sources for asynchronous notifications. The abstract model also defines instance managers -- component homes -- which are based on two design patterns: factory and finder. A home is defined to create and retrieve a specific component type, and can only manage instances of this type. Nevertheless, it is possible to define several home types for a single component type. The programming modelThe CCM programming model defines the Component Implementation Definition Language (CIDL) which is used to describe the implementation structure of a component and its system requirements: the set of implementation classes, the abstract persistence state, etc. This language is associated with the Component Implementation Framework (CIF). This framework allows developers to merge the component functional part they have produced and the non-functional part generated from OMG IDL3 and CIDL descriptions. The functional part includes the implementation of the provided interfaces (facets and event sinks). Using the OMG IDL3 definition as well as the CIDL description of the component, a compiler produces the skeleton of the component implementation. This skeleton includes the non-functional part of the component implementation, i.e. unmarshaling GIOP requests, port management, activation, and persistence requirements. These skeletons are implemented on top of APIs provided by containers. Thus, a developer only has to write the functional code in order to complete the component implementation. The compiler also produces the OMG IDL2 mapping as well as a XML descriptor for the component implementation. The OMG IDL2 will be used by component clients. The XML descriptor will be used during the deployment of the component implementation as discussed in the following subsection. The implementation generated part also provides a dynamic introspection API. It includes the operations to discover component ports in a generic manner (same operations for any component type), or in a specific one (operations generated according to the component type). These operations can be used in a dynamic platform to introspect and interconnect component instances at runtime. The deployment modelThe CCM deployment model is based on the use of software packages, i.e. ``ZIP'' archives containing component descriptors and implementations. Descriptors are written using the Open Software Description (OSD) language which is a XML vocabulary. This language allows architects to describe four kinds of descriptors:
The deployment process allows architects to easily install an application on various sites. A ComponentInstallation and an AssemblyFactory have to be running on any site an application could be installed. These two objects are used by the deployment tool to install the packages of the application, and to create an instance of it. AssemblyFactory objects manage Assembly objects that represent deployed applications. The deployment tool provides an OSD assembly descriptor to the Assembly object that really performs the deployment of the application. Thus, the deployment process is fixed in this object, and cannot be controlled by an architect nor by the application! The execution modelThe CCM execution model defines containers as the technological artifacts. A container is a runtime environment for component instances and their homes. Several containers could be hosted by a same component server. A container is more than a simple execution environment. Containers hide the complexity of most of the system services like the POA, transaction, security, persistence, and notification services. Thus, containers take part in the management of non-functional aspects of a component. Clients interact with a component instance through the generated OMG IDL2 interfaces. An interesting feature of component servers is the ability to download archives from repositories. Thus, downloading packages can be done at any time, and more precisely only when a component is required. Some WWW linksSome interesting WWW links about the CORBA Component Model are:
Some interesting OMG documents are:
Some interesting english papers:
Some interesting french papers and reports are:
|