> I meant that JMS as part of the architecture seems to be dragging behind.
> Everyone knows about it and agrees it does neat stuff but no one quite
> seems to know where to put it in good use. This is the feeling I
> got when I
> glanced through the message bean stuff.
>
> It's kinda odd, really. Not sure why that is. Maybe messaging is just too
> mundane :)
Man I take three days off the lists (much needed ;() and when I come back
all the cats are going in their directions.
<theory> mach the unix kernel the FSF was tackling at one point, with
message based modules to implement the kernel never really worked. The fact
that it was hard to implement is bs, the real issue is that "systems" in the
sense of "hardware systems" are today fairly robust and "nodes" don't
usually go down. Hence no real need. Correct me if I am wrong (I am fairly
ignorant when it comes to micro-kernels) but only in microkernels that need
to be always up and modular does the "message" based infrastructure matter
today (think of chorus OS for example with CORBA).
Now on the web and for the "web OS" this is another matter altogether. The
fact is that nodes go down all the time in the web (network, disk, services,
dns etc etc) and another fact is that in our "grand dream" of farms of jboss
services will go down and up for maintainance, reconfiguration, installation
and start-stop of new servers as well as applications... in other words,
since the webOS *will* be modular (think of BEA's black monolyth by
comparison) a message based infrastructure and the flexibility it buys
become relevant.
ALl this is very theoretical</theory> now the guy behind the spec, Mark
Hapner, the guy also that co-authored EJB is a real genius and I tend to
trust him. If Mark says that JMS is relevant, chances are that JMS is
relevant, not just because of the (good ;-) reasons exposed above but
because Mark says so...
<applied> we will try to see how that plays in the EJB framework for
jboss3.0, and yes I agree, "besides" the message beans, but don't be fooled
by the spec it might be critical to the future architecture of these
systems. The folks I know of at Progress where looking at such a message
based architecture for an EJB container (I remember drawings on their walls
one time I went there). I do think that messaging everywhere in the
container is a bit overkill, but it might be VERY interesting for the say
the invocation layer (current invocation is completely synch) and that will
make stuff like SOAP integration easier, we will scale much much better too.
Also the persistence layer can afford to be de-synchronized and we will see
huge performance increases there imho... </applied>
to be continued ....
marc
>
> -- Juha
>
>
>
>
