We have completed our discussion on how Java and CORBA object models were integrated to provide developers a suitable platform to program distributed objects. It began with a conceptual overview of the Java and CORBA worlds [Jacob2001April]; we then progressed to see how OMG IDL was mapped to Java [Jacob2001May] and how Java remote interfaces were mapped back to IDL [Jacob2001July]. The rational behind these mappings were also discussed in detail. Well, the world is moving towards Components. In this article, I would focus on introducing you to the concept of components, how it all begun and through it the idea of the next generation of components: Component Software. I would also introduce an architectural pattern: Enterprise Component Runtime Architectural Pattern. Through this I shall be able to concentrate upon the integration of EJB and CORBA technologies, which I believe, was made of each other.

As the complexities of software increased, solutions powerful enough to capture these complexities in sufficient measures came about or better said evolved. A simple rule followed throughout history to capture complexity is: Divide and Conquer. In software speak, we call it modularizing software. In the beginning, the needs for a language sufficient to capture simple problems were addressed by Assembly languages (support for modules were absent). As the complexity of the problem domain increased, there was a transformation in the style of programming; Structured approach was sufficient for this purpose (modules were introduced as data structures and functions to manipulate them). Then came the Object Oriented approach that addressed real world entities as objects (modules came in the form of classes). Components are the next step in this evolutionary approach. Components use the concept of an Interface to hide the complexity (modules expose its behavior in the form of an interface or multiple interfaces). In simple terms, an interface is a collection of operations with a pre-condition and a post-condition. Common interface definition languages like CORBA IDL, COM IDL and Java Interfaces have been used in the past for specification of interfaces. As discussed in the third article [Jacob2001June], the interface in CORBA IDL encapsulates a lot of features like remoteness, architecture and platform independence. This is the first generation of component systems.

As the enterprise started heavily relying on computing power for its day-to-day activities, the need for managing all that larger amount of data attained critical importance. Hence, the past two decades was indeed dominated by Data Base Management Systems. Relational Database technology enabled the needed data management technology. Then came the need to manage the large amount of data that was distributed across various enterprise systems. Transaction Processing Monitors or Application Servers grew out of the need for a scalable, transaction oriented, fault tolerant, manageable and secure mechanism for such systems. Concepts like transaction processing, persistence, security, scalability and performance could be addressed. However, there was a problem. Developers used to program these features into their functional logic and would end up in a very precarious position, needing to know complicated non-functional logic and also the application logic. A consensus among the middleware players emerged as how to tackle the problem. Component Software was the answer to this predicament. It consists of Components, Tools to manage them and a Component Runtime. The integration of traditional application servers and components led to the next generation Component Software Systems. The current contenders in the market are Sun Microsystems with the EJB specification, Microsoft with the COM+ solution and OMG with the Corba Component Model (CCM, more on this in the next article).

Next, I shall give a brief introduction to the elements of Component Software. Components are

a physical, replaceable part of a system that packages implementation and provides the realization of a set of interfaces. A component rep-resents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files.

This definition is taken from the UML Specification [OMG1999].

The Runtime defines the environment in which a component lives. The Tools aid in managing the components and to configure them to the desired runtime environment. They would typically consist of an Integrated Development Environment (IDE). I would like to concentrate on the Runtime, as the tools are not important for our discussion.

The problem of defining a runtime environment for components has evolved into an architectural pattern (a pattern is defined as a common solution to a recurring problem in a particular context [OMG1999]. An architectural pattern is one that expresses a fundamental structural organization scheme for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationship between them [Buschmann1996]). This I would refer to as the Enterprise Component Runtime Architectural Pattern (there is no common consensus as to how this pattern is called). I shall take a scaled down version of the Mowbray and Malveau Template [Mowbray1997] for introducing the pattern. It is essential that you get to read the book to get the finer details of this template.

Solution Name: Enterprise Component Runtime Architectural Pattern

Intent:
Specify a runtime environment for components that provides customization of components and declarative access to component services.

Primal Forces:
Manage Components by decoupling Functional and Non-functional logic.

Solution Summary:
The Enterprise Component Runtime Architectural Pattern is in itself composed of a number of Design Patterns. I do expect the reader to be familiar with the Proxy and Factory Pattern [Gamma1995]. In addition to these patterns another of those important patterns is the Interceptor Pattern (this concept is not documented much as a pattern.) This pattern could be categorized as an Architectural Pattern. The basic idea is to intercept all requests and have all non-functional activities carried out while interception is in progress. Once all non-functional requirements are satisfied, the functional code is invoked. The concept of interception can help in Instance Management, Scalability with load balancing, Fault Tolerance, Transaction Management, Persistence Management and Security Management. We can call the encapsulated environment a Container.

