J2EE applications are the resulting product of multiple compiled Java source files, non-Java source artifacts, and resource files of various formats.
These different artifacts work together to provide the logic and functionality that make the application useful to approaching a particular domain of problems.
Most J2EE applications are composed of one or more J2EE components, and these J2EE components are in turn composed of one or more Java source files. Session EJBs, for instance, require separate compiled class files to define their home interface, remote interface, and bean classes. JSP files are another example of components that rely on multiple files to function properly.
During the development process, it is useful to manage the collection of the source files and resources that constitute a J2EE component in a way that all the files are readily accessible to the developer. This way, changes to files that are related to work being done can be easily implemented, and the resulting deployable artifact from the project can then be easily tested.
Extending this approach beyond individual components to groups of components that compose a J2EE application is immediately apparent. The structure that is used to manage this within Eclipse is a J2EE project. Projects are special structures created within the file system and referenced by the Eclipse Workbench that associate multiple files that are related to a J2EE component.
Several types of projects are supported by JST.
To be clear, projects are not a new feature introduced to Eclipse by the WTP project. Projects have always existed in Eclipse for use in managing myriad activities such as creating Java applications or Eclipse plug-ins.
What has been introduced by JST is the capability to create J2EE projects of various kinds, including web and EJB applications, connectors, application clients, and enterprise applications.
JST Project Types
JST provides Eclipse with the ability to create different types of J2EE application components. Each J2EE application component being created must be defined within a project type that can support such an application component. This means that EJBs must be created within an EJB Project because the EJB project type contains the logic to properly package and deploy the EJBs.
A servlet, which is aWeb Tier component and exists within a Dynamic Web Project, can therefore not be created within an EJB Project. The five types of project introduced by JST are the following:
- Dynamic Web Project
- EJB Project
- This project type is used to create EJB deployment modules that are targeted for deployment within the EJB container of an application server. An EJB Project is used to create session, entity, and message-driven EJB components.
Additionally, this project typically contains Java objects that were created to support the functionality of the EJB components.
- Application Client Project
- This project type is used to create clients that can be employed to access either web or EJB components. Application client modules do not need to be deployed within an application server and only require a Java Virtual Machine (JVM) within which to execute. This project type is often composed of Java objects and additional resources such as image files that are used by these objects.
- Connector Project
- This project type is used to create resource adapters that can access resources from back-end legacy systems known as Enterprise Information Systems (EISs).
- Enterprise Application Project
- Projects of this type are created to hold references to one or more modules from EJB, Web, Application Client, or Connector Projects. While each of the projects described previously can represent a portion of an enterprise application, an Enterprise Application Project is often used to represent a complete enterprise-wide solution to a problem.
The Trouble Ticket application we look at in this book is an example of an enterprise application. The web component within this project provides a mechanism to add to and view a ticket, while the EJB component provides a mechanism to add, update, and delete tickets. Together, both the web and EJB deployable modules constitute the Trouble Ticket enterprise application.
In addition to these project types, WST provides support for the creation of a Simple Project. This project is created as an empty structure within which different static web artifacts such as HTML files and CSS documents can be stored. This works well for the creation of static web pages, which, unlike JST projects, do not need to be packaged into a deployable module.
Most IDEs available today limit each project structure to containing only a single deployment module. This means that, for instance, when a J2EE web application is being created in the form of aWeb Tier project, there can be only one module managed within this project, with the module contents being packaged into aWAR file for deployment of the web application.
To create many WAR file structures that are perhaps targeted at different subdomains of a large problem set will require the creation of multiple project structures to hold each of the deployabable modules. In short, most IDEs only support the creation of a single deployable asset from each project that is managed within them.
By default, JST similarly operates in this default mode of a single module per project. However, it is possible to unleash the full flexibility of the platform to allow the creation of multiple modules within each project. Doing this simply requires setting an option in the Preferences page.
This option is available by choosing Window *Preferences *Flexible Java Project Preference.