In the previous article we saw how Enterprise Java Beans Components were accessible to CORBA Clients. Specifically, we dealt with interoperability issues surrounding Distribution, Naming, Transactions and Security aspects. We also introduced the term Component Software and the Enterprise Component Runtime Architectural Pattern. The last of the sequel on Java and CORBA integration deals with issues relating to integration between two Component Software technologies - OMG's CORBA Component Model (CCM) and Sun's Enterprise Java Beans (EJB). I shall give an overview of CCM, but for brevity, keep it brief. However, I assume you have enough EJB experience. In the spirit of giving the complete internals of the integration, I shall also introduce the concept of a Component Model to better understand what it takes to integrate the two. I will also attempt to make it easy for the EJB community to understand the CCM. But beware; we are dealing with bleeding edge technology! As of today, the CCM specification, and specifically the CCM EJB interworking section has not been finalized. I have tried to avoid those features and details in the CCM that are expected to change.

To refresh a bit, Component Software consists of Components, Tools to manage them and a Component Runtime. Components are a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. The Tools aid in managing the components and to configure them to the desired runtime environment. A Component Runtime defines a runtime environment for components.

Every Component Software technologies like CCM, EJB and COM+ offer a model for dealing with components. This is called a Component Model. The first step of integrating CCM and EJB is in finding the commonalties between the two component models. Before that we need to understand what a Component Model is. The component model must give sufficient support for reusability. A classic Component Model supporting reusability has these four basic traits:

Reusability is achieved with

1. Extensibility

2. Evolvability

3. Replacability

4. Composability

Reusability stated in simplified words is "stop reinventing the wheel". Ever since Doug McIlroy's much quoted presentation ("MASS PRODUCED SOPTWARE COMPONENTS") at the NATO Software Eng. Conference in 1968, the software industry has been in pursuit for an answer to the problem of reusability. One thing every one agreed upon was that the answer lies in Information Hiding. The concept of object-oriented programming did provide an answer: Classes. However, a class was simply a classifier for things with the same characteristics and behavior. It wasn't explicit about what is provided and what is required for it to function. Information hiding was achieved with the help of a set of access specifiers attached to the methods and members of a class. Definitely not a good way expose what is provided and what is required. Also, classes broke the concept of information hiding with the concept of implementation inheritance. The concept of Interfaces allowed a class to explicitly state what an object exposed. This was the first step towards components. An interface is also a partial specification of a component (a specification for a component will also include features like QOS, Time and Space constrains, the version etc). An ideal interface has a set of operations, each having a set of pre conditions and a set of post conditions. The concepts of pre and post conditions are taken from the Design by Contract paradigm made famous by the Eiffel language.

Extensibility allows for a component to add more features to it in the course of time. The key to this again is the concept of Interfaces. This is achieved with the help of inheritance of interfaces or by having a component expose an additional interface with the required features. One more thing to be aware of is the fact that extensibility should not break existing clients. For example, it is found in the second iteration, that a Calculator component needs to provide for trigonometric operations in addition to basic arithmetic operations. Ideally, you would add a new interface called TrignometricOperations to the Calculator component. You can also live by writing a TrignometricOperations interface extending for the ArithmeticOperations interface. For aesthetic reasons, I prefer the former way of extending a component.

Evolvability allows for a component to become better in the course of time. This time around, the specification is stable, only the implementation needs to be made better. The key to this is again in the concept of Interfaces. The ability of the interface to hide implementation characteristics allows for the component to evolve in time. There is a common term used to express this characteristic of a component: Polymorphism. Polymorphism is the ability to manipulate components using only knowledge of their common feature: the interface. Well, evolvability is not as simple. There are a lot of issues surrounding it like versioning that spoils the harmony. Most implementation technologies are yet to come with a suitable solution for versioning. A very crude form of versioning still exists in most implementation technologies: published interfaces are immutable. To explain evolvability, lets take the example of the Calculator component itself. Lets say that the operation for factorization in the ArithmeticOperations interface needs improvement. It could also be possible that we have found a way to improve the performance of this operation.