The solution also introduces the concept of Remote Objects that act as delegates of the instances (they realize the Proxy Pattern). The combination of Remote Objects and Interceptors provide the required decoupling of the client from the component instances and the required manageability. We also use the concept of a Home (they realize the Factory Pattern) for components, whose job is to create, remove and find existing components. In addition to this, the component is given access to the container if it takes on the responsibility of managing certain non-functional logic by itself. This is done with the help of the Contexts.

Key Benefits:
The two major benefits is the ability to customize components by declaratively programming them and to decouple the non-functional concerns from the functional concerns allowing the component-based developers to concentrate on important functional logic. All this helps in faster enterprise software development in the age where software has to be developed at Internet speed.

Consequences:
This approach needs sufficient code generation capability to simplify programming, tools to configure components while they are deployed in the system and an advanced middleware system that has built in Transaction, Persistence, Security and Manageability capabilities, which can be configured with the help of policies.

Well, why talk about an Enterprise Component Runtime Architectural Pattern when the main focus is to be integration of EJB and CORBA. If you see the consequences section of the pattern discussed above, you can see a requirement of an advanced middleware system with Transaction, Persistence, Security and Manageability capabilities, which can be configured with the help of policies. An enterprise solution like EJB needed all these features. In addition to this, interoperability between EJB's deployed in various vendors EJB Server's were also of great importance. This required of the middleware system to have interoperability semantics.

CORBA has evolved into an advanced middleware platform that can support the needs addressed above. It has a robust broker runtime and a powerful array of services. Well, remember the discussion we had about the Portable Object Adapter (POA) in a previous article [Jacob2001June]. A POA can offer the required runtime that can be configured using CORBA Policy objects. In addition to this, the POA also offers advanced servant management capability. The ubiquitous CORBA Services, commonly called COS offers Transaction (COSTransaction), Persistence (Persistent State Service) and Security (COSSecurity) services. As for interception, we can use the Portable Interceptors that is now a standard feature with all of the latest CORBA ORBs.

Off course, EJB needed all this support and Sun did not want to address the need for an advanced middleware by evolving RMI into something similar to the OMG's Object Management Architecture (OMA). Instead it focused on specifying what a component is and what it can expect from the EJB component runtime environment. All this was to be specified in the Java language. So the EJB specification built on a set of Java interfaces in the javax.ejb package. As discussed in the previous article, RMI style interfaces were the choice of Sun to express remote interfaces. There needed to be a binding between CORBA runtime and RMI remote interfaces. This led to the RMI over IIOP specification [Jacob2001July]. In addition to this, the OMA offers support for Naming, Event, Transaction, Security and Persistence support. Sun has a better Persistent model than the Persistent State Service (PSS). As for Naming, Transaction and Security, they chose to embrace the OMA version of these services.

So, Sun decided to have a specification to ensure CORBA and EJB integration. The major goals of the specification is to define an "on the wire interoperability" mechanism so that multiple CORBA based implementations of EJB containers can interoperate and allow CORBA clients to access EJBs deployed in a CORBA based EJB Server through standard CORBA API's. To quote from Sun's EJB CORBA Mapping Specification [Sun1999b]: We expect that many EJB servers will be based on the CORBA/IIOP industry standards. To ensure interoperability among CORBA-based EJB server implementations from multiple-vendors, we have defined a standard mapping of EJB to CORBA. The EJB to CORBA mapping is divided into four areas:

• Mapping of Distribution - defines the relationship between an Enterprise JavaBean and a CORBA object, and the mapping of the Java RMI remote interfaces defined in the EJB specification to OMG IDL.
  
  
• Mapping of Naming - specifies how CORBA's COS Naming service is used to locate EJBHome objects.
  
  
• Mapping of Transactions - defines the mapping of EJB transaction features to the CORBA Object Transaction Service.
  
  
• Mapping of Security - defines the mapping of the security features in EJB to CORBA security.

"As a server-side implementation technique, the CORBA runtime may use an RMI-IIOP servant implementing the enterprise bean's EJBObject interface which receives a method invocation and delegates it to the appropriate enterprise bean instance. One way to achieve this is to use Tie based skeletons (as defined in the Java Language to IDL Mapping)."
Java system exceptions including java.rmi.RemoteException and its subclasses may be thrown by the EJB container, as specified in EJB1.0. The EJB server is required to map these exceptions to CORBA system exceptions as specified in the following table:

No enterprise can exist without a proper Directory and Naming service available for publishing compound names. COSNaming can be used to publish and resolve EJB Home and Remote objects. Ideally it would be better to store EJBHome objects. The JNDI specification separates the API used by the client from the service provider's API, and there by decoupling the underlying mechanism. There is a standard COSNaming service provider defined for COSNaming. The API is a wrapper around the COSNaming service. The clients of JNDI service provider is insulated from the COSNaming APIs through this wrapper, which delegates JNDI requests to a COSNaming service by converting it into a COSNaming API. Say for example, the javax.naming.Context.bind method will get converted to the CosNaming::NamingContext.bind method.

