Introduction to JBoss Seam

1) Introduction

Yet another Web Application Framework! This time it is from JBoss Community. JBoss provides a new Web Application Framework called "JBoss Seam" which combines the advantages from the two rapidly growing technologies Enterprise Java Beans 3.0 and Java Server Faces. JBoss Seam, by sitting on top of J2EE provides a nice way of integration between JSF and EJB Components with other great functionalities. This article is an introductory article only and it covers the idea that gave birth to JBoss Seam, its advantages, the various modules involved along with a Sample Application. This article assumes the readers to have some bit of knowledge and programming in areas like Java Server Faces and Enterprise Java Beans 3.0. For more information about these technologies, visit http://jsf.javabeat.net/index.php and http://www.javabeat.net/javabeat/ejb3/index.php.

2) The Need for JBoss Seam

Let us exactly define what JBoss seam is. JBoss Seam provides a Light-weight Container for J2EE standards and it addresses the long-standing issues in any Typical Web Application like State Management and Better Browser Navigation. It also neatly provides an integration between the two popular technologies, Java Server Faces (in the UI tier) and Enterprise Java Beans (EJB 3 in the Server Side). Before getting into the various details about JBoss Seam let us see the common set of problems that are being faced in a Development and the Usability of a typical Web Application using Java Server Faces and Enterprise Java Beans.

For this, let us assume an imaginary application. Let us keep the requirements of the imaginary Web Application we are going to consider very small. The Web Application is a simple Registration Application, which provides the user with a View which contains username and password text-fields. User can click the submit button after filling both the fields. If the username password information given by the user is not found in the database, the user is assumed to be a new user and he is greeted with a welcome message; else an error page is displayed with appropriate message.

Let us analysis the roles of JSF and EJB 3.0 in this Web Application. More specifically, we will analysis the various components in both the client as well the server tier along with their responsibilities.

In the Client side, for designing and presenting the form with the input controls (text-field and button) to the user, we may have written a userinput.jsp page with the set of JSF core tag libraries like <f:view> and <h:form>. And then, a JSF Managed Bean called UserBean encapsulated with properties(username and password) may have been coded which serves as a Model. The UI components values within the JSP page would have got bound to the properties of the Managed Bean with the help of JSF Expression Language. Since the logic is to query from the database for the existence of the username and the password, a Stateless Session Facade Bean would have been written whose sole purpose is to persistence the client information to the database. For persistence the information, the Session Bean may depend on the EntityManager API for querying and persisting entities.

The Data Traversal Logic from JSF to EJB Session Bean should have be taken care by the Managed Bean only. The Managed Bean apart from representing a Model may also act as a Listener in handling the button click events. Say, after clicking the register button, one of the action methods within the Managed Bean would have been called by the framework, and here the Bean might have a JNDI Look-up to get an instance of the Session Bean to persisting or querying the user information. If we look at carefully, the JSF Managed Bean is serving as an intermediary between the transfer of Data from the Client to the Server. Within this Managed Bean is the code for getting a reference to the Session Bean for doing various other functionalities. Wouldn't a direct commnication between JSF UI Components and the Enterprise Bean Components be nice? There is no purpose of the intermediate Managed Bean in this case. JBoss Seam provides a very good solution for this. Not only this many of the outstanding problems that are faced in a Web Application are also addressed and given solution in this Framework.

3) Advantages of JBoss Seam

Following are the major advantages that a Web Application may enjoy if it uses JBoss Seam Framework. They are

• Integration of JSF and EJB
• Stateful Web Applications
• Dependency Bijection Support

Let us look into the various advantages of JBoss Seam in the subsequent sections.

3.1) Integration of JSF and EJB

Today the Web Application World see more and more matured technologies that are focusing to establish an easy-to-use development by reducing lots and lots of boiler-plate code along with some other added functionalities in their own domains. Let us consider JSF and EJB technologies to extend further discussion regarding this.

EJB 3.0 which is a specification given from Sun has gained much popularity because of its simplified yet robust programming model. Much of the middle-ware related services like Security, Transactions, Connection Pooling etc is delegated to the container itself. Comparing to its predecessors, EJB 3.0 offers a POJO programming Model. No need for your beans to extend or implement EJB specific classes or interfaces. And also, along with the new specification Java Persistence API (JPA) http://www.javabeat.net/javabeat/ejb3/articles/2007/04/introduction_to_java_persistence_api_jpa_ejb_3_0_1.php, an unified programming model to access the underlying database along with rich set of features are now possible thereby completely eliminating the heavy-headed entity beans.