Replacability allows for a component to be plugged into and out of a component software system. The key to replacability is polymorphism that we discussed above. This also leads to the component being called as a Unit of Deployment. This concept also requires of a component to support some sort of modularization concept. Hence any component model should support a good packaging construct to package the implementation of the provided interfaces. Going through the same example of a Calculator component, all that we do is implement the component with a better algorithm and replace the existing component with the new one.

Composability allows for components to be assembled together forming a component software system. For components to be composed, they should expose their provided interface and state the required interfaces explicitly. Also, detailed information about their specification should be available to the application assembler. Hence components are also known as Plug and Play software. The assembly is typically achieved with the help of writing a script or using a tool. As for a working calculator, it requires of a user interface for people like accountants to access their functionality. So the Calculator component is to be composed with a Display component and a set of Button components. Interestingly, what if some scientific community needed this component to calculate the mass of the universe, they can access the highly efficient ArithmeticOperations interface of the same calculator component. All that they need to do is compose their scientific components with the Calculator component.

Other minor traits like support for component instance management, configuration and concurrency of components are not detailed for simplicity. What is important about component model is to make it easy for people to use a component software system. So said, lets take a look at what a component is for the CCM and EJB component software systems. Before that we need to identify how EJB and CCM support components. In EJB a bean comes in two forms: Entity Bean and Session Beans. Interestingly, the EJB Specification [Sun1999] calls an entity bean an object oriented view of some entities stored in a persistent storage, such as a database or entities that are implemented by and existing enterprise application. And the specification calls a session bean a session object in a non-persistent object that implements some business logic running in the server. One way to think of a session object is as a logical extension of a client program that runs on the server. A session object is not shared across multiple clients. The J2EE specification also talks of the J2EE module being a collection of one or more J2EE components of some container type with one component deployment descriptor of that type. Deployment descriptors for J2EE modules are also extensible. Any number of components of the same container type can be packaged together with a single container specific J2EE deployment descriptor to produce a J2EE module. A J2EE module represents the basic unit of composition of a J2EE application. An individual J2EE module can be deployed as a stand-alone J2EE module without an application level deployment descriptor.

Well, from the extensive discussion of what a component is and its essential traits, for me its clear that a bean is not a component; rather, the J2EE module is the component. Its unfortunate that Sun decided to call a bean a component. It only adds to the existing confusion about components (I was once a victim of this terminology war). As for CCM, the specification [OMG1999] has two Component Levels: Basic CORBA Components and Extended CORBA Components. The basic CORBA component supports a single interface (or multiple interfaces related by inheritance) and does not define any ports (provided interfaces or event source/sinks). The implementation of a basic component may use transaction, security, and simple persistence (i.e. a single segment) and relies on its container to manage the construction of CORBA object references. The basic component is functionally equivalent to the EJB 1.0 Component Architecture. As for extended components, it's a basic component with multiple ports (supported interfaces, provided interfaces and/or event source/sinks). The implementation of the extended component may use all basic function, advanced persistence (multiple segments) plus the event model and participates in the construction of component object references. Also, the CCM talks of packaging components. Component implementations may be packaged and deployed. A CORBA Component package maintains one or more implementations of a component. It may be installed on a computer or grouped together with other components to form an assembly. A component assembly is a group of interconnected components represented by an assembly package. A package, in general, consists of one or more descriptors and a set of files. The descriptors describes the characteristics of the package and points to its various files. The files that make up a package, including the descriptor, may be grouped together in an archive file or stored separately. When stored separately, the descriptor contains pointers to the location of each file. If you take a careful look at what the extended components provides, you can see that they define a provided interfaces, required interfaces and asynchronous event processing capability. All of them together are called the ports of the component. Figure 1 can explain better.

Facets (provided interfaces)

Since it's not always possible to extend a component by inheritance, there should be a mechanism to associate other interfaces to a component's equivalent interface. Facets, also known as provided interfaces, answer this problem. It's through the equivalent interface that the client can navigate to discover other facets that are supported.

Receptacles (required interfaces)

