Continue to provide all functionality from Project 1; especially the unit tests as you revise your earlier implementations For example, you should continue to have the ability to run the unit and end-to-end tests implemented in project 1. Make sure you design your project 2 testing such that it does not depend on residue from project 1 tests.
Create an EJB tier to host your eSales business logic and data access tiers. Each of the EJBs provided will supply the necessary dependency injection and initialization for the business objects. Transaction scope will be added as a part of a separate requirement. Security will be added in the next project. The main construction, deployment, and remote interfaces of the EJB will be the focus of this requirement. You will have to address the data that gets serialized to the client in a set of Data Transfer Objects (DTOs).
The EJBs will be used to inject and initialize implementation objects and provide a remote interface.
AccountMgmtEJBThis EJB will primarily host the AccountMgmtImpl business logic. A remote interface and bean implementation will need to be designed for this EJB.
SellerMgmtEJBThis EJB will primarily host the SellerMgmtImpl business logic. A remote interface and bean implementation will need to be designed for this EJB.
BuyerMgmtEJBThis EJB will primarily host the BuyerMgmtImpl business logic. A remote interface and bean implementation will need to be designed for this EJB.
SalesTestUtilEJBThis support EJB will primarily host the TestUtilImpl business logic to support remote testing requirements. A remote interface and bean implementation will need to be designed for this EJB.
Create a set of Data Transfer Objects (DTOs) to serialize the state of the business objects between the EJB and client when using the remote interface.
Remember that there can be more than 1 DTO to represent the same information related to a business object. For example, collections might contain summary information only and a single result might contain full details. The following is only provided as a reasonable starting point.
AccountDTOThis class is meant to primarily be an aggregation of the state found in the Account and related POC business objects.
AddressDTOThis class is meant to be a representation of the state found in the Address business object. Depending on how the Address business object is designed, there may not be a need for this stand-in.
AuctionDTOThis class is meant to be a representation of the state found in the AuctionItem and POC business objects.
BidDTOThis class is meant to be a representation of the state found in the Bid and related POC business objects.
Create an EAR to host the eSales server-side components; including the EJB component just developed.
Create a Test project that will deploy the EAR to the application server and run through a set of JUnit test using the remote interface of the EJBs.
Complete and test the eBidbot business logic using the remote interface of eSales. The diagram below shows the business logic within the context of the EJB Tier implemented as a part of a separate requirement.
OrderMgmt/OrderMgmtImplEncapsulates the functionality required to create an automated bidding account, place an order, and check the status of that order. You should be able to test this component using the running eSales application or implement a stub that implements the BuyerMgmtRemote interface. This implementation may return the eSales DTO classes if desired.
Create a WAR module to host the eBidbot server-side components and the remote tests for the WAR/EJB components.
Create an EJB tier to host your eBidbot business logic and data access tiers. To provide practice in alternative deployments, it is a requirement that this EJB either be implemented as part of the implementation module, as part of the WAR module, or part of a combined implementation/EJB/WAR module. Either way, the eBidbot EJBs must ultimately be deployed using a WAR. The EJB(s) provided will have the necessary dependency injection and initialization for the business objects. Transaction scope will be added as a part of a separate requirement. Security will be added in the next project. The main construction, deployment, and remote interfaces of the EJB will be the focus of this requirement.
OrderMgmtEJBThis EJB will primarily host the OrderMgmtImpl business logic. A remote interface, local interface and bean implementation will need to be designed for this EJB.
BidbotTestUtilEJBThis support EJB will primarily host the TestUtilImpl business logic to support remote testing requirements. A remote interface, local interface and bean implementation will need to be designed for this EJB.
The DTOs are be used to serialize the state of the business objects between the EJB and client when using the remote interface. However, with care, business objects can be directly used as DTOs. You are required to re-use the entity classes as DTOs in this application. That means you must account for serialization of the entity class and Lazy-Load issues that can occur during post-transaction marshalling of the entity class.
Add separate Web UIs (WARs) to both applications to demonstrate integration between the Web UI and EJB Tiers.
Tip
In order to save development time and better leverage the work you have already performed in the remote interface testing, you may use the remote interfaces between your WAR and EJB components even though local interfaces would be more efficient when deployed within the same EAR or WAR. This is being done to cut down on the amount of project work for class. You would ideally use the local interfaces when possible. You should already be using the local interfaces between EJBs.
Add a Web UI to the eSales application. This may use EJB local or remote interfaces. The WAR for the Web UI must be deployed as part of the eSales EAR. The Web UI must have the following functionality.
Anonymous User
List open auctions
Get details for specific auction
createAccount (using AccountMgmtEJB)
Test Admin
reset All tables
populate tables (using Ingestor)
Seller
createAction (using SellerMgmtEJB)
getUserActions (using SellerMgmtEJB)
getAuction (using SellerMgmtEJB)
Buyer
Place bid (using BuyerMgmtEJB)
Add a Web UI to the eBidbot application (i.e., to the WAR you have already created for the EJBs). This may use the EJB local or remote interfaces. The WAR for the Web UI must be deployed solo -- containing the EJBs and Impls. The Web UI must have the following functionality.
Test Admin
reset All tables
Admin
createAccount (using OrderMgmtEJB)
Bidder
placeOrder (using OrderMgmtEJB)
Add transaction properties to the EJBs.
Transaction Scope - all session bean methods in these two applications should require a transaction.
Transaction Integrity - add transaction rollback logic to EJBs that detect a move date for a residence is prior to the move-in date.
Create a demonstration of transactions and the capability of rollback by implementing a scenario that adds something to the database and then a *follow-on* rollback causes the changes to be undone.
Note
To satisfy the transaction demonstration requirement, you must actually store something in the database and then later in the transaction roll it back based on some decision. If you make the decision before you store the information -- you are not satisfying the requirement. It is common for students to implement a wrapper around an existing method that takes a collection and populate the collection with good data up front and bad data at the end. The good data that got successfully processed should get rolled back once the bad data is processed. Create remote methods that can tell your RMI client that this actually occured.