A common strategy to shield the presentation tier from the persistence tier is to model the services in between. These services implement the business logic in the application tier. In the EJB3 cartridge, these services are stateless or stateful session beans.
To create a service you just create another class and model the <<Service>> stereotype on this class.
Most of the time you only model operations in these services which represent the operations that can be called remotely (default view type). The EJB3 cartridge allows you to specify local operation or even both. These operations are the API of your application's back-end.
The following illustrates the use of a service bean that operates on the 2 entities. Notice how we have modeled dependencies from the service to the entities. This will render the getter accessor to the DAOs of both entities in the service and inject the corresponding DAO (stateless session bean containing CRUD API for entity).
Drawing these dependencies indicates the need to access the persistent storage of entities via the persistence entity manager injected in the DAO that handle this task and eliminates much of the complexity.
There are a few other things you can do with these services, these features will be presented in the sections ahead.
The RentalServiceBase.java injects the javax.ejb.SessionContext by default and makes this available for use in the subclass via the context protected attribute.
The default persistence context is injected into the Entity Manager. This is defined via the @javax.persistence.PersistenceContext annotation in RentalServiceBase.java. The unitName property matches the entity manager name in persistence.xml and is determined from the project name for the default persistence context.
By default, if a session bean does not have any instance attributes, then it is by definition a Stateless session bean since there are no attributes to maintain state between bean method invocations.
If you model an instance scoped attribute on the bean, the EJB3 cartridge will declare this session bean as a Stateful session bean in the ejb-jar.xml deployment descriptor.
If you wish, you can override this feature by modeling the andromda_service_type tagged value on the session bean class.
Stateless session beans that are JBoss Seam components do not follow the above rule. If your class is modeled as a Seam component and you have modeled attributes on this class, it will not be rendered as a stateful session bean, unless you specify the andromda_service_type tagged value.
By default, the EJB3 cartridge creates and registers a remote view interface which implies that the client view of the session bean is location-independent. In this case, the session bean and the client can exist in different JVMs on the same or different machines.
To create a local view interface and register this with the container, you model the andromda_ejb_viewType on the session bean operation or at the class level of the session bean. Your options are:
If you have operations that exist in both the local and remote interfaces, your service delegate class will allow you to select how you want to invoke your bean operations.
To declare the transactional nature of session bean business methods, you can model the andromda_ejb_transaction_type tagged value on the session bean business methods individually, or on the session bean class. To find out more information, click on Transaction.
The EJB3 cartridge provides the ability to set security constraints to allow role based security when accessing and invoking session bean business operations. To find out more information, click on Security.
To inject an environment entry resource value, model a service attribute with classifier scope and set the attribute stereotype to <<EnvEntry>>. The environment entries will be defined in the session bean class and configured in the ejb-jar.xml deployment descriptor. You must define a default value for these attributes in the model. Refer to Environment Entry Injections for further information.
If you want an operation to have a parameter which is allowed to be null then simply assign the <<Nullable>> stereotype to that parameter.
As you saw in the example in this howto, a session bean delegate class is generated for every session bean. A client invokes the session bean's business methods via the delegate class, acting like a proxy via the service locator class.
Both the service delegate and service locator classes are re-generated every time AndroMDA is run. You can find out more information about session delegates from here.
In some cases, setting up lifecycle event callbacks for the session bean can be quite useful. The EJB3 cartridge provides the facility to define these callback methods in the listener class. This class if NOT generate by default. To find out more information, click on Listener Callback.
You can intercept calls to session bean business method invocations via an interceptor class. By default, this class is NOT generated. To find out more information, click on Interceptors.
The container will supply default JNDI bindings for the remote and local interface of the session bean. By default, JBoss will use ejbName/local and ejbName/remote for the local and remote interfaces, respectively. Other providers will do something similar.
You can override the default JNDI bindings. To specify the JNDI name of the local interface bound to the session bean, model the andromda_service_jndi_local tagged value on the session bean class. To specify the JNDI name of the remote interface bound to the session bean, model the andromda_service_jndi_remote tagged value on the session bean class.
The EJB3 cartridge derives a default persistence context associated with the default entity manager for every session bean. The persistence context unitName property is determined via the persistenceContextUnitName namespace property which is provided via your application andromda.xml descriptor.
Every session bean provides the facility to override the default persistence context annotation declaration by modeling the following tagged values on the session bean class:
andromda_service_persistence_context_unit_name Override the unit name for the default persistence context.
andromda_service_persistence_context_unit_type Specify whether a transaction scoped or extended scoped persistence context is required for the persistence context associated with the default entity manager.
To inject another persistence context, associated with a different entity manager, you need to model a new class with the <<PersistenceContext>> stereotype and draw a dependency from the session bean to the this new class. The entity manager attribute declaration will use the class name as the attribute name. To define the properties of the persistence context annotation, you need to model the above tagged values on this new class.
The following example shows a new persistence context securityEntityManager.
Notice that SecondaryEntityManager has defined the andromda_service_persistence_context_datasource tagged value specifying the JNDI name of the JDBC datasource used in this persistence context. You can specify this tag on a class where the <<PersistenceContext>> stereotype has been modeled.
To inject another session bean into the current session bean, simply model a dependency from the source session bean (which will contain the @javax.annotation.EJB annotation) to the target session bean. For more information on dependency injections, click here.
The EJB3 cartridge provides the facility to develop message driven beans. To find out more information, click on message driven beans.
Once you have modeled the MDB with <<MessageDriven>> stereotype, you can model a dependency from the source session bean to the MDB. This will render the appropriate @javax.annotation.Resource injections associated with JMS specific objects such as QueueConnectionFactory, TopicConnectionFactory and the Destination object.
To setup a timeout callback and use the EJB Timer Service, just model the <<Timeout>> stereotype on a session bean operation. This will render the @javax.ejb.Timeout annotation on the operation. Every session bean injects SessionContext with the @javax.annotation.Resource annotation which allows registration of the timer with the EJB Timer Service.
In the next section we'll learn about composite primary keys, click here to continue.