- 27.1. Data Tier, Business Logic, and EJB/WAR Support
- 27.2. eSales Access Restrictions
- 27.3. eSales RMI client Authentication
- 27.4. eBidbot Access Restrictions
- 27.5. eBidbot RMI client Authentication
- 27.6. eSalesWAR Access Restrictions
- 27.7. eBidbotWAR Access Restrictions
- 27.8. Interceptors and Validators
- 27.9. eSales JMS Publisher
- 27.10. eBidbot JavaSE Subscriber
- 27.11. eBidbot MDB Subscriber
- 27.12. eSales EJBTimer
- 27.13. eBidbot EJBTimer
Provide all functionality from Projects 1 and 2.
Enhance eSales with access restrictions.
Assign the EJB to the "other" security domain
Restrict access to the EJB methods to appropriate read/write roles using declarative security.
Only users with the esales-user role can access account information but only for their authenticated identity. Derive this information from their login. (i.e., user1 logs in and may only access user1's account as "my account". They do not specify which account they access.
Only users with the esales-admin role may run the test utility functions.
Anonymous users may access Auction information.
Extend your existing eSales RMI Test project and any RMI client(s) to address new authentication requirements.
Add a valid login to your existing tests to re-enable them under the newly secure environment.
Add a new unit test that verifies the access controls of the protected and open methods. This means that -- after fixing access issues in the previous bullet -- you purposely attempt to violate access restrictions from a new JUnit test to show a test of access control.
Enhance eBidbot with access restrictions.
Assign the EJB to the "other" security domain.
Restrict access to the EJB read/write methods to appropriate roles using declarative security.
Only users with the ebidbot-user role may access OrderMgmt (once their account is created).
Only users with the bidbot-admin role may run the test utility functions.
run-as an esales-trusted user when making bids on behalf of a user. This may require the use of a "helper" EJB to encapsulate the scope of the run-as role/identity
Extend your existing eBidbot RMI Test project and any RMI client(s) to address new authentication requirements.
Add a valid login to your existing tests to re-enable them under the new secure environment.
Add a new unit test that verifies the access controls of the protected and open methods. Same comment as above -- after fixing proper access to eBidbot you should have at least one test that demonstrates how the application is preventing unauthorized access.
Enhance eSalesWAR with access restrictions.
Assign the WAR to the "other" security-domain.
Restrict access beyond the main page to users with the appropriate roles. You may use FORM or BASIC authentication. (I suggest FORM for easy logout/login as new user).
Permit only users to only ask the EJB tier for information that is associated with their login. For example, an esales-user/non esales-trusted user should only be allowed to enter a bid for the account they authenticated against.
Enhance eBidbotWAR with access restrictions.
Assign the WAR to the "other" security domain.
Restrict access beyond the main page to users with the appropriate roles. You may use FORM or BASIC authentication. (I suggest FORM for easy logout).
Permit only users to only ask the EJB tier for information that is associated with their login. For example, a eBidbot user should not see an option to reset the database or see another users' account.
Implement a "thin slice" of capability to demonstrate JavaEE interceptors using validation.
Define javax.validation constraints on at least one of your DTOs.
Implement a JavaEE interceptor that gets a Validator injected, intercepts all calls of your EJBs, and runs the validator against each parameter input to the EJB method.
The interceptor can have no knowledge of the specific EJB, method, or parameters it is intercepting and validating.
The EJB can have no knowledge of the interceptor and should do no work to validate the DTO itself.
Extend your eSales implementations to publish a JMS message to a topic whenever information for an auction changes.
Use the emarket-esales-auction topic (JNDI name: topic/ejava/projects/emarket/esales-auction)
Design your JMS Message. You can use any JMS Type and JMS/custom properties you wish. However, know that some subscribers will be filtering on such things as the category or state of an auction.
Have your eSales EJBs publish JMS Messages to the topic when the Auction changes state (created, bid, close).
Add a Java SE JMS subscriber to consume events about Auctions pertaining to a specific category.
Implement a Java SE JMS subscriber that listens for Auctions with a category matching a JMS Selector. This must be a JMS selector, not client-side Java logic.
Simply print the fact that the process was called and the contents reported in the message.
You must launch this subscriber using an Ant wrapper script.
Implement a Message Driven Bean within eBidbot to subscribe to auction closed events.
Use a JMS Selector for the MDB to limit the types of messages consumed.
Update any orders as being closed and with results based on the contents of the JMS message.
Implement an EJB Timer that will allow eSales to automatically wake-up and expire auctions.