Enterprise Java Beans define a server side distributed component model architecture that intends to provide solutions for business applications in a transactional, secure, scalable and platform independent way. It provides features like automatic data persistence, remote messaging, security, resource management and transparent Client/Server communication. EJBs (versions 1.1 and 2.0) are primarily converted to .NET Framework through COM+ technology (System.EnterpriseServices API). EJBs with Container Managed Persistence (CMP) have no direct equivalent in COM+.
Principally, JLCA 3.0 helps to convert the following features of EJBs: Session Beans (Stateful and Stateless), Entity Beans (BMP and CMP), Message Driven Beans, Client Side, Security (Permissions and Roles) and Transactions (EJB level and Method Level). It is relevant to note that JLCA 3.0 only converts standardized features (stated in the EJB Specification) and does not convert vendor-specific implementations. Since features that are stated and configured from the application’s XML Deployment Descriptor (ejb-jar.xml) are converted, JLCA 3.0 requires that this file be placed inside the source code directory for successful conversion.
Table 8 and Table 9 contain the relevant details for EJB conversion. In a summarized manner, they enunciate the EJB features preserved in converted applications. On the other hand, they suggest the issues that the user should take care while converting EJBs.
Class / Interface in Package java.beans
JLCA 3.0 Coverage
These exceptions are converted to a more generic exception (System.Exception).
This provides an instance with access to the container-provided runtime context of an enterprise Bean instance.
This interface is not completely converted. Some of its methods such as ‘isCallerInRole’ have direct equivalence in .NET Framework and are therefore converted.
These are the interfaces that must be extended by Bean’s remote home, local home, local and remote interfaces respectively.
These interfaces are not supported in .NET Framework. JLCA 3.0 supports the conversion of the common scenario where there are classes/interfaces extending/implementing user-defined EJB Local, Home, and Remote interfaces to publish the EJBs’ lifecycle and business logic.
This interface allows a client to obtain the enterprise Bean’s meta-data information.
This interface is not converted as it is used only to provide EJB Meta Data Information.
These interfaces are implemented by every enterprise, entity, message-driven and session bean.
These interfaces are converted to System.EnterpriseServices.ServicedComponent since all EJB bean classes are converted to a COM+ ServicedComponent.
These interfaces are related to specific EJB Contexts.
These are not supported as COM+ Contexts are managed differently and their information is not equivalent in content/context to the information provided by EJB Contexts.
Interfaces implemented by EJB and home object handle respectively.
These interfaces are not converted as remote network references to objects are managed by the framework itself.
This interface allows a session Bean instance to be notified by its container of transaction boundaries.
This interface is not needed in COM+ as COM+ manages synchronization and transactions automatically.
Table 8: EJBs Conversion Coverage – Package java.beans
EJB Application Deployment Issues are not covered as JLCA 3.0 only supports features stated in the standard EJB Specification. These are stated in the XML Deployment Descriptor (ejb-jar.xml). The EJB deployment procedures are vendor-specific.
The user should deploy the target COM+ Applications.
Bean Managed Transactions
There are no special rules to convert user transactions in BMP EJBs (using a transaction API like JTA).
A workaround could be to use declarative transactions (attributes) for the targeted .NET Framework Serviced Components.
EJB Clients conversion requires converting the server side application at the same time as the client because it needs the metadata information about the EJBs and the respective XML Deployment Descriptor. The conversion is based on source code patterns and it does not replicate the reference lookup (performed through JNDI). The user should manually add the respective references and fix JNDI-related issues in the Client project.
Entity Beans Relationships
Entity bean’s relationships with one-another are not entirely converted by JLCA3.0 as they are based on the underlying vendor-specific datastore schema. For each relation, JLCA converts the relations by means of a Serviced Component field and provides a dummy implementation for the respective properties. Additional steps could require setting the respective value of each property for each relation.
The Environment Entries are not converted at all because logical references for publishing – performed through JNDI – must be executed from a Directory Service.
A workaround could require publishing the resources in a Directory Service like ADS and specifying in the target code where the resource was published.
EJBs conversion depends on the XML Deployment Descriptor (ejb-jar.xml file). For each XML Deployment Descriptor found inside the source code directory (or inside files .jar and .ear) JLCA 3.0 creates a target COM+ project if all classes/interfaces described in the corresponding XML Deployment Descriptor are provided inside the source code directory. The target COM+ project is named as COMPlusApplication and contains only the EJBs classes/interfaces described in the respective XML Deployment Descriptor. The user should add all classes that contained EJBs are depending on (referencing and/or using) during the conversion to the target COM+ projects.
As COM+ manages transactions in a different way, state synchronization availability with the outcome of transactions is not converted. A possible workaround could be to declare a transactional .NET Framework Serviced Component by adding the attribute System.EnterpriseServices.Transaction and manually adding invocations to the implemented methods of javax.ejb.SessionSynchronization in the proper sections of the code.
Stateful Session Beans
Stateful Session Beans are not converted entirely by JLCA 3.0 because COM+ is a stateless technology, in the sense that it requires to manage “session state” for each client (Read more here). A workaround could require changing the application design to emulate persistence of session states.
Transaction Isolation Levels
Transaction Isolation Levels are not converted by JLCA 3.0. Container-managed transactions are specified using vendor-specific tools and bean-managed transactions are specified using an API like java.sql.Connection.setTransactionIsolation(). A workaround could be to apply the attributes (System.EnterpriseServices.Transaction.Isolation and System.EnterpriseServices.TransactionIsolationLevel) to the target .NET Framework Serviced Components.
Table 9: EJBs Conversion Issues