What Is JBoss Seam?

What Is JBoss Seam?

seam (sem) n.

A line of junction formed by sewing together two pieces of material along their margins.

A similar line, ridge, or groove made by fitting, joining, or lapping together two sec- tions along their edges.

The preceding definition¹ of seam is usually used when discussing sewing. However,

this definition also fits the latest in frameworks from JBoss-JBoss Seam. JBoss Seam is a

framework that brings together existing Java Platform, Enterprise Edition ( Java EE) stan- dards to enable them to work as an integrated solution. At its core, the Seam framework ties the Enterprise JavaBeans 3 (EJB3) and JavaServer Faces ( JSF) specifications. How- ever, Seam does not just stop there-it will also join together other component models that you may be used to, such as jBPM, Drools, and more that we will get into as the

book progresses.

When I mentioned EJB, you may have been taken aback with fear or may have started shaking your head profusely. Although EJB 2.1 had some negative connotations, especially regarding the way it relates to stateful session beans (SFSBs) and entity beans (EBs), any negative feelings about it should be reexamined today. With the new EJB3 specification, EJBs have become lightweight plain old Java objects (POJOs) that do not require as much of the "plumbing" as before. Hopefully those of you who may harbor negative feelings toward EJB3 will review and revise those feelings as you see how Seam enables you to not only cut development time but also more clearly separate your busi- ness logic and presentation tiers by cutting out the connecting code (for example, Struts actions) normally associated with web frameworks.

For years developers realized that the JavaServer Pages ( JSP)/servlets paradigm was not enough to create enterprise-level web pages. That model provided the capability for a web tier that could pass objects from the client to the server, but essentially that was it. For most developers, this simple paradigm was not enough; more-complex operations

were needed, and developers found themselves writing infrastructure code to deal with

1. https://www.thefreedictionary.com/seam ¹

the shortcomings of the Servlet specification. Eventually, all the ideas learned from cre- ating custom infrastructure code resulted in the web frameworks we know today, such

as Apache's Struts and Tapestry, OpenSymphony's WebWork, and so forth. The Java com- munity also got together and through the Java Community Process ( JCP) created the JSF specification to tackle some of the issues raised and deal with the shortcomings of the Servlet specification.

Even though we now have web and business tiers with improved functionality, we have still been forced to create the plumbing code needed to connect them together. With Seam, however, these two areas can now focus more exclusively on what they do best-presentation and business logic.

What Does Seam Buy You?

When picking up this book, one of your first questions should be, "Why do I even need Seam if I have EJB3 and JSF already?" After all, they were designed to simplify the process of creating web applications. What is the benefit of using the Seam framework with these components if they have already taken care of much of the plumbing that was required before?

The answer lies in what you are trying to accomplish. To be useful, your application has to be a multitiered application that uses specific components for the presentation, business, and persistence tiers. Before, you may have accomplished this with a combina- tion of Struts (presentation), Interface21's Spring (business), and JBoss's Hibernate (persistence) frameworks. Now, following the Java EE specification, you will be using JSF (presentation), EJB3-SB (business), and EJB3-EB (persistence). As before, each of these components requires lots of glue to link them together to talk to each other. Throughout this book I will show you how Seam has transformed this messy gluing you had to do before into a now seamless process.

Three-Tier Architecture

Any beginner may ask not only, "Why do we need all this?" but also, "Where does Seam fit into the equation?" Since about 1999, standard development practice in Java EE was to divide your application into three distinct tiers: presentation, business, and persistent tiers, as illustrated in Figure 1-1. ( Java EE was then known as J2EE. It became Java EE after version 1.4 of the Enterprise Edition).

Figure 1-1. The three-tier Java EE architecture

These tiers are defined as follows:

Presentation tier: The presentation tier encompasses everything from the Hypertext Markup Language (HTML) page to objects controlling the request, such as Struts Action classes or JSF backing beans. Everything in this tier deals with communication to the client-be it a web page or BlackBerry.

Business logic tier: The business logic tier is where you make your business decisions;

it contains the logic of the application. Also, this is where the business processing and (if needed) the database transactions occur.

Persistence tier: The persistence tier represents the interaction with the database. This is where you maintain data access objects (DAOs), Hibernate DAOs, or your entity beans. These classes can be either database specific or nonspecific, depending on what you need. This tier may also contain your database domain objects.

Three-Tier Architecture with Seam

Now you will take a look at the same architecture when using Seam. Figure 1-2 shows the injection points of Seam into the tiers; notice that it encompasses every tier.

Figure 1-2. The three-tier Java EE architecture with Seam

In Figure 1-2, you can see that Seam wraps the components by using annotations to declare the POJOs to be wrapped. Then Seam identifies those annotated POJOs and

binds the components across the tiers by using interceptors. This allows a smoother tran- sition between tiers. Usually the binding and connecting between the tiers is much rougher in Java EE architecture without Seam. This allows you to then focus your devel- opment on the business, presentation, and persistence tiers without worrying about making them interact. Chapter 5 covers in more depth the interception of the Seam com- ponents as well as their life cycle.

Component Choices

As you know, and as I pointed out earlier, there are many different components that can work for the various tiers. So why should you use JSF + EJB3 + Seam? The simple answer is that the first two are the "new standard." However, there are additional, more-solid answers than that as well. In this section and in the following few chapters you will more closely examine the usefulness and clean implementations (due to being POJOs) of

these components.

Why JSF?

JSF is now a Java standard from the JCP for presentation tier development. Now, just because something is a standard does not necessarily mean it is the best choice, but that you should factor it into the equation. JSF being part of the JCP will guarantee that there

will always be support from an army of developers with skill sets specific to its imple- mentation. Along with this support, there are also a wealth of built-in tools from vendors and third-party programs for creating robust JSF pages. Plug-ins are being cre- ated, and even more are planned to help make JSF pages as easy as possible to create by having drag-and-drop functionality for the various integrated development environ- ments (IDEs). There are also multiple JSF implementations to choose from. Apache's MyFaces is what JBoss uses for its JSF implementation and is what we will be using throughout the book.

Another positive with JSF is its ability to handle multiple presentation tier types. Yes, many other frameworks can be hacked to do that as well, but this is out-of-the-box sup- port. This is achieved through JSF's presentation tier component-based architecture. Although the JSF pages still use tag libraries for the display, the component orientation of the JSF components makes them more than just simple user interface (UI) pieces. The libraries are naturally then more involved with each other.

Another advantage to JSF is that it simplifies the development of code that is called from the client page. In JSF, these listeners are referred to as backing beans. As I said ear- lier, JSF is partially independent from the servlet context, so the backing beans used can be regular POJOs with no knowledge of the Servlet specification. I say partially because they can have access to the Servlet specification if it is directly declared.

Finally, JSF continues to make inroads into the community and with Struts. Many of the former Struts developers used their knowledge of what they did right and wrong in the past to help create the JSF specification.

Why EJB3?

EJB3 provides just about everything you could want for business logic and presentation tiers. You get enterprise-level state-managed classes, Java Message Service ( JMS) listen- ers, and database-level objects. Now, most of you may think, "Well, so did EJB 2.1; why do I need EJB3?" Well, this is all provided without the need for Extensible Markup Language (XML), and all your classes are still POJOs. You no longer have the overhead of multiple interfaces for creation and remotes, no more convoluted deployment descriptors, and no more stub creations. Also, like JSF, this is an industry standard, so you also get the regular cadre of developers working on it as well as different implementations.

Why Seam?

The simple answer to why we are using Seam is to create simplicity from complexity. Regardless of how easy it is to implement JSF and EJB3, they still require you to create backing beans to allow your presentation tier to talk to your business logic tier. With JSF, you have to write extensive XML files telling the presentation tier what kind of domain objects to expect. By using Seam, you can remove extra coding and focus more on the parts that matter-the presentation and business logic.

Seam does this not by creating an extra class such as a JSF action listener, but by using Java annotations. Seam allows you to create a seamless transition between appli- cation tiers by utilizing metadata in the form of Java annotations to define how the presentation and business logic tiers can talk to each other. In addition, Seam also

allows you to define EB domain objects to be used on the presentation tier. The question then becomes, "How are we just removing classes?" or "Were these classes really needed before?" After working with many web frameworks on many projects, I have noticed that often what your action listeners are doing is just translating presentation tier data to some business logic tier object, validating that data, and then sending it over to the business logic tier for processing. If they are doing more than that, you are often mixing business logic into your presentation tier. Seam helps you skip this step.

Of course, there are times where the presentation tier needs to do a bit more, so, if you wish, you can also use regular JavaBeans as your annotated objects as well. If you do this, note that the only reason to do so is because you need to prep the data before send- ing it over to the business logic tier. Based on what I have said thus far, Seam is not adding any features but just taking a few steps away-which, by itself, still makes Seam a valuable tool. However, it also does add some valuable context-management abilities, which allows you to have features such as wizards on your page without having to add a bunch of extra plumbing code. We will get into the details of this in later chapters (Chapters 5, 6, and 7). Hopefully, however, you can already start to see the value of not only Seam, but the combination of Seam, EJB3, and JSF.

Seam Environment Requirements

Because Seam is dependent on JSF and EJB3, it has a few more needs than frameworks such as Spring or Struts. Specifically, Seam requires the following:

. You have to use Java 5 or greater on the front end, because Seam relies heavily on annotations provided by Java 5 or higher implementations of Java Specification Request ( JSR) 250.

. You have to use a JSF implementation for the presentation tier. This means either using an application server that supports it or using an open source provider of JSF such as Apache's MyFaces.

. For the most part, you need to have an application server that uses EJB3. Chapter 9 discusses alternatives to using EJB3. However, it is best to assume that you are either going to be able to use EJB3 now or in the near future.

Hello World Example

So before you dive into the intricate details of Seam and the functionality around it, let's take a quick look at building a simple Seam application. As I have said, it provides the glue between the presentation tier and the business logic tier, specifically EJB3. However, in reality, your business logic tier does not have to be EJBs-it can just be plain Java- Beans. So let's look at a Hello World application done with Seam. In this example, a simple JSF page will call the JavaBean to get the text of outputText that has been initial- ized. We will start with the Seam-annotated JavaBean in Listing 1-1.

Listing 1-1. Our JavaBean, HelloWorldAction.java, with Seam Annotations

package com.petradesigns.helloworld;

import org.jboss.seam.annotations.Create;

import org.jboss.seam.annotations.Name;

@Name('helloWorld')

public class HelloWorldAction implements IHelloWorld

public String getOutputText()

}

As you can see, this is a fairly straightforward Hello World JavaBean. The first @Name

annotation defines for us that this is a Seam component with the name of helloWorld. You will then notice that there are two methods. The init() method has an @Create annota- tion signaling that this method should be called upon instantiation of the JavaBean. The public method getOutputText() can be used to retrieve the output text.

Now that we have the JavaBean, we will create the JSF page needed to retrieve it. The page is defined in Listing 1-2.

Listing 1-2. Our JSF Page, helloWorld.jsp, to Display "Hello World"

<%@ taglib uri='https://java.sun.com/jsf/html' prefix='h' %>

<%@ taglib uri='https://java.sun.com/jsf/core' prefix='f' %>

<f:view>

<h:outputText value='#'/>

</f:view>

This is a JSP page; more specifically, it is a JSF JSP page. The first part contains the standard tag library definitions, and the second part defines the <f:view> component. This is a standard component to encapsulate any JSF functionality and is required.

Finally, our # references the method outputText on the Seam component helloWorld that we defined previously. When this page is run, it gives us the output shown in Figure 1-3.

Figure 1-3. The Hello World screen shot

This is all the code it takes to create a Hello World example by using JSF and Seam. This small application consists of a presentation and business tier, even though our busi- ness tier is not really doing much.

■Note If we wanted to make the JavaBean an EJB3 object, all we would have to do is add the

@Stateless annotation to the class description of the JavaBean.

One of the first things you should notice is our JavaBean representing the business logic. Not only can it be a POJO, but there is nothing in it making it interact exclusively with the presentation tier; nor is there anything on the presentation side telling it to interact exclusively with a Seam component. Seam is handling all that messy middle work usually needed to pipe between the tiers. The end result: you are able to put the bulk of your effort in building a solid business logic tier as opposed to making those objects available to the presentation tier.

I strongly advise you to use my build script included in the source to create this code because there are some intricacies on how to create JSF + EJB3 + Seam that may not be entirely obvious to you yet. These intricacies are explained more clearly in Chapter 5. For now, this can give you a bit to play with.

Introduction to MVC Architecture

If you are familiar with web application design in Java, the MVC pattern is probably fairly well known to you. However, if this is your first time writing a web application, you should follow along closely. This is essentially the pattern that has been followed for designing most web frameworks.

This section presents the MVC architecture and gives examples of various implemen- tations of it, including JSF. For those who are new to web applications, this should help provide some background into how it works.

Basics of MVC Architecture

If this is your first attempt at web development, the concept of Model-View-Controller (MVC) may be new to you. It is the basis for most web application development today. The core principle is to separate your business data from your view components, and then have the ability to translate the data back and forth, as illustrated in Figure 1-4.

Figure 1-4. A diagram of the MVC architecture

The following are the definitions of the MVC parts:

Model: This represents data in the business logic tier and the business rules defining interactions with that data.

View: The view renders the contents of the model for the presentation tier.

Controller: The controller translates the model into the view. The translation will be performed by POST/GET requests from the Web.

Frameworks

A variety of web frameworks have come out over the last few years to implement MVC. For this book we will be using MyFaces, an open source implementation of the JSF speci- fication. However, it would be handy to learn about a few of the others as well.

Fundamentally, all web frameworks work the same way. They all, in some way, extend the Servlet specification. How they usually differ is in how much you are aware that they are extending this specification. When using Struts 1.x and Spring MVC, you are fully aware that your classes are part of the Servlet specification. There are servlet- specific classes such as HttpServletRequest and HttpServletResponse given to you. When using frameworks such as Struts 2 and JSF, you are not as aware. In general, the servlet- specific objects are fairly well hidden and you have to explicitly ask for items such as HttpServletRequest and HttpServletResponse. Finally, with frameworks such as Tapestry, you are not really aware of the specification at all except through configuration files.

Next you will take a look at each of these frameworks. This small preview gives you an idea of what is out there and has been tried and will hopefully give you insight about why you do not have to worry about the nitty-gritty of these when using Seam.

Struts

Struts, one of the first web frameworks, has definitely proved to be the most popular one out there. It works by having a front controller servlet call action classes. The data from the screen is passed into the classes via an ActionForm. With Struts 1.x versions, the user was fully aware that they were working in a presentation tier-and the classes were con- crete, not POJOs. Much of this has been redressed with Struts 2; however, Struts 2 does not have nearly the success and is not used as much as Struts 1.x.

Spring MVC

Spring MVC is a more recent entrant to the MVC game. Spring MVC is distributed with the regular Spring package and can perform business logic as well for a complete Java EE framework. However, Spring MVC is not as new as the rest of Spring. It does provide vari- ous ways of interacting with the presentation tier, and if you are looking for a low-key approach, this can work well. However, Spring MVC does not seem to have the robust- ness of the other web frameworks such as JSF, Struts, and Tapestry.

Tapestry

Tapestry is another web framework that has been around for a long time. The major recent upgrade of Tapestry 4 is powerful. One of its biggest advantages is that, contrary to JSF and most other web frameworks, your Tapestry classes have no knowledge that they are part of a web state because your controller classes (pages in Tapestry) have no knowledge of the

request or the session. However, unlike Seam, these pages are not POJOs but they imple- ment the IPage interface. Another advantage of Seam is the use of Object-Graph Navigation Language (OGNL) for its presentation tier. This allows HTML and Java developers to create HTML pages that can be translated to dynamic code when run in the application server,