Exercises
The exercise starts with a version of today's case study that has a complete set of Session beans, but an incomplete set of Entity beans. Where there is no Entity bean, the Session bean performs direct SQL. The state of affairs is shown in Table 6.4.
Table 6.4. Case Study Session and Entity Beans| Session Bean
| Functional Area
| Functions
| Implementation/Delegation
|
|---|
| Agency
| Applicants
| create, delete, find all
| Direct SQL
|
| | Customers
| create, delete, find all
| Customer bean
|
| | Locations
| add, get details, get plural, remove
| Location bean
|
| | Skills
| add, get details, get plural, remove
| Skill bean
|
| Advertise
| Job
| create, delete, get plural
| Job bean
|
| | Customer
| get details, update
| Customer bean
|
| AdvertiseJob
| Job
| get details, update
| Skill bean, Location bean
|
| Register
| Applicant
| get details, update
| Direct SQL
|
The exercise is to implement an Applicant Entity bean and to update the Agency and Register Session beans to use this new Entity bean.
The Applicant bean should map itself to the Applicant and ApplicantSkill tables and define the following fields:
login
This is the primary key for the Applicant Entity bean.
name
Simple scalar field.
email
Simple scalar field.
summary
Simple scalar field.
location
Should be a reference to a LocationLocal to ensure referential integrity.
skills
Should be a collection of SkillLocal references to ensure referential integrity.
You should find that the structure of your new bean shares many similarities with the Job Entity bean. One difference will be the primary key. The Job bean required a JobPK because it had a composite primary key. For your Applicant bean, you should not need to develop a custom primary key class because applicants will be identified simply by their login—a simple String.
The ApplicantLocalHome and ApplicantLocal interfaces have already been provided; note their similarity to JobLocalHome and JobLocal.
The directory structure of day06exercise is the same as yesterday:
src
The source code for the EJBs and clients.
classes
Directory to hold the compiled classes; empty.
dd
Holds XML deployment descriptors.
build
Batch scripts (for Windows and UNIX) to compile the source and to build the EAR files into the jar directory.
jar
Holds agency.ear: the agency enterprise application. Also holds agencyClient.jar, the client-side JAR file optionally generated when deploy EAR. This directory also holds some intermediary JAR files that are used only to create the previous two jar files.
run
Batch scripts (for Windows and UNIX) to run the JARs. Use the files in the jar directory.
In the detailed steps that follow, note one difference from yesterday is that today you will be defining and configuring the EJB as part of the enterprise application by directly editing the XML deployment descriptors in the dd directory. If you feel uneasy about doing this, there is nothing to prevent you from making the changes through the GUI.
Do note, however, that the build scripts that create the agency.ear file do require that the ApplicantBean.java source exists (even if its implementation is incomplete).
The steps you should follow are:
1. |
Locate the ApplicantBean.java file within day06exercisesrcdata. This should have an empty implementation.
|
2. |
Implement ApplicantBean to support the Applicant and ApplicantLocalHome interfaces supplied. Base your implementation on JobBean, if you want.
|
3. |
Next, modify the AgencyBean Session bean. The findAllApplicants(), createApplicant(), and deleteApplicant() methods should instead delegate to ApplicantHome.
|
4. |
Now update the RegisterBean Session bean. In its ejbCreate() method, it should obtain a reference to an underlying Applicant Entity bean. Each of the business methods should then delegate to this applicant. If you want something to work from, look at the approach adopted by the AdvertiseJob Session bean, delegating to an instance of Job Entity bean.
|
5. |
Update the data_entity_ejbs_ejb-jar.xml deployment descriptor in the dd directory; again, cloning and adapting the Job bean entries will be a good start.
|
6. |
Update the agency_session_ejbs_ejb-jar.xml deployment descriptor to indicate the new dependencies of the Agency and Register Session beans. Both will depend on ApplicantLocal; you should also find that Register depends on SkillLocal and LocationLocal (to call the business methods of Applicant).
|
7. |
The buildDataEntityEjbs script already references ApplicantBean, so there is no need to change it. This causes your classes to be added to the resultant data_entity_ejbs.jar
ejb-jar file.
|
8. |
Now, build the jaragency.ear enterprise application by using builduildAll. Load the resultant EAR file into deploytool, and check that the EJB is correctly defined. If it is not, either make the appropriate changes and run buildAll or make the changes through the deploytool
GUI itself. Then, save the deployment descriptors into the dd directory.
|
9. |
Your agency.ear file is not quite ready to deploy, because the vendor-specific mapping information has not yet been specified. This is most easily generated by deploying the enterprise application from deploytool. The wizard that then appears will ensure that you have the opportunity to indicate any missing information. Then, test by using the AllClients client, invoked using the run
unAll script.
|
10. |
Optionally, you may want to save the auxiliary deployment descriptor to ddagency_ea-sun-j2ee-ri.xml. If you do this, you will be able to build and deploy the application directly from the command line using builduildAll and builddeploy, respectively. However, to obtain the auxiliary deployment descriptor, you will need to manually load the agency.ear file (from the previous step) into WinZip or equivalent and extract the auxiliary deployment descriptor; the deploytool
GUI does not provide any direct mechanism.
|
Good luck. A working example can be found in day06agency (with a correct auxiliary deployment descriptor).
