Showing posts with label EJB. Show all posts
Showing posts with label EJB. Show all posts

Thursday, 12 September 2013

EJB Patterns: Service Facade example

This article shows the common Service Facade pattern in the EJB context. Several aspects takes into account this pattern.

 

1) The Service Facade insolates the service definition from its implementation.

2) It is the way of decoupling the Web tier from the Business tier.

3) From a transactional point of view, the business service may implement his transaction scope or be part of the current transaction.

4) The contract of the Service Facade interface is oriented to be invoked by Web tier or client software, but methods of the contract should not be invoked within the business implementation.

The following is an example of this pattern.

Firstly, an interface with the contract definition is defined:

@Local

public interface FarewellBusiness {

      public void sendMessage(String message);

      public void sendMessageDetail(String message,String detail);

     

}

 Secondly, a class that implements this interface is created. This class is the Stateless bean that will be managed by the JEE-container.

@Stateless (name="farewellBusiness")

@Clustered

@TransactionAttribute (TransactionAttributeType.REQUIRES_NEW)

public class FarewellBusinessBean implements FarewellBusiness {

 

      @Inject FarewellBusinessLogic business;

      public void sendMessage(String message) {

           

           

            business.sendMessage(message);

     

      }

      public void sendMessageDetail(String message,String detail)

      {

            business.sendDetailForMessage(message, detail);

      }

 

}

As the class reflects :

@Stateless: It is a stateless java bean.

@Clustered: It is executed within a JBoss cluster (for instance)

@TransactionAttribute (REQUIRED_NEW). Invocations of methods of this class require a transaction scope. If there is already a transaction scope running, the instance is executed under the transaction scope, if not; a new transactional process is created.

The invocation of the EJB is by way of the Service Interface, as the example below shows:

@ManagedBean (name="manager")

@SessionScoped

public class ManagerBean implements Serializable{

            @ManagedProperty(value="#{farewell1}")

            FarewellBean bean;

           

            @EJB

            FarewellBusiness farewellBusiness;

           

            public String send(){

                                    // send the message invoking business ejb

                 

                  farewellBusiness.sendMessage(bean.getFarewell1());

                  return "success";

            }

            public void setBean(FarewellBean bean) {

                  this.bean = bean;

            }

            public String sendDetail(){

                  farewellBusiness.sendMessageDetail(bean.getFarewell1(), bean.getDetail());

                  return "success";

            }

           

}

 

Sunday, 1 September 2013

JBoss AS 7.1.1.Final. EJB Pooling.

This article shows how to stablish the EJB instantiation in JBoss 7.1.1.Final. From a performance point of view, it must be thought how many instances of a stateless bean must be alive at the same time along the application lifecycle.

This article is focused on the standalone JBoss execution mode.

In order to change the maximum number of instances that the application server manage, the following part of the JBOSS_HOME\standalone\configuration\standalone.xml must be changed:

<subsystem xmlns="urn:jboss:domain:ejb3:1.2">

            <session-bean>

                <stateless>

                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>

                </stateless>

                <stateful default-access-timeout="5000" cache-ref="simple"/>

                <singleton default-access-timeout="5000"/>

            </session-bean>

            <pools>

                <bean-instance-pools>

                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="10" instance-acquisition-timeout="1" instance-acquisition-timeout-unit="MINUTES"/>

                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>

                </bean-instance-pools>

            </pools>

      The strict-max-pool tag has two properties:

·         name: Specify the pool of the stateless beans if the value is “slsb-strit-max-pool-size”.

·         max-pool-size specify indeed, the number of max bean instances.

How the application server instantiates the several instances?

It has its own strategy for doing so. That is to say, the bean instances are not created eagerly but they are created by demand, when JBoss considers.