These are connection points that a component offers to delegate responsibility of work to other components. In effect, the component that has receptacles is a client to another component that implements that interface. They can be simple (having a one-to-one relationship) or complex (connecting to more than one reference).

Event sources (asynchronous event producers)

A component's ability to generate events is expressed by providing event service interfaces for event sources. An event is sent either directly to consumers or to an event channel.

Event sinks (asynchronous event consumers)

A component's ability to accept external events from suppliers or from an event channel is expressed by its support of event sinks. An event sink is a special kind of facet whose type is an event consumer.

The CCM does not stop at this. They categorize components into Service, Session, Process and Entity Components. The CCM specification elaborates [OMG1999]:

The Service Component is a CORBA component with the following properties: no state, no identity and has behavior The lifespan of a service component is equivalent to the lifetime of a single operation request (i.e. method) so it is useful for functions such as command objects which have no duration beyond the lifetime of a single client interaction with them. A service component can also be compared to a traditional TP monitor program like a Tuxedo service or a CICS transaction. A service component provides a simple way of wrapping existing procedural applications. A service component is equivalent to a stateless EJB session bean.

The Session Component is a CORBA component with the following properties: transient state, identity which is not persistent and has behavior. The lifespan of a session component is specified using the servant lifetime policies. A session component (with a transaction lifetime policy) is similar to an MTS component and is useful for modeling things like iterators, which require transient state for the lifetime of a client interaction but no persistent store. A session component is equivalent to the stateful session bean found in EJB.

The Process Component is a CORBA component with the following properties: persistent state which is not visible to the client and is managed by the process component implementation or the container, persistent identity which is managed by the process component and can be made visible to the client only through user-defined operations and behavior which may be transactional. The process component is intended to model objects that represent business processes (e.g. applying for a loan, creating an order, etc.) rather than entities (e.g. customers, accounts, etc.). The major difference between process components and entity components is that the process component does not expose its persistent identity to the client (except through user-defined operations). It has no EJB counterpart.

The Entity component is a CORBA component with the following properties: persistent state, which is visible to the client and is managed by the entity component implementation or the container, identity which is architecturally visible to its clients through a primary key declaration and behavior which may be transactional. As a fundamental part of the architecture, entity components expose their persistent state to the client as a result of declaring a primary key value on their home declaration. The entity component may be used to implement the entity bean in EJB. The primary key is used to identify a unique instance of the component within the persistent store.

OMG's specification is a lot clearer about what a component is. For me, a packaged Extensible CCM component is the ideal candidate for a component that supports all the features of a component model. A basic CCM component package, consisting of more than one basic component and having a large granularity is also a good candidate for a component. Lets now identify areas of commonality with the two component models by identifying the kind of support that is provided for the classic component model.

Extensibility is supported in EJB Component Model with the help of interface inheritance and by adding a bean which implements the new interface into the J2EE module. As with CCM, you have the choice of basic components and extended components. Basic component support for extensibility is the same as what EJB offers. But extended components can add a new feature by adding a new provided interface and implementing it. For new clients to access the new interfaces, extended components provided the ability to navigate from an old interface to a new one. In EJB, a client can navigate to a new interface by accessing the JNDI environment context.

Evolvability is supported in the EJB Component Model with the help of Java remote interfaces. Sun wanted a simple programming model for its EJB Component Model and opted for plain Java remote interfaces to hide all the implementation details. All you have to do is write the Remote Interface for the bean and implement it. Versioning problems are better solved in Java with the help of run time support from the JVM. As with CCM, it's the IDL Interface meta-type, which is used for hiding implementation details. CCM adopts CORBA's versioning approach of immutable interfaces.

Support for Replacability and Composability can be found in the packaging mechanisms employed by both EJB and CCM. In EJB a unit of deployment is the J2EE module. J2EE module is a jar file with a set of enterprise beans of the same container type and a deployment descriptor. In the case of CCM, it too has a packaging mechanism, which contain one or more descriptors and a set of files explaining the specification of the component in detail. All external dependencies are named in the deployment descriptor in both technologies. In addition to this, EJB defines a specific role for a deployer in deploying components. Same is the case with CCM. As for composition, both these technologies rely upon extensive tool support. Both technologies have a specific role for an application assembler whose job is to assemble components into component software systems.

As with component instance management, both CCM and EJB Component Models support the concept of a Home for components. The basic idea is to provide clients with the ability to create, delete and find components. Both EJB and CCM support very similar Home concepts. The only difference being EJB uses the Java language to program interfaces while CCM extends the OMG IDL to add a new meta-type home to support the concept. As for configuration of components, it's done at deployment time. All external dependencies declared by the component are resolved at this time. Enterprise Beans use the JNDI environmental context to get to the configuration parameters applied by the component. CCM components are configured with the help of attributes, similar to attribute definitions of an IDL interface. This time, attributes can throw exceptions. Other configuration setting like transaction and security attributes are applied at deployment time (transactions are an exception as its possible to have component managed transactions). Support for concurrency has always been a tough task on the component developer. So, both EJB and basic CCM components opt for a simple concurrency model: single threaded access, essentially meaning that only one invocation can be handled within a component instance at a time (with transactions it a bit more complicated). But the extended CCM components are allowed multiple invocations to be allowed to pass through a component at a time. Well, this could be one feature that could lead to some poor implementations of extended CCM components. Writing thread safe code has always been a tough undertaking.

So much for a comparison between CCM and EJB Component Models. Well, if you were attentive, you can very easily see that the basic CCM components are designed with interoperability with EJB in mind. Lets take a look at how the Calculator component will look like in CCM and EJB. They are aptly designed as session components. To keep the code simple, I leave apart the TrigonometricOperations interface out of the basic CCM component and the EJB component. Exceptions are also avoided.

Basic CCM Calculator Code.doc

Lets move on to the Component Runtime environment. Remember the Enterprise Component Runtime Architectural Pattern [Jacob2001August]. The pattern specifies a runtime environment for components that provides customization of components and declarative access to component services. Central to the concept of a component runtime environment is the concept of a Container. The component container interaction is referred to as the Container Programming Model. The container-programming model identifies a set of two API's: External APIs and Container APIs. The external API types are defined by the component developer and include the home specification. The Container API type is a framework made up of internal interfaces and callback interfaces used by the component developer. Figure 2 explains better. Well, do you see something very familiar? Yes, it's the component runtime environment described in the Enterprise Component Runtime Architectural Pattern.

API Architecture Diagram

In EJB, External APIs are written in the Java programming language. It requires of the external API to follow the Java-to-IDL mapping specification [Jacob2001July]. All remote interfaces are to inherit from the javax.ejb.EJBObject interface and all home interfaces are to inherit from the javax.ejb.EJBHome interface (EJB purists will argue that the diagram does not reflect its persistent and event model correctly). CCM does not have any such constrains as, components and homes are built in CORBA meta-types. The code section below makes this amply clear. It must be said that both the component models offer a simplified External API set for component developers. The Container APIs for both the EJB and basic CCM component specifications are very similar. OMG has given an exact semantic mapping to the meaning of the Container APIs for the basic CCM components. For example, take a look at the EJB javax.ejb.EnityBean interface that is to be implemented by an entity bean and the Component::EntityComponent local interface.

EJB EnityBean Source .doc

