At 11:05 5.9.2000 -0700, you wrote:
><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).
As far as I know, both Mach and CHORUS are *distributed* microkernels, so
to me it would seem that for both of them the messaging is required for the
sole reason of not having shared memory available. So it would not be
merely a matter of modularity or availability but the transparent
distribution aspects they offer. You can be modular without message-based IPC.
>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
Why is it another matter for the WebOS? The Internet is unreliable due to
its network more than its server nodes (although they *do* go down as well)
but for a farm of jBoss servers you would most likely have a reasonably
reliable network connecting your computers, no?
So you would have a LAN network connecting robust nodes. I don't see how
this differs from the scenario of distributed microkernels. Bottom line is
that you have to replicate your critical services anyhow and nodes tend to
be there unless you're doing HW maintenance.
>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.
Modular but at the same time distributed as well, right? (I'm pretty sure
this is what you mean anyhow :)
We do gain the distribution of the components by they way of JMX framework.
What I was trying to advocate was that it might be possible to use the same
messaging system to implement the intercomponent communication and the
component dependency "discovery". But if I understood Rickard's response
correctly, this might not be possible if we wish to adhere to the JMX API
specification (because only asynch API is specified).
>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...
Well I certainly did not intend to give the impression that I was thinking
of JMS being irrelevant. Quite to the contrary. I think it's very relevant.
What I was wondering is why these component specs always (well, at least
twice already, that counts as "always", right?) give the inter-component
communications a "to be defined later" status? It happened with JavaBeans
and now it's happening with JMX. With JavaBeans you could get only so far
with the property change notifications. This wasn't enough for the real
"applied" stuff as you needed to share data between the components and so
the Lotus folks came up with the Infobus specification. Now we have JMX
components which define a naming pattern for property identification (like
JavaBeans), property change notification patterns (like JavaBeans) and no
way for the components to really work together (like JavaBeans). The
components will need to rely on the services provided by others and I'd
suspect that eventually you will want to share data between dependant
components as well.
But this is certainly getting out of the scope of jBoss Dev. Just some
generic griping about the components specs...
-- Juha
