Hmm. What has JDK1.1.7 got to do with JMS support? We are merrilly using it
with MQ's JMS implementation .... and it works with both JDK1.1.7 and
JDK1.1.8 which WAS 3.0.2.1 supports...
In fact the very scenario you mentioned can be built with WAS and MQ's JMS
interface quite easily...
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of More, Yogesh
> Sent: Saturday, 8 July 2000 04:25
> To: [EMAIL PROTECTED]
> Subject: Re: Push data to a Client - Possible ?
>
>
> Thanks for your time and a "prompt" reply and a cool elaboration
> on the all
> the issues involved. Further ahead.
>
> Making some more things clear --
> I'm using Websphere for the development and consequently for
> production too,
> which has jdk1.1.7 support only. This made JMS, which should have been the
> obvious choice ( which you too have mentioned), go out of contention.
>
> Then we thought of making a RMI callback mechanism for the
> publish-subscribe
> to run in the same environment as the EJBs. This didn't seem to work as
> essentially the EJB is a request-response environment only.
>
> Now some things which I am not clear about which you mentioned.
> The RMI server will just be a timer, which triggers the publish process.
> And is some EJB going to do the distribution here? If it's the
> EJB which is
> going to do the distribution is it possible without the client requesting
> for a update to send one?
>
> This actually boils down to this question
> Can a bean be invoked by one of the clients .... and some way it's holding
> the number of clients subscribed...the bean sends of a message to
> all these
> clients? Simulating a "PUSH" by one client ( the rmi server in our case)
> invoking the bean and the bean publishing the message to all the
> subscribers. I would like to know your opinion about it.
>
> I'm currently testing this ;-), let's see what happens.
>
> Thanks again,
> Yogesh
>
>
> -----Original Message-----
> From: Jon Tirs�n [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 07, 2000 12:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Push data to a Client - Possible ?
>
>
> > Scenario:
> >
> > 1. A client connects to a "session bean".
> > 2. The reference of this client is given to a
> > Notifier ( just another
> > object).
> > 3. Can this Notifier, in an independent thread call
> > methods on these
> > clients..essentially Pushing Data ?
> >
> > Is this possible? Has anybody done it before? Need
> > to know it very urgently.
> >
> >
> > The actual doubt from my side is
> > -- Can a real time notification system be built
> > side by side with the
> > EJBs,which do the subscription of the clients for
> > such a notification in
> > addition to many other things.
>
> Yes, it can be implemented but not as an EJB. The
> actual "activation" of the push needs to be done in a
> separate application (in J2EE it is called an
> "application-client") which needs to be run as a
> server next to the ejb-server.
> The reason for this is actually pretty simple: An ejb
> can not be activated by itself and it can not start
> threads.
> These two restrictions (actually it suffices with any
> one of them) makes a "publish-and-subscribe" type of
> application impossible to implement with just ejb's.
>
> I don't think that the MessageDrivenBean (MDB?) in EJB
> 2.0 solves this either.
> An all ejb-application is simply reactive, never
> active.
>
> One more thing to consider is the means of
> communication between the subscribers (those receiving
> the push) and the "notifier" (publisher). One way
> (which seems to be what you are thinking about) is to
> use RMI, this will surely increase performance and put
> less overhead on the implementation. It _will_ altough
> decrease robustness and scaleability for higher number
> of subscribers. If your requirements are on high
> robustness and scaleability for a high number of
> subscribers I would seriously consider using JMS
> instead of RMI which is designed for this types of
> applications.
>
> Also, since the server that actually activates the
> ejb's doing the work is an independent server
> maintained externally from the ejb-server it's
> "quality-of-service" will not be guaranteed by the
> ejb-server (fail-over, restarts etc.). Thus I would
> implement as little as possible in that server
> optimally just a simple configurable timer propagating
> everything to an ejb (transaction management,
> security, distribution etc. etc.) making it less prone
> for errors.
>
> Hope this will put you somewhere in the track of a solution.
>
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/
>
> ==================================================================
> =========
> 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".
