General Overview

Typically an EJB deployment consists of gateways and providers. All of them are implemented as stateless session beans. It is most efficient that all beans are linked together using local EJB references.

All providers and gateways have the following EJB interfaces which are generic openMDX interfaces. These common generic interfaces are used by the transport layer to access the features of the desired gateway or provider instances.

• the remote interface org.openmdx.compatibility.application.dataprovider.transport.ejb.cci.Dataprovider_1_0Remote

• the local interface org.openmdx.compatibility.application.dataprovider.transport.ejb.cci.Dataprovider_1_0Local

• the home interface org.openmdx.compatibility.application.dataprovider.transport.ejb.cci.Dataprovider_1Home

• the local home interface org.openmdx.compatibility.application.dataprovider.transport.ejb.cci.Dataprovider_1LocalHome

With the exception of gateway_NoOrNew all gateways and providers use container-managed transactions. For this reason it is recommended to use the naming suffixes Mandatory, Supports and Never. These gateway/provider naming conventions reflect the standard EJB transaction attribute settings used for beans that are using container-managed transactions. Since gateway_NoOrNew uses bean-managed transactions, there is no EJB transaction attribute setting available. It is recommended to use the suffix NoOrNew because this reflects the transaction behaviour of this gateway.

You will find more information on these settings in the subsequent sections.

The figure Figure 7-1 shows a typical gateway/provider setup.

A typical setup consists of three gateways: gateway_NoOrNew, gateway_Mandatory and gateway_Never. These gateways represent the client view of the subsequent providers. They are responsible for routing incoming client requests to the desired providers. For clients gateway_NoOrNew is the most important gateway. It acts as the entry point for clients (client 2 and client 3) to access their associated providers.

The task of gateway_NoOrNew is to set transaction demarcations. A client calls gateway_NoOrNew within a UnitOfWork. Depending on whether it is transactional or not, gateway_NoOrNew will begin a new transaction.

• If the UnitOfWork is transactional, gateway_NoOrNew will begin a new transaction and route the request to the subsequent gateway gateway_Mandatory from where it is routed to the desired provider.

• If the UnitOfWork is non-transactional, gateway_NoOrNew will not begin a new transaction and route the request to the subsequent gateway gateway_Never from where it is routed to the desired provider.

Generally, gateway_NoOrNew is not called in a transactional context itself (client 2). A typical client calls gateway_NoOrNew within a UnitOfWork but not within a transactional context. But if a transactional client (client 3, e.g. a provider which delegates to another provider in a transactional context) calls gateway_NoOrNew, the incoming transaction is suspended. Again gateway_NoOrNew decides then, depending on whether the incoming UnitOfWork is transactional or not, to which subsequent gateway the request is going to be routed to. It is important to know however that usually delegating providers call their subsequent providers directly.

In the case where clients initiate transactions on their own (client 1), e.g. message driven beans or batch clients, gateway_Mandatory can be called directly. This avoids that the incoming transaction is suspended.