Enterprise Java development has changed dramatically in recent years, particularly with the introduction of the Java Enterprise Edition version 5 (Java EE 5) specifications in early 2006. One of the main goals of Java EE 5 was to make the development of enterprise Java applications easier through the use of annotations. Annotations were first introduced to the Java platform with Java SE 5, and allow information about Java classes to be embedded within the Java source files themselves, rather than being stored in external XML files.
Java EE 5 promotes a tiered development pattern by using Session Beans to develop server-side code, and Java Server Faces (JSF) to develop web based user interfaces. The Java EE specification, however, doesn't specify how these two technologies are to interoperate. This is where the Seam Framework fits in, helping to bridge the gap between server-side programming and web development.
In this chapter, we will learn what Seam is and why we, as Java enterprise developers, should use Seam. We'll take a brief look at why Seam is different when compared to the previous frameworks used by Java enterprise developers, and then we'll look at how we can install Seam and the JBoss Application Server. Finally, we'll run some sample applications to confirm whether we've got the infrastructure installed correctly, so that we can learn all about the Seam framework.
As most Java developers will know, there are many web frameworks available to the Java developer. But why Seam? Before we discuss what exactly is Seam and what makes Seam a different framework, let's take a very brief look at the history of the earlier web frameworks.
With the increased popularity of the Model-View-Controller (MVC) pattern and frameworks such as Struts, Java web development suddenly got a whole lot easier. With de facto standard frameworks, developers were able to concentrate on their application logic rather than think about the plumbing of how to develop scalable database-driven web applications. However, with these frameworks, developers still had to think about HTTP requests and responses, and developing effective web-based user interfaces implied writing HTML code.
The next evolutionary stage in web development came in 2004 when the Java Server Faces (JSF) technology was created. JSF uses a component-based approach to web development, unlike previous frameworks such as Struts. This component-based approach opened up the market for drag-and-drop style development environments. If a developer wanted to have a table of results shown on a web page backed by database queries, this could be achieved using drag-and-drop and minimal coding effort. If, for example, the developer wanted to change the user interface to allow the table of results to have clickable column headings, this could typically be achieved by setting a few properties within the IDE rather than having to write lots of Java code and HTML. Oracle's JDeveloper and Sun's Java Studio Creator, amongst others, offered GUI builders for web applications—the type of technology previously found only in GUI designers for desktop applications. All of the modern IDEs (Eclipse, NetBeans, and IntelliJ IDEA) now support this type of drag-and-drop support for JSF development. Examples of such a type of support in Eclipse (using JBoss Tools) and NetBeans 6.1 are shown in the following screenshots.
We've now seen how JSF came to be, and how web development used to be tricky and cumbersome, but how does Seam fit into this web development landscape? What is Seam, and why is it different? In simple terms, Seam is a web framework that makes developing web applications simpler. Because they have become standard with Java EE 5, Seam makes extensive use of annotations to help us achieve this goal. All of the annotations used within Seam applications take common-sense defaults with the aim of cutting down on the amount of configuration required by annotations. This use of default values is called configuration by exception. In most cases, the default values for annotations are correct and applicable to the task at hand, meaning that less configuration data has to be entered into the application code. Of course, it is still possible (and necessary) to change configuration values and add parameters into annotations. But in most cases, configuration by exception helps cut down on the amount of configuration required.
The use of annotations in Seam does not completely remove the need for XML configuration. However, it is greatly reduced when compared to other frameworks such as Spring, Struts, or JSF. With the exception of defining page flows in XML files, Seam rarely uses XML configuration. The XML configuration in these cases is generally very similar among applications, and is not considered a large part of application development.
With the Java EE 5 framework, Dependency Injection has become a standard feature of enterprise application development. Within Java EE 5, Dependency Injection allows components to be automatically set within classes without the need for the developer to call any setter methods. For example, Session Beans can automatically be looked up using the @EJB annotation, or the Entity Manager Factory can be set using the @PersistenceUnit annotation. Seam extends the Dependency Injection capabilities provided by Java EE 5 and allows Seam components to be both injected into and outjected from other components. This facility to perform both Dependency Injection and Dependency Outjection is more commonly called Dependency Bijection, and will be discussed fully in Chapter 2.
The Seam Framework is a stateful framework. Seam components can be declared to have different contextual scopes. These scopes range from stateless (having no state) through to long running scope or application lifetime scope. Frameworks such as Spring and Struts are stateless frameworks in the sense that they do not offer facilities to define scope for components. All of these frameworks allow components to be cached using various caching strategies, but Seam component scope further allows different components to be declared with different levels of scope. This is discussed in depth later in this book.
Seam components are used to define entities and classes that manage entities within an application. Seam does not impose any design patterns on components. We do not need to extend Seam classes or implement Seam interfaces to define Seam components. A Seam component can be any POJO (Plain Old Java Object). In this book, however, we will use Session Beans (both stateless and stateful) as Seam components. This will be useful because of the benefits (security, transactions, pooling, and so on) that Session Beans provide us. With Seam we don't have to use Session Beans as Seam components. A Seam component can be just as easily declared a POJO as can it be declared a Session Bean.
Seam is supplied with, and fully integrates with, the RichFaces component library. RichFaces provides many user interface components, and is described fully in Chapter 6.
JSF didn't really take off as a development model until it became the standard web framework used within Java EE 5 applications. The first versions of Seam used JSF with JSP as the view technology, but this is no longer the view technology recommended by JBoss, and has been superseded by Facelets. Seam also allows other view technologies, such as Flex, GWT, and Wicket, to be used. However, these technologies are not covered in this book. JSF or JSP can still be successfully used as the view technology for Seam applications, and we will be using them in the next few chapters of this book, to learn the basics of Seam. We will discuss Facelets in Chapter 4, when we have a good understanding of Seam, and will see what it offers that JSF does not.
Over the past few years, agile techniques have turned favorable, including Test Driven Development and Unit Testing. Traditionally, testing web applications has been a fairly complex task. However, Seam provides a simple yet effective mechanism for unit testing that includes not only testing our application logic, but also testing the user interface logic. In Chapter 5, we will detail how we can successfully test our Seam applications and provide good test coverage by using the TestNG test tool.
So far, we have discussed Seam as though it were only a web framework. Seam promises to be much more than that. At the beginning of this chapter, we learned that Seam helps bridge the gap between server-side programming and web programming. Well, what exactly does this mean?
In traditional J2EE, Java EE 5 web applications, database tables are typically modeled as either Entity Beans or Entities with Persistence. The typical flow of events in a database-driven web application would be:
1. A web page requests information that is held in the database.
2. The server makes a request to the database and retrieves the entities.
3. The entities are detached (or worse, converted into DTOs) and returned to the web page.
4. The web page displays "dumb" data.
This technique of detaching objects and displaying "dumb" data works quite well for small domain models that don't have many relationships between objects. However, when there are complex relationships, the web client cannot always access the entire domain model, as only certain aspects of the model have been serialized to the client. This can lead to lazy initialization errors, where clients try to access parts of our data model that have yet to be initialized from the database. Seam alleviates this problem by allowing Java EE 5 Persistent Entities to be used within the web tier. In Java EE 5, Persistent Entities are simple POJOs. Hence, full access to an applications domain model is available on the web tier within Seam applications.
Seam provides the Hibernate Validator classes as a part of the framework, and these provide an additional level of entity validation over what the Java EE framework provides as standard. We can therefore validate our entity properties easily in the user interface, to ensure that invalid values are not entered into our domain model.
We will discuss database persistence in depth in Chapter 7.
More often than not, web applications require users to traverse through several pages before completing a given action. Consider, for example, applying for motor insurance. As users of motor insurance web sites, we have to enter our name, address, the use of our motor vehicle, the type of insurance required, and so on, before we can finally get a quote for insurance. Typically, this type of procedure is mapped out as a series of web pages with the Previous and the Next buttons. How many times have you accidentally closed the browser in the middle of applying for or buying something on the Internet? How many times have you pressed the Back button and lost all of the submitted data that you had just entered? Seam provides the solution to these problems in terms of conversations, which we'll discuss in Chapter 8. These conversations can be anything from a simple one-page request/response conversation through to a multipage conversation that lasts several hours or longer!
A conversation is an example of how Seam works as a stateful framework, with a conversation being one of the different levels of component scope.
With the advent of modern web applications and AJAX, users expect a higher level of interactivity within their web applications. The distinction between desktop applications and web applications is becoming increasingly blurry. Manually crafting JavaScript code can be time-consuming and prone to error, and isn't always the best way to add AJAX functionality to an application. The Seam Framework provides AJAX support via tight integration, with the AJAX4JSF library helping to alleviate the issues with writing the JavaScript code manually. We will discuss AJAX4JSF support in Chapter 9.
Most applications need some sort of security access to restrict application functionality between users. Sometimes, a simple level of security access is required, whereby, only logged-on users can access certain pages—for example, so that only registered and logged-on users can post comments on a blog. Sometimes, this level of security isn't sufficient and a role-based security model is required. For example, again in a blog application, only users with the editor role would be able to edit and delete comments. You'll be pleased to know that Seam provides both user-based and role-based security mechanisms. We'll discuss these in detail in Chapter 10.
On top of all of these features that the framework provides, Seam is also supplied with a tool for rapidly generating application skeletons. The SeamGen tool allows application skeletons to be built via a series of interactive questions that are asked to the developer. Throughout the course of this book, we'll first learn how to write Seam applications without using the SeamGen tool, so that we can get a good understanding of the different parts of a Seam application and how they all fit together. Only when we have a solid understanding of what constitutes a Seam application, we'll introduce the SeamGen tool and show the benefits and performance gains that it provides.
As most Java developers will know, there are many web frameworks available to the Java developer. But why Seam? Before we discuss what exactly is Seam and what makes Seam a different framework, let's take a very brief look at the history of the earlier web frameworks.
With the increased popularity of the Model-View-Controller (MVC) pattern and frameworks such as Struts, Java web development suddenly got a whole lot easier. With de facto standard frameworks, developers were able to concentrate on their application logic rather than think about the plumbing of how to develop scalable database-driven web applications. However, with these frameworks, developers still had to think about HTTP requests and responses, and developing effective web-based user interfaces implied writing HTML code.
The next evolutionary stage in web development came in 2004 when the Java Server Faces (JSF) technology was created. JSF uses a component-based approach to web development, unlike previous frameworks such as Struts. This component-based approach opened up the market for drag-and-drop style development environments. If a developer wanted to have a table of results shown on a web page backed by database queries, this could be achieved using drag-and-drop and minimal coding effort. If, for example, the developer wanted to change the user interface to allow the table of results to have clickable column headings, this could typically be achieved by setting a few properties within the IDE rather than having to write lots of Java code and HTML. Oracle's JDeveloper and Sun's Java Studio Creator, amongst others, offered GUI builders for web applications—the type of technology previously found only in GUI designers for desktop applications. All of the modern IDEs (Eclipse, NetBeans, and IntelliJ IDEA) now support this type of drag-and-drop support for JSF development. Examples of such a type of support in Eclipse (using JBoss Tools) and NetBeans 6.1 are shown in the following screenshots.
We've now seen how JSF came to be, and how web development used to be tricky and cumbersome, but how does Seam fit into this web development landscape? What is Seam, and why is it different? In simple terms, Seam is a web framework that makes developing web applications simpler. Because they have become standard with Java EE 5, Seam makes extensive use of annotations to help us achieve this goal. All of the annotations used within Seam applications take common-sense defaults with the aim of cutting down on the amount of configuration required by annotations. This use of default values is called configuration by exception. In most cases, the default values for annotations are correct and applicable to the task at hand, meaning that less configuration data has to be entered into the application code. Of course, it is still possible (and necessary) to change configuration values and add parameters into annotations. But in most cases, configuration by exception helps cut down on the amount of configuration required.
The use of annotations in Seam does not completely remove the need for XML configuration. However, it is greatly reduced when compared to other frameworks such as Spring, Struts, or JSF. With the exception of defining page flows in XML files, Seam rarely uses XML configuration. The XML configuration in these cases is generally very similar among applications, and is not considered a large part of application development.
With the Java EE 5 framework, Dependency Injection has become a standard feature of enterprise application development. Within Java EE 5, Dependency Injection allows components to be automatically set within classes without the need for the developer to call any setter methods. For example, Session Beans can automatically be looked up using the @EJB annotation, or the Entity Manager Factory can be set using the @PersistenceUnit annotation. Seam extends the Dependency Injection capabilities provided by Java EE 5 and allows Seam components to be both injected into and outjected from other components. This facility to perform both Dependency Injection and Dependency Outjection is more commonly called Dependency Bijection, and will be discussed fully in Chapter 2.
The Seam Framework is a stateful framework. Seam components can be declared to have different contextual scopes. These scopes range from stateless (having no state) through to long running scope or application lifetime scope. Frameworks such as Spring and Struts are stateless frameworks in the sense that they do not offer facilities to define scope for components. All of these frameworks allow components to be cached using various caching strategies, but Seam component scope further allows different components to be declared with different levels of scope. This is discussed in depth later in this book.
Seam components are used to define entities and classes that manage entities within an application. Seam does not impose any design patterns on components. We do not need to extend Seam classes or implement Seam interfaces to define Seam components. A Seam component can be any POJO (Plain Old Java Object). In this book, however, we will use Session Beans (both stateless and stateful) as Seam components. This will be useful because of the benefits (security, transactions, pooling, and so on) that Session Beans provide us. With Seam we don't have to use Session Beans as Seam components. A Seam component can be just as easily declared a POJO as can it be declared a Session Bean.
Seam is supplied with, and fully integrates with, the RichFaces component library. RichFaces provides many user interface components, and is described fully in Chapter 6.
JSF didn't really take off as a development model until it became the standard web framework used within Java EE 5 applications. The first versions of Seam used JSF with JSP as the view technology, but this is no longer the view technology recommended by JBoss, and has been superseded by Facelets. Seam also allows other view technologies, such as Flex, GWT, and Wicket, to be used. However, these technologies are not covered in this book. JSF or JSP can still be successfully used as the view technology for Seam applications, and we will be using them in the next few chapters of this book, to learn the basics of Seam. We will discuss Facelets in Chapter 4, when we have a good understanding of Seam, and will see what it offers that JSF does not.
Over the past few years, agile techniques have turned favorable, including Test Driven Development and Unit Testing. Traditionally, testing web applications has been a fairly complex task. However, Seam provides a simple yet effective mechanism for unit testing that includes not only testing our application logic, but also testing the user interface logic. In Chapter 5, we will detail how we can successfully test our Seam applications and provide good test coverage by using the TestNG test tool.
So far, we have discussed Seam as though it were only a web framework. Seam promises to be much more than that. At the beginning of this chapter, we learned that Seam helps bridge the gap between server-side programming and web programming. Well, what exactly does this mean?
In traditional J2EE, Java EE 5 web applications, database tables are typically modeled as either Entity Beans or Entities with Persistence. The typical flow of events in a database-driven web application would be:
1. A web page requests information that is held in the database.
2. The server makes a request to the database and retrieves the entities.
3. The entities are detached (or worse, converted into DTOs) and returned to the web page.
4. The web page displays "dumb" data.
This technique of detaching objects and displaying "dumb" data works quite well for small domain models that don't have many relationships between objects. However, when there are complex relationships, the web client cannot always access the entire domain model, as only certain aspects of the model have been serialized to the client. This can lead to lazy initialization errors, where clients try to access parts of our data model that have yet to be initialized from the database. Seam alleviates this problem by allowing Java EE 5 Persistent Entities to be used within the web tier. In Java EE 5, Persistent Entities are simple POJOs. Hence, full access to an applications domain model is available on the web tier within Seam applications.
Seam provides the Hibernate Validator classes as a part of the framework, and these provide an additional level of entity validation over what the Java EE framework provides as standard. We can therefore validate our entity properties easily in the user interface, to ensure that invalid values are not entered into our domain model.
We will discuss database persistence in depth in Chapter 7.
More often than not, web applications require users to traverse through several pages before completing a given action. Consider, for example, applying for motor insurance. As users of motor insurance web sites, we have to enter our name, address, the use of our motor vehicle, the type of insurance required, and so on, before we can finally get a quote for insurance. Typically, this type of procedure is mapped out as a series of web pages with the Previous and the Next buttons. How many times have you accidentally closed the browser in the middle of applying for or buying something on the Internet? How many times have you pressed the Back button and lost all of the submitted data that you had just entered? Seam provides the solution to these problems in terms of conversations, which we'll discuss in Chapter 8. These conversations can be anything from a simple one-page request/response conversation through to a multipage conversation that lasts several hours or longer!
A conversation is an example of how Seam works as a stateful framework, with a conversation being one of the different levels of component scope.
With the advent of modern web applications and AJAX, users expect a higher level of interactivity within their web applications. The distinction between desktop applications and web applications is becoming increasingly blurry. Manually crafting JavaScript code can be time-consuming and prone to error, and isn't always the best way to add AJAX functionality to an application. The Seam Framework provides AJAX support via tight integration, with the AJAX4JSF library helping to alleviate the issues with writing the JavaScript code manually. We will discuss AJAX4JSF support in Chapter 9.
Most applications need some sort of security access to restrict application functionality between users. Sometimes, a simple level of security access is required, whereby, only logged-on users can access certain pages—for example, so that only registered and logged-on users can post comments on a blog. Sometimes, this level of security isn't sufficient and a role-based security model is required. For example, again in a blog application, only users with the editor role would be able to edit and delete comments. You'll be pleased to know that Seam provides both user-based and role-based security mechanisms. We'll discuss these in detail in Chapter 10.
On top of all of these features that the framework provides, Seam is also supplied with a tool for rapidly generating application skeletons. The SeamGen tool allows application skeletons to be built via a series of interactive questions that are asked to the developer. Throughout the course of this book, we'll first learn how to write Seam applications without using the SeamGen tool, so that we can get a good understanding of the different parts of a Seam application and how they all fit together. Only when we have a solid understanding of what constitutes a Seam application, we'll introduce the SeamGen tool and show the benefits and performance gains that it provides.
So, how is Seam different from other web frameworks, and why should we learn a new technology?
Seam is a stateful, conversational framework, as opposed to being a stateless framework such as Spring or Struts, which provide rapid application development tools that wouldn't be unfamiliar in a RAD environment such as Ruby on Rails. Seam integrates different aspects of Java EE, providing us with a unified development model where we don't need to worry about redundant patterns such as DTOs. We can access our domain model and data model and all of their classes from within our web tier, without worrying about detached classes and lazy initialization errors. Seam uses the Hibernate Validator classes to provide additional validation on classes over what Java EE provides as standard. We could use JPA as our persistence provider if we wished, but by no means is this mandatory.
We can use as many or as few aspects of the Java EE specification as we wish—a simple Seam application could use Servlet and JSF, and be deployed on Tomcat. Alternatively, we could use more advanced Java EE features such as Session Beans and JPA, and deploy our applications to full Java EE Application Servers such as JBoss, GlassFish, or Weblogic. Seam components don't need to extend any Seam classes or implement any Seam interfaces—they can be simple POJOs or Session Beans.
Finally, Seam requires a minimal XML configuration, with the majority of configuration being required as Java annotations, where the default values are usually the correct ones.
To compile and build Seam applications, we need JDK 5.0 or above installed. We also need Apache Ant 1.6 or above (http://ant.apache.org) installed, as we use this as the build tool for the projects that we build throughout this book. Here, we do not describe how to install Apache Ant as there is full documentation for this on the Apache Ant web site.
To run our Seam applications, we need to deploy them to a Java Application Server. Throughout this book, we will be using the JBoss Application Server version 5.0. Many other application servers can be used for deploying and running Seam applications, such as WebSphere, WebLogic, GlassFish, or even Tomcat. However, we will concentrate solely on the JBoss Application Server.
The JBoss Application Server can be downloaded from the JBoss web site at http://www.jboss.org/jbossas/downloads/.
Throughout this book, we will be using JBoss Application Server version 5.0.0.GA. This version is licensed under the LGPL license. Please check and read the license agreement before downloading the software. When downloading JBoss, make sure you download the application server (with a name similar to JBoss-5.0.0.GA.zip) rather than the source code (which has a name similar to JBoss-5.0.0-src.tar.gz). As the application server is written in pure Java, there is only one download for all operating systems. Hence, regardless of whether you are developing on Windows, MaxOS X, or Linux, the download is the same.
After downloading the JBoss Application Server, use your favorite unzipping tool to extract the JBoss Application Server. Once unzipped, you should find the directory structure of the application server to be as shown in the following screenshot.
The JBoss Application Server is started on Windows by executing the<jboss_home>/bin/run.bat command, where<jboss_home> is the directory into which you have installed JBoss (for example, C:\jboss-5.0.0.GA).
Note
The run.bat application can be started with different command switches to start JBoss in different configurations. The default configuration is correct for our Seam applications throughout the course of this book. So, the easiest way to start JBoss is by double-clicking run.bat within an explorer window.
Once started, the JBoss Application Server window will contain a log of all of the startup events that have occurred, and will appear as shown in the following screenshot. If this window indicates any errors upon startup, check whether you have downloaded and installed your JDK correctly before proceeding. Depending upon your hardware configuration, starting the application server can take anywhere between 20 seconds and a few minutes.
To shut down the JBoss Application Server, we can simply press Ctrl+C within the application server console window.
To start the application server in either Linux or MacOS X, open up a command window and execute the<jboss_home>/bin/run.sh command. Refer to the following example:
/Applications/jboss-5.0.0.GA/bin $> ./run.sh
Similar to Windows, press Ctrl+C within the JBoss Application Server window to shut down the application server.
The Seam framework can be downloaded from http://seamframework.org/Download.
The latest stable release of Seam is 2.1.1.GA, which is the version we will be using throughout this book. Download this package from the Seam web site and unzip it into a directory of your choice. The name of the download will be similar to jboss-seam-2.1.1.GA.zip. As with the JBoss Application Server, Seam is platform-independent. So, there is only one package to download and install, irrespective of your operating system. Again, please read the license agreement for Seam, and make sure that you are happy with it before downloading the product.
After extracting the Seam archive, you should see the following directory structure:
Now that we have downloaded and installed both the JBoss Application Server and the Seam Framework, we can deploy one of the sample applications provided with Seam to ensure that we have got everything configured correctly.
To test our environment, we need to:
1. Start the JBoss Application Server
2. Deploy the sample application
3. Run the sample application
As we mentioned in the earlier section, starting the JBoss Application Server is a simple matter of either double-clicking on the run.bat file or executing the run.sh script. Startup the Application Server using the appropriate technique and ensure that there are no errors displayed within the console window.
Each of the Seam sample applications can be built using pre-supplied ant scripts. These scripts allow applications to be built and deployed from the command line.
Before building and deploying these sample applications, we need to edit the <seam_home>/build.properties file to specify the location of the JBoss Application Server. We need to do this so that the compiled application can automatically be deployed to the application server. Edit this file and add a line that sets the jboss.home property to the location of the application server, as shown (/Applications/jboss-5.0.0.GA) in the following example screenshot:
Now that we have started the application server and specified its location within the Seam example configuration files, we can build one of the sample applications to ensure that it runs correctly.
Open up a command prompt (or command shell) and navigate to the <seam_home>/examples/numberguess directory. Within this directory, execute the ant deploy task, which will build the Number Guess example application and deploy it to our running instance of the application server. In the case of the JBoss Application Server, deploying the sample application is simply a matter of the application's .ear file being copied into the <jboss_home>/server/default/deploy directory.
Assuming that no errors were displayed whilst deploying the application, we can open up a browser and point it to http://localhost:8080/seam-numberguess to test the application, as shown in the following screenshot:
In addition to running the sample application, we can run the unit tests that are supplied with it by executing the ant test command. The Seam Framework provides excellent support for unit testing applications, which we will discuss in detail in Chapter 5. For the moment though, execute the test target command and note that several tests run successfully.
In this chapter, we've provided an overview of what the Seam Framework is, and the benefits that we as Java developers, will gain by using the framework.
We've learned that Seam is much more than a web framework, and that it provides:
Java 5 annotation support, allowing Seam components to be configured easily
Dependency Bijection facilities and component lookup, without needing to write large amounts of XML
Integration with both JSF and Facelets web view technologies
First-class support for testing Seam components both as POJOs and within the JBoss embeddable Application Server
Tight integration with RichFaces (including AJAX4JSF) and ICEFaces
An application framework for handling database persistence
AJAX support via integration with the AJAX4JSF library
User-based and role-based security access
A tool for generating skeleton applications
After the introduction to Seam, we saw that Seam can be deployed to many different Application Servers such as JBoss Application Server, WebLogic, and Tomcat. We saw how we are going to use the JBoss Application Server throughout this book, and also how to install, start, and stop this server.
Finally, we looked at how to download the Seam Framework, and how to configure it to allow us to compile and deploy the supplied sample applications.
In the next chapter, we are going to look in detail at the Seam Framework, and will begin our journey of learning how to develop with Seam.