Java Server Faces provides a Component-based approach for developing User Interface Components in a Web Application. It hides most of the boiler-plate code and provides a higher-level abstraction over the client request and the server response objects. Using Java Server Faces, a Web Application can be viewed by components making events and listeners executing the appropriate logic for the Events. No need for the traditional HttpServletRequest and HttpServletResponse object to extract the client input parameters and to generate the response.

JBoss provides a framework in which the Events that are emitted by the JSF UI Components can be directly handled by the Enterprise Beans. No need for the intermediate Managed Beans which establishes the data transfer from and to JSF and EJB.

3.2) Dependency Bijection Support

Before getting into Dependency Bijection, it is wise to look at the two types: namely Dependency Injection and Dependency Outjection. These two are the popular patterns and modern Frameworks and Containers makes use of this abundantly. Let us see these two techniques

3.2.1) Dependency Injection

This model is used when a Component or a Service which is running inside some Framework or a Container is well known in the early stages so that the Framework/Container can create instances of them thereby taking the burden from the Clients. These type of model is used heavily in most of the J2EE Components, to name a few, EJB, Servlets, JMS etc.

For example, consider the following piece of code,

MySessionBean.java

				
@Stateless
public class MySessionBean{

    @PersistentContext
    private EntityManager entityManager;

    public void query(){
        // Do something with EntityManager reference.	
    }
}
				

In the above code, the Session Bean (MySessionBean) is depending on the services of EntityManager. So, before the session bean starts using the EntityManager object, the EntityManager instance should be available. This is made simple because the EJB Container will creates a new instance of the EntityManager object based on the various parameters taken from the Configuration File and injects this instance to the EntityManager reference. This way of doing is called Dependency Injection.

In Seam, injection of a Component by the Seam framework is done by the use of @In Annotation. For example, consider the following piece of code,

MyComponent.java

				
public class MyComponent{

    @In
    private MyInjectorComponent compToBeInjected;

}
				

When the Application gets deployed, Seam Framework will keep track of these Annotated Components and during run-time, upon creation of MyComponent class and before the invocation of any other methods, the Container will inject and instance of an object of type MyInjectorComponent to the compToBeInjected reference.

3.2.2) Dependency Outjection

In Dependency Injection, usually the Framework injects the services to components that are in need of, whereas the reverse happens in Dependency Outjection. Consider the following piece of code,

MyComponent.java

				
public class MyComponent{

    @Out
    private MyService myService;

    public MyComponent(){
    }

    public MyService getMyService(){
        return createMyService();
    }

    private MyService createMyService(){
        // My own way of creating 
    }
}
				

MyServiceClient.java

				
public class MyServiceClient{

    @In
    private MyService myService;

}
				

In the above code, MyComponent class is acting as a factory class for creating MyService objects. Assume that this MyComponent class is a controlled class meaning that is being managed by the Container or the Framework wherever it is embedded. Situations may arise such that the MyService object might be needed by the Container so that the Container can use this MyService to inject dependencies on other components or clients. For instance, MyServiceClient is in need of MyService object and the Container can inject this reference from the object that it has taken from MyComponent class. This model is Dependency Outjection where a Service is taken by the Container from the Component.

Seam supports both these models in the form of @In and @Out annotations. For example consider the following class,

MyClass.java

				
public class MyClass{

    @In
    private MyServiceOne service1;

    @out
    private MyServiceTwo service2;
}
				

The above code can be read like this. The container injects the reference to service1 because it is annotated with @In (meaning for Injection). And at a later stage, the Container may taken the reference of service2 (because of @Out) thereby serving it to other needful Components.

3.3) Stateful Web Applications

Since the underlying protocol used in a Web Application is Http, all Web Application are Stateless in nature. Precisely it means that all the requests that are coming from the Client Browser are treated as individual requests only. The Server shows no partiality for the Client Requests. It is up to the Application or the Framework to identify whether requests are coming from the same Client or not. Session Management in Web Application is a time-consuming job and typically Servlets/Jsp provides various ways to manage sessions. Even in this case, Application Developers still have to depend on HttpSession like classes for creating session objects and storing/retrieving objects from the session.

JBoss Seam provides an excellent way to Manage States amongst multiple client requests. The State Management Facility is tightly integrated with Seam Components in the form of various Contexts. Following are the most commonly used Contexts in Seam.

• Conversation – A Conversation generally represents multiple requests that come from the same client. Components that come under this category can remember the state of the client and this forms the heart of State Management in Seam.
• Application – This context generally holds information that is used by various components within the same Application.
• Session – Components that fall under this category simply uses Http Session Api for state management.
• Page – The scope of the components managing the information is restricted to the Current Page only. All the stored information is lost when the user leaves this current page.
• Stateless – Components that falls under this category don't manage state between multiple Client Requests.