Welcome!

Ryan LeCompte

Subscribe to Ryan LeCompte: eMailAlertsEmail Alerts
Get Ryan LeCompte via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Apache Web Server Journal, XML Magazine

Apache Web Server: Article

Simplifying EJB Development with XDoclet and BEA WebLogic

Simplifying EJB Development with XDoclet and BEA WebLogic

Are you tired of going through the cumbersome process of creating local/remote component and home interfaces for your EJBs, as well as the necessary WebLogic XML deployment descriptors?

Wouldn't it be wonderful to develop only the particular EJB bean file and have another tool generate all of the necessary interfaces and WebLogic deployment descriptors? Look no further: XDoclet to the rescue! XDoclet is an open-source tool that uses attribute-oriented programming concepts to automatically generate various source code files based on embedded XDoclet-specific javadoc comments. XDoclet is used in conjunction with the Ant build tool to process the various XDoclet comments in the developer's main EJB file. In this article I'll demonstrate how to use XDoclet with BEA WebLogic server to handle the creation of CMP Entity beans and container-managed relationships among CMP entity beans, as well as how to use the various WebLogic-specific XDoclet tags. (Note: The source code was generated using XDoclet 1.2 Beta and Ant 1.5. The source code for this article can be found at www.sys-con.com/weblogic/ sourcec.cfm).)

XDoclet Basics
So how does a developer actually use XDoclet? I've provided a simple business domain model that is implemented as three CMP entity beans with the following relationships:

  • Doctor Bean [M <--> N] Patient Bean (Bidirectional)
  • Patient Bean [1 <--> M] Illness Bean (Unidirectional)
  • Doctor Bean [1 <--> 1] Illness Bean (Bidirectional)

    To simplify matters we assume that:

    1. A doctor can have multiple patients.
    2. A patient can be seen by multiple doctors.
    3. A patient can have more than one illness.
    4. Only one patient can have a certain illness.
    5. Only one doctor can cure any one illness.
    XDoclet is comprised of two types of tags: class-level and method-level tags. Class-level tags are used to set properties of the EJB that characterize a main function, such as the actual bean type and the JNDI name that will be used to locate the EJB. Other options specify the name of the EJB, finder methods, transaction settings, as well as other WebLogic-specific settings. The following is an example from the Doctor bean:

    /**
    * CMP Bean utilizing XDoclet tags to represent a
    * Doctor entity.
    *
    * @ejb.bean
    * name="Doctor"
    * type="CMP"
    * local-jndi-name="Doctor"
    * primkey-field="doctorId"
    * view-type="local"
    *
    * @ejb.persistence
    * table-name="doctor"
    *
    * @ejb.transaction
    * type="Required"
    */

    Method-level tags specify attributes such as a particular method's transactional configuration (if it should appear in the remote/local component interface), create methods, relationship attributes, etc. The following is an example from the Illness bean:

    /**
    * @ejb.interface-method
    * @ejb.relation
    * name="Doctor-Illness"
    * role-name="Illness-Has-Doctor"
    *
    * @weblogic.column-map
    * foreign-key-column="doctor_id"
    * key-column="doctor_id"
    *
    */
    public abstract DoctorLocal getDoctor();

    Container-Managed Relationships
    One of the rather challenging tasks for XDoclet newcomers is establishing various container-managed relationships among CMP entity beans via the XDoclet tags. XDoclet handles relationships with the @ejb.relation tag and @weblogic.column-map for specifying the familiar <column-map> elements that must be listed in the weblogic-cmp-rdbms-jar.xml file. Let's look at an example from PatientBean.java:

    /**
    * @ejb.interface-method
    * @ejb.relation
    * name="Doctors-Patients"
    * role-name="Patients-Have-Doctors"
    *
    * @weblogic.relation
    * join-table-name="doctor_patient_link"
    *
    * @weblogic.column-map
    * foreign-key-column="patient_id_fk"
    * key-column="patient_id"
    *
    */
    public abstract Collection getDoctors();

    Here we are specifying a many-to-many relationship between the Doctor and the Patient beans. The name and role-name attributes will be used to generate the necessary elements in the ejb-jar.xml file. The WebLogic-specific tags specify a common join table for the relationship as well as the <column-map> elements that will be used in the generated weblogic-cmp-rdbms-jar.xml file. A bidirectional relationship is implied here due to the corresponding XDoclet relationship tags in DoctorBean.java. To demonstrate how a windirectional relationship is described, let's look at PatientBean,java.

    /**
    * @ejb.interface-method
    * @ejb.relation
    * name="Patients-Illness"
    * role-name="Patient-Has-Illness"
    * target-ejb="Illness"
    * target-role-name="Illness-Has-Patient"
    * target-cascade-delete="yes"
    *
    * @weblogic.target-column-map
    * foreign-key-column="patient_id"
    * key-column="patient_id"
    */
    public abstract Collection getIllnesses();

    Here we are specifying a unidirectional relationship between the Patient and Illness beans. The target-ejb, target-role-name, and target-cascade-delete are used to specify the other side of the unidrectional relationship. XDoclet tags describing this particular relationship are not included in the corresponding Illness bean, since we are explicitly specifying the related entity from the Patient bean. In a unidrectional relationship, the @weblogic.target-column-map tag is used to specify the related bean's <column-map> elements.

    Other WebLogic-Specific XDoclet tags
    XDoclet supports both WebLogic 6.1 and 7.0 deployment descriptor settings. Instead of describing various WebLogic-specific characterstics for EJBs explicitly in the weblogic-ejb-jar.xml and weblogic-cmp-rdbms-jar.xml files, you can express them using XDoclet tags in the centralized EJB bean file. This eliminates the need to create these XML files manually.

    Following is an example of how to configure WebLogic to autoincrement an entity bean's primary key, set the concurrency strategy element to ReadOnly, and specify that the WebLogic server is not required to call ejbLoad() upon each new transaction:

    /**
    * @weblogic.cache
    * concurrency-strategy="ReadOnly"
    * read-timeout-seconds="5"
    *
    * @weblogic.persistence
    * db-is-shared="False"
    *
    * @weblogic.automatic-key-generation
    * generator-type="ORACLE"
    * generator-name="doctor_seq"
    * key-cache-size="10"
    */

    XDoclet provides many other WebLogic tags that allow the developer to conveniently configure features such as clustering, field groups, and relationship caching in a single bean file via Javadoc comments. Consult the XDoclet documentation for more information on these specific tags as well as other features provided by XDoclet. Utilizing the powerful capabilities of XDoclet with BEA WebLogic Server defintitely facilitates the development of EJBs.

    References

  • http://xdoclet.sourceforge.net
  • http://jakarta.apache.org/ant
  • http://dev2dev.bea.com
  • More Stories By Ryan LeCompte

    Ryan LeCompte is a research assistant with the ACIM Center of the University of Louisiana at Lafayette. Ryan has been selected to engage in research and development at the Center as part of a NSF-funded Research Experiences for Undergraduates Program. He has extensive research and development experience in designing and implementing enterprise solutions based on Enterprise JavaBeans and BEA WebLogic application server technologies. He has developed various J2EE applications that have been deployed by the State of Louisiana, the University and the private sector.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.