Sunday, December 13, 2015

WSO2 ESB EJB 2.x Connector

Enterprise JavaBeans is an architecture for transactional, component-based distributed computing. The specification for EJBs lays out not just the format of a bean itself, but also a set of services that must be provided by the container in which the bean runs. This makes EJBs a powerful development methodology for distributed application development. Neither the bean developer nor the client application programmer needs to be concerned with service details such as transaction support, security, remote object access, and many other complicated and error-prone issues. These are provided transparently for the developers by the EJB server and container.

The effect of the EJB architecture is to make server-side development much easier for the Java application programmer. Since the implementation details are hidden from the developer, and since services such as transaction support and security are provided in an easy-to-use manner, EJBs can be developed relatively quickly. Furthermore, EJBs offer portability. A bean that is developed on one EJB server should run on other EJB servers that meet the EJB specification. Portability has not been tested yet for most servers, but it is a bright promise for the future. for more..

EJB2 Connector

EJB2 Connector used to create a client Dynamically from the esb Configuration and if method is not a void method then it will add the return value into messagecontext property. it’s have two methods called Stateless bean and Stateful bean. and EJB2 Connector will support with multiple Servers and its tested with Jboss 5.1 and GlasFish 4. before start the ESB copy the client libraries and service jar inside the component->Lib folder.

Operation details

  • Init Operation
  • Stateless Bean
  • Stateful Bean
This section provides further details on the operations related to theEJB2 connector.

Init Operation

init method will contain JNDI Naming Property and in order identify correct property we need to set key value and property value name should be start with that key name. these values are depend on the backend server we are using above one is example for glassfish 4


  • key: unique identifier for each context
  • key.{name}: this depend on server properties and configuration(property value name)
  • key.{name}.Value:value of the key.{name}(property value)

Stateless Bean

A stateless session bean is a session bean with no conversational state. All instances of a particular stateless session bean class are identical.
A stateless session bean and its client do not share state or identity between method invocations. A stateless session bean is strictly a single invocation bean. It is employed for reusable business services that are not connected to any specific client, such as generic currency calculations, mortgage rate calculations, and so on. Stateless session beans may contain client-independent, read-only state across a call. Subsequent calls are handled by other stateless session beans in the pool. The information is used only for the single invocation.
OC4J maintains a pool of these stateless beans to service multiple clients. An instance is taken out of the pool when a client sends a request. There is no need to initialize the bean with any information.

Stateless Bean

  • method: name of the method.
  • param.arg{X}:this will be name of the arguments and it want to be in a flow like param.arh1,key,arg2..
  • jndiName: Java API for a directory service.

Stateful Bean

A stateful session bean is a session bean that maintains conversational state.
Stateful session beans are useful for conversational sessions, in which it is necessary to maintain state, such as instance variable values or transactional state, between method invocations. These session beans are mapped to a single client for the life of that client.
A stateful session bean maintains its state between method calls. Thus, there is one instance of a stateful session bean created for each client. Each stateful session bean contains an identity and a one-to-one mapping with an individual client.
When the container determines that it must remove a stateful session bean from memory (in order to release resources), the container maintains the bean's state by passivation (serializing the bean to disk). This is why the state that you passivate must be serializable. However, this information does not survive system failures. When the bean instance is requested again by its client, the container activates the previously passivated bean instance.
The type of state that is saved does not include resources. The container invokes the ejbPassivate method within the bean to provide the bean with a chance to clean up its resources, such as sockets held, database connections, and hash tables with static information. All these resources can be reallocated and re-created during the ejbActivate method.
If the bean instance fails, the state can be lost, unless you take action within your bean to continually save state. However, if you must make sure that state is persistently saved in the case of failovers, you may want to use an entity bean for your implementation. Alternatively, you could also use the SessionSynchronization interface to persist the state transactionally.

Stateful Bean

  • method: name of the method
  • param.arg{X}:this will be name of the arguments and it want to be in a flow like param.arh1,key,arg2..
  • jndiName:Java API for a directory service.

Sample configuration

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns=""
         <property name="argument1" expression="json-eval($.argument1)"/>
         <property name="argument2" expression="json-eval($.argument2)"/>
         <property name="method" expression="json-eval($.method)"/>
         <property name="jndiName" expression="json-eval($.jndiName)"/>
         <property name="return" expression="json-eval($.return)"/>
            <property name="out" expression="get-property('Result')"/>
            <payloadFactory media-type="json">
                 <format>{ "Result": $ctx:out}</format>