Chapter 26
Java EE 6 Overview
Starting from this lesson you’ll be learning about Java Enterprise Edition (Java EE or formerly J2EE), which is a powerful, mature, and widely used platform for development of distributed applications. The word enterprise here doesn’t imply that it is only for large-scale applications. Java EE components are used for the development of everything from an application for a local pizza parlor’s website running on a five-hundred-dollar computer to a super-powerful Wall Street trading application that runs on a cluster of hundreds of interconnected servers.
This lesson is an overview of the Java EE architecture, concepts, components, and terms that will be covered in detail in the remaining lessons of this book. The goal of these lessons is to give you an understanding of how to approach the development of Java EE applications by showing you how to build small applications rather than making you read the thousand-page manuscript that would otherwise be required for detailed coverage of this subject.
There are an abundance of online materials and books published on the subject of Java EE, and when you will figure out which components are a good fit for your project, finding materials on the selected topic will not be difficult at all. My task is to help you in making that decision and getting you started in the quickest possible way. The Oracle website Java EE at a Glance is a good complement for this lesson: www.oracle.com/technetwork/java/javaee/overview/index.html.
If you start browsing the Internet trying to find more information on Java EE, you can easily get confused by trying to compare the features of different versions of Java EE components. I highly recommend that you stay focused on the features of Java EE 6, which is the most current platform and the easiest to use. It was released in December 2009.
Go to your favorite online job search engine and search for job listings with the keyword J2EE. Even though J2EE was re-branded into Java EE many years ago, recruiters and job agencies keep referring to this platform as J2EE. Here’s one of many job descriptions I found on a major Internet job board:
- Title: Java/J2EE Engineer with Core Java, Hibernate
- Skills: J2EE, JMS, Spring, MQ, EJB, J2EE, Servlets, JDK, Core Java, Websphere, Junit, log4j, Apache, Oracle, SQL
- The candidate should know:
- * Core Java 6
- * Expertise in EJB, J2EE, Servlets
- * Expertise in Web Services, JAX-WS, JAX-RPC
- * Working knowledge of Hibernate, JDBC, JPA (Oracle)
- * Java Frameworks: JUnit, Log4j
- * Oracle 11, SQL
- * Expertise in Development IDEs: Eclipse/RAD
- * Knowledge of Spring framework
- * WebSphere Application Server v6/7
- * JMS and WebSphere MQ v6/7
How many items from this list of skills did you recognize after mastering the first 25 lessons of this book? You know Core Java 6, JDBC, Eclipse, and SQL. After studying the remaining lessons you’ll understand what other skills are required in this ad, why they are required, and how they all fit together. You’ll also have technical knowledge of many of the buzzwords listed there.
JCP, JSR, and Other Acronyms
The Java community is accustomed to lots of acronyms. Initially these acronyms might sound intimidating and confusing, but with a little effort they will make perfect sense and explain the way the Java ecosystem lives and functions.
Each version of Java EE includes a set of specifications for various technologies, such as Servlets, JavaServer Pages (JSP), Enterprise Java Beans (EJB), and Java Messaging Service (JMS). Each of these specifications has been defined by an organization called the Java Community Process (JCP). If a person or a group of people decides to propose a specification for some future technology, it will create a Java Specification Request (JSR) and form a group of experts to work on this specification. JSRs are numbered. For example, the specification for Servlets 3.0 was described in JSR 315.
If you decide to get familiar with any specific JSR, visit the website http://jcp.org. Currently Java EE includes 45 JSRs, Java SE has 44, and Java ME (Micro Edition covers small devices) has 85. In other words, Java EE is based on standards. If you’d like to get hold of the 33 specifications that were included in Java EE 6, they are described in JSR 316 and are available at http://jcp.org/aboutJava/communityprocess/final/jsr316/index.html.
Tiers of Java EE Applications
A typical distributed Java application can be divided into three or four logical tiers. (If the application is getting data directly from a DBMS, as described in Lesson 22, it has a two-tier client-server architecture, and Java EE components are not needed.) Figure 26-1 shows selected technologies and possible ways of building a distributed application that includes Java EE tiers or layers.
The client tier can be implemented on a user’s desktop, notebook, or mobile phone, or any other device that has JRE or can connect with Java on the web server. You can create a client as an independent Java application, an applet, or a thin client (an HTML/JavaScript file running in a web browser). The word thin refers to the fact that no business processing is being done on the client side, so the server has to work hard processing all application logic for all clients.
If you’re building a web application, the web tier (aka the presentation tier) comes into the picture. You have your choice of JSP, JavaServer Face (JSF), Servlets, or web services. These components are responsible for the look of your thin client. Java Swing and JavaFX are typically (but not necessarily) used as fat clients of web applications. The word fat here refers to the fact that the client can contain some business logic, which minimizes the load on the server.
The business logic of your application is placed in the business tier, which is represented by EJBs. In the past EJBs were pretty heavy components and third-party frameworks such as Spring (see Lesson 35) became a popular choice for implementing the business tier. But Java EE 6 will regain its market share in this department because it’s a light POJO- and annotation-based technology that incorporates the best features of the third-party framework. POJO stands for plain old Java object — a Java class that can be written any way you want and doesn’t have to extend any framework class or implement mandatory interfaces. This term is easily understood by people who witnessed the evolution of EJBs, which were Java classes that had to be written and deployed in a certain convoluted way and accompanied by heavy XML configuration files. Things changed drastically, and now EJBs have turned into POJOs marked with annotations. If for some reason you skipped Lesson 24 on annotations, you should go back and study it; otherwise you won’t understand most of the remaining material in this book.
While drawing the diagram for Figure 26-1, I moved the Web Services box a couple of times between the presentation and business tiers. On one hand, Web Services (see Lesson 34) are based on web communication protocols; on the other hand they can serve as a façade hiding anything, including an entire legacy application written in COBOL on mainframes. In the final version of my diagram, Web Services span both tiers and exist as a separate box in the data tier.
Using DBMSes remains the most popular but not the only way to store data in enterprise Java EE applications. The data can be served by an external web service or arrive as a real-time feed from some messaging infrastructure. MOM stands for message-oriented middleware, and you’ll learn what it is in Lesson 30.
Without some practical example, all these new buzzwords may not make much sense to you. You’ll see examples in the upcoming lessons, but let’s just briefly discuss how you can rebuild the Stock Market application that you already started developed using sockets and RMI.
- Have an applet to connect to StockQuoteServlet, which creates what is known as a session EJB called StockMarketQuote, which connects to external stock exchange software and requests a price quote on the specified symbol(s). This session bean has a timer that updates the quotes every second.
- Do as described in the previous bullet, but replace the applet with a thin HTML client.
- The same as before, but replace the Servlet with a JSP.
- The same as before, but replace the JSP with a JSF.
- The same as before, but replace the session bean with a timer with a message-driven bean (MDB) that subscribes via MOM to the external stock exchange application that sends back new prices only when they change.
- The same as before, but add a session bean with business that will process every price quote received by MDB and apply a secret modeling algorithm, and on certain conditions send a message to buy or sell a specific number of shares of the suggested stock to a third-party trading system via a call to a web service.
Is this enough? I can keep going. As you can see, there are many ways to design a distributed Java EE application. This is what Java architects do for a living.
Containers versus Application Servers
Java EE tiers are implemented in containers. It’s easy to guess that containers were created to contain something. In the Java EE world containers not only contain, but also control the birth, life, and death of Java components. For example, you don’t need to write the new statement to create a new instance of an EJB; the container will create a pool of them based on configuration parameters. Even on the client side, while reading about applets you might have noticed that applets’ life cycles are controlled by the JRE, which can be called an applet container. Basically, a container is an area inside JVM that can support a lifecycle of certain types of Java objects, such as applets, servlet, EJB, etc.
Containers can take care of various functions, and one of them is thread safety. It’s great that multiple clients can connect and make requests to the same server, but can you be sure that a thread initiated by Mary won’t interfere with John’s thread? An EJB container implements a single-threaded model ensuring that each client’s request operates in a dedicated thread. Containers may offer transactional support with Java Transaction API (JTA) and persist data for you with Java Persistence API (JPA).
In the first few lessons I used a blueprint analogy to explain the relationship between Java classes and objects. I’ll use this analogy again, but this time to explain the relationship between the Java EE specification and application servers. The Java EE is a specification, and when a release is published, vendors who want to implement it in their software products create application servers that support this specification.
Multiple vendors offer their versions of a Java EE application server. The question is what version of the Java EE specification they support. Currently the application servers GlassFish (Oracle) and JBoss (Red Hat) support Java EE 6. At the time of this writing WebLogic (Oracle) and WebSphere (IBM) are still on Java EE 5, but should offer support of the latest specification soon.
Java EE application servers have to support multiple containers, for example a Servlet container and an EJB container. Some vendors prefer to create products supporting only certain technologies defined in the Java EE specification. For example, Tomcat (Apache), Jetty (Eclipse Foundation), and Resin (Caucho) offer support for selected technologies (such as Servlets and JSP), which makes them suitable for implementing web applications, but if you are planning to create web applications based on one of these products, you’ll need to figure out what other tools or frameworks will be needed to support transactions, the business tier, data persistence, and more.
In this book I’ll be using GlassFish 3 from Oracle, which is fully compliant with Java EE 6. I have selected the most widely used technologies in Java EE development today. In particular you’ll be learning about the following:
- Java Servlets 3.0
- JSP 2.2
- EJB 3.1
- JPA 2.0
- JTA 1.1
- CDI 1.0
- JMS 1.1
- JAX-RS 1.1
Two of the acronyms in this list have not been spelled out yet in this book. CDI stands for Context and Dependency Injection and JAX-RS is Java API for RESTful Web Services. You may feel overwhelmed with all these terms, but I’ll try to explain them in easy-to-understand language.
Although Java EE 6 offers a full stack of server technologies, most of the real-world applications don’t need all of them. In the past, to get Java EE certified, a vendor of an application server had to implement all JSRs that were listed in the Java EE specification. But most of the applications don’t use all technologies included in full Java EE specification. This is how that concept of a profile came about. A profile is a preconfigured subset of Java technologies geared toward solving a specific type of application. Currently, besides the Full Profile, there is the Web Profile, which is designed specifically for the development of web applications. Web profiles include Servlets JSF, JSP, CDI, EJB Lite, JPA, JTA, Interceptors, Managed Beans, and Bean validation.
In the future new profiles may be created to address specific needs of developers. For example, chances are that a new profile will be created for developers for small devices. In general, the mechanism of lightweight profiles should encourage vendors of web containers to expand their support of Java EE by implementing web profile components. For example, creators of the Resin container are focusing on the implementation of a web profile.
Pruning is a way to reduce the size of the Java EE platform. The pruning process starts with marking in JavaDoc the technologies that are candidates for removal. Then, based on the reaction of the Java community, they will be either removed from the future specifications or not. As an example, some of the Java EE components (such as EJB 2.x) will be removed in Java EE 7.
You may say, “I want my RMI-based stock server application back. Why make things so complex?” The reason is that the only instance of UnicastRemoteObject in our RMI StockServer may need to process thousands of concurrent user requests, and because of this you’ll need to write code ensuring that such concurrent processing is thread safe.
Servlet and EJB containers are scalable and they take care of all multi-threading issues, enabling you to write application code as if the application were the only user! This alone should be a good reason for using the Java EE stack as opposed to RMI. Without going into a detailed comparison between RMI and Java EE, I’ll just add that if you need to deploy your StockServer application on the Web, corporate firewalls won’t allow clients that use the JRMP communication protocol required by RMI.
Java EE is a very robust, reliable, and scalable platform and you will appreciate what its container will do for your code. I’ll just mention a couple of concepts here.
If you want Java EE containers to help you, help them by providing configuration parameters (annotations) that specify how many instances of the same session bean StockMarketQuote you want pre-created for you by the EJB container. Each of these session beans may be “rented” from a pool to the client’s request, and then put back. How many beans do you need? I don’t know. I don’t have enough information at this point, as it depends on the load on your system — the number of concurrent (simultaneous) requests for price quotes that have to be supported by your system.
Java EE implements dependency injection. An object doesn’t have to reach out to get the resources it needs, because the container injects the resources into the object using annotations. you’ll see examples of CDI later in the book.
Interceptors offer a mechanism by which containers can intercept method invoked on your session beans. When the call is intercepted you can specify additional code to be called before or after the method is executed. For example, imagine that you need to add logging before certain methods are called. Adding interceptors is an easy way to do this.
Integration of Java EE 6 with third-party web frameworks like Spring and Hibernate is made easy by web fragments.
Starting in the next lesson you’ll have a chance to apply all these concepts and features.
This lesson was a high-level overview of the Java EE 6 platform. The hands-on exercises starting from the next lesson will require that you have an application server installed, and installing the GlassFish v3 server is your next assignment.
Lesson Requirements
You should have Java installed.
Hints
NetBeans IDE has very good support for Java EE 6. By now switching from one IDE to another should be as easy for you as switching from one bicycle to another. If you’d like to experiment with NetBeans 7 IDE instead of Eclipse, download the Java bundle from http://netbeans.org/downloads/index.html — it includes NetBeans 7 IDE with the GlassFish v3 server packaged and preconfigured.
Step-by-Step
1. Download GlassFish Server Open Source Edition. At the time of this writing the latest version, GlassFish 3.0.1, is available at the following URL: https://glassfish.dev.java.net/public/downloadsindex.html#top.
2. Click the Download button, and the next web page will offer downloads for Windows, Linux, and Mac OS. You will have your choice of two profiles: full platform and web profile. Get the full platform distribution for your OS and follow the installation instructions.
3. If you are using Windows, just run glassfish-3.0.1-windows.exe.
4. Mac OS users should use the Unix distribution called glassfish-3.0.1-unix.sh. In the Terminal window set the executable permissions and then run the installer:
chmod +x glassfish-3.0.1-unix.sh ./ glassfish-3.0.1-unix.sh
5. During the installation process you’ll be asked to select the directory where GlassFish Server will be installed. In my case, on Mac OS, it’s /Users/yfain11/glassfishv3.
6. Select and enter the password on the next screen, shown in Figure 26-2. Note that by default GlassFish Server will run on port 8080 and the port for server administration is 4848.
7. Click Next and Install on the next two pop-ups. The installation process will start and at the end you may optionally register your newly installed copy of GlassFish Server. Your installation process is complete.
8. Download the Oracle GlassFish Server 3.0.1 Quick Start Guide from http://docs.sun.com/app/docs/doc/821-1757 and test your server by starting and stopping the default domain as described in this document. For reference, here’s the output in my Terminal window after I start GlassFish on my Mac:
yakov-fains-macbook-pro-2:bin yfain11$ ./asadmin start-domain Waiting for DAS to start ........... Started domain: domain1 Domain location: /Users/yfain11/glassfishv3/glassfish/domains/domain1 Log file: /Users/yfain11/glassfishv3/glassfish/domains/domain1/logs/server.log Admin port for the domain: 4848 Command start-domain executed successfully.
After the server has successfully started, open your web browser and enter http://localhost:8080/ — you should see the GlassFish welcome page.
Please select Lesson 26 on the DVD with the print book, or watch online at www.wrox.com/go/fainjava to view the video that accompanies this lesson.