> > The network is the computer, the computer is the network, who cares... java
> > lets you do cool things. Admins across the planet (perhaps beyond) will be
> > greatful for millenia to come. Assuming we can get of the planet before the
> > sun goes red giant =)
>
> Assuming that there will be a need in the first place to get off the
> planet if the Sun goes red giant.. but that's another issue ;-)
If the human species is going to survive, then we have to get off this
planet. If not solely because we are destroying this one, or that we are
filling it faster and faster each year.
There are several billion years left... true, but if we don't start thinking
of it now, given the present, how do we expect our children to take the full
burden?
Hrm... ok this is not the save-the-planet mailing list... where am i, what
have you done with my apple?
> > JMX provides a local namespace and flexibility for integration.
> > Jini provides a network, global or rather grouped namespace.
> > Jini is to packages, as JMX is to classes.
>
> I believe that's an ok analogy, yes.
I am glad you approve, took me a minute to type though =P
> > How does a JMX serivce interact? Throgh JMX api's or Jini API's. In other
> > words, if service0 depends on service1 and service2, does it access them
> > through the MBeanServer or by looking up the service interface ala jini,
> > then use RMI semantics to process any reqests?
>
> I'd prefer Jini lookups. Note that what you get from the lookup service
> *does not have to be an RMI object*. Heck, it can just be a Plain Old
> Java Object (POJO, tm Martin Fowler) that implements all of the stuff
> locally. That's the beauty of Jini: it *can* be distributed, but doesn't
> have to be. Having a method throw RemoteException only means that the
> method *may* be remote, but it doesn't have to be.
It can simply be a serializable?
How about resource control?
I guess you would implement that at the stub level? If I want a machine0 to
allow 10 clients to use it's service0 and no more... what do you do?
With jms, your client would create 10 sessions, with reading threads
behind them. At JavaOne there was some talk about this... don't remember
what it was called of the top of my head...
> > What about leasing? or events?
>
> What about them?
Wondering if you had anything to say about it. Likes, dislikes, ideas,
improvements, prodding you to drop some knowledge =)
> > How could we replace the JMX event/notification fluff with something backed
> > up by a topic? We could link JBossMQ instances via there group namespace,
> > then configure links between groups and provide a routing mechanism. Now we
> > have a distrubuted event system which we can use to provide os level
> > services to the nodes in the cluster (configuration notices,
> > node activation or rather when a node accepting client connections).
>
> Yes, that could work. You could even use JBossMQ as the backbone for a
> Jini event handler. Would work quite nicely I believe.
I would really like to see JBossMQ be used as the communication backbone.
JBossMQ has really come a long ways. It is better than many commercial
impls that I have had to investigate.
Kudos!
> Plus, another very important question is: how does JBoss make writing
> applications in Jini better? Looking at the Jini community, and having
I was a bit taken by the whole rmid thing, the install the service, then
leave it. Perhaps I am old fashioned but I like to start with a clean slate
every time and remind the server what it should be running.
Perhaps I don't trust Sun code that much?
How does activation fit into this scheme? Does it?
> talked to Jini folks on this topic recently, it is now very easy to
> write clients and services in Jini, but it's still pretty awkward to
> actually run the damn critters. Enter JBoss, which can provide all the
> gory stuff (conf, lifecycle) that they need. Package the Jini services
> as MBeans and off you go. Very very nice.
In your opinion; What needs to be done to make this happen? Hope and
promise are prevalent, but there must be order to take an idea and turn it
into a reality.
=]
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
