The threading restrictions, JNI restrictions, etc. that EJB 1.1 imposes
define are an important part of the EJB Component/Container contract on
which EJB portability is based.
Some EJB vendors may provide access to Java features that go beyond the
minimum set of Java permissions defined by EJB 1.1 and J2EE specs;
however, no EJB vendor is required to support EJBs that require more
than the specified minimum permissions.
Charlie Alfred wrote:
>
> 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".
===========================================================================
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".
