Enterprise Java Development@TOPIC@
Continue to re-use and update the implementations from the previously implemented data access tier and initial business logic
Deploy data access tier and business logic as an EJB component to server
Configure server-based components
Deploy EJBs using different deployment approaches (EAR and WAR)
Provide a remote interfaces to business logic using RMI and JAX-RS
Define transaction boundaries using the EJB container
Provide integration prototype for Web UI
Expand the current project development architecture to include EJB, WAR, and EAR components and remote Tests for eLeague. For eLeague you will have separate EJB, WAR, EAR, and remote Test modules to host the new components and test. This is being done to simulate a complex project option.
Expand the current project development architecture to include EJB and WAR components and remote Tests for eClub. There will be a few Maven module options for you to take, but in the end all server-side logic for eClub must be deployed to the server in a single WAR artifact. This is being done to simulate a simple project option.
Create and configure the EJB and WEB components with necessary persistence context (EntityManager), component, and EJB injections.
Deploy the server-side components as part of testing.
Re-host the data access tiers and initial business logic from Project 1 within the new EJB and WEB components deployed to the server-side.
Design and implement transactional behavior of business methods using explicit EJB annotations.
Design and implement remote application interfaces (APIs) to server-side components using RMI (some) and JAX-RS (mostly).
Design and implement data transfer objects (DTOs) to be used to communicate with clients using the remote interfaces. For eLeague you will design a set of DTO classes separate from your BO classes. For eClub you will reuse your BO classes as DTOs.
Create remote tests that verify functionality and compliance with requirements using remote EJB interfaces.
Create a browser-based web user interface (UI) that will be deployed to the server-side as an basic proof of integration concept.
This project and the final project rely heavily on the components from Project 1. You are encouraged to make sure your implementation of Project 1 is sound and resonably tested (within the bounds of the end-to-end scenario) prior to doing too much work on Project 2. You should continue to maintain your JUnit tests for the earlier components while working on these higher level tiers.
We are continuing a theme that eLeague is complex and requires all levels of architecture and that eClub is simple and can leverage any and all shortcuts. The intent is to show how JavaEE can be used for projects of different sizes and demands. To inially meet satisfy this requirement, you must ...
Deploy eLeague as an EAR and eClub as a WAR
Implement separate DTOs for eLeague and re-use BOs as DTOs for eClub
Implement separate Impl and EJB modules for eLeague and combine Impl and EJB into a single module for eClub. The combined Impl and EJB module may also be combined with the WEB module for eClub WAR. It is easily possible for you to implement eClub with only a single WAR module at this time.
The project will continue along two parallel paths; eLeague and eClub. However, this time we will add several new Maven project types; EJB, EAR, WAR, Client (library) and (remote) Test. We will add all new project types to eLeague. We will add (or migrate to) the WAR type to eClub. These new modules will become siblings to your existing eLeague Impl -or- BO, DAO, and BLImpl leaf modules. For eClub, you have the option of:
making the WAR a sibling of the existing leaf Impl module
migrating the existing Impl project to be a WAR project (and remain with a single module for eClub)
making the WAR be the only module (i.e., no mid-level parent)
The new projects will depend on your legacy work. The remote interface of the EJBs will also require specific design of what gets externalized to the client. The remote clients do not share the same address space we had in Project 1 and cannot lazily access relationships. We also cannot afford to serialize the entire contents of a database full of related information. Data Transfer Objects (DTOs) will be part of the EJB remote interface design.
You have finished a significant amount of eLeague during Project 1; the O/R mapping and core business logic of a non-trivial business model. You will now host the data access tier and business logic within EJB component(s). These EJB component(s) will directly supply the EntityManager, control transaction boundaries, supply a local interface, and other features (like security access control) used in the follow-on project. These EJB component(s) may directly implement an RMI remote and JAX-RS web interfaces. However, we will focus the bulk of our remote interfaces on modern WEB-based, REST-like, JAX-RS remote interfaces. Most of the remote access will be provided from the WEB tier using JAX-RS and a browser-based Web UI. You are to deploy eLeague using an EAR and eClub using a WAR.
The business logic for eClub will require additional work as well. With a remote interface for eLeague in hand and the ability to either simulate or operate with a live instance, we can now complete the rest of the the business logic that will also be hosted within an EJB tier to keep from significantly impacting any tests from project 1. The testing of eClub can always assume that a local instance of eLeague can be deployed locally at any time.
You may develop your Web UI in an alternate environment. However, it must be deployed as part of the application that runs within JBoss/Wildfly.
As with the previous project, the use of the name eSport, eLeague, and eClub within the project specification are to be taken as placeholders. Please make an effort to uniquely name your directories, components, Java packages, JNDI names, etc. to help logically separate the parallel project implementations.
There should be no use of System.out.println() in the code and all implementations must use a logging API with the log4j logging provider. You may leave debug in your code, but this should be able to be turned on/off with the proper logging priority changes in the log4j.xml configuration.