Enterprise Java Development@TOPIC@
The business objects encapsulate the core business data and rules of the application. You will design the business objects and then map them to the database. You are required to implement CRUD (Create, Read, Update, and Delete) capability with JPA but you only need to implement the CRUD methods that are necessary to complete the provided end-to-end scenario. You will be required to encapsulate all object to relational (O/R) mapping within the DAOs, descriptor files, and/or class metadata annotations. You will be given a set of test data to initially populate your applications and be the source of data for the ingest requirement. To use the data, you will ingest using a parser supplied by the instructor. There is a sample thread in the projects/eSport/eLeague directory that shows how to use the parser as well as other aspects technology within the project.
The database will have a functional schema and indexes to provide query performance. Business objects will be validated in the database using schema constraints and within the JVM using the Validation API.
The business logic will provide a set of classes with concise methods that map easily to the provided end-to-end scenario. The business logic will ensure proper use of the overall application, delegating some business logic functionality to the business objects and full O/R responsibility to the DAOs. eLeague will have an ingest requirement as well as the requirement to manipulate and add to what was ingested. eClub will start fresh and obtain all data from users and coordinate with eLeague. However, for project 1, eClub will be unable to fully implement data exchange with eLeague because remote interfaces will not be implemented until project2. Some of that must be stubbed at this point. You are only required to implement enough business logic methods that it takes to implement the end-to-end scenarios specified later within this specification.
The test acceptance for the first project will be the unit tests and an integration test that takes the business logic, data access tier, and business objects through a provided end-to-end scenario that will be consistent during the semester. You are required to supply the following tests:
A unit test that implements the steps of the provided eLeague end-to-end scenario
A unit test that implements the steps of the provided eClub end-to-end scenario
At least one unit test per architectural layer (BO, DAO, BL) that demonstrates your ability to test at that level.
The amount of work that you can implement within the bounds of this project spec could be endless if you attempted to account for everything and anything. It is very important that you limit your work to only what is necessary to implement (and test) the functionality required for the end-to-end scenario. That means you may have entities that are designed to be created but never modified while having other entities that go through a full lifecycle. When deciding to add or skip certain capabilities -- always ask yourself "does the business logic need this behavior to implement the end-to-end scenario".
Since the work is for separate applications, we will need to establish two separate application projects for this work; eLeague and eClub. The development can physically share resources (e.g., same database and application server), but should be easily separated. It is suggested that you form a root for the overall eSport work to coordinate integration testing, and then group the lower-level work under two mid-level projects; eLeague and eClub. See some suggested project layouts at the bottom of this specification. A sample set of projects that implement a thin eLeague thread has been made available. Please ignore the sibling eSportData project when using the example to craft your source tree. You will depend on projects within the sibling data tree -- not re-implement them and not copy them. See the Getting Started section towards the end of this specification for a more detailed sample project layout.
You will likely copy significant portions of the thin thread example and other class examples into your project. Be aware that the thin thread and other example pom.xml files inherit from the class root project that provide dependencyManagement and pluginManagement duties. You will either need to also inherit from the course dependencies/pom.xml or compensate by re-defining the management sections in the root pom.xml of your project.
Since students in the class will be producing parallel implementations for the applications and submitting them for evaluation, it is asked that you come up with unique names for your artifacts. This could be done by replacing the "e" in eSport, eLeague, and eClub with a unique name that corresponds to your newsgroup or college login (ex. jcsMarket, jcsSales, jcsBidbot). You should also use this same pattern for java packages (ex. jcs.sales, jcs.bitbot), DB tables (e.g., JCS_), etc.
There should be no use of System.out.println() in the code and all implementations must use a logging API with log4j as the 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.