EJB’s: Time to let them go?

If you are a JEE developer, you may already be familiar with the benefits of using EJB’s (Enterprise Java Beans) instead of POJO’s (Plain Old Java Objects) in your applications. The list includes, but is not limited to:

• Transaction management.
• Scalability – you can distribute your application across multiple machines.
• Lifecycle management.
• Security management.
• Dependency Injection.

EJB’s have been with us for a long time and have certainly evolve in the right direction. From the cumbersome EJB 2.x specification with all those interfaces, a very verbose XML definition and an over-designed Entity Beans, to a more convenient EJB 3.0 spec which uses annotations and better persistence management with the introduction of JPA (Java Persistence API).  The new EJB 3.1 spec even gets simpler with no need of the Local interface and the possibility to run inside a Servlet Container.

On the other hand, we have initiatives like Spring and JBoss Seam that try to bring the benefits of the EJB’s to POJO’s. They have been very successful in this task and are being widely adopted. In fact, the reason EJB’s are getting much more simpler lies in the success of these frameworks. The idea behind them is very easy to understand: use annotations inside your POJO’s when you want the benefits of EJB’s and we will use AOP (Aspect Oriented Programming) to deliver that functionality.

They even go further and bind each object to a scope. So, for example, you may want an object to last through the duration of a request or through the whole session of the user. I will not get into the details of this powerful feature but you can read more in this post where I explain how this works in JBoss Seam.

As you can see, there are two approaches to achieve the same goal. The top-down approach is used by the JCP (Java Community Process) expert group to make EJB’s simpler and the bottom-up approach used by frameworks like Spring and JBoss Seam to empower simple POJO’s with enterprise services.

We still need the standards!

Standards are good. They allow us as developers to focus on what we have to learn, facilitates the technology selection process, promotes vendor independence and are easily accepted by the executive team in companies, among other benefits.

There have been some efforts to standardize some of the bottom-up approaches. The JSR-299 (Context and Dependency Injection) is one of these efforts leaded by the Seam group which has been approved by the JCP. With JSR-299 you could have POJO’s that behave like EJB’s with dependency injection support and scope demarcation (contexts). So the question is: do we still need EJB’s?

Well, the answer is we do. Unfortunately, the JCP group wants to keep the EJB specification and the JSR-299 group had to make the concept of component (called bean in the JSR-299) more abstract to support EJB’s. I think is confusing and not good for the Java community. While other languages are moving to the KISS (keep it simple, stupid!) principle, we are making things more confusing to developers. With JSR-299, you will be able to work with or without EJB’s. The only benefit of using EJB’s will be the clustered services and JMS but that is something that could have been added to the JSR-299 component model.

Conclusion

I don’t think it’s healthy to continue changing the EJB specification to adapt it to a new simpler model. The JCP group should really let them go, create a unified component model based on POJO’s and add it to the JSR-299. We really need to keep it that simple ;)

K6QA68WYDWM2

Seam and JSF

In my last post, I talked about Seam contexts and how to use them from your application. Now, I’ll show you how you can access them from JSF, especially how to use the event context correctly. At the end, I’ll give you some tips you may find useful when developing the web tier of your application with Seam and JSF.

Accessing contexts from your JSF pages

In Seam, you can access anything saved in the contexts from a JSF page using the #{} notation. For example, consider the following line of code:

<h:outputText value="#{employee.name}" />

This will search all the stateful contexts for the “employee” key using the Contexts.lookupInStatefulContexts() method as I showed you in my last post. Remember that the context search priority is: event, page, conversation, session, business process and application. If the key is not found in any of the contexts, it will return null. Otherwise, it will try to call the getName() method on the object.

JSF and the event context

The event context is the narrowest of the stateful contexts; it only lasts during a single http request. It is very useful when working with data iteration because Seam binds the iterated variable into the event context. Consider the following code fragment:

<rich:dataTable value="#{employees}" var="employee">
 <rich:column>
  <h:outputText value="#{employee.name}" />
 </rich:column>
 <rich:column>
  <h:outputText value="#{employeeSalaryResolver.netSalary}" />
 </rich:column>
</rich:dataTable>

In line 6 we are calling another component called employeeSalaryResolver to retrieve the net salary of the employee. Seam binds the actual employee object into the event context, so, we can just inject it in the EmployeeSalaryResolver component:

@Name("employeeSalaryResolver")
public class EmployeeSalaryResolver {
 
 @In
 private Employee employee;

 public double getNetSalary() {
  double netSalary = employee.getBaseSalary();
  
  // do other complex calculations (extra hours, bonus, etc.)  
  
  return netSalary;
 }
}

The employee attribute is being injected from the iteration variable (the event context) and used to retrieve the net salary of the employee. This component can be then reused in other use cases.

You can also use the event context to pass information between pages. For example, imagine a component that searches for an employee using the social security number and shows the result in another page.

@Name("searchEmployee")
public class SearchEmployee {
 
 private String ssNumber;
 
 @Out(scope=ScopeType.EVENT,required=false)
 private Employee employee;

 public String search() {
  Employee employee = ...; // search for the employee
  if (employee != null) {
   return "success";
  }
  
  return null; 
 }
}

When the search method is called (from a page I’m not showing) and an employee is found, the searchEmployee component will outject the Employee object to the event context and render the result in another page. The navigation in pages.xml would be something like this:

<page view-id="searchEmployee.xhtml">
 <navigation>
  <rule if-outcome="success">
   <render view-id="searchResult.xhtml"/>
  </rule>
 </navigation>
</page>

If you notice, we are using render tag instead of redirect tag. This will forward the request to the searchResult.xhtml page instead of redirecting, so the event context will not be lost.

Seam and JBoss EL

Standard EL (the #{} notation you use in your JSF pages) does not allow you to call methods with predefined parameters. However, Seam overcomes this limitation by using JBoss EL, which is an extension of the standard EL. For example, in our employees application, suppose we have a list of employees and we want to add an option on each row to fire employees. So, we create a fireEmployee component with a fire method that receives an Employee as an argument.

@Name("fireEmployee")
public class FireEmployee {

 public void fireEmployee(Employee employee) {
  // fire employee
 }
}

Now, we just need to add the action to the employees' page.

<rich:dataTable value="#{employees}" var="employee">
 <rich:column>
  <h:outputText value="#{employee.name}" />
 </rich:column>
 <rich:column>
  <h:outputText value="#{employeeSalaryResolver.netSalary}" />
 </rich:column>
 <rich:column>
  <s:link value="Fire Employee" action="#{fireEmployee.fire(employee)}" />
 </rich:column>
</rich:dataTable>

Really cool feature! Look at the <s:link> tag. Seam introduces some JSF tags to ease development. I won’t describe them here, but if you want, you can check them here.

Tips using Seam and JSF

1. Backing beans

In Seam, you can use EJB’s as your backing beans. However, by default, use JavaBeans (POJO’s). The reason is that you usually bind the backing bean to the page scope, but, if you use EJB Session Beans, you will not be able to do this.

@Name("someBean")
@Scope(ScopeType.PAGE)
@Synchronized
public class SomeBean implements Serializable {

 private static final long serialVersionUID = -2524956479693778917L;

 // your code ...
}

You can also bind your backing beans to the conversation or session scopes when needed. The @Synchronized annotation tells Seam to serialize requests from the backing beans as concurrency may cause some problems occasionally, especially when you are using AJAX calls. A better approach, however, is to use the eventQueue attribute in your richfaces components. See this for more information.

2. Use a naming convention for your components

You have to choose carefully the name you assign to each of your components because as the application starts growing, you may repeat component names and having some conflicts. So, you can use the package as a prefix for the name of the component.

However, if the project is small, you also can use a simpler prefix if you want. For example, you can use the “controller” prefix for your backing beans, “logic” for your business components and “model” for your entities and DAO’s.

3. You can use more than one Backing Bean per page

A lot of people use one backing bean per page. However, I really discourage this at it does not promotes code reusing and increments coupling. For example, if you have something you show in every page, use a separate backing bean and bind it to the session scope instead of retrieving the same information in every page.

Conclusion

Seam allows you to access any component in any context from JSF, this gives you the opportunity to choose how you want to architect your solution with some cool features that help you speed development time.

Understanding Seam Contexts

One of the most exciting features of JBoss Seam is the contextual component model that radically changes the way we design applications. It has become so important, it is now part of the JEE6 specification through the JSR-299. In this post, I will concentrate on explaining how Seam contexts work and how to use them from your code.

You may already be familiar with the request, session and application scopes of the Servlet specification. They are very useful to save and retrieve data but they have a huge limitation: you can only access them from a Servlet/JSP.

JBoss Seam overcomes this limitation by making the scopes (called contexts in Seam) available to the whole application instead of only to Servlets/JSP’s. So, you’ll find request(event), session and application contexts and 3 more they’ve created: page, conversation and business process contexts.

The request(event), session and application contexts work exactly as they do in Servlets/JSP’s so I’ll just skip their explanation. I will, however, explain briefly the page, conversation and business process contexts.

Page Context

The page context is broader than the request context as it spans multiple requests over the same page. This is very useful if you need to make roundtrips to the server to perform validation, bring information, etc. while maintaining the same page state.

Conversation Context

The conversation context is broader than the page context as it can expand to multiple request and pages but narrower than the session context. It is very useful to implement wizards-like interfaces in which the user has to fill data across multiple pages while maintaining the state over the whole process. You control the creation and destruction of each conversation.

Business Process Context

As it name implies, it is used to maintain state information during the execution of a business process instance in jBPM.

Using contexts from your code

You can use the Contexts class to gain access to one of the contexts, defined by the Context interface, and then use the set or get methods to save or retrieve information respectively.

For example, to save the current user information in the session context you use the following code:

User user = new User();
Contexts.getSessionContext().set("user", user);

Then, when you need to retrieve the user information, you use:

User user = (User) Contexts.getSessionContext().get("user");

Really simple, ah? You can also use the @Out and @In annotations in class attributes to save and retrieve information:

@Out(value="user",scope=ScopeType.SESSION)
private User user;

What the @Out annotation is telling Seam is to save the User object in the Session context with the key “user”. Then, you can retrieve the user with the following code:

@In(value="user",scope=ScopeType.SESSION)
private User user;

Again, the @In attribute is telling Seam to inject the User object from the Session context saved with the “user” key. You don’t have to write any getters or setters in your class, Seam will just outject or inject the information whenever an @Out or @In annotation is present. If no object is found under the “user” key, null will be injected.

As you can see, the value attribute of the @In and @Out annotations are used as a key for searching or saving data in the contexts. The scope attribute is used to specify the context in which the value should be injected or outjected. This attributes are optional; so, what happens if we don’t specify them as in the following example?

@In
private String name;

@Out
private User user;

When you don’t specify the value attribute, Seam uses the attribute’s name as key by default. In the preceding code fragment, Seam will use “name” as the key for the @In annotation and “user” for the @Out annotation.

If you don’t specify the scope of an @In annotation, Seam will scan all the contexts in the following order: event, page, conversation, session, business process and application. If the key is not found, it will inject null. You can use this feature programmatically by calling the Contexts.lookupInStatefulContexts() method.

If you don’t specify the scope of an @Out annotation … well, as the @Out JavaDoc states: “If no scope is explicitly specified, the default scope depends upon whether the value is an instance of a Seam component. If it is, the component scope is used. Otherwise, the scope of the component with the @Out attribute is used.” I know, I haven’t talked anything about Seam components as it is not the topic of this article. If you want to know about Seam components read this.

Conclusion

I hope this introduction has given you the basics of Seam contexts. It is a very simple, yet powerful, concept that has to be taken seriously when designing your next applications.

AJAX: JQuery, Google Web ToolKit or RichFaces

If you are reading this, you probably have already decided to use an AJAX framework for your web application instead of writing plain JavaScript code yourself. However, with so many options out there, picking one is not an easy task. I’ll try to compare JQuery, GWT and RichFaces and hopefully help you to choose the one that suits your needs.

JQuery

JQuery is just a JavaScript library that simplifies AJAX development by allowing you to:

• Manipulate HTML (i.e. adding and removing css styles, changing input values, etc.) from the client.
• Handle events (i.e. keydown, focus, mouseover, etc.)
• Make AJAX calls to the server (i.e. sending data to a Servlet and processing the returned information) 

JQuery is very simple to setup. All you need to do is download the jquery.js file and reference in the head of your page with the following line:

<script type="text/javascript" src="jquery.js"></script>

HTML files are written as usually and JQuery is added where needed. There is no need of an application server to use JQuery as it is pure JavaScript. You will need, however, some JavaScript and CSS skills to get the work done. So, if you are not a very good JavaScript developer, you’ll be better with one of the other options.

Server calls are done via HTTP requests so you’ll have to expose your services through Servlets. You can use JSON, XML or plain text to send and receive information but you’ll have to manage object serialization/deserialization and state between requests yourself.

Google Web ToolKit

GWT is based on Java. It allows you to write code in Java and "convert" it into JavaScript. As you may know, GWT is used in some of the Google Applications including the new Google Wave and Google AdWords, so it is really fast! It now has a Plugin for Eclipse that makes development simpler.

GWT is not as easy to setup as JQuery, but still relatively simple. You can use either the Eclipse Plugin or a command utility called webAppCreator to create the skeleton of the project.

Even though you wont need to know JavaScript at all, GWT is the most difficult to learn as it is a completely new technology built from ground-up. Basically, you create your template in HTML, add all the components from a Java class using the GWT API and format those components using a CSS file. You don’t get to see how your interface looks until you compile and run it. However, once you are familiar with the development process, is very straightforward.

Web server calls are done using GWT RPC or JSON over HTTP. GWT RPC hides the complexity of object serialization/deserialization. You must create a couple of interfaces and a implementation for each “service”. Then, from those services, you can call your business logic. Still not the ideal solution for server calls. Besides, you will still need to manage your state between requests yourself.

One thing I like about GWT is that it has a really good support for browser history so you can easily avoid problems when the user hits the browser's back button. However, you will need to spend development effort to achieve this.

RichFaces

The thing about RichFaces is that it is really simple to understand as it is built over an already known technology: JSF (Java Server Faces). If you haven't work with JSF, I really suggest you do as it is one of the most powerful, easy to learn Web technologies, very similar to swing with heavy use of components and events. It also has a really good support for managing the state in the server using plain Java objects (POJO’s).

So, RichFaces is really a JSF set of components with AJAX support. You’ll find components such as button, table, calendar, tabs and suggestion box, among others. It also adds AJAX support to existing JSF components such as input texts and buttons.

Setup is not as easy as JQuery or GWT as you need to configure JSF first and run it using a J2EE web container. RichFaces is great with server calls but has no support for HTML manipulation. So, you’ll need integrate JQuery with RichFaces to speed up your interface which is really simple to do.

What I really like about RichFaces is the clean separation of concerns (Model, View, Controller) and that it is built on top of JSF, which makes it very powerful and easy to learn.

Conclusion

Each framework offers you unique benefits depending on your skills and needs. JQuery is ideal for those JavaScript developers who need to do a lot of HTML manipulation and animation. GWT offers the benefit of JQuery to those who don’t want to write javascript code directly. Finally, if you are planning to use JSF, RichFaces gives you a perfect balance with a set of rich controls for your web interface and AJAX calls to your Backing Beans.

Resources

• JQuery
• Google Web ToolKit
• RichFaces