Technical Publications-Whitepapers-A Detailed Comparison of Enterprise JavaBeans (EJB) & The Microsoft Transaction Server (MTS) Models (with specific code examples)

14 May 1999

Publications, Container-Managed-Models

Before you read this article, please be fore-warned that this was written with the developer in mind. I assume that you are familiar with MTS and EJB and have a working knowledge of at least one of these technologies.

A Note on the Terminology

Let us now look at some of the terminology that will be used in this article.

Introduction

A while back, I had written a Detailed Comparison on the CORBA, DCOM and Java/RMI models. In that article, I had promised that as soon as OMG announced their middleware CORBA Component Model (CCM), I would write another article comparing MTS, EJB and CCM. In a press release on April 6, 1999, the OMG officially announced that the JavaSoft's Enterprise JavaBeans (EJB) model would also serve as a subset to CORBA's Component Oriented Middleware platform.

Middleware Component Models take a high level approach to building distributed systems. They free the application developer to concentrate on programming only the business logic, while removing the need to write all the "plumbing" code that is required in any enterprise application development scenario. For example, the enterprise developer no longer needs to write code that handles transactional behavior, security, database connection pooling or threading, because the architecture delegates this task to the server vendor.

When it comes to Middleware Component Models there are several 'de-jure' and 'de-facto' Standards in the industry today. In this article, we will look at two of them namely, The Microsoft Transaction Server (MTS) Architecture from Microsoft and JavaSoft's Enterprise JavaBeans (EJB). Let us examine the differences between these models from a programmer's standpoint and an architectural standpoint. At the end of this article, you will be able to better appreciate the merits and innards of each of these Middleware Component Architectures.

MTS, based on the Component Object Model (COM) which is the middleware component model for Windows NT, is used for creating scalable, transactional, multi-user and secure enterprise-level server side components. MTS provides a surrogate for in-process server-side components. MTS can also be defined as a component-based programming model. An MTS component is a type of COM component that executes in the MTS run-time environment. MTS supports building enterprise applications using ready-made MTS components and allows you to "plug and work" with off-the shelf MTS components developed by component developers. Just as a COM component can be modelled on the basis of interfaces and their implementation, MTS enforces modelling based on the component's state and behavior. MTS, through the COM infrastructure, handles communication between components using DCOM. This allows MTS to expose its components to Windows applications from anywhere on the net or the web. As long as you are only running on Windows NT, MTS components can be deployed on top of existing transaction processing systems including traditional transaction processing monitors, web servers, database servers, application servers, etc. Legacy system integration with non-Windows systems and MTS is achieved using the COM Transaction Integrator (COM-TI) technology. Also, it is important to realize that MTS is a stateless component model, whose components are always packaged as an in-proc DLL. Since they are composed of COM objects, MTS components can be implemented in a variety of different languages including C++, Java, Object Pascal (Delphi), Visual Basic and even COBOL!

EJB is a middleware component model for Java and CORBA and is a specification for creating server-side, scalable, transactional, multi-user and secure enterprise-level applications. It defines a set of specifications and a consistent component architecture framework for creating distributed n-tier middleware. It would be fair to call a bean written to EJB spec a Server Enterprise Bean. Most importantly, EJBs can be deployed on top of existing transaction processing systems including traditional transaction processing monitors, web servers, database servers, application servers, etc. Since these components are written using Java, EJBs containing the business logic are platform-independent and can be moved to a different, more scalable platform should the need arise. If you are hosting a mission-critical application and need to move your EJBs from one platform to the other, you can do it without any change in the business-logic code. This allows you to "plug and work" with off-the-shelf EJBs without having to develop them or have any knowledge of their inner workings. EJB provides both a stateless and a stateful model and are packaged as jar files. Since EJB is built on top of Java technology, EJB components can only be implemented using the Java Language.

Caveat Emptor

1. The term "Server" has different connotations in different contexts. There are Web Servers, Application Servers, EJB Servers, Transaction Servers, etc. or, in some casses, even a piece of hardware can be construed as a Server. Unless explicitly mentioned otherwise, when I talk about a Server, I am refering to either an EJB Server, or the MTS runtime host process (mtx.exe) that acts as a Server.

2. A "Resource" can be a anything from a Database, to a File, to a Socket, to an OS Semaphore. So when I refer to a Resource in the write-up, they can mean any of the above, not necessarily only Databases.

