See comments below.
> 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.
JDK 1.1.7 wouldn't be a problem; to my knowledge JMS
is 1.1.7-compatible.
Larger problem is WebSphere. WAS does not have it's
built-in JMS and there is no standard way of pluging
in an JMS into an app-server. (Even though it is in
EJB 1.1 a supported resource.)
I think it could be done, but buying an external JMS
is pretty expensive. It's easier in for example
WebLogic where a JMS-implementation is "bundled".
So let's skip JMS for now.
> 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.
Correct.
> 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?
There are several problems if you are going to use
rmi. One is the storage of the client's remote
references (client-stubs).
The only ejb-type that can store state in simple
instance-variables is the statefull session-bean, and
having a statefull session-bean instance allocated for
the entire lifetime of the system does not seem like
an entirely feasible solution.
One could serialize the stubs into a database but that
too does not seem like an entirely robust solution.
> 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.
Hmm... I'm not really following this (could be an
implication of the vast amount of partying done
yesterday... :)
I'll try to comment it and if I've misunderstood
you'll have to correct me.
The problem (which is what I've stated above) is that
there are problems of robust "long-time storage" of
the stubs to the clients in the bean. One way of
solving this is to have the external server do the
actual distribution, the server wakes up (by some
means, either by a timer or by an external client
calling it), fetches the actual data from the
ejb-application and distributes this message to the
clients. In this way the external server maintains the
actual stubs and the business-logic is still
implemented in ejb.
There are many, many problems of this which is solved
by JMS (transactions, robustness, security,
persistence, scaleability etc.). I reiterate that JMS
is the "correct" solution to this and is definitely
worth looking into twice. RMI is simply not designed
to implement this type of publish-subscribe in an
enterprise-level distributed system.
> I'm currently testing this ;-), let's see what
> happens.
It will probably work for smaller loads. As the system
is put under more heavy-weight tests it will probably
run into some problems. That's just my 2c.
Good luck!
__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail � Free email you can access from anywhere!
http://mail.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".
