Mark Hapner wrote:
>
> The goal is to delegate all responsibility for managing concurrency to a container
> and its resources (DBMSs, etc). EJB 1.1 succeeds in doing this for many types of
> applications. EJB 2.0 will significantly expand the EJB app domain by adding support
> for asynchronous invocation (JMS integration).
>
> So, the question is not what you can do within your container it is what your
> container can do for you :>). Why should you be worrying about creating threads if
> you can get the container to handle all of that complexity?
>
This last paragraph seems to represent a simplistic view of an EJB component. Namely,
that its only dependencies are on its container, some other EJB container, standard
resource managers (JNDI, JDBC, etc.) or a trivial Java class that is packaged with
the EJB. Such Java classes are supposedly not allowed to manage threads or socket
connections, or perform file I/O.
JMS adds asynchronicity and indirect dependency. An EJB that sends a JMS message
depends on the semantics of the message destination (i.e. which message types are
permitted, what contents the message body may contain, and what properties must be
set). The message send itself is part of the transaction (if the txn is rolled back,
so
is the message send), but the receipt and handling of the message are not.
On the flip side, an EJB can "receive" asynchronous JMS messages with the help of
a listener object that registers with a JMS message session. This enables one EJB
to handle requests from another (in separate transactions as mentioned above), and
it allows non-EJB components that have access to a JMS provider to communicate with
EJB's, without themselves needing to be EJB clients.
While this is a powerful extension of the EJB platform, it doesn't yet provide a
complete answer to the rhetorical question you raised: "Why should you be worrying
about creating threads if you can get the container to handle all of that complexity?"
It seems to me that in addition to the common dependencies of an EJB that I
mentioned above (its container, some other EJBs, standard J2EE RM's, or trivial
Java classes), many real-world EJB's will have other dependencies, such as:
1. Use of non JDBC/JMS resources in EJB transactions. The J2EE Resource
Manager spec that is currently under development should address this by
opening up the API for a JTS transaction resource. This should allow
3rd party vendors and experienced developers to implement transaction
support for resources (legacy databases, file-system stores, etc.) that aren't
covered by an existing Resource Manager. Unfortunately, it's unclear when
this spec will be integrated with EJB and when vendor support will be ready.
2. Access to Utility Services, such as distributed event logging or run-time
statistics capture. Unlike the Resource Manager capabilities described in
#1, Utility Services typically do not have transaction or security
requirements,
but they may need to be called directly from EJB's. It would be possible
to build this connection on top of internal JMS queues, but would be more
work and more awkward than a direct API.
3. Connections to non-EJB external applications, such as:
- ERP systems,
- CORBA or COM components, and
- legacy systems that can support various network protocols like SNA
or TCP/IP, but don't have access to JMS.
The goal statement for the Connector Architecture spec that is in the process
of being defined addresses this. However, it is not clear how long we are
going to have to wait for this spec to be integrated with EJB. In the
meantime,
these requirements don't go away. The ability to permit an EJB to depend on
a Java class that uses threads, sockets, I/O, and JNI provides a poor-man's
way to make these connections today.
I'm not suggesting that this poor-man's approach would possess the transaction
and security support or flexibility that would be provided under the Connector
Architecture. However, it would provide the ability to implement and
encapsulate
a basic capability until something better comes along.
In summary, I think that the goal of pushing as much "system" intelligence as possible
from the enterprise bean into its container is a noble one. Unfortunately, given the
fact that EJB 1.1 only defines a partial subset of such things, we can either:
a. take the strict approach and legislate away all requirements that don't
fit neatly into the existing spec, or
b. take a slightly looser approach by permitting certain practices, and
documenting the restrictions and caveats.
IMHO, the second approach provides a broader foundation for EJB's adoption and
marketplace success.
Charlie Alfred
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
