Java EJB Introduction to EJBs: Part 3

Introduction to EJBs: Part 3


This is the third of four installments that make up Chapter 4: Introduction to EJBs from the book Sams Teach Yourself J2EE in 21 Days (ISBN:0-672-32384-2) written by Martin Bond, Dan Haywood, Debbie Law, Andy Longshaw, and Peter Roxburgh, published by Sams Publishing.


How Do I Create an EJB?

You will create specific types of EJB as you progress through the book.
However, the creation of EJBs follows the same steps and principals for all
types of EJB.

The Creation Mechanism

As you may have gathered from the previous discussion on EJB contents, the
EJB developer must go through the following cycle:

  1. Design and define the business interface. This may involve mapping from a
    UML model of the solution into Java.

  2. Decide on a bean type appropriate to the task in hand. Entity, Session,
    and Message-driven beans all have their own pros and cons. If you choose to use
    a Session bean, another question is whether to use a stateful Session bean or a
    stateless Session bean. Choice of the appropriate type is discussed in more
    detail on Days 5, 6, 7, and 10.

  3. Decide which home interface methods are appropriate for the bean type and
    define the home interface for the EJB.

  4. Create (or generate) a "boilerplate" bean with correct
    lifecycle methods.

  5. Create your business logic by filling out the business
    methods.

  6. Fill out lifecycle methods to control creation,
    destruction and to manage state (if applicable).

If your EJB classes are written correctly, all that remains is to wrap them
up as a deployable unit. However, there are certain caveats you should bear in
mind while creating your bean.

Caveats on Code Creation

Due to the managed nature of the bean lifecycle, the EJB container imposes
certain restrictions on the bean including:

  • EJBs cannot perform file I/O. If you need to log messages or access
    files, you must find an alternative mechanism.

  • EJBs are not allowed to start threads. All threading is controlled by the
    container.

  • EJBs cannot call native methods.

  • EJBs cannot use static member variables.

  • There is no GUI available to an EJB, so it must not attempt to use AWT or
    JFC components.

  • An EJB cannot act as a network server, listening for inbound
    connections.

  • An EJB should not attempt to create classloaders or change factories for
    artifacts, such as sockets.

  • An EJB should not return this from a method. Although not
    strictly a restriction (the container will not prevent you from doing it), it is
    identified as being a very bad practice. This relates to the earlier discussion
    that a bean should not implement its associated remote interface. This would
    potentially give a client a direct remote reference to the bean rather than the
    EJBObject. Instead, the bean should query its EJB context for a reference to its
    associated EJBObject and return that to the caller.

For a full list of restrictions, see section 24.1.2 of the EJB 2.0
specification (available online at
http://java.sun.com/products/ejb/docs.html).

Create the Deployable Component

One alternative definition of a component is "a unit of
deployment." Following this theme, a component should

  • Contain all the information required to deploy it, above and beyond the
    classes. This is the metadata discussed earlier.

  • Be bound up in such a way that it can easily be transported and deployed
    without losing any parts along the way.

Consequently, after the classes and interfaces for an EJB have been created,
the following steps must be performed:

  1. Capture the EJB's metadata in a universally understood format. This
    takes the form of an XML-based deployment descriptor (DD).

  2. Bundle
    the classes and deployment descriptor up in a deployable format, namely a JAR
    file.

The Deployment Descriptor

The EJB specification defines a standard format of an XML deployment
descriptor document that can house EJB metadata. The exact format of a
deployment descriptor is usually hidden behind tools that manipulate them on
your behalf. However, it is worth examining some of the contents of a deployment
descriptor to see how the EJB fits together and how extra information and
metadata is provided.

Listing 4.5 shows the deployment descriptor for the example Agency EJB.

Listing 4.5 Agency Bean EJB Deployment Descriptor

 1: <?xml version="1.0" encoding="UTF-8"?>
 2: 
 3: <!DOCTYPE ejb-jar PUBLIC 
 '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'
 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
 4:
 5: <ejb-jar>
 6:  <display-name>Simple</display-name>
 7:  <enterprise-beans>
 8:   <session>
 9:    <display-name>Agency</display-name>
 10:    <ejb-name>Agency</ejb-name>
 11:    <home>agency.AgencyHome</home>
 12:    <remote>agency.Agency</remote>
 13:    <ejb-class>agency.AgencyBean</ejb-class>
 14:    <session-type>Stateless</session-type>
 15:    <transaction-type>Bean</transaction-type>
 16:    <env-entry>
 17:     <env-entry-name>AgencyName</env-entry-name>
 18:     <env-entry-type>java.lang.String</env-entry-type>
 19:     <env-entry-value>J2EE in 21 Days Job Agency</env-entry-value>
 20:    </env-entry>
 21:    <security-identity>
 22:     <description></description>
 23:     <use-caller-identity></use-caller-identity>
 24:    </security-identity>
 25:    <resource-ref>
 26:     <res-ref-name>jdbc/Agency</res-ref-name>
 27:     <res-type>javax.sql.DataSource</res-type>
 28:     <res-auth>Container</res-auth>
 29:     <res-sharing-scope>Shareable</res-sharing-scope>
 30:    </resource-ref>
 31:   </session>
 32:  </enterprise-beans>
33: </ejb-jar>

The essential parts of the deployment descriptor in Listing 4.5 are

  • The <session> tag delimits the definition of the
    Agency EJB and indicates that it is a Session EJB (lines 8 and
    31).

  • The <ejb-name> tag defines the name of the EJB, in this
    case Agency (line 10).

  • The home and remote interface types (as defined by their fully-qualified
    class filenames) are specified by the <home> and
    <remote> tags, respectively (lines 11–12). The type of the
    bean itself is defined by the <ejb-class> tag (line 13).

In addition, two other parts are of particular note at this point in
time:

  • An environment entry is defined between lines 16 and 20 by using the
    <env-entry> tag. This indicates that a String property
    called AgencyName should be made available to the bean. The value of
    the property is J2EE in 21 Days Job Agency. The environment defined in
    the deployment descriptor is made available through JNDI under the name
    java:comp/env. In this case, the agency name can be retrieved by
    looking up the name java:comp/env/AgencyName. This lookup can be seen
    in the ejbCreate() method of Listing 4.3.

  • An external resource is defined in lines 25–30 using the
    <resource-ref> tag. This defines that a DataSource
    should be made available to this EJB under the name jdbc/Agency. As
    with the environment entry for the agency name, this resource is made available
    through JNDI under java:comp/env, so the EJB can retrieve the
    DataSource by looking up the name java:comp/env/jdbc/Agency.
    Again, this lookup can be seen in the ejbCreate() method of Listing
    4.3.

Latest Posts

Related Stories