Let's move our discussion of CORBA from the past to the future. We have discussed much of the fundamental aspects of CORBA programming and there are many more details to cover before we can begin to say that we have our arms around the core functionality of CORBA or the CORBA Services. The problem with this comprehensive functionality is the high level of complexity -- which scares many people away from developing in the CORBA environment. An interesting aspect of developing distributed applications is that most developers are interested in trying to provide or acquire many of the same underlying services. These underlying services include security, event notification, persistence and transactions. And they are critical for giving your distributed application long-term value. The question we need to have answered is: How can these services be packaged so that they are easy to use, easy to learn and easy to distribute?
The specification for the CORBA Component Model (CCM) is written to address these and other complexities in the CORBA object model. The CCM is part of the CORBA 3.0 specification, which is due to be released this year. The CCM is a server-side component model for building and deploying CORBA applications. It is very similar to Enterprise Java Beans (EJB) because it uses accepted design patterns and facilitates their usage, enabling a large amounts of code to be generated. This also allows system services to be implemented by the container provider rather than the application developer. The benefit and need for these types of containers can be observed through the growth of Application Server software. The CCM extends the CORBA object model by defining features and services in a standard environment that enable application developers to implement, manage, configure and deploy components that integrate with commonly used CORBA Services. These server-side services include transactions, security, persistence, and events.
Keeping to the open principles of the Object Management Group (OMG), the CCM is language-independent. This means that the OMG must package the technology more tightly than the EJB standard. This is accomplished by building on the software packaging architecture being developed by the W3C to provide a complete vocabulary for describing binary executables.
Since I have already referenced EJBs, I should note that an important part of the CCM specification is a CORBA container for hosting EJBs. This provides the mechanics for two-way interoperability between EJBs in Java and CCM components in any CORBA programming language.
The CCM specification introduces the concept of components and the definition of a comprehensive set of interfaces and techniques for specifying implementation, packaging, and deployment of components. As with any specification from the OMG, a new batch of terminology has been unleashed. Let's look it over:
Facets
Think interfaces with this one. The component facets are the
interfaces that the component exposes.
Receptacles
These allow components to "hook" themselves together. Component
systems contain many components that work together to provide the client functionality. The receptacle allows a component to declare its dependency to an object reference that it must use. Receptacles provide the mechanics to specify interfaces required for a component to function correctly.
Event sources/Sinks
Allow components to work with each other without being tightly linked. This is loose coupling as provided by the Observer design pattern. When a component declares its interest to publish or emit an event, it is an event source. A publisher is an exclusive provider of an event while an emitter shares an event channel with other event sources. Other components become subscribers or consumers of those events by declaring an event sink.
Attributes
An extension of the traditional notion of CORBA interface attributes that allow component values to be configured, the CCM version of attribute allows operations that access and modify values to raise exceptions. This is a useful feature for raising a configuration exception after the configuration has completed and an attribute has been accessed or changed.
These new terms are illustrated in Figure 1.
Figure 1. Component model
Component Implementation Definition Language (CIDL)
To support all the above features, the CCM extends the CORBA Interface Definition Language (CIDL) to the point that it "introduces a new declaration language." CIDL, like IDL, relieves developers from having to provide much of the "plumbing" needed to include components within a container. To be exact, CIDL is a superset of the Persistent State Definition Language (PSDL), which itself is a superset of IDL. You should be aware that OMG IDL is morphing. Since CIDL is a language to emphasize the description of components, it has many new keywords. All of these keywords have been added to support the features introduced above. Listing 1 provides an example:
Listing 1. An example
interface VideoPlayer {
VideoStream play();
int fastForward(in Speed spd);
int rewind(in Speed spd);
};
component VCR supports VideoPlayer{
provides AudioStream audioPort;
provides VideoStream videoPort;
};
component DVD supports VideoPlayer{
provides AudioStream audioPort;
provides VideoStream videoPort;
};
|
This example has the keywords component , supports and provides . If you think about a component long enough, one aspect jumps out at you –– the need for multiple interfaces. A component will have a set of interfaces that will let it "behave nicely" in its designated container, and it will have to have one or more interfaces that clients will call to perform business logic. You could say the former would be a management interface and the latter a service interface. OMG IDL allowed you to express a set of interfaces as a new interface that inherited all the interfaces. This combined interface was usually long and complicated. An alternative is to define an entry point interface that is used to navigate to the other interfaces of the object.
The OMG has long known about the Multiple Interface gap. In fact it issued a Request for Proposal (RFP) regarding this topic back in 1996. That RFP was never specified concretely by a document, but the CCM can be looked at as fulfilling the requirements of that RFP. Component types specified by CIDL are allowed a combination of different interfaces that are not related by inheritance.
A component type name is defined with the component keyword. The component has is own interface, termed its "equivalent" interface, that is implicitly defined in the component definition. The equivalent interface for the components VCR and DVD is VideoPlayer; the relationship is declared through the supports keyword.
The component facets provide the business logic to expose to clients. These "facets" of our component come to life through the keyword provides . Provided interfaces are the "ports" that clients or other components can connect to. This is important because another keyword introduced in CIDL is the uses keyword. Uses declarations define a dependency of a component to an interface provided by another component or CORBA object. Clients can then navigate to a specified interface at runtime using Navigation operations generated by the provides declarations.
Distributed computing, the future and CORBA 3.0
It should be obvious that distributed computing is where software technology is headed. It suits our businesses and our homes. Component manufacturing is utilized in cars, stereos and kitchens. The promised land for distributed computing and software engineering will be an architecture model that will eventually provide many of the services we all need in an easy-to-learn and easy-to-use package. The CCM will provide greater opportunity for off-the-shelf components and commodity development tools, as well as an eventual reduction in time to market. All these should combine to create better long-term value for our software.
Over the next several months I will look more closely at different aspect of the CCM. It is new and not widely implemented. However, you should expect to see and hear much more about CORBA 3.0 and the CCM in the months and years ahead.
-
CORBA 3.0 Eases Object Development
, A TechWeb article from 1998
-
CORBA Component Model RFP
-
The CORBA & CORBA Component Model (CCM) Page
-
The CORBA Component Model (CCM)
-
CORBA Component Model Will Help Developers Quickly Design and Implement Mission Critical Distributed Systems
-
The OMG's New Corba Component Model: How Will It Play Against Enterprise JavaBeans and COM+?
Dave Bartlett lives in Berwyn, Pennsylvania, consulting, writing and teaching. He is the author of Hands-On CORBA with Java, a 5-day course presented via public sessions or in-house to organizations. Presently, Dave is working to turn the course material into the book Thinking in CORBA with Java. Dave has Masters degrees in Engineering and Business from Penn State. If you have questions or are interested in a specific topic, you can contact Dave at dbartlett@pobox.com.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
