But a JDBC drivers is an example of a resource manager that has
to be configured at the app server level and accessed through JNDI. Support
for an SPI to integrate arbitrary resource managers is one of the items
listed in the Features deferred to future releases section of the 1.1 spec.
I agree with all that your saying with regard to the EJB design. What I am
curious about is how people are integrating proprietary libraries into EJB
implementations without such an SPI.
----- Original Message -----
From: "Assaf Arkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 23, 1999 8:09 PM
Subject: Re: Are people integrating asynchronous services into EJBs?
> This is perhaps the greates misconception about EJB.
>
> If your EJB bean is using a JDBC connection that obviously it's using
> threads, static objects, network connections, files, etc. All these
> resources that you're not allowed to use directly. And it works.
>
> The difference between these resources and your beans is that these
> resources have sufficient logic to deal with complex issues, while your
> beans are implemented very easily letting the EJB server take care of
> the details.
>
> And that's also the beautify of EJB.
>
> If your EJB bean has (by accident) entered an infinite loop, the EJB
> server can track that and terminate the bean's thread as it's running.
> The EJB server can also load balance your bean between two servers by
> serializing it in and out. To get these benefits your bean must not
> manage threads or shared resources.
>
> On the other hand your bean might be using some library that needs to
> use threads and shared resources -- your stock quote is one example,
> JDBC and JMS are two other -- that library must have sufficient
> knowledge to work well even if the bean calling it has been terminated
> or the instance has been moved to a different server.
>
> The solution in your case would be to separate what is the bean (i.e.
> very simple logic) and what is the library (i.e. way more complicated),
> implement the library in the best possible manner, and implement simple
> beans on top of that library. You beans will benefit from load
> balancing, fail over, recovery etc by adhering to the EJB specs and
> running inside the EJB server. Your library must be well coded to deal
> with all these issues directly, since it's not under the EJB server
> control.
>
> arkin
>
>
===========================================================================
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".
