Correct me if I'm wrong,
but with weblogic I can call a session bean that fires an event to the
topic tree.
The call then returns and the event can get executed.
I would call this a semi-asynchronous call.
Filip
Assaf Arkin
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: A Subject: Re: Are people integrating
asynchronous services into EJBs?
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@jav
a.sun.com>
12/23/99 05:09 PM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
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
Scott M Stark wrote:
>
> In my reading of the EJB specs, books and articles, it does not seem to
> be an easy matter to front end asynchronous msging systems with an EJB.
> A simple example of such a system is a stock quote server that delivers
> intraday prices changes to a client. Let's say I want to write an EJB
that
> generates an intraday price chart like those you see at a number of web
> sites that show the price movement of a stock at 5 minute intervals. This
> removes the need for asynchronous delivery of msgs from the EJB to
> the EJB client. The EJB home and remote interfaces would be something
> like:
>
> public interface IntradayChartHome extends EJBHome
> {
> public IntradayChart create(String stockSymbol, int updateFreqInMins)
> throws RemoteException, CreateException;
> }
>
> public interface IntradayChart extends EJBObject
> {
> public IntradayChartImage getChart() throws RemoteException;
> }
>
> My biggest sticking point is the integration of the intraday prices into
the
> EJB implementation. This entails connecting to a price server using a
> multi-threaded asynchronous api for handling the proprietary msg
protocol.
> This type of code does not seem to be allowed to be used by 1.0 or 1.1
EJBs
> in that it entails thread creation and thread synchronization as well as
the
> legacy code msging the EJB implementation object without going through
> the EJB container.
>
> Am I wrong in this read of the spec? Are others integrating this type of
> data
> service into EJB environments, and if so, how?
>
> Thanks,
> Scott Stark
>
>
===========================================================================
> 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".
===========================================================================
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".
