Enterprise Java (605.784.31) Fall 2015

This is the course home page for the Enterprise Java Course (605.784), taught at John's Hopkins University, Engineering Programs for Professionals. This site will be populated as the semester progresses and topics are addressed. If you are looking for a version of the full content for ejava-javaee, refer to https://jcs.ep.jhu.edu/legacy-ejava-javaee/.

Legal Disclaimer: The information and opinions expressed within the materials located on this site are the personal contributions of Jim Stafford. Content published here is not reviewed or approved by my employers (The Johns Hopkins University) before it is posted and does not necessarily represent the views and opinions of my employers.

What's New

  • 2015-12-02: Posted Async TODOs
  • 2015-11-18: Posted JMS TODOs
  • 2015-11-11: Posted Security TODOs
  • 2015-11-04: Posted Web Tier TODOs
  • 2015-10-28: Posted Transaction TODOs
  • 2015-10-21: Posted EJB TODOs
  • 2015-10-14: Posted Final Project 1 TODOs, Project2 Spec and Server-side EJB Modules
  • 2015-10-07: Posted JPA-QL TODOs
  • 2015-09-29: Posted Updated ORM Relationship TODOs
  • 2015-09-22: Posted Core JPA TODOs
  • 2015-09-15: Posted EntityManager TODOs
  • 2015-09-09: Activated project and jpa modules in root-level build
  • 2015-09-09: Posted Project 1 description and Business Logic TODOs
  • 2015-09-01: Posted initial class site

Class To Do

    • Setup and deploy your JMS publisher code to eSales. All resources should be injected by the container.
    • Setup and implement a JMS MDB in the eBidbot to receive updates published by eSales.
    • Setup and deploy your JMS publisher code to eBidbot. Again - all resources should be injected by the container.
    • Verify that the JMS JSE Subscriber from last week receives published messages from EJB tier
    • Implement an EJBTimer to perform scheduled work
    • Test, cleanup, document, and turn in project 3

Things you should have finished!

    • Security
      • Finish security configuration, implementation, and testing
    • JMS Message Design
      • Design your JMS message type(s)
      • Write a utility class that publishes the messages. This class ideally would be placed in with the BLImpl classes. However, if it publishes DTO classes, the DTOs may have to get moved in with the BO module to satisfy dependency constraints.
      • Write an integration-test for the publishing and subscribing of the message types designed above. The integration-test should use the topic(s) pre-configured in the class server.
    • JavaSE JMS Client
      • Implement a Java SE Client to receive and log the JMS messages. This client can be placed in BLImpl, must use a selector, and be launchable by the grader using an Ant script. The Ant script can be part of either the BLImpl or RMI Test project. See class examples on how write the Ant script.
    • Project
      • Complete your project 2, finish testing, and turn in.
      • Start project 3
    • Examples
      • Look at updated securePing application for examples on how to perform different logins using EJB Client and JBoss Remoting.
    • EJB
      • Assign EJB to security-domain "other". The RMI Tests should fail access at this point.
      • Specify required roles to access each EJB method
    • Integration Tests
      • Add the necessary logins to your existing integration tests to allow them to pass again.
      • Author at least one new test to demonstrate you have security enabled
    • WAR
      • Assign WAR to security-domain "other"
      • Add security-constraint elements to the WAR web.xml. The user should be prompted for a login at this point and be able to access web pages and EJB methods that they are authorized for and be refused access to what they are un-authorized to access
      • Eliminate access to any information or option the user does not have access to see or use
    • Overall
      • Eliminate the passing of userId information when the appropriate means is to obtain through the EJB or WARs security context.
    • Examples
      • Look over Web UI parts of the ejbsessionBank (Servlets & JSPs) and cdisales (JSF).
      • The webejb example shows an example of RMI and JAX-RS being used as a remote facade. You may use either technique for eBidbot. eSales must use RMI.
    • Web/Project
      • Add a WAR project to eSales. Add in supporting Web UI implementations.
      • Add supporting Web UI implementations for eBidbot. This WAR may obtain functionality implemented by eSalesEJB. However, it should not directly communicate with eSalesEJB. eBidbotEJB should act as a facade for all behavior performed on behalf of eBidbot
      • Re-implement the JUnit end-to-end scenario using a Web UI. Keep both.
    • Examples
      • ejb-jpa-example provides beyond-basic examples of using JPA on the server-side - to include LAZy-load exceptions/solutions, DTOs, caching state with Stateful EJBs, etc.
    • Project
      • Design your remote interfaces and DTO classes for eSales
      • Begin adding the other session beans, remote interfaces, business logic integration, and RMI tests for project 2.
      • Finish implementing EJB use cases for eSales end-to-end testing.
      • Transactions
        • Add @Transaction declarations
        • Implement the transaction test requirement. Remember, your entities must actually hit the DB and be rolled back as part of the transaction. Simply rejecting bad data does not satisfy the project transaction rollback demo requirement.
    • Exercises
      • Continue working through the Java EE exercises (Basic EJB Development, JNDI/ENC Configuration, and JPA/EJB Remote Interfaces). It is highly recommended that you go through this since it takes you through many of the use cases and common issues related to project 2.
    • Examples
      • Continue looking at ejb-basic and ejbsessionBank example applications; which form an EJB, EAR, RMI Test, as well as a WAR Client. These will be key component types within project 2.
    • Project
      • Look over the specification for project 2.
      • Apply the maven, EJB, EAR, RMI Test, and remote interface concepts from the exercises to your project 2.
      • Have one end-to-end thread through eSalesTest, EJB, and project 1 operational
    • DAOs
      • Add indexes to your DB schema to at least account for where clauses used in queries and foreign keys used in relationship joins.
    • Project
      • Finish up project 1 and submit according to the submission guidelines.
      • Perform any desired post-submission refactoring of your project 1 implementation prior to re-use within project 2.
      • Look over the specification for project 2.
      • Apply the maven, EJB, EAR, RMI Test, and remote interface concepts from the exercises to your project 2.
      • Have one IT test deploying eSalesEAR with and EJB and invoking skeletal methods from end-to-end scenario.
    • Examples
      • The class examples have been updated to include the server-side modules. Be be sure to have your jboss server running when building prior to building them from this point forward.
      • Begin looking at ejb-basic-example and ejbsessionBank example applications; which form an EJB, EAR, RMI Test, as well as a WAR Client. These will be key component types within project 2.
    • Exercises
      • Start working through the EJB exercises. It is highly recommended that you go through this since it takes you through many of the use cases and common issues related to project 2. Stop after completing Basic EJB Development
    • Exercises
      • Go through the Query Exercise if you have time.
    • DAOs
      • Finish mapping remaining relationships
      • Refactor or implement any necessary functionality using Queries and JPA-QL.
    • Project
      • Finish adding required business logic for end-to-end testing.
    • Exercises
      • Go through the Relationship Mapping Exercise. This exercise covers issues that come up when mapping Java class relationships to an RDBMs using JPA. There is more there than one could possibly ever finish in the time alloted. Pick and choose which sections are relevant to your project and use it as a reference to refer back to later.
    • JPA Entities
      • Enhance your business objects to include JPA relationships. Be sure to include proper deletion as a part of your cleanup in your test case. This now must take foreign key constraints into consideration (e.g., can't delete parent object when you still have related child)
    • DAOs
      • Enhance your DAOs and DAO unit tests to account for storing parent/child relationships. It is recommended that you *not* use Cascades when starting out. Keep the functionality implemented within the scope of the requirements of the end-to-end scenario. Not every entity and relationship needs full CRUD behavior.
    • Business Logic
      • Fully implement your ingest capability. Provide some sort of verification that the ingest worked. You don't have to test for the entire model ingested, but provide a brief set of sanity checks that compares pre/post and selected information.
      • Implement your populate() method of the end-to-end scenario using your ingest capability. Encapsulate it and your resetAll() within a TestUtilImpl class. Re-use this class as a part of your unit testing. You may want to reference the following examples when implementing this class.
      • Begin filling in business logic methods to satisfy the specified end-to-end scenario. Add unit tests to verify the functionality of the individual business logic methods.
    • Exercises
      • Go through the Entity Mapping Exercise. This exercise covers issues that come up when mapping Java classes to an RDBMs using JPA.
    • JPA Entities
      • Create the remainder of your business objects for the project.
      • Declare the business objects as @Entities and map the classes to tables and columns in your database. Your schema file(s) and JPA DAOs should be using the same database tables at this point. Mark relationships and problem fields as @Transient at this point in time.
      • Add additional bean validation rules to your business objects to address any non-null, minimum, maximum, and pattern constraints you may have.
      • Create unit tests for any non-trivial business rules implemented within the business object classes.
    • JPA DAOs
      • Create unit tests for the ability to create your business objects and get them by primary key. Pay attention to the business rules your application has for ordering the creation (e.g., must have AuctionItem before having a Bid). Solve dependency issues with sensible pre-conditions for child objects.
      • Enact your bean validation rules for @PrePersist and @PreUpdate
    • Business Logic
      • Create unit test for injest and begin implementation of injest for at least one of the types in your model and provided test data. Try to avoid using classes with required relationships at this point. This goal has been achieved when you have instantiated the provided parser within a unit test, read in the provided XML data file, streamed through the data file looking for objects of early interest from the parser, and persisted the objects using one of your DAOs. This will be a thin slice of the overall dataset.
      • Manually validate a DTO or business object using the programmatic validation API in your JUNit test or helper class that is part of the application. Try not to make a specific call from within the business logic.
    • Project Sanity Check
      • Correct and complete your project structure based on comments from your early submission last week. Turn in by due date unless your early submission was previously accepted.
      • Only business logic interfaces, skeletal business objects, and skeletal end-to-end tests are required for the project sanity check. Data tier/JPA topics listed below are not a required part.
      • Complete this before beginning to add details listed below to your project.
    • Exercises and Examples
      • Go through the EntityManager Exercise. This exercise is just as much about covering the details to create a maven module for data tier classes as it is about the JPA EntityManager.
      • Look over the class project example implementation under the projects/eMarket/eSales directory as it relates to integrating JPA within the individual modules.
    • Database Schema
      • Design a draft DB schema for your business object. This should go in the module hosting your DAOs.
      • Implement a way to create your schema in the DB as a part of your DAO testing. Factor in reuse across multiple modules, multiple test cases, and multiple test methods.
    • Maven and DAO Unit Test Framework
      • Add JPA/Hibernate infrastructure to your project DAO/Impl module. This should at least consist of a successful connection to the DB. You are done with this goal when you have a JPA JUnit test for the DAO and the setUp() method is able to create an EntityManager.
    • JPA Entities and DAOs
      • Enhance your business object (BO) definition with @Entity declarations, a non-private default constructor, and a primary key designation (@Id) to make them legal entities. Leave other things default for now. Annotate all collections with @Transient annotation. We are not ready to cover relationships just yet.
      • Design DAO interfaces to support the data access requirements of your business logic participating in the end-to-end scenario. These interfaces should be void of persistence technology detail - but feel free to commit to JPA for the semantics of how the calls should work.
      • Implement an initial JPA implementation for your DAO interfaces. Keep in mind the scope of the end-to-end scenario when building these methods to help limit and focus the work performed.
    • DAO Testing
      • Design and implement a set of unit tests for a few of your JPA DAO(s). Note how the default schema for the @Entities may not match up with your desired DB schema at this point when you run the tests.
    • Project
      • Look over the class project 1 and post any questions.
      • Establish your project directory structure and perform a build from the root.
      • Send me an early submission of your project sometime this week (ideally by Mon evening) in a stable, known but not necessarily complete state. You should have a project structure in place that can build from the root, a good start on the items mentioned above, and a list of issues or questions that you would like answered about how to move forward. This will be used as feedback to the class.
        •
    • Business Logic
      • Create the business logic interfaces and define the operations that will satisfy the end-to-end scenario.
      • Create a JUnit unit test for the business logic to address the requirements for the end-to-end scenario. Place this unit test in with the module containing your business logic and use it to help scope your future work on the project.
      • Create a set of business logic classes to implement the busines logic interfaces. Stub out each call for now so the end-to-end test will execute.
    • Business Objects
      • Create skeletal business object classes necessary to express the vocabulary of the business logic interfaces.
      • Design and implement the basics of a JUnit unit test for a business object (just one). Place this unit test within the module containing your business objects.
    • register for newsgroup and setup e-mail handling (all e-mails will have ejava_class in subject)
    • post at least 1 test message to newsgroup
    • setup development environment by going through exercises 0 and 1
    • post your weekly newsgroup contribution based on development environment setup
    • had a nice break!