To make it easy if your just starting out with J2EE using JBoss, we will make use of the example applications provided in the J2EE tutorial, in particular the Duke’s Bank application. The J2EE tutorial explains how to run the applications using the J2EE SDK Reference Implementation server. Our aim is to show how to deploy and run them in JBoss, and we do so by supplementing the J2EE tutorial where necessary with JBoss-specific configuration information and deployment descriptors.
You can find the J2EE tutorial on-line at http://java.sun.com/j2ee/1.4/docs/tutorial/doc/. You should read the "Getting Started" [6] information in the J2EE Tutorial and download the example code from http://java.sun.com/j2ee/1.4/download.html#tutorial. Unpack/Uncompress that code with whatever the correct tool is for your system and then you'll end up with a directory named j2eetutorial14. You can get the JBoss code on the JBoss documentation page, http://www.jboss.org/docs/index. Unpack/Uncompress the JBoss example code into the J2EE tutorial directory j2eetutorial14. This code provides the JBoss specific configuration and deployment descriptors.
Additionally, we also use the Apache Ant build tool, which you should download and install. You can get an up-to-date copy of Ant from http://ant.apache.org/. We recommend using version 1.6.2 or later with this tutorial. Ant is almost universally used in Java projects these days so if you aren’t already familiar with its use then we recommend you spend some time reading the documentation that comes with it and learning the basics of Ant build files. The default file name is build.xml, and it contains a set of targets which you can use to perform automated tasks in your project. Usually all you will have to do is run the Ant command in the directory which contains the build file. The default target in the file will perform the necessary operations to build and deploy the tutorial applications.
J2EE technologies are designed so that the code is independent of the server in which the application is deployed. The deployment descriptors for EJBs and web applications (ejb-jar.xml and web.xml, respectively) are standard and also do not need to change between different J2EE containers. However, there are still one or two things that need to be done in order to move the application to JBoss. In particular, we have to supply JBoss-specific descriptors and make sure that the database scripts will work.
Container-specific information is usually contained in extra XML descriptors which map logical information used in the application (such as JNDI names and security role names) to actual values which are used in the server. JBoss uses separate files for the EJB and web modules of an application, called jboss.xml and jboss-web.xml respectively. There is also a client version of these files which fulfils the same role in a Java client, in combination with the J2EE application-client.xml descriptor. If container-managed persistence (CMP) is being used for entity EJBs, it is also possible to configure the JBoss persistence engine through the jbosscmp-jdbc.xml file.
The J2EE SDK comes with the Cloudscape database and this is used throughout the tutorials. We will be using the Hypersonic database which runs as an embedded service within JBoss.
In a real-world situation, porting an application to a different databases is rarely straightforward, especially if proprietary features such as sequences, stored procedures and non-standard SQL are used. For these simple applications, though it is relatively easy. When we look at the Duke’s Bank application in the next chapter, you will see that there are only a few minor syntax changes required in the database scripts.
We’ll look at how to configure JBoss to use a different database in Chapter 8, Using other Databases.
J2EE defines how you specify security constraints within your application, but doesn’t say how the authentication and access control mechanisms are actually implemented by the server or how they are configured. As we mentioned earlier, JBoss uses JAAS to provide a pluggable means of incorporating different security technologies in your applications. It also comes with a set of standard modules for the use of file, database and LDAP-based security information. We’ll start out using file-based information as this is the simplest approach.
The examples here are only intended to get you up and running with JBoss and to help you familiarize yourself with the basics. The applications definitely aren’t intended to reflect how you should go about writing production J2EE software - indeed there is a lot of differing opinion on this subject. Many people disagree on the use of EJBs for example, particularly the use of entity beans; the use of bean-managed persistence is especially controversial yet is convenient for examples. There is also endless debate about the use of different web technologies (it would be safe to say that not everyone loves JSPs) and the numerous different Model-2 frameworks that are out there. Struts was one of the first and is probably the best known but is not without its critics. We’ve provided some sources at the end of this chapter which you can check out for more information.
If you’re starting out, your best bet is probably to look at some existing open-source projects and see how they are structured, and then pick something appropriate for your project.
Finally, we hope you’ll realize that there’s a lot more depth to JBoss than we can hope to cover here and once you’ve worked your way through this basic introduction, we hope you’ll be eager to learn more. JBoss is also a continually evolving project with lots of plans for the future. So keep an eye on the bleeding-edge version, even if you’re running all your production applications on the stable 4.0 series.
[6] In the current J2EE 1.4 Tutorial, there are two "Getting Started" sections specifically. 1) GS with Web Applications 2) GS with Enterprise Beans.