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
Deploy EJBs using different deployment approaches (EAR and WAR)
Provide a remote interface to business logic
Provide integration prototype for Web Tier
Expand the current project development architecture to include EJB, WAR, EAR, and remote Test sub-projects for eSales. For eSales you will have separate EJB, WAR, EAR, and RMI Test modules. This is being done to simulate a complex project option.
Expand the current project development architecture to include EJB, WAR, and remote Tests for eBidbot. For eBidbot you will have a single WAR for deployment. You may merge all architectural levels into a single WAR module (or a few other options). This is being done to simulate a simple project option.
Re-host the data access tiers and initial business logic from Project 1 within the new EJB and WEB tiers at component/runtime.
Design the data transfer objects (DTOs) to be used to communicate with clients using the remote interface. For eSales you will design a set of DTO classes separate from your BO classes. For eBidbot you will reuse your BO classes as DTOs.
Create the EAR and WAR sub-projects to host/deploy the Java EE components.
Create the remote Test sub-project(s) to deploy and run tests using the remote EJB interface.
Create and test the WAR sub-project to host the user interface. This component will ultimately be deployed the application server and may use local interfaces of the EJB to access business logic.
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 well tested 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 eSales is complex and requires all levels of architecture and that eBidbot is simple and can leverage various shortcuts. The intent it to show how JavaEE can be used for projects of different sizes and demands. To inially meet satisfy this requirement, you must ...
Deploy eSales as an EAR and eBidbot as a WAR
Implement separate DTOs for eSales and re-use BOs as DTOs for eBidbot
Implement separate Impl and EJB modules for eSales and combine Impl and EJB into a single module for eBidbot. The combined module may be also combined with the eBidbot WAR.
The project will continue along two parallel paths; eSales and eBidbot. However, this time we will add several new project types; EJB, EAR, WAR, and Test. We will add all new project types to eSales. We will add (or migrate to) the WAR type to eBidbot. These new sub-projects will become siblings to your existing eSales Impl -or- BO, DAO, and BLImpl sub-modules. For eBidbot, you have the option of making the WAR a sibling module, the only module, or migrating the existing Impl project to be a WAR project ( and remain with a single module for eBidbot). The new projects will depend on your legacy work. The remote interface of the EJB 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 we 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 eSales 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 an EJB component. This EJB component will supply the EntityManager, control transaction boundaries, provide local interaction for the Web Tier, and a RMI interface for remote clients. Security will be addressed in the next project. To limit the scope of the project, the Web UI requirements will be constrained to a limited number of use cases. You are to deploy eSales using an EAR and eBidbot using only a WAR.
eBidbot will require additional work as well. With a remote interface for eSales 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. We'll try to keep the Web-UI minimal.
You may develop your Web tier in an alternate environment, such as Jetty. However, it must be submitted as part of the application that runs within JBoss/Wildfly.
As with the previous project, the use of the name eMarket, eSales, and eBidbot 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.