Thoughts on Software Architecture

Jogger design decisions FAQ

2012-05-14T10:02:00.000-07:00

Jogger is a lightweight library for building Web Applications that provides a routing mechanism and a view template engine based on FreeMarker. The source and documentation are on Github.

In this post, however, I would like to answer some questions about design decisions I made with Jogger that will help you understand the philosophy behind.

Why do we need another Java Web Framework?

I wanted a super simple Java web framework that would allow me to:

Map HTTP requests to Java methods: similar to Play! Framework (which is inspired by Ruby on Rails).
Use a better request/response API than the one provided by the Servlet API.
Define views and layouts: reuse layouts in multiple views.
Plug into any project: let me choose the project structure and the libraries/frameworks I want to use; don’t make this hard on me.
Deploy into any Servlet Container: such as Jetty or Tomcat.
Easy testing: test controllers and views without having to start a Servlet Container.

Why not a component based framework like JSF, Wicket, etc.?

Short answer is that they couldn't keep the promise of isolating the user from client side development and the request/response nature of HTTP. Long answer is here.

Why not using the Servlet API directly?

Because it sucks! It's difficult to test, it has an endless hierarchy of classes, exposes hundreds of useless methods and provides an inconvenient configuration mechanism. The only good part is that it doesn't try to hide the request/response nature of HTTP.

Why using FreeMarker for the view?

JSP's (Java Server Pages) were dismissed from the beginning, you just can't create and reuse a layout with them. My first options were Jade and Haml but there is not a decent implementation for Java that I know. The truth is that I am happy with FreeMarker now.

Why not using annotations instead of the routes.config file?

First, with annotations you would have all this routing configuration scattered in multiple Java files. I wanted to keep this information centralized and as simple as I could. Second, I'm against of scanning the classpath (one of the reasons I moved away from JEE), it just doesn't scale. Third, it would be a problem for hot deployment.

Why exposing the Jogger Request and Response in the controller actions?

Because I think we should embrace the fact that HTTP is a request/response protocol. You retrieve things from the request and use the response to, well, respond.

Why testing without starting a Servlet Container?

First, it's an unnecessary overhead. Besides, you wan't to test that your routing is working as expected, that your controller is rendering the correct template, etc. and I think that mocking the Servlet Container works well in this cases. It really depends on how you need to test your application.

If you have another question or think that an answer is not clear enough, ping me and I will add it or improve it. Thanks.

Java web development: back to basics

2012-05-12T17:26:00.001-07:00

The first post that I wrote on this blog is titled AJAX: JQuery, Google Web Toolkit or RichFaces. There, I praise RichFaces for being built on top of 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)"

What has happened since? Well, after working with Wicket and Vaadin (which I still use in one of my open source projects), I have drifted away from component based web development.

The reason is simple. It doesn't have to do with performance, number of components or the size of the community. It's just that component based web frameworks couldn't keep the promise of isolating the programmer from client side development and the request/response nature of HTTP.

A leaky abstraction

Yes, I know. Every abstraction, to some degree, is leaky. However, the problem with this specific abstraction is that it leaks way too fast. You end up investing large amounts of time understanding how the framework works underneath and how to tweak it in order to achieve what you want. It's a real pain in the ass. The productivity that they promise in their "build an app in 10 minutes or less videos" is dead in the eleventh minute or so.

The other problem is that the technology underneath is moving too fast. HTML5 introduced a lot of new features such as web sockets, canvas and new data storage options. Web development is also moving towards stateless REST services and heavy clients. The future is not clear yet, though.

Back to basics

Lately, I have been working with Ruby on Rails and Express.js (Node.js). I think that their success lies in the fact that they embraced the request/response nature of HTTP. However, I don't buy the "Ruby made programming fun again" bullshit - a topic for another post -. I still like Java.

I also tried Play! Framework for a few weeks. It's an interesting option but I don't think that the solution is to copy exactly how Ruby on Rails works in Java/Scala. It's not really about productivity, it's about maintainability.

So, I'm actually using a super simple Java request/response based framework I made, HTML5, CSS3, Javascript and JQuery.

Extension points (plug-in) design

2010-09-26T21:07:00.000-07:00

In a plug-in architecture, extension points allow other users to extend the functionality of your application, usually by implementing interfaces or extending abstract classes (known as the Service Provider Interface or SPI). Designing a good SPI is as important as designing a good API; it should be easy to learn and use, powerful enough to support multiple scenarios and should evolve without breaking existing implementations.

Starting with a simple interface is simple, the problem is keeping it like that as new requirements arrive. For example, take a look at the following MessageSender interface that allow other users to implement different ways of sending messages (e.g. SMS, Email, Twitter, etc.):

public interface MessageSender {

  void send(Message message) throws Exception;

}

Nice interface; it’s simple and easy to implement. However, suppose that implementations could have an optional name, an optional description and methods to setup and destroy. After adding the required methods to the MessageSender interface, it ends up like this:

public interface MessageSender {

  // clean up resources
  void destroy() throws Exception;

  // return null or "" for empty description
  void getDescription() throws Exception;

  // return null or "" for empty name
  void getName() throws Exception;

  void send(Message message) throws Exception;

  // setup resources
  void setup() throws Exception;

}

Besides breaking existing implementations, this changes will make the interface much harder to implement. So, how can we keep the MessageSender interface as simple as it was before and support the new requirements? Let’s take a look at two different approaches that will keep our SPI simple and extensible: creating optional interfaces and using annotations.

Optional interfaces

Instead of having all those methods in the MessageSender interface, we are going to split them up in three interfaces: MessageSender, Nameable and Configurable.

public interface MessageSender {

  void send(Message message) throws Exception;

}

public interface Nameable {

  String getName();
  String getDescription();

}

public interface Configurable {

  void setup() throws Exception;
  void destroy() throws Exception;

}

Now, we’ve cleaned up the MessageSender interface. Users can implement Nameable and/or Configurable if they need to (they are optional). You’ll have to check at runtime if the optional interfaces are implemented and call the corresponding methods where applicable. For example, the following helper method will call the setup method if the MessageSender implementation implements Configurable:

...
  public static void setup(MessageSender ms) throws Exception {
  
    // check if ms implements Configurable
    if (Configurable.isInstance(ms)) {

      // cast to Configurable and call setup method
      Configurable configurable = (Configurable) ms;
      configurable.setup();
    }
  }
...

Annotations

Another option, besides splitting into multiple interfaces, is to create annotations; for our example, we will need four: @Name, @Description, @SetUp and @Destroy. Implementations can place these annotations as needed. For example, a MessageSender implementation (e.g. SmsMessageSender) with a name “SMS Message Sender” that needs to be destroyed at the end will look like this:

@Name(“SMS Message Sender”)
public void SmsMessageSender implements MessageSender {

  public void sendMessage(Message message) throws Exception {
    // send the message (connect if not connected)
  }

  @Destroy
  public void destroy() throws Exception {
    // disconnect from the SMSC
  }
}

As you can see, we have placed the @Name annotation above the class declaration and the @Destroy annotation in the method that will release the resources. Again, we are going to need some helper methods to check if the implementation has the annotations and call the corresponding methods. For example, the following code will check if the @Destroy method exists and will call it accordingly:

...
  public static void destroy(MessageSender ms) throws Exception {
		
    Method destroyMethod = locateDestroyMethod(ms);
    if (destroyMethod != null) {
      destroyMethod.invoke(ms);
    }
  }
	
  private static Method locateDestroyMethod(MessageSender ms) {
    Method[] methods = ms.getClass().getMethods();
    for (Method method : methods) {
      // check if the @Destroy annotation is present
      if (method.isAnnotationPresent(Destroy.class)) {
        return method;
      }
    }
		
    // no method has the @Destroy annotation
    return null;
  }
...

Annotations gives us more flexibility than optional interfaces as users will only have to add the required annotations. However, both options will make your interfaces simpler, so it’s up to you.

Conclusion

Regardless of the approach you choose, keeping the interfaces (extension points) as clean as possible will allow you to:

Lower the learning curve of the interfaces. Users can now focus on the core methods that need to be implemented in order to add new functionality.
Make your documentation simpler, especially for the 101 examples. Then, you can create more advanced examples that include more complex scenarios.
Evolve the interfaces without breaking existing implementations.

Mokai: Architecture of a Messaging Gateway

2010-09-20T12:15:00.001-07:00

Software architecture is all about simplicity. In this post, I’ll show you the process of building the architecture of Mokai, an open source Java Messaging Gateway capable of receiving and routing messages through a variety of mechanisms and protocols including HTTP, Mail, SMPP and JMS (Java Message Service), among others.

The black box

Applications send and receive messages to and from external services such as an SMSC, a SMTP server, a JMS queue, etc. In the picture, we can identify the first three challenges of the gateway:

Receiving messages from applications using any protocol.
Sending messages to external services using any protocol.
Routing messages internally.

Normalizing messages

Let’s start with the last point. How do we route messages internally? Well, with so many protocols for receiving and sending messages, we’ll need a Message class we can manipulate inside Mokai. It will contain some basic information, a body and a map of properties. This way, we can encapsulate any type of information we want inside the message (in the body or properties).

When Mokai receives a message, it will have to be normalized (i.e. encapsulated in a Message object) so it can be routed through the gateway. Once we are ready to send the message to an external service, it will have to be de-normalized (i.e. converted to a protocol that the external service can understand). Easy, right?

Receivers and Processors

The other two challenges we have described above involve extensibility. Anyone should be able to create new protocols for receiving messages or routing them outside the gateway. When creating extension points for your application, make them as simple as you can. In this case, we will introduce two interfaces: Receiver and Processor. Users will have to implement these interfaces to introduce new protocols for receiving or sending messages.

The Processor interface is really straightforward. Nothing strange in there. It just exposes two methods; one for checking if the processor supports a Message and other to process it (de-normalizing it to the desire protocol).

The Receiver interface is even simpler; it exposes no methods, but it uses an instance of a MessageProducer to route the received messages inside Mokai. The MessageProducer will be injected automatically to the Receiver at runtime.

Routing messages

When Mokai receives a message from an application, it will have to decide which processor will handle it. To achieve this, each processor will have a collection of acceptors attached. Acceptors are an extension point of the application, so we introduce the Acceptor interface.

The Acceptor interface exposes only one method that returns true if the acceptor accepts the message or false if it rejects it. When a message is received, a router will query each group of acceptors, based on a priority, to select the processor that will process the message.

So far, our architecture looks like this:

We have introduced a new element in the diagram: a router; it’s task is to query all acceptors and processors to see who will handle the message.

Executing actions on messages

It is possible that we might want to execute actions on a message such as validate it, transform it or re-route it to a different location. For this cases, we introduce a new extension point, the Action interface.

The Action interface exposes only one method to execute the action on the message. There are three places where we can execute actions on a message:

After a message is received (post-receiving actions).
Before the message is processed (pre-processing actions).
After the message is processed (post-processing actions).

Now, with the introduction of actions, the complete architecture of Mokai looks like this:

We have encapsulated the receiver in a Receiver Service and the processor in a Processor Service. A Processor Service also has a collection of post-receiving actions not shown in the diagram (processors can act as receivers too). We have also introduced two queues to store the messages until they are processed.

The class diagram

Now that we’ve seen the architecture of Mokai, let’s see the final class diagram that models the architecture.

In this diagram we can see all the elements described in the architecture and their relationships.

Wrapping up

As you can see, Mokai’s architecture is simple, elegant and powerful. It provides all the elements we need to extend the platform to our will, keeping extension points simple and manageable.

In the first release of Mokai, there are also additional services such as message persistence, a plugin mechanism, an administration console and a configuration module, among others. You can check the project homepage for more information.

4 areas of possible confusion in JEE 6

2010-04-09T05:42:00.000-07:00

The JEE specification is released and maintained through the Java Community Process, which defines the different API’s that will be included in each release, and how they relate to each other. Due to the technical and political factors involved in the process, besides the time constraint, is no surprise that some areas of the specification may be confusing to new developers, especially with the rising number of annotations introduced by each API.

In this post, I will try to explain four areas where developers might find themselves confused when working with JEE 6.

1. Managed Beans and EL access

The following two annotations from the JEE 6 API are both used to access a bean from the Expression Language (i.e. using the #{} notation):

@javax.faces.bean.ManagedBean – Defined in the JSF 2.0 Managed Bean Annotations specification (JSR-314), it provides an alternative to the declaration of managed beans in the faces-config.xml descriptor file.

@javax.inject.Named – Defined in the Dependency Injection (JSR-330) specification, is one of the built-in qualifier types of CDI (JSR-299) used to provide a name to a bean, making it accessible through EL.

So, which one to use? Always use the @Named annotation, unless you are working in a JSF 2.0 environment without CDI (a very unlikely scenario). There is just no reason to use JSF Managed Beans if CDI is present. You can check this article for more information.

Furthermore, there is another @ManagedBean annotation you might also get confused with:

@javax.annotation.ManagedBean – Defined by the Commons Annotations specification (JSR-250), it is used to declare a managed bean as specified in the Managed Beans specification (JSR-316).

Most likely, you will never need to use this annotation. Let’s look why.

First, don’t confuse Managed Beans with JSF Managed Beans, they are different things. The Managed Beans specification, a subset of the JSR-316, is an effort to provide services like dependency injection, lifecycle callbacks and interceptors to POJO’s (Plain Old Java Objects), which is really cool! So, why not to use it?

CDI treats all POJO’s as Managed Beans! There is no need to explicitly annotate the POJO with @javax.annotation.ManagedBean. Nothing stops you from doing it though.

2. Duplicated @…Scoped annotations

The following annotations are duplicated in the JEE 6 API:

@javax.faces.bean.RequestScoped and @javax.enterprise.context.RequestScoped.

@javax.faces.bean.SessionScoped and @javax.enterprise.context.SessionScoped.

@javax.faces.bean.ApplicationScoped and @javax.enterprise.context.ApplicationScoped.

The @javax.faces.bean… annotations are defined in the JSF Managed Beans specification (JSR-314) and the @javax.enterprise.context… annotations are defined in the CDI specification (JSR-299).

So, which ones to use? Always use the CDI annotations, unless you are working in a JSF 2.0 environment without CDI (a very unlikely scenario). As discussed above, there is no reason to use JSF Managed Beans if CDI is present.

One scope that is missing in CDI is the @ViewScoped of JSF. However, the problem is solved by creating a portable extension which will be included in the Seam 3 Faces Module.

3. Defining a Singleton

There are four annotations that provide very similar functionality:

@javax.ejb.Singleton – A new type of EJB from the JSR-318 specification, it is used to maintain a single shared instance; it’s thread safe and transactional.

@javax.inject.Singleton – From the Dependency Injection specification (JSR-330), marks a type the injector will only instantiate once.

@javax.enterprise.inject.ApplicationScoped – One of the built-in scopes from the Contexts and Dependency Injection specification (JSR-299), specifies that a bean is application scoped.

@javax.faces.bean.ApplicationScoped – Defined in the JSF 2.0 (JSR-314) Managed Beans specification, specifies that a JSF managed bean is application scoped.

They all guarantee a single instance of the class. But, which one to use?

We have already discussed the duplicated @ApplicationScoped annotations above, so we will just dismiss @javax.faces.bean.ApplicationScoped to move on. That leaves us with just 3 options.

@javax.ejb.Singleton is the only one that will give you out-of-the-box “enterprise” services such as concurrency and transaction management. So, if you need these features, this is the annotation to use. You can optionally add the @javax.enterprise.inject.ApplicationScoped annotation but you will not feel the difference, although, CDI will treat it differently. You can check this forum thread for more information.

Note: even though it is possible to use @javax.enterprise.inject.ApplicationScoped with a Stateful Session Bean, I can’t find any good reason to use it given that EJB 3.1 has introduced the Singleton Beans.

If you want to use POJO’s (called Managed Beans in the JEE world), instead of EJB’s, you can also annotate them with @javax.enterprise.inject.ApplicationScoped to guarantee that the class is instantiated only once. Be aware that you will lose all of the services provided by EJB’s such as concurrency and transaction management.

I would not suggest using @javax.inject.Singleton unless you are working in a JS2E environment without CDI support. You can check the Weld documentation and this forum thread for more information about how this annotation is handled in CDI.

Note: none of the annotations discussed above will guarantee a shared single instance in a clustered environment. Usually, you will have one singleton instance per JVM.

4. @Inject or @EJB

They are both used for injection. @Inject is from the Dependency Injection specification (JSR-330) and @EJB from the EJB specification (JSR-318).

So, which one to use?

In most of the cases you will use @Inject over @EJB unless you are working on an environment with EJB’s but no CDI (very unlikely since JEE 6), or if you need to define an EJB resource. You can check the this forum thread for more information.

Conclusion

If you need to access a bean through EL (i.e. from a JSF page), annotate the bean with @Named.
Usually, you will never need none of the @ManagedBean annotations.
Always use the @…Scoped annotations from the javax.enterprise.context package (CDI).
To define a singleton, use the @ApplicationScoped annotation. If you need the EJB services such as concurrency and transaction, add the @javax.ejb.Singleton annotation.
Always use @Inject instead of @EJB, unless you really have a motive to do so.

What’s so wrong with EJB’s?

2010-03-28T12:07:00.001-07:00

It’s not that they are heavy. It’s not that they are difficult to write. So, what’s wrong with EJB’s?

EJB’s can be either Stateless, Stateful or Singleton. However, when you are working on a web environment for example, these lifecycles will not suffice. Request, session and application lifecycles would be much better suited in that case. Another example is a business process application, where you could have a task or a process lifecycle; again, EJB’s will not match those lifecycles. This is what I call the Lifecycle Mismatch.

Through the years, EJB’s have become more POJO-like, through the use of annotations and without requirements such as XML descriptors and Java interfaces. However, it doesn’t matter how simple they get, until they don’t remove the lifecycle restriction, you will end up creating additional layers in your application and different component models to adapt your required lifecycles.

Note: The lifecycles I’m referring are also known as contexts or scopes in other frameworks/specifications.

For example, take a look at JSF. They introduced the JSF Managed Beans to handle this problem. JSF Managed Beans can be bound to request, session or application contexts. From there, you are on your own on how you connect them to the EJB’s different lifecycle.

CDI (Contexts and Dependency Injection) is a specification, part of the JEE stack, that is trying to fill that gap. It provides dependency injection and lifecycle management to POJO’s and EJB’s. But providing lifecycle management to EJB’s doesn’t feels right, because they already provide their own. CDI does its best effort to accommodate this mismatch.

On the other hand, CDI could provide to POJO’s, all the services EJB’s currently have, through extensions. So, do we really need EJB’s? Well, not really! You can check my post EJB’s - Time to let them go? for more information.

Conclusion

EJB’s have become light weighted and easy to write. But the lifecycle mismatch is still there. POJO’s, on the other hand, don’t have this restriction and, with CDI, they could have all the services EJB’s currently provide.

Understanding and Comparing Dependency Injection Frameworks

2010-03-04T04:44:00.000-08:00

If you have used a modern Dependency Injection (DI) framework like JBoss Seam, Google Guice or CDI (Contexts and Dependency Injection), you might already be familiar with the following line of code:

@Inject MyBean myBean;

But, to really understand how a DI framework works and what makes one different from the other, we are going to build one from scratch. Let’s call it OurDI. Then, we will compare it with some of the most popular DI frameworks out there.

So, let’s start by writing a Quick Start Guide for OurDI that shows how it works.

Quick Start Guide

As any other modern DI framework, OurDI allows you to inject dependencies using annotations as in the following example:

public class UsesInjection {
  @Inject MyBean myBean;
  ... 
}

In order to configure OurDI, all you need to do is to populate a class named Injector with all the objects that can be injected at runtime; each object must be identified by a unique name. In the following example, we are going to configure the Injector with two classes MyBean and AnotherBean, bound to the names “myBean” and “anotherBean” respectively:

public class Main {
  public final static void main(String[] args) {  
    Injector injector = Injector.instance();  
    injector.bind(“myBean”, new MyBean());  
    injector.bind(“anotherBean”, new AnotherBean(); 
  }
}

So, when a method of the UsesInjection class (defined above) is called, a search will be done for the name of the attribute “myBean” on the Injector instance, and the value associated with that name will be injected.

Building the framework

Well, that was a quick Quick Start Guide! Now let's see how OurDI works underneath.

OurDI is composed of two classes and an annotation:

A singleton class named Injector, that will store the bound objects.
A class named InjectorInterceptor, which will use AOP (Aspect Oriented Programming) to inject the dependencies at runtime.
The @Inject annotation.

Let’s take a look at the Injector class:

public class Injector {

  private Map<String,Object> bindings = new HashMap<String,Object>();

  // static instance, private constructor and static instance() method 
 
  public void bind(String name, Object value) {
    bindings.put(name, value);
  }
 
  public Object get(String name) {
    return bindings.get(name);
  }
}

As you can see, Injector is singleton class backed by a Map<String,Object> that binds each object to a unique name. Now, let’s see how injection is done when an @Inject annotation is found.

We can use any AOP library to intercept method calls and look for all the dependencies that need to be injected on the target object. In this case, we are going to use AspectJ:

@Aspect
public class InjectorInterceptor {

  @Around("call(* *.*(..)) && !this(InjectorInterceptor)")
  public Object aroundInvoke(ProceedingJoinPoint joinPoint) throws Throwable {
  
    // this should return the target class
    Class clazz = joinPoint.getTarget().getClass();
  
    // inject fields annotated with @Inject
    for (Field field : clazz.getDeclaredFields()) {
      if (field.isAnnotationPresent(Inject.class)) {
        doInjection(joinPoint.getTarget(), field);
      }
    }
  
    return joinPoint.proceed();
  }
 
  private void doInjection(Object target, Field field) throws IllegalAccessException {
    String name = field.getName();
    field.setAccessible(true);
    field.set(target, Injector.instance().get(name));
  }
}

Before each method call, the aroundInvoke method will be called. It will look at all the fields of the target object to see if it finds any @Inject annotation. For each of the annotated fields, it uses the name of the field to find the corresponding object in the Injector class.

Finally, here is our @Inject annotation:

@Target(value={FIELD})
@Retention(value=RUNTIME)
@Documented
public @interface Inject {}

That’s all! you can check the full source here. Now, let’s check some aspects of our solution and compare them with other popular frameworks out there.

Configuration

In OurDI, we have to manually populate the Injector instance with the objects that are going to be injected. This is similar to Google Guice. However, in Guice, there is no need to use a name and, instead of binding objects, we bind classes:

Injector injector = Guice.createInjector(new Module() {
  public void configure(Binder binder) {
    binder.bind(Notifier.class).to(SendSMS.class);
    binder.bind(Database.class).to(MySqlDatabase.class);
  }
});

JBoss Seam and CDI take a different approach. Instead of binding each class manually, they scan all your classes on bootstrap to populate the “injector”. In JBoss Seam, you will need to register the Seam Servlet Listener on your web.xml; for CDI, no configuration is required (besides the beans.xml descriptor), the application server will do the scanning automatically (one of the benefits of being part of the JEE stack).

Scanning all classes and choosing the ones suitable for injection can take a while. So, Google Guice (and OurDI) will be faster starting up. However, with JBoss Seam or CDI, you won’t have to worry about binding each class/object manually.

Type safety

As you might already have noticed, OurDI will break at runtime with a ClassCastException if the injected object is not of the expected type. The same happens with JBoss Seam, which also uses a name-based approach (components are named using the @Name annotation).

On the other hand, Google Guice and CDI are type safe, meaning that the injected objects are not identified by a name, but by their type.

Overriding/changing implementations

In OurDI, to override/change the implementation of an injected class, all we need to do is change the object bound to the Injector class. This is very similar to Google Guice as shown before.

For JBoss Seam and CDI, we need to provide more information about the classes we want to use. I won’t dive into the details but you can check how this works in the Weld documentation for CDI and in this post for JBoss Seam.

Constructor and method injection

Besides field injection, some DI frameworks provide constructor and method injection to initialize your objects. OurDI doesn’t support any of these, neither JBoss Seam. Both CDI and Google Guice support them.

Injection of external resources

Sometimes, you need to inject things you don’t have control of. For example, DataSources, 3rd party libraries, JNDI resources, etc. OurDI doesn’t support this. JBoss Seam supports it with factories and manager components, Google Guice supports it with provider methods and CDI supports it with producer methods and fields.

Scopes

Scopes, also known as Contexts, are a fundamental part of development. They allow you to define different lifecycles for each object (i.e. request, session, or application). OurDI doesn’t support scopes. However, Google Guice, JBoss Seam and CDI, all support scopes in one way or another. You can read more about scopes and their importance on this post.

You can also check the documentation of scopes for each framework/specification: Google Guice, JBoss Seam and CDI.

Static vs. Dynamic Injection

In OurDI, every time a method is called, it will scan the object to find dependencies that need to be injected. This is called Dynamic Injection and is how JBoss Seam works. The advantage of dynamic injection is that if a dependent object is changed, the new object will be injected in the next method call, so, you’ll always end up with the “correct” instance.

Google Guice and CDI uses Static Injection, which means that injection will only occur once after the object is created. The problem here, as stated above, is that if a dependent object is changed, you will still have the reference to the old object. CDI solves this problem by using proxies that will always point to the correct instance. So, even though it uses static injection (the field is injected only once), it works like dynamic injection.

Lazy Loading of objects

In OurDI, you will need to instantiate all the classes that need to be injected on startup. This is definitely not a good idea as you are loading things in memory that you are not still using. Google Guice, JBoss Seam and CDI all use a lazy loading approach where the objects will be loaded only when needed, which is a good thing.

Aspect Oriented Programming

Most DI frameworks provide some type of method interceptor mechanism that simplifies AOP development, usually with annotations. This is another feature that OurDI lacks! However, Google Guice, JBoss Seam and CDI, all support this feature with a very similar approach.

Integration

Integration with other environments is really simple with OurDI and Google Guice. You just need to configure the Injector on startup and that’s it. JBoss Seam is a complete development platform that integrates multiple technologies and it would be almost impossible to integrate it on a different environment different from JEE. CDI is part of the JEE 6 stack, however, implementations like Weld can run on different environments with the appropriate hookups.

Conclusion

Ok, let’s face it. Our own DI framework sucks!:

It doesn’t support constructor or method injection (or provide an alternate solution).
It doesn’t support injection of external resources.
It needs all classes to be instantiated on startup.
It doesn’t support scopes.
It doesn’t provides a method interceptor mechanism.

However, I hope OurDI was useful enough to compare different DI frameworks. We only talked about Google Guice, JBoss Seam and CDI, but you can do the exercise with any other DI framework out there.

Overriding a component in JBoss Seam

2010-02-18T02:05:00.000-08:00

A few days ago, I was asked to explain how to change/override/mock a component in JBoss Seam. So, here is it.

To override a component in Seam, all you need to do is to create a second component that satisfies the following conditions:

It must have the same name as the component you are overriding.
It must be of the same type than the component you are overriding. Or you will end up with a ClassCastException on injection.
It must have a higher precedence than the component you are overriding.

The first two points need no further explanation. However, the third one raises the following questions: What is the precedence of a component? How do I change it?

The precedence of a component is a numeric attribute all components have, which by default is 20. You can change the precedence of a component using the @Install annotation:

@Name("myBean")
@Install(precedence=40)
public class MyBean {
 ...
}

On startup, if Seam finds more than one component with the same name, it will choose the one with the higher precedence value. If it finds two components with the same name and the same precedence, an Exception is thrown.

Let’s take a look at an example. Suppose that you have an interface called CodeGenerator with two implementations: DefaultCodeGenerator and an alternate MockCodeGenerator.

public interface CodeGenerator {

 public String generateCode();
 
}

@Name("codeGenerator")
public class DefaultCodeGenerator implements CodeGenerator {

 public String generateCode() {
  ...
 }
}

DefaultCodeGenerator. No @Install annotation; it will have a precedence of 20 (the default value).

@Name("codeGenerator")
@Install(precedence=Install.MOCK)
public class MockCodeGenerator implements CodeGenerator {
 
 public String generateCode() {
  ...
 }
}

MockCodeGenerator. Notice that it has the @Install annotation with a precedence of 40 (see the table below).

Now, suppose both DefaultCodeGenerator and MockCodeGenerator are on the classpath and that we have the following injection point:

@Name("testCodeGenerator")
public class TestCodeGenerator {
 ...
 @In
 private CodeGenerator codeGenerator;
 ...
}

Which component will be injected? Seam will choose the one with the higher precedence. In this case: MockCodeGenerator. So, a common usage is to have a separate JAR with the alternate implementation that can be included on the classpath only when needed (i.e. added to the WAR or EAR archive).

Seam defines some predefined precedence values:

Constant	Value	Description
Install.BUILT_IN	0	Built in Seam components have this precedence.
Install.FRAMEWORK	10
Install.APPLICATION	20	The default precedence
Install.DEPLOYMENT	30
Install.MOCK	40	For mock objects used in testing

Note: It is recommended to use one of this constants for the precedence. However, nothing stops you to set a different value.

Using components.xml

Another way of overriding a component in Seam is to define the component in the components.xml descriptor file instead of using the @Name annotation. XML-based configuration is discouraged by Seam but valid anyway. This way you can change the class directly in the XML without re-compiling.

What I usually do is to have a default implementation annotated with the @Name annotation which has the default precedence. When I need to override it, I define a second component in the components.xml descriptor with a higher precedence (this way, I’m only using the XML file to install the alternate implementations). For example, instead of annotating the MockCodeGenerator with @Name and @Install, we could have added it to the components.xml:

<components>
 ...
 <component name="codeGenerator" class="org.test.MockCodeGenerator" precedence="40" />
 ...
</components>

Other options

The @Install annotation is much more powerful than what I’ve just shown you. It allows you to “install” a component only when certain conditions are satisfied. For example:

When you are working on debug mode.
When a class or group of classes are present on the classpath.
When a component or group of components are present on the classpath.

When you are working on your development environment, you might want to mock some components to: simulate external systems you don’t have access to, simulate emails, sms, etc., disable some functionality, etc. For these cases, you can have some components annotated with @Install(debug=true) that override the default ones. They will be installed only when working on debug mode (this setting is configured in components.xml).

More advanced options allow you to install a component if some classes or other components are present on the classpath. You can do some complex stuff here but that is out of the scope of this post.

Finally, you can always rely on @Install(false) which won’t install the component by default. You will have to install it manually in the components.xml descriptor file. Al lot of built-in components of Seam are configured this way so you can install them only when needed.

Conclusion

Seam offers you a variety of ways in which you can override components, or, how Seam calls it, conditionally install components. It offers you so many options, it can sometimes get tricky. However, once understood, it is a very powerful feature.

JMX Portable Extension for CDI

2010-01-28T18:37:00.000-08:00

CDI (Contexts and Dependency Injection) is a new standard that makes application development easier by providing type safety dependency injection, scope binding (request, session, application, etc.) and contextual lifecycle management of Java components. It also exposes a powerful SPI (Service Provider Interface) to extend its functionality through portable extensions.

JMX (Java Management Extensions) provides a consistent, well defined interface to monitor and manage your applications by exposing objects (MBeans) through an MBeanServer. Currently, there are two ways to expose an object as an MBean: you can either provide an interface of your class, in which case, you won’t be able to add textual descriptions for your exposed fields and methods; or you can implement javax.management.DynamicMBean, which is cumbersome and difficult to maintain.

JSR-255, the JMX specification 2.0, is an initiative that will make the writing of MBeans easier through annotations. However, by the time of this writing, the JSR is inactive as stated here.

I’ve decided to write my first own portable extension that will allow you to expose any object automatically or manually through JMX by just adding some simple annotations. You can download the complete code from here.

Let’s take a look at the following example:

When the bean is instantiated by CDI, a dynamic MBean is created and registered on an MBeanServer to expose the attributes and methods annotated with @ManagedAttribute and @ManagedOperation respectively. You can then use any JMX Agent Viewer to monitor and manage your code.

Figure 1. JBoss AS JMX Console. A view of an MBean.

You don’t have to worry anymore about obtaining an MBeanServer, registering the MBean and unregistering it. This is all done automatically for you. It’s a simple way of instrumenting your code without writing complex and uneven administration interfaces!

Creation and registration of the MBean is done when the bean is instantiated by CDI, not on startup. If you want the MBean to be registered on startup, you will have to annotate your class with the @Singleton and @Startup annotations.

If you don’t want the object to be automatically registered on instantiation but still want to register it yourself later in the code, you can set the autoRegister property of the @MBean to false. To register your object programmatically, you use the MBeanFactory service to create a DynamicMBean instance, and then register it to an MBeanServer. For example:

You can even expose objects that are not annotated with @MBean. In this case, all fields and methods from the class are exposed. Any @ManagedAttribute or @ManagedOperation annotations will be ignored.

CDI Integration

Writing the portable extension was pretty straightforward. First, I created a class org.gescobar.management.cdi.ManagementExtension that extends javax.enterprise.inject.spi.Extension with a method to observe the ProcessInjectionTarget event:

Basically, what we are doing here is replacing the InjectionTarget with a wrapper class that will register and unregister the MBean if the @MBean annotation is present and autoRegister is true

To register the portable extension, I created a file called javax.enterprise.inject.spi.Extension with only one line:

Testing

I used TestNG and Arquillian to write and execute the tests inside a remote JBoss AS 6.0.0.M1 container. One of the tests looks like this:

Arquillian is a JBoss project for running tests on different containers. By the time of this writing, it hasn’t been release but you can download the code from SVN and build it using Maven 2.

What’s next?

It would be nice to support the following:

Automatic and manual registration of MBeans for JBoss Seam.
Manual registration of MBeans in any J2SE environment.
@ManagedAttribute annotation on methods that return information.
Name for operation parameters.
Notifications using annotations.
Message keys from resource bundles for descriptions.

You can check the project on Google Code here. Please, feel free to download it and give it a try!

From JBoss Seam to CDI (JEE6)

2010-01-17T03:25:00.000-08:00

Seam is a popular open source application framework that has led to the creation of CDI (Contexts and Dependency Injection), a specification that is now part of the JEE 6 ecosystem. In this post I’ll show you the architectural similarities and differences between both and how Seam has influenced CDI. So lets start!

Contexts

Contexts are definitely one of the most exciting features of Seam (you can read more about them in this post) and remain in the core of CDI. Seam defines six stateful contexts: request (event), session, application, page, conversation and business process context. CDI only define 4, leaving page and business process contexts out. However, CDI allows you to define new contexts which was not possible in Seam. You can see an example of creating a context (the equivalent of the page context in Seam) by Steven Verborgh here.

Additionally, CDI now defines a new “dependent” context which allows a bean to have the same context as the bean that declares it. They will share the same lifecycle meaning that “it [the dependent bean] is instantiated when the object it belongs to is created and destroyed when the object it belongs is destroyed”, as stated in the Weld documentation.

Dependency Injection

Even though Seam and CDI both make heavy use of the Dependecy Injection pattern, they take different approaches to implement it. The most notable differences are the following (I’ll explain each one in more detail below):

Seam uses a string-based approach to search for components which is not type safe while CDI brings type safety to the limit.
Seam uses dynamic injection while CDI uses static injection.

Type safety

In Seam, every component has a name defined by the @Name annotation. When an injection occurs, Seam searches for the name of the component which can lead to runtime exceptions. For example, suppose you have the following component:

@Name("myBean")
public class MyBean {
 ...
}

Now, suppose you mistakenly inject MyBean into a String like this:

@In
private String myBean;

This will compile just fine, but at runtime you will get an exception. In large applications, this is a problem as you will potentially have a lot of bugs at runtime, something you really want to avoid.

CDI implements dependency injection based on the type of the bean like in Google Guice. There is no need to name a bean unless you want to access it from EL, in which case, you will need to annotate your bean with the @Named annotation. Lets look at a simple case of injection in CDI:

public class Bean1 {
 ...
}

public class Bean2 {
 @Inject
 private Bean1 bean1;
 ...
}

When Bean2 gets instantiated, Bean1 will be injected on Bean2. As you can see, there is no need to name the beans.

Static vs. Dynamic Injection

In Seam, injection occurs on each method call. After the method completes, all injected values are desinjected (set to null). This is known as dynamic injection and it has its benefits and drawbacks. The most outstanding benefit is that you can inject components from different contexts (i.e. a request component injected in a conversation component) and you will always have the “correct” instance on each method call. However, dynamic injection has some problems including performance and null values on concurrency.

CDI uses static injection, meaning that all the values are injected on the creation of the bean and they are not desinjected between method calls. To handle injection of beans from different contexts, it uses proxies that reference the “correct” instance of each bean. A much more elegant solution in my opinion.

Factories

Remember the @Factory annotation in Seam? It allows you to obtain objects that are not Seam components; or it could also be used when you need to perform some custom initialization on a component before returning it. In CDI, there is an equivalent functionality called “producer method”:

@Produces
public User getUser {
      ...
}

Every time a User object is injected, this method will be called to obtain a reference. CDI provides a simpler alternative to a producer method called a producer field:

@Produces
private User user;

Events

In Seam, you can decouple your components using events. Each event must have a name. You can raise an event using the @Raise(“<name_of_event>”) annotation or programmatically using the Events.instance().raiseEvent(“<name_of_event>”) method. To observe for an event, you mark the method you want to be called on the event with the @Observer(“<name_of_event>”) annotation.

CDI grabs this concept from Seam and makes it type safe. So, for raising an event we can obtain an Event object by injection:

@Inject
private Event<User> userEvent;

And then call the fire method on the Event object:

userEvent.fire(user);

Now, for observing an event you use the @Observes annotation:

public void observeUserEvent(@Observes User user) {
 ...
}

Interceptors

Seam relies heavily on interceptors for injection, security, persistence and much more. CDI also provides an interception facility called interceptors bindings, based on the Java Interceptors specification. Furthermore, CDI provides the concept of “decorator”, which is a kind of interceptor for implementing the decorator pattern.

Wrapping up

Let’s take a look at the services provided by CDI and see if they were inspired by Seam:

Contexts: heavily inspired by Seam.
Dependency Injection: mostly inspired by Google Guice but we have an equivalent in Seam (which is not type safe).
EL integration (the #{} notation): completely inspired by Seam.
Interceptors: completely inspired by Seam.
Events: heavily inspired by Seam but type safe.

Wait a minute! Are these all the services provided by CDI? What about all the out-of-the-box functionality I used to have in Seam (page flows, business process integration, security, scheduling, caching, remoting, etc.)? Don’t worry! Portable Extensions, the only service we are missing in this list, will solve this question, so just keep reading!

Portable Extensions and Seam 3

Besides the services described above, CDI provides a powerful SPI (Service Provider Interface) you can use to create extensions (called Portable Extensions in CDI). This is where Seam 3 enters the game!

Seam 3 will be a set of portable extensions that will provide almost all of the out-of-the-box functionality you actually have in Seam 2. At the time of this writing, Seam 3 is on its first steps and there is no official release yet. However, you can start developing your own portable extensions on top of CDI. Take a look at this post by Matt Corey to start writing your own first portable extension!

Conclusion

CDI has been heavily influenced by Seam with two major architectural changes:

Instead of providing everything out-of-the-box as Seam, CDI provides a set of core technologies and a powerful SPI that will enable any one write its own portable extensions.
Type safety. This was included in every aspect of CDI (Contexts, DI and events), except for the EL integration.

Remember that Seam is a framework and CDI is a specification (Weld is the Reference Implementation). For more information on CDI, check the Weld documentation and the CDI specification.

EJB’s: Time to let them go?

2009-12-05T13:30:00.000-08:00

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

2009-11-22T09:07:00.000-08:00

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

2009-11-06T15:40:00.000-08:00

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

2009-10-29T21:37:00.001-07:00

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