The only difference that you will notice is in the name of the operations associated with activating, loading, storing, passivating and removing of component instances. All of them that differ have a ccm (ccm_load) appended to them instead of ejb (ejb_load). As for semantics of the load operation, both the specifications intend the component developer to synchronize its in-memory state with the underlying persistent storage mechanism. And to get access to the specific entity in the persistent store, use the EntityContext interface for the purpose. How very similar. The extended CCM components have greater control of their environment than what is currently provided for a bean, including advanced persistence, event control, runtime management of references and servants (refer to the article detailing about servants and references [Jacob2001June].

There is a minor discrepancy within the EJB External API definition corrected in the CCM specification. The EJBObject has an operation to get the primary key of an entity bean. However, the EJBObject is also applicable to session bean clients. A call on a session bean's remote interface for the primary key will result in a rude shock (its impolite to ask a session bean its primary key). In the case of CCM, the operation to get the primary key is moved to the home interface instead of the remote interface, and there is a separate home interface for components with a primary key and those that do not have them.

Other issues (relating to component-container interaction) like Component Instance Lifetime Management, Events, and Persistence management do differed a lot. Both the specifications agree on the concept of state management for entity components. You can opt for bean-managed persistence or container-managed persistence. But the mechanisms used to achive state management differ a lot. Java relies on the Java Serialization specification for instance pooling. As for entity beans, they can rely on the JDBC 2.0 specification to provide advanced object-relational mapping. CCM offers basic and advanced persistence through the Persistence State Specification (PSS) [OMG1999August]. There is no support for Events in EJB. The recent introduction of Message Beans will answer the problem of asynchronous messaging capability. However, CCM does not have an answer to a messaging bean in the specification for both extended and basic components. In EJB, a components lifetime is managed explicitly by the container. It decides when to passivate and activate a component instance. With CCM, the container provides advance memory management capabilities. You have a choice of method, transaction, component and container servant lifetime policies. The CCM specification [OMG1999] elaborates:

The method servant lifetime policy causes the container to activate the component on every operation request and to passivate the component when that operation has completed. This limits memory consumption to the duration of an operation request but incurs the cost of activation and passivation most frequently.

The transaction servant lifetime policy causes the container to activate the component on the first operation request within a transaction and leave it active until the transaction completes and which point the component will be passivated. Memory remains allocated for the duration of the transaction.

The component servant lifetime policy causes the container to activate the component on the first operation request and leave it active until the component implementation requests it to be passivated. After the operation which requests the passivation completes, the component will be passivated by the container. Memory remains allocated until explicit application request.

The container servant lifetime policy causes the container to activate the component on the first operation request and leave it active until the container determines it needs to be passivated. After the current operation completes, the component will be passivated by the container. Memory remains allocated until the container decides to reclaim it.

Transactions are an exception to when it comes to identifying the mechanisms relating to its management in a CCM or EJB container. Both the models have similar transaction management services. Both of them offer component-managed and container-managed transaction demarcation capabilities in similar style. Component-managed transactions are handled through the common UserTransaction interface. The UserTransaction interface in CCM is equivalent to the UserTransaction interface (javax.transaction.UserTransaction) in EJB with the addition of the suspend and resume operations. In the case of container managed transaction demarcation, the transaction policies are specified in the deployment descriptor.

What we can conclude from this detailed discussion is that there are a lot of inconsistencies with the EJB and CCM container-programming model. Hence, arguments for an integration of the two container-programming models are moot. Hence, you have no way of deploying an EJB within a basic CCM container. What would be possible is to have an EJB container within a CCM server that supports the CCM container-programming model. Interestingly, the component runtime environment for both EJB and CCM can be built on top of the existing CORBA 2.3 infrastructure. Form more details about this; refer back to the previous issue [Jacob2001August]. Figure 3 explains better how to support both the EJB and CCM container in a CORBA 2.3 server.

So, the OMG has decided to have a bridging of the two technologies from a client's perspective. The CCM specification has defines CCM views for EJB components so that both EJB clients and CCM clients could access it at the same time. Similarly, there is a EJB view for CCM components as well. This concept of bridging follow in the same prescription for interworking as described in the CORBA 2.3 specification. The interworking model is represented in Figure 4.

The CCM specification elaborates this [OMG1999]. On the left is a client in object system A, that wants to send a request to a target object in system B, on the right. We refer to the entire conceptual entity that provides the mapping as a bridge. The goal is to map and deliver any request from the client transparently to the target. To do so, we first provide an object in system A called a View. The View is an object in system A that presents the identity and interface of the target in system B mapped to the vernacular of system A, and is described as an A View of a B target. The View exposes an interface, called the View Interface, which is isomorphic to the target's interface in system B. The methods of the View Interface convert requests from system A clients into requests on the target's interface in system B. The View is a component of the bridge. A bridge may be composed of many Views.

To achieve this, the bridging mechanism has to translate CCM requests to EJB components and vice versa. Essential to this strategy is to have a complete CCM to EJB mapping and an EJB to CCM mapping specification. The EJB clients use the JNDI to get access to the homes of the CCM components. Hence, a mechanism for exporting CCM homes to JNDI services is to be found. Ideally, it would be the tool vendor who should provide this transparency (when a new CCM component is deployed). Similarly, when an EJB component is deployed in the integrated system, CCM clients should be able to access its CCM view of the home from the naming service utility or from a Home Finder (a Home Finer can be though of as an abstraction above the Naming Service which helps in identifying homes, either though the name of the component, or through the name of the home itself). For such a mechanism to work, a compiler that can do the proper method translations is required. Any attempt to generate the bridging code would require of introspection of the deployment descriptors. Since the deployment descriptors are in XML, the task of introspection is simplified. The CCM specification defines the mapping of EJB Remote and Home interfaces to basic CCM component and home definitions. This mapping follows the Java-to-IDL mapping specification [Jacob2001July]. There is also a mapping of basic CCM component and home definitions to EJB Remote and Home interfaces. For example, the EJB version of the Calculator component that we saw above is translated into the very same Basic CCM Calculator component. Figure 5 explains how the interworking is achieved.

Issues relating to incompatibility between the CORBA remote invocation model and the RMI model of invocation has led to the consensus that any basic CCM component with inout and out parameters in the home and component declaration are not to be mapped to an EJB remote or home interface. RMI does not support out and inout style of programming. In such a situation, adopt the CCM client approach as the replacement. There are a few other issues relating to the CCM EJB interworking specification. I would not cover the exact mapping of the EJB view for CCM components and the CCM view for EJB components in this article, instead, I shall post the latest information on the iCMG website (http://componentworld.nu) for your perusal. This way, you stay updated about the latest developments. I must admit to have been influenced by the most excellent book on components - Component Software Beyond Object Oriented Programming by Clemens Szyperski [Szyperski1999]. This article has borrowed a lot of material from the early draft of the CCM specification [OMG1999] and EJB 1.0 specification [Sun1999]. All these materials are presented in italic paragraphs.

Resources on CCM

A good place to look for CCM related material is the unofficial CCM website maintained by Diego Sevilla Ruiz (http://www.ditec.um.es/~dsevilla/ccm/). iCMG is coming out with an implementation of the CCM specification. The details of product (named K2) can be accessed form the http://www.componentworld.nu/corp/K2/k2.overview.asp website. For a sneak peek at the ongoing finalization of the CCM specification, get to the OMG web site (http://www.omg.org). There are lots of open source CCM implementations in the pipeline for you to start with. All details of ongoing CCM implementations are available from Diego's website. Keep a sharp eye on that web site for the latest CCM developments.

It's time to say "Good Bye"

We have come to the end of the 6-part story on CORBA and Java integration. It sure is not the end for CORBA and Java. The series has attempted at providing the reader with an in-depth view of what it took OMG and Sun to integrate their flagship technologies. OMG's CORBA is a time tested middleware technology. With the addition of the CCM, the appeal for CORBA in the enterprise will grow beyond known bounds. Sun's EJB has already captured a large share of the enterprise component market. Java has evolved from a client side/embedded technology to a powerful server side technology with the introduction of J2EE. The seamless integration of the CCM with EJB component models facilitates enterprise architects the power to exploit this combination to come out with industrial strength solutions. Ciao.

References:-
[Jacob2001June] POA and Object by Value - IT Magazine June 2001

[Jacob2001July] The Java to IDL mapping and RMI/IIOP specification - IT Magazine July 2001

[Jacob2001August] EJB and CORBA Integration - IT Magazine August 2001

[OMG1999] CCM FTF Draft ptc/99-10-04

[OMG1999August] Persistent State Service 2.0 August 2, 1999

[Sun1999] EJB 1.0 Specification 1999-2000.

[Szyperski1999] Component Software: Beyond Object Oriented Programming - Addison Wesley Longman 1999.


The complete text of the Mass Produced Components paper is available at this web site: http://www.cs.dartmouth.edu/~doug/components.txt

   - Mr. Jacob Jose Cherakal - Software Architect,