Transactions are used to make a collection of operations work as one unit, in total isolation and maintain consistency of data. The industry buzzword to enable such traits is called the ACID characteristics of transactions.

1. A transaction is atomic; if interrupted by failure, all effects are undone (rolled back).

2. A transaction produces consistent results; the effects of a transaction preserve invariant properties.

3. A transaction is isolated; its intermediate states are not visible to other transactions.

4. A transaction is durable; the effects of a completed transaction are persistent; they are never lost (except in a catastrophic failure).

However, interfaces to CORBA Transaction Service were specified in IDL. So, Sun decided to have a Java language mapping independent of the OMG IDL to Java mapping [Jacob2001May] called the JTS (javax.jts package).

JTS specifies the implementation of a transaction manager, which supports the JTA specification at a high-level and implements the Java mapping of the OMG Object Transaction Service (OTS) 1.0 Specification at the low-level. JTS uses the CORBA OTS interfaces for interoperability and portability (that is, CosTransactions and CosTSPortability). These interfaces define a standard mechanism for any implementation that utilizes IIOP (Internet InterORB Protocol) to generate and propagate transaction context between OTS/JTS Transaction Managers. Note, this also permits the use of other API over the IIOP transport mechanism to be used; for example, RMI over IIOP is allowed. [Sun1999].

What is important is to understand the mechanism that is used to propagate a transaction context across various implementations of the JTS. This is achieved with the help of the Service Context field of every message that is sent over IIOP. Here are the details of Transaction Propagation. EJB allows for marking a set of methods in an EJB interface as transactional. However, CORBA allows you the choice of marking the entire interface as transactional by inheriting from the CosTransactions::TransactionalObject IDL interface or by using a specific POA policy, which allows for all CORBA objects in that POA to be transactional.

The following rules list the types of EJB interfaces having remote methods that execute in the client's transaction context [Sun1999b]:

1. SessionBean remote interfaces satisfying both the following rules:
a) the SessionBean's transaction demarcation type is set to Container", i.e. SessionBeans with container-managed transactions, and

b) at least one of the SessionBean's remote interface methods has one of the transaction attributes "Supports", "Required" or "Mandatory".

2. EntityBean remote interfaces satisfying the following rule:
a) at least one of the EntityBean's remote interface methods has one of the transaction attributes "Supports", "Required" or "Mandatory".

3. EntityBean home interfaces satisfying the following rule:
a) at least one of the EntityBean's home interface methods has one of the transaction attributes "Supports", "Required" or "Mandatory".

The IDL mapping of an EJB interface satisfying the above rules must inherit from the CosTransactions::TransactionalObject IDL interface. This ensures that if the client makes an invocation to the EJB home/object within the scope of a transaction, the transaction context will be implicitly propagated to the server. For EJB/CORBA servers which use implicit IDL, the is_a operation (defined on CORBA::Object) with the repository-id parameter "IDL:omg.org/CosTransactions/TransactionalObject:1.0" should return TRUE for EJB interfaces satisfying the above rules.

A CORBA client will typically use the CosTransactions::Current OTS interface to demarcate transaction boundaries. An EJB/CORBA client will use the javax.transaction .UserTransaction interface in the Java Transaction API to demarcate transaction boundaries. In both cases the ORB must propagate transaction context implicitly to the server as described above.

OMG's Security Service provides features like authentication, authorization, auditing, secure communication, delegation, non-repudiation and administration, essential to every self respecting security system. Above all, the specification is independent of any one particular security technology. As for interoperability with other security service implementation, it's taken care of by the GIOP feature - service context, mentioned above.

The main security concern in the EJB1.0 specification is access control, which requires the EJB server to determine the client's security identity. This specification does not require usage of a specific CORBA security protocol for propagating security information. Vendors should use compatible CORBA security protocols to ensure on-the-wire interoperability. This specification will track the Common Secure Interoperability RFP at OMG. EJB/CORBA servers should determine the client identity based on the actual security and communication protocols used by the ORB, as specified in the CORBA Security Service [OMG1999b]:

• Plain IIOP - since the Security Service does not specify the mechanisms for propagating identity information in plain IIOP messages, the determination of client identity is vendor specific.



• Common Secure IIOP (CSI) - The client identity is defined by the specific mechanism (GSSKerberos, SPKM, CSI-ECMA) used with SECIOP (Secure IIOP).



• IIOP over SSL - The client's identity is the X.500 distinguished name of the subject obtained from the X.509 certificate during SSL client authentication. Note: since SSL does not support delegation, an EJB/CORBA server using IIOP over SSL may not be able to propagate client principals from caller to callee in an interoperable manner.