3. MTS the acronym - coined more than three years ago - means a lot of different things in different contexts, just as EJB the acronym can at times refer to EJB the packaged component, EJB the enterprise bean class, and EJB the architecture - it all depends on the context. Similarly, MTS the architecture is different from an MTS component or the MTS runtime host process (which is what these MTS components are deployed on).

4. Given that MTS is also an implementation, comparisons must be made with the EJB spec and real EJB implementations. However, since most of these details are hard to come by, and may vary from vendor to vendor, I have tried to point out as much of implementation related stuff in EJBs as I possibly could.

5. An EJB is entirely different from a plain 'vanilla' JavaBean. A JavaBean is more of a client-side component (more akin to ActiveX controls) which can be visually manipulated in a builder tool. However, an EJB resides entirely on the Server-side (just as an MTS or a DCOM component would).

Application Sample - The Checking Account Server and Client

The Checking Account Server component has methods for managing a typical Bank Checking Account. Consequently, it has methods to create an account, and credit & debit money from the Account.

I have selected Java as the implementation language for these examples here for three reasons :

1. EJBs can only be implemented using Java.
2. Since I am comparing EJB with MTS, I should also implement the MTS components in Java for ease of comparison.
3. The Java Language keeps the implementation simple, easy to understand, and is very elegant.

The Background

Middleware components are always deployed on the server side. Each Server will probably service tens to many thousands of client requests at any point in time. The server should be able to scale well and service these calls efficiently from multiple clients. Hence the technology used to build these server components has to provide the features and a framework that will help the developer build scalable middleware server components.

Most client applications spend a long portion of their time waiting for a user to key in some data. If the middleware component on the server were to wait for this data from the user to come in, it would continue to tie up valuble server resources like network connections, processes, threads, memory, and database connections. This means at some point in time sooner than later, the server may not be able to service any more clients since all its resources may be tied down by middleware components waiting for input from their clients.

Both EJB and MTS solve this problem by requiring that the actual middleware components run within a controlled runtime environment. While EJB Components run inside an EJB Container, MTS components run in an MTS Executive. Instance Management Algorithms are used to make sure that these middleware components are not idle and are working to their maximum potential.

Lifecycle and Instance Management

The MTS runtime (mtxex.dll) manages creation, management, and destruction of MTS components. An EJB container creates, manages, and destroys EJB components.

MTS Client - The MTS client code shown below calls into the MTS server object's methods by first acquiring a pointer to the server object. Though it looks simple once implemented, there are a lot of things that happen internal to the Microsoft Java VM. The new keyword here instantiates the bank.Checking MTS Server object. This leads the Microsoft JVM to use the CLSID (obtained from the COM specific class file attributes) to internally make a CoCreateInstance() call. The IUnknown pointer returned by CoCreateInstance() is then cast to bank.IChecking, as shown below. All these are handled internally and automagically by the Microsoft VM and is transparent to the user.

Realize that the object created in the MTS case is a regular Java object, that doesn't require any transaction specific interfaces. In fact, to anyone using the object they don't necessarily even know that it uses transactions.

EJB Client - The EJB client shown below calls into the EJB server object's methods by first acquiring a pointer to the server object. The client first uses the Java Naming and Directory Interface (JNDI) to get a reference to the EJB component's home interface. It then uses this reference to create an instance of the EJB component and holds on to this reference when calling into the component methods. The home interface also allows you to get an object reference that already exists.

In essence, both MTS and EJB work by intercepting method calls and inserting services based on a set of attributes defined at deployment time. MTS uses class factory wrappers and object wrappers to intercept the method calls (the MTS executive is called automatically by the COM runtime). Similarly, EJB requires wrappers for each component type (EJBHome) and each component instance (EJBObject).

Instance Management is about giving an impression to the client that a dedicated middleware component is waiting to service its request. The client has no idea whether such a component instance really exists or not. When a client makes a call to the middle tier component, this call is intercepted by the container. The container now kicks in its Instance Management Algorithm. The Figure 1 below shows the generic architecture of both the EJB and MTS models.

Figure 1: The Generic Architecture

While what happens till now is the same both in the EJB and MTS architectures, the next steps are different. MTS uses an Instance Management Algorithm called Just In Time Activation (JITA). EJB uses an Instance Management Algorithm called Instance Pooling (IP).

Location Transparency

Both MTS and EJB application components are location transparent. A client, at best, may only need to know the DNS name of a Server machine from which to get a reference to the component. It is unnecessary for the client of a component to know the physical location of the component in the file system or on the network. It doesn't matter where a component is - on the local machine or a remote machine, inprocess or out of process and this is a feature of the underlying transport mechanism. If this knowledge is unavailable to the client, it forces a consistent approach for interaction with components. The same exact components can be deployed so that all users can share them. This means that only one set of code needs to be supported for multiple configurations. This lowers the cost associated with maintaining code and it increases deployment choices.

Database Connection Pooling

Generally, a lot of time is wasted establishing a database connection. This means, acquiring a database connection and initializing it - verifying user against system using authentication schemes, logging on to database, etc...- is an expensive operation. So it is always a good idea to create a pool of database connections that can be shared amongst multiple clients.

The Architecture

The MTS model

A basic MTS architecture is shown in the Figure 2 below and is made up of:

The MTS Executive (mtxex.dll)

The Factory Wrappers and Context Wrappers for each component

The MTS Server Component

MTS clients

Auxiliary systems like COM runtime services, the Service Control Manager (SCM), the Microsoft Distributed Transaction Coordinator (MS-DTC), the Microsoft Message Queue (MSMQ), the COM-Transaction Integrator (COM-TI), etc.

Figure 2: The MTS Model

The EJB model

A basic EJB architecture is shown in the Figure 3 below and consists of:

• An EJB server
• EJB containers that run within the server
• Home objects, Remote EJBObjects and Enterprise Beans that run within containers
• EJB clients
• Auxiliary systems like the Java Naming and Directory Interface (JNDI), Java Transaction Service (JTS), Security services, etc.

Figure 3: The EJB Model

 

Distributed Transaction Support

Transactional Model in MTS

In the MTS model, each MTS component declaratively declares its transactional primitives. The MTS runtime environment automatically initiates transactions. For every component, MTS creates a corresponding Context Object that contains information like the transaction identity, the current activity identifier, the security ID of the caller, etc. The Context Object is loaded as part of the MTS Executive (mtxex.dll). In addition to holding the Context Object, the MTS Executive takes part in transaction processing on behalf of the component. The components and the MTS Executive typically execute in a separate host process provided by MTS (mtx.exe). MTS uses OLE Transaction technology to carry out two-phase commit transactions. This model defines three entities in transaction processing:

1. Transaction Client,
2. Transaction Manager - the Microsoft Distributed Transaction Coordinator (MS DTC for short), and
3. Resource Manager - anything that manages persistent, durable resources such as a databases or a files and allows transactional access to the underlying data (e.g., SQL Server).

The Figure 4 below illustrates the transaction model in MTS.

Figure 4: Transactional model in MTS

MTS does a good job of isolating MTS components from the details of how transactions are carried out. The MTS Executive, the Dispenser Manager, and the MS DTC do most of the work required to perform two-phase commit, distributed transactions behind the scenes. To achive this, MTS takes on all the major responsibilities of a Transaction Client and perform such steps as:

• Creating transactions and maintaining the transaction context,
• Instructing MS DTC to commit or abort the current transaction,
• Propagating the transaction context to all participating objects and enlisting the appropriate resources.

Transactional Model in EJB

EJB uses the Java Transaction Service (JTS) and the Java Transaction API (JTA) for transactional support. JTA provides the exceptions and interfaces that the components and clients see. However, it can be expected that many Servers will use JTS for the underlying server provider. However, JTS is actually not a transaction service, but an interface to an underlying transaction service provider. JTS just has one interface and several exceptions. It is clear by looking at its list of exceptions that it was modeled to work with OTS, even though it could be used as an interface to other transaction services as well. The transactional model used in EJB is very similar to OTS. Therefore, understanding how OTS works helps us to understand how transactions work in EJB.

The components that are involved in OTS transactions are:

1. Control
2. Resource
3. Synchronization
4. Terminator
5. Coordinator

These OTS components can be mapped almost directly to EJB transaction components. The Figure 5 below, shows all the objects participating in a transaction. Commits and Rollbacks are applied to all Resource objects in the group.

Figure 5: Transactional model in OTS and EJB

The Control object represents the transaction. From this object, the Terminator and the Coordinator can be obtained. The Control object is used by the EJB Container to manage transactions on behalf of the bean and is transparent to the EJB developer.

The Resource object has transactional state (since it may represent a connection to a database). Calling commit() on this object will will force the updates to be applied to the database. Similarly, calling rollback() on this object will revert all changes to the database since the start of the transaction, to be reverted. Once the commit() or rollback() id done, the corresponding rows in the database will be unlocked. It participates in the two-phase commit protocol and has a vote as to whether the transaction has to be committed or rolled back.

The Synchronization object needs to be notified upon completion of the transaction whether the transaction was committed or rolled back. It is a passive participant in the two-phase protocol and has no vote on the commit or rollback of transactions.

The Terminator object may be used by the EJB container to commit or rollback the transaction when a thread returns from a bean method. When a commit or rollback is requested, all objects in the transaction will committed or rolled back as appropriate.

The Transaction Coordinator object is what co-ordinates all this and makes it all work seamlessly. Both the Resource and Synchronization objects are registered into the transaction using this object. The bean may not get access to this object directly. Transaction-aware objects that are intended for use with the EJB will automatically obtain a reference to the current Transaction Coordinator to register themselves.

In General...,

Distributed transaction management involves two possible layers of distribution: multiple application participants and multiple data resource managers. Each layer must be managed separately. A Transaction Coordinator is responsible for ensuring support for distributed transactions. The director of a transaction is called the transaction manager or Transaction Coordinator. The participants in the transaction that implement transaction-protected resources such as relational database drivers are called resource managers. When an application begins a transaction, it creates a transaction object that represents the transaction. The application then invokes the resource managers to perform the work of the transaction. As the transaction progresses, the transaction manager keeps track of each of the resource managers enlisted in the transaction.

The application's first call to each resource manager identifies the current transaction. Thereafter, all calls made over that connection are performed on behalf of the database transaction until it ends. If the application fails, the Transaction Manager aborts the transaction. When the application successfully completes the transaction's work, it calls the Transaction Manager to commit the transaction. The Transaction Manager then goes through a two-phase commit protocol to get all of the enlisted resource managers to commit.

In a distributed object environment, a single transaction may involve a number of different objects. One object starts the transaction, then it calls some number of methods in other objects to execute the work, then when everything is complete, the object commits the transaction. The transaction context, keeps track of all the object participants in the transaction. When the transaction commits, the commit request is forwarded to a transaction coordinator (TC) to manage the data resource managers. Transaction Coordination can also be delegated to a third party - either the transaction coordinator in a database or a separate distributed transaction coordinator (such as Microsoft's DTC or an XA-compliant transaction coordinator like Encina or Tuxedo). While JTS/OTS focuses on managing the multiple application participants, XA and DTC focus on managing the multiple data resource managers.

The Distributed Transaction Service

The piece in the MTS architecture that is similar to JTS (or OTS) is the MSDTC. The MSDTC provides distributed transaction support in MTS just as OTS does in the CORBA architecture.

Support for Transactions

In MTS, when a client references an MTS component, a Context Object is created. This Context Object provides information to MTS, the client, the MSDTC and other data source drivers involved. The information includes the "Transaction Settings" for the component, which depends on the properties set either when it was deployed on the Server or set programmatically. In addition to calling SetComplete() and SetAbort() methods, a component can always exert control over how transactions work. For example, it can call the DisableCommit() method to prevent the MSDTC from allowing a SetComplete() or SetAbort() method to commit open data store transactions on all resource managers until further notice. When it is ready to commit, it can always call the EnableCommit() method. MTS automatically provides transaction support to applications running on the server, providing a reliable failure isolation and recovery mechanism. Transaction support is transparent to the application programmer. This is a considerable improvement compared to previous generations of transaction processing systems, where developers had to explicitly program low-level transaction control primitives into their applications.

In essence, in MTS, the developer implements the business methods, but doesn't have to implement any callback methods. The developer must code transaction commit and rollback demarcation statements. If everything goes right, the developer must call SetComplete() on the transaction context object. If anything goes wrong, the developer must call SetAbort() on the transaction context object. MTS supports four automatic transaction semantics which may be assigned declaratively. MTS does not support manual transactions.

Similarly, in EJB, the transaction semantics for an enterprise bean are defined declaratively rather than programmatically. At runtime, the EJB container automatically implements transaction services according to the TransactionAttribute specified in the deployment descriptor. In EJB, the developer must define the remote interface, and the developer must implement the business methods and the EJB callback methods (although in many cases they can be left empty). The EJB container deployment tools automatically generate the EJB wrapper objects. Optionally, an EJB developer may deploy a component with "Bean Managed Transaction" specified. In this case the component uses the JTS to manually control its transaction behavior.

Component Types

MTS components have the following characterestics:

• MTS components typically execute on behalf of a single client.
• MTS components may be transaction-aware.
• They can update data in an underlying database.
• They are relatively short-lived, since their lifetime is limited to that of a client call.
• They may be destroyed as soon as they are done processing a client request and the component either calls SetComplete()/SetAbort(), or the transaction that it's part of ends, or the client calls Release() on the component.
• MTS components do not represent data that has to be stored in a database.

EJB components are of two types - Session Beans and Entity Beans:

The characteristics of a Session Bean can be summarized as follows:

• Session EJBs execute on behalf of a single client. A Session Bean instance is an extension of the client that creates it.
• Session beans may be transaction-aware.
• They can update data in an underlying database.
• They are relatively short-lived, since their lifetime is limited to that of their client.
• They may be destroyed when the EJB server crashes. The client has to establish connection with a new Session Bean object to resume any computation.
• Session beans do not represent data that has to be stored in a database.

Every Entity Bean has the following characteristics:

• Entity beans can share access from multiple users.
• They can participate in transactions.
• Entity beans represent data in a domain model.
• They are persistent. They live as long as the data lives in the domain model.
• Entity beans can survive EJB server crashes. Any EJB server crash is always transparent to the client.
• Entity beans have a persistent object reference. The object reference encapsulates the Persistent key for this Bean.

EJB also supports the notion of a component Handle which can be retrieved from a component (session or entity), stored in a data store, and later retrieved and re-hydrated to re-establish the connection to the component.

Portability

MTS components only interoperate on Windows NT, since as I said earlier, it is a middleware model for Windows NT. That acknowledged, however, since the MTS Executive is developed by Microsoft and there are no other servers which can run MTS components, there are no portability issues for MTS components when they are moved between servers (Every Server is from the same vendor). However, COMTI technology allows some third party transactions to participate with MTS and vice versa.

EJB portability can be discussed by dividing the discussion into two -

1. platform level portability and
2. portability between the different EJB Servers/Containers.

Since EJB components are developed using Java, there is no platform level portability issues (as long as you are using a JVM that supports JDK1.1 and above and its extensions) since Java programs are supposed to run seamlessly from one platform to the other.

However, the same cannot be said about portability of EJB components between EJB Servers. For one, the interfaces between the Containers and Servers have been left open in the EJB Specification. Portability between EJB servers is higher for bean managed persistence than container managed. In container managed persistence, the mapping between the components and the datastore is done through a vendor provided provisioning tool, and this aspect of the specification is open. Deployment to another EJB server will certainly require re-provisioning, but the component's implementation code is probably ok.

Similarly, until the EJB 1.1 specification came in (also called the Moscone release of the EJB spec), there was no common way of defining deployment descriptors and each vendor had their own proprietary way of defining them thus making deployment on multiple different Servers a hassle since the deployment descriptors had to be modified to suit each Server. If vendors do'nt move on to support EJB 1.1, CMP entity beans may not be portable and their servers will be non-EJB 1.1 compliant.

A reference implementation and a compatibility test suite from JavaSoft will go a long way in mitigating this problem.

Interoperability

MTS components can be invoked from other machines by clients using DCOM or through local COM if they reside on the same machine. For communication through HTTP, clients can always talk to MTS servers through the Microsoft Internet Information Server (IIS) which is the Web Server built into Windows NT. Clients wishing to use the CORBA/IIOP protocol communicate with the server component through a COM-CORBA bridge. COMTI technology allows some third party transactions to participate with MTS and vice versa. Similarly the integration of MTS and MSMQ helps to provide asynchronous messaging in MTS.

EJB components can be invoked from other machines by clients using RMI/JRMP or RMI/IIOP. While the EJB spec allows the EJB server implementors to use any communication protocol between the client and server, the EJB/CORBA mapping document is prescriptive with respect to what goes on the wire. This allows both system-level and application-level interoperability between products from vendors who choose to implement the EJB/CORBA protocol as the underlying communication protocol.

EJB clients will optionally communicate with server components using IIOP. Java EJB clients will have a choice of APIs – either the Java RMI or the Java mapping of the CORBA IDL interface. Non-Java clients communicate with the server components using IIOP and the appropriate language mapping. Clients wishing to use the COM+ protocol communicate with the server component through a COM-CORBA bridge. Also realize that the client of an EJB can itself be a server component (eg., a servlet), so an HTTP-only web client can use a servlet to make EJB invocations.

RMI/IIOP is trivially easy to do. However, RMI/JRMP is a simple protocol to do simple things. It needs to change and look an awful lot like IIOP and CORBA when it's finally mature. It thus comes down to what is missing from JRMP that is present in IIOP. In JRMP for example, it is impossible to transparently add support for distributed transactions, security, etc. The protocol simply doesn't support the addition of information to the message on the client end, and the support for retrieving this information on the server side. This means that any system built using JRMP has to deal with transactions and security as part of the message, rather than as part of the context of the message, which is added, modified and interpreted by services that are neither the client nor the server.

State Management

Every transactional application makes changes to one or more databases based on some input from a client or user. If the transaction commits, the database changes are made permanent. However, if the transaction fails and aborts, these changes are rolled back.

MTS uses a stateless model to ensure database consistency. Stateless models are essentially stored procedures that operate on the database state. There is no state that is kept between calls on the stored procedure, so as soon as that procedure has finished its task, you can just throw everything away, and start off on a clean slate.

This is an extremely old model that has served extremely well. This is why every database in the world has some sort of stored procedure language that runs right in the sql process and is tuned for database operations, and is good about transient state between calls (i.e., the database call is a central part of the memory management). The stateless model ensures the consistency of the database's state which is the primary goal of a transaction processing system.

MTS provides a mechanism called Shared Property Managers that makes it easy to share data among multiple concurrently executing objects without forcing the developer to program complex state sharing and synchronization logic. This state management in MTS, provides data type state management.

MTS components are essentially stateless components. MTS ensures database consistency by using such a stateless model. When a component completes its work and invokes SetComplete() or SetAbort(), MTS deactivates that component. Even though clients still retain their references to these components, MTS, transparent to the client, silently re-creates another instance using its Just In Time Activation (JITA) algorithm, the next time the client invokes a method on the component. MTS components participating in a transaction are not allowed to maintain any in-memory state across transactional boundaries. Thus, any state that the component had is destroyed by the time the transaction ends and so must be refreshed from a reliable source (e.g., the shared property manager, the client or the database) when it is next needed. This mechanism guarantees that the next transaction will always use the right state values of the component.

EJB handles state management and uses both the stateless and stateful models to ensuring database consistency. If a session bean is stateless, the container may automatically reset the state within that component after each method call. If the session bean component is stateful, the container may automatically maintain the component's state until the component is destroyed, even if it is temporarily evicted from memory. A session bean represents work performed by an individual client. This work may either span just one single method call or may require multiple method calls. If the work spans multiple method calls, the component state must be maintained between calls. The state management options for a session bean are defined in the StateManagementType attribute in the deployment descriptor. All entity beans are inherently stateful. The EJB model uses methods like ejbLoad(), ejbStore(), ejbActivate() and ejbPassivate() to handle state management in each EJB class.

Persistence Management

MTS components are not persistent, even though they may contain information that needs to be persisted. MTS doesn't directly support the idea of a persistent component model. If the need arises (which may be extremely rare), the component developer needs to invent and implement his own persistence management algorithm in the component, allowing the component to read or write data to the database as needed. Thus if the need arises, the developer has to manually code the mapping of an MTS component call to database interaction.

EJB has two types of components -- persistent (entity beans) and non-persistent (session beans). An entity bean represents persistent data. Each entity bean is long lived -- as long as the associated data exists in the domain model. Each entity bean may be shared by multiple clients. The EJB spec defines a programming model for implementing persistence management in an EJB component. Whenever components are created or destroyed, or whenever components are loaded or evicted from memory, Persistence management algorithms acts on the component. The EJB spec defines methods like ejbCreate(), ejbPostCreate(), ejbRemove(), ejbLoad(), ejbStore(), ejbActivate(), and ejbPassivate() to handle persistence management in each EJB class. The ContainerManagedFields attribute in the deployment descriptor defines the persistence management option for an entity bean.

Persistence management in Entity beans are of two types. When the bean manages its own persistence, its called Bean Managed Persistence (BMP). When the bean delegates the task of Persistence Management to its container, it is called Container Managed Persistence (CMP).

In Bean Managed Persistence, the enterprise bean has to implement persistence operations directly in the bean class methods using JDBC or embedded SQL calls.

In Container Managed Persistence, the entity bean delegates persistence management to the container so that the EJB container can implicitly and transparently manage persistence for the entity bean. This means that instead of the bean developer having to code JDBC and embedded SQL calls into the bean, these database calls can be generated and handled by the EJB container. The EJB spec does not define how the container has to manage persistence and leaves the implementation details to the container tools vendor.

Session beans are very similar to MTS components in that they are not inherently persistent. However, if they need to implement persistence management, they can implement their own within the methods of the bean. The bean can also implement transaction synchronization code directly in the bean using the SessionSynchronization interface. They can use notification methods such as afterBegin(), beforeCompletion(), and afterCompletion() to signal transaction demarcation points, allowing the component to read or write data to the database as needed.

Resource Management

The MTS runtime implements different policies to manage scarce resources such as memory and threads. This enables components to operate automatically in a multi-user environment without forcing developers to build this complexity into their applications.

The EJB Server implements different policies to manage scarce resources such as memory and threads. Some EJB Servers may maintain all components in memory, while others may evict every component after every method call. Some Servers may even use a least-recently-used algorithm to evict components when the resources get tight.

Security

Both MTS and EJB allow setting a component's security requirements to be set by an administrator.

MTS provides a distributed security service that is integrated with Windows NT security. This allows developers to prevent unauthorized access to business applications, even if the application includes components purchased from third parties. MTS also provides standard graphical tools that allows an administrator to set the component's security requirements. Distributed security services are provided by the NT Lan Manager (NTLM) security protocol supported by both Windows and Windows NT. The administrator is allowed to graphically administer authorization and restrict access to secure objects and methods. The administrator can thus, using the GUI tools supplied, graphically associate a method with a list of users that have rights to invoke a method.

EJB provides authorization using the Java security model. EJB server implementations may choose to use connection-based authentication in which the client program establishes a connection to the EJB server. The client's identity is attached to the connection at connection establishment time. The EJB/CORBA mapping specifies that the CORBA Principal propagation mechanism be used. This means that the client ORB adds the client's principal to each client request. The communication mechanism between the client and the server propagates the client's identity to the server. Security in EJB 1.1 is declaratively defined in the deployment descriptors and is role based.

Java platform security supports authentication and authorization services to restrict access to secure objects and methods. The security rules for each EJBean are defined declaratively in a set of AccessControlEntry objects defined in the deployment descriptor. An AccessControlEntry object associates a method with a list of users that have rights to invoke a method. The EJB container uses the AccessControlEntry attribute to perform all security checks on behalf of the enterprise bean.

Deployment

Both MTS and EJB models support Application Partitioning. Administrators can easily partition an application across multiple servers by deploying an application’s components into several packages, with each package running on its own server. This improves system fault isolation, while increasing application performance and scalability.

MTS includes a component packaging service that manages the complicated logistics of integrating, installing, and deploying many components as a single application. In addition to this, using MTS packages, developers and administrators can easily isolate components so they operate in their own system process. This is called Process Isolation. This provides an additional level of failure isolation and data protection.

EJB components can be packaged as individual enterprise beans, as a collection of EJBs, or as a complete application system. EJB components are distributed as jar files. The jar file contains a manifest file outlining the contents of the file, the enterprise bean class files, the Deployment Descriptor objects, and optionally the Environment properties. Deployment Descriptors defined in XML, specify the runtime settings for the EJB. The settings can be set at application assembly or deployment time.

The Source Code Comparison

The source code comparison which follows tries to build a three-tiered Checking account application, with the client tier, a middleware component tier (of either an MTS or an EJB component) and a database as shown in Figure 6:

Figure 6: Our Example three-tier Bank Checking Account Application

The Interface Definition Code Comparison

The Interface

Whenever a client needs some service from a remote distributed object, it invokes a method implemented by the remote object. The service that the remote distributed object (Server) provides is encapsulated as an object and the remote object's interface is described in an Interface Definition Language (IDL). The interfaces specified in the IDL file serve as a contract between a remote object server and its clients. Clients can thus interact with these remote object servers by invoking methods defined in the IDL.

MTS - The IDL file shows that our MTS server implements a dual interface. COM supports both static and dynamic invocation of objects. For the static invocation to work, The Microsoft IDL (MIDL) compiler creates the proxy and stub code when run on the IDL file. These are registered in the systems registry to allow greater flexibility of their use. This is the vtable method of invoking objects. For dynamic invocation to work, COM objects implement an interface called IDispatch. As with CORBA or Java/RMI, to allow for dynamic invocation, there has to be some way to describe the object methods and their parameters. Type libraries are files that describe the object, and COM provides interfaces, obtained through the IDispatch interface, to query an Object's type library. In COM, an object whose methods are dynamically invoked must be written to support IDispatch. The MTS IDL file also associates the IChecking interface with an object class Checking as shown in the coclass block. Also notice that in MTS, each interface is assigned a Universally Unique IDentifier (UUID) called the Interface ID (IID). Similarly, each object class is assigned a unique UUID called a CLasS ID (CLSID). COM gives up on multiple inheritance to provide a binary standard for object implementations. Instead of supporting multiple inheritance, COM uses the notion of an object having multiple interfaces to achieve the same purpose. This also allows for some flexible forms of programming.

The Checking Account Server component has methods for managing a typical Bank Checking Account. Consequently, it has methods to create an account, and credit & debit money from the Account. Consequently, we define different methods like createAccount(), credit(), debit(), getBalance() and getCustomerName().

EJB - Notice that unlike MTS, EJB uses a .java file to define it's remote interface. This interface will ensure type consistency between the EJB client and the EJB Server Object. Every remotable server object in EJB has to extend the javax.ejb.EJBObject class. Similarly, any method that can be remotely invoked in EJB may throw a java.rmi.RemoteException. java.rmi.RemoteException is the superclass of many more RMI specific exception classes. We define an interface called Checking which extends the javax.ejb.EJBObject class. Also notice that all the remote methods like createAccount(), credit(), debit(), getBalance() and getCustomerName() throw a java.rmi.RemoteException.

 

The Component Implementation Code Comparison

Implementing the Server Component

MTS server component- All the classes that are required for Java/COM are defined in the com.ms.com package. The com.ms.mtx package contains all the MTS related class definitions. The com.ms.wfc.data package contains all the ADO related class definitions. The MTS Server object shown below implements the IChecking interface that we defined in our IDL file. Implementation code for the different methods like createAccount(), credit(), debit(), getBalance() and getCustomerName() are also shown.

In MTS, the developer implements the business methods, but doesn't have to implement any callback methods. The developer must code transaction commit and rollback demarcation statements. If everything goes right, the developer must call SetComplete() on the transaction context object. If anything goes wrong, the developer must call SetAbort() on the transaction context object. MTS supports four automatic transaction semantics which may de assigned declaratively. MTS does not support manual transactions.

EJB server component- All the classes that are required for Java/RMI are defined in the java.rmi package. The javax.ejb package contains all the EJB related class definitions. The java.sql package contains all the JDBC related class definitions. The EJB Server object shown below implements the SessionBean interface since its a session bean. Implementation code for the different methods like createAccount(), credit(), debit(), getBalance() and getCustomerName() are also shown.

In EJB, the transaction semantics for an enterprise bean are defined declaratively rather than programmatically. At runtime, the EJB container automatically implements transaction services according to the TransactionAttribute specified in the deployment descriptor. In EJB, the developer must define the remote interface, and the developer must implement the business methods and the EJB callback methods (although in many cases they can be left empty). The EJB container deployment tools automatically generate the EJB wrapper objects.

 

The Client Code Comparison

Implementing the MTS/EJB Client

Both the EJB and MTS clients have been implemented using Java code using the Visual J++ version 6.0 compiler.

MTS Client - The MTS client shown below calls into the MTS server object's methods by first acquiring a pointer to the server object. The new keyword here instantiates the bank.Checking MTS Server object. This leads the Microsoft JVM to use the CLSID to make a CoCreateInstance() call. The IUnknown pointer returned by CoCreateInstance() is then cast to bank.IChecking, as shown below.

EJB Client - The EJB client shown below calls into the EJB server object's methods by first acquiring a pointer to the server object. The client first uses JNDI to get a reference to the EJB component's home interface. It then uses this reference to create an instance of the EJB component and holds on to this reference when calling into the component methods.

Conclusion

The architectures of MTS and EJB provide mechanisms for developing distributed enterprise components. Though the mechanisms that they employ to achieve their objective may be different, the approach each of them take is more or less similar.

The Sources

Download the MTS and EJB implementations of the Bank Checking Account as a zip file