hi

i was following the discussion AvalonJ2EE, as
i see some benefits using the avalon component framework
in an ejb environment.
The ejb would should designed in coarse grained fashion.
In contrast Avalon components could be designed a bit
more fine-grained.
Moreover it should be possible to use the Avalon components
in a servlet environment, or in some other environment, too.

As the EJB are implemented using avalon components, the components
could be JUnit tested and used indepent from the EJB framework.

Thus it might be possible to reuse the JUnit test in some JMX
framework to provide some continouse testing.

Last as avalon components should not be too visible i
would suggest to use some delegate approach. As it was
suggested by Peter and the AvalonEJBFrame.

For example:
UseCase is some OrderManagement. OrderData of this
OrderManagerment is gathered by an servlet.
Avolon components implement the validating of the OrderData,
and calculating some information.
Using this approach will give you the opportunity to test, and
use the avalon components either from the servlet or from the ejb.

Testing of the avalon components can be done indepent from its
J2EE deployment. You may even think to reuse the code in some
fat client.

1. Configuring the Avalon EJB Delegation

1.1. Defining the avalon configuration in the ejb-jar.xml
ie:
... the ejb-jar.xml snippet ...
<env-entry>
  <env-entry-name>AvalonEJBFrame</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value><![CDATA[
    <configuration>
      <logger>
        <!-- use the log4j logger -->
        <log4logger/>
        <!-- use the jdk14logger
        <jdk14logger/>
        -->
        <!-- optionally you may use the logkit logger
             see ExcaliburTestCase, and avalon.excalibur.logger
        <logkit>
          <factories>...</factories>
          <targets>...</targets>
          <categories>...</categories>
        </logkit>
        -->
      </logger>
      <components>
        <component role="A.ROLE" class="x.y.z.AImpl1"/>
      </components>
    <configuration>
    ]]>
  <env-entry-value>
....

Accessing this configuration:
Context ctx = new InitialContext();
String xconfString = ctx.lookup( "java:comp/env/AvalonEJBFrame" );
Configuration xconf = ... // build configuration from xconfString

Note: prefix java:comp/env is part of the EJB spec and should be
portable across the different application servers.

1.2. Lookup the avalon configuration from the JNDI stored as DOM, or 
plain xml
... the ejb-jar.xml snippet ...
<env-entry>
  <env-entry-name>AvalonEJBFrame</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>avalon/xconf/a/b/c/EJB1.xconf</env-entry-value>
</env-entry>
....

1.3. Lookup the AvalonEJBFrame from the JNDI
... the ejb-jar.xml snippet ...
<env-entry>
  <env-entry-name>AvalonEJBFrame</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>avalon/xconf/a/b/c/AvalonEJBFrame</env-entry-value>
</env-entry>
....

2. Using the AvalonEJBFrame

I see two usage scenario of AvalonEJBFrame/AbstractAvalonEJB.

2.1 First use it in ONE stateless or stateful SessionBean as an
central instance. All other EJBs and classes has to request
avalon components from this SessionBean, let's call it
CentralServiceManager.

Managing an Avalon component means an EJB call, making the call
surely not lightweighted.

2.2 Secondly each EJB has its own ServiceManager.
That's the usage scenario I thought about it would be okay.
As EJBs are coarse grained, the avalon components should be
a bit more fine-grained, acting as a toolbox for implementing
EJBs quickly, offering some kind of infrastructure which
is used by all EJB, and implementing simple basic business logic.

3. Consequences of EJB lifecyle

3.1 Using in a StatelessSessionBean
The AvalonEJBFrame object is shared by all StatelessSessionBean instances.
This means that all avalon components should be ThreadSafe.

3.2 Using in a StatefulSessionBean
Each StatefulSessionBean instance has its own AvalonEJBFrame.

3.3 Using in an EntityBean
I think it is like 3.2


I hope my thoughts are valuable and understandable.

bye bernhard



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to