[an error occurred while processing this directive]
> developer > web app development
Making EJBs Flexible with Environment Entries
by Michael Demastrie, QA Engineer, Novell
Date Created: 2001-02-14 13:51:00.000
  Introduction
  Rules of the Game
  Using Environment References
  Creating Environment References
  Referencing Environment Entries from your EJBs
  Summary

The message-driven bean (MDB) -introduced by EJB 2.0-has an interesting and useful feature called selectors that allows the bean to be selective in the messages it responds to. This article discusses the features of the MDB selector and examines some basic sample code.

introduction
EJB environment entries: it's a subject so seemingly elementary that I almost dismissed it as an article topic. However, although simple, environment entries play a huge role in making Enterprise JavaBeans (EJBs) flexible. Therefore, at least for beginners, the topic of EJB environment entries is worthwhile.

With EJBs, it's possible to create named value entries of type String, Integer, Boolean, Double, Byte, Short, Long and Float within the EJB environment. These references can be used by the bean deployer or assembler to modify the business logic of the bean without altering the underlying code. This is a powerful technique when properly applied.

Rules of the Game
An environment reference entry is very much like a constant variable that is scoped for a particular EJB. It is set up in the deployment descriptor, and it can be overridden in the deployment plan. There are some very basic rules of the game for using EJB environment entries:

  1. Environment references must be set up in the deployment descriptor of the EJB.
  2. Values set at assembly time can be overridden at deployment time.
  3. Environment entries are only accessible by instances of that particular bean deployment.
  4. If the same bean is deployed more than once on the same server (using different JNDI names), the environment entries can have the same name, but there will be a risk of collision.
  5. Values of the environment references can not be changed at runtime (only at deployment or assembly time).
  6. Environment entries will be located in the java:comp:/env JNDI context.
Using Environment References
Environment references can be used to control business logic at deployment or assembly time. This is a necessary requirement for the production of "canned beans." The bean developer can set certain parameters, like maximum order size, alarm trigger temperature, minimum applicant age, company name and so on, by looking up environment entries. At assembly or deployment time, the assembler or deployer sets these references to values that reflect the rules of the particular business application. This way the developer is able to build generic or adaptable EJBs that require no re-coding for application in a particular problem domain.
Creating Environment References
Referencing Environment Entries from your EJBs
Environment reference entries can be made in the deployment descriptor using the <env-entry> elements. These elements consists of four sub-elements:

Element: <description>
Description: A textual description of the reference.

Element: <env-entry-name>
Description: The environment name of the reference.

Element: <env-entry-type>
Description: The class type of the reference.

Element: <env-entry-value>
Description: The value assigned to the reference.

These elements can be manually entered into the deployment descriptor or, with some application servers, by using graphical tools. (See Example 1 and Figure 1.)

Example 1. Excerpt from Deployment Descriptor for Environment Reference Entries (SilverStream) 

<enterprise-beans>

    <session>

    ...

        <ejb-name>EnvironmentDemo</ejb-name>

        ...

        <env-entry>

            <description>

            The name of your company.

            </description>

            <env-entry-name>companyName</env-entry-name>

            <env-entry-type>java.lang.String</env-entry-type>

            <env-entry-value>Acme Explosives</env-entry-value>

        </env-entry>

        <env-entry>

            <description>

            The maximum number of sticks of dynamite allowed per order.

            </description>

            <env-entry-name>maxSticks</env-entry-name>

            <env-entry-type>java.lang.Integer</env-entry-type>

            <env-entry-value>12</env-entry-value>

        </env-entry>

        ...

    </session>

</enterprise-beans>


Figure 1. Adding an Environment Entry with a Graphical Tool (SilverStream)


While the environment entries must be established in the deployment descriptor, their values can be overridden at deployment time. The means for doing this will depend on your EJB container (e.g. an application server) provider. Often this is done with graphical tools or by using a particular deployment plan. (See Figure 2 and Example 2.)

Figure 2. Overriding an Environment Entry with a Graphical Tool (SilverStream)


Example 2. Excerpt from Deployment Plan for Overridden Environment Entries (SilverStream) 


    ...

    <beansList isObject="true">

      <session isObject="true">

        <bean isObject="true">

          <beanName>EnvironmentDemo</beanName>

          <environmentList isObject="true">

            <environmentEntry isObject="true">

              <name>companyName</name>

              <value>Acme Discount Explosives</value>

            </environmentEntry>

            <environmentEntry isObject="true">

              <name>maxSticks</name>

              <value type="Integer">12</value>

            </environmentEntry>

          </environmentList>

        </bean>

      </session>

    </beansList>

    ...
summary
EJB environment entries are a simple way to create flexible EJBs. Environment entries allow changes to be made at the time of assembly or deployment without requiring additional modification to previously tested bean code. This technique enables bean deployers and assemblers to create beans that can be easily applied in many different problem domains simply by changing environment entry values.