Streamline Your Java Web Applications Using Java Server Faces and Managed Beans
- Java Application Layers
- A New Perspective on Application Layer Integration
- A Simple JSF Example
- Running the JSF Application
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many Java programmers have worked with or used Java Beans in their web applications. It has become a timely art, but since the introduction of web services it has slowly faded away. The strength of Java Beans is their capability to manage complex transaction states while providing an easy interface for hiding the class implementation. But most of all, Enterprise Java Beans (EJBs) were designed for distributed components to work across different servlet containers.
It was a good idea, but expensive in terms of remote invocation calls between Java components across the network, and really didn't take off like its successor, web services.
A lot of the web service frameworks took ideas from EJB frameworks, especially for providing remote method access across disparate networks. The strength of web services is that these components can reside on any system and communicate with other components on any other systems, much like EJBs. You could probably say EJBs were primitive web services for only Java-based components and containers. Now, with web services, you can communicate across language boundaries that include components from multiple languages that reside in applications on different web servers.
EJBs have since evolved more or less into POJOs (Plain Old Java Objects) that have removed the need for multiple interface types. With Java 6, you can use Java Server Faces (JSF) 1.2 and EJB 3.1 managed beans to streamline your applications by reducing the number of steps needed to handle requests.
Managed beans in EJB 3.1 are used as the "backing beans" behind JSF events and no longer require interfaces along with handling their own persistence data. EJB 3.1 introduces the concept of a no-interface view, consisting of a variation of the Local view, which exposes all public methods of a bean class. Session Beans are no longer required to implement any interface anymore. The EJB container provides an implementation of a reference to a no-interface view, which allows the client to invoke any public method on the bean, and ensuring that transaction, security, and interception behave as defined.
EJBs are commonly used with Struts, but now with Java Service Faces (JSF), which was built on Struts, you can make your application's Presentation layer much more effective than what Struts provided. JSF uses an event driven model for the Presentation layer (JSPs) that easily raise and handle events with managed beans. Think of JSF as Java Swing[md]but for web applications.
In this article, I will show you how you can remove at least one integration layer in your application, making your application architecture much easier to follow and more adaptable by using EJBs as your managed beans behind Java Service Faces.
Java Application Layers
Most Java programmers have used Data Transfer (DTs) and View Objects (VOs) in their EJB applications. Often, just to get from Presentation layer to your Enterprise Information System (EIS) layer that contains your back-end storage, requires going through some hoops.
For example, using the three-tier model, view, controller architecture for large Java applications typically goes like this:
- User requests a JSP.
- JSP calls a servlet (front controller in the model, view, control architecture).
- Servlet directs request to a Java Action class.
- Java Action class calls a Delegate method.
- Delegate method calls an EJB interface.
- EJB goes to the database or calls other EJBs to collect information required by request.
- EJB passes information back in a VO object.
- VO object populates a form bean.
- Servlet routes response to appropriate JSP on success/failure.
Whew! Even in a nutshell, that's a lot of hoops to go through for one request, even if you're using Entity (Persistence) Beans to interact with the database.
Steps 1, 2, and 3 involve the application's Presentation layer. Steps 4 and 5 involve the Business Logic layer. Steps 6 and 7 involve binding the Business Logic layer to the database layer (Web and Persistent tiers of the EJB container). And finally, steps 8 and 9 come full circle back to the Presentation layer with the response.
What if I told you that we can get rid of four of these steps and yet still maintain a solid model, view, controller architecture? You're in luck, because with Java Server Faces and managed beans, we can do just that.