Scott, Interesting.. Do you have this scoped in your mind yet? I mean, Jboss (I hate how outlook "fixes" the b in jboss) currently uses JavaGroups, which assumes a multicast-enabled network. When you get to true peer-to-peer, you may have a double firewall situation where multicast doesn't work outside your LAN. In which case, you need concepts of superpeers on your local network that all register with public directory services to create a web of superpeers bridging private networks. This is (sortof) what JXTA does best (cough). In the past, I've seen discussions of JXTA + Jboss but haven't seen many thoughtful proposals, just "it would be cool ifs". Am I taking this vision of yours too far, not far enough, or missing you completely? The architecture of your dynamic proxies and JavaGroup networking seems to work great for local networks, so you must be envisioning more?
James > -----Original Message----- > From: Scott M Stark [mailto:scottmstark@;attbi.com] > Sent: Saturday, November 09, 2002 12:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JMX on the client side? > > > A JMX microkernel on the client is an avenue to explore. The > focus should be extending the current dynamic proxy and > detached invokers to a kernel for peer-peer type of > computing: agents, grid computing, JMS, RMI callbacks, > distributed caches, and whatever P2P is going by these days. > > To me the extension is one of a client simply downloading > smart proxies to downloading a microkernel whose base > configuration is defined by the server, extensible by the > client, and capable of offering services for peer-peer computing. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > From: "Dain Sundstrom" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, November 09, 2002 9:10 AM > Subject: Re: [JBoss-dev] JMX on the client side? > > > > Matt Munz wrote: > > > What's wrong with mbeanServer().registerMBean(mmb, name) ? > > > > Thank you matt. That is exactly what I am thinking. > > > > The first time you lookup an EJB or JMS connection, we we > lazily force > > the client side to have an MBeanServer. Then we register only the > > mbeans required to service that object. For an EJB that > may mean just a > > light weight client side container and a cache MBean. For > JMS we would > > register a client side container and a reverse invoker. > > > > I'm not talking about anything heavy weight. I still want > this to be > > able to run on a cellphone. If the programmer decides that > they want a > > heavier solution they can start an MBean server a startup > with a sar > > deployer. > > > > > I guess I'm thinking that some clients will not want to > get overly > > > involved with the file system. > > > > Like applets. > > > > > JMX on the client side and JBoss on the client side are two > > > different things, right? AFAIK, > > > MBeanServerFactory.createMBeanServer() doesn't require > the service > > > deployer. If it does, that's another thing... > > > > Agreed. All I am talking about is an MBean server. If > someone wants > > more JBoss services on the client side they can do that, but it > > shouldn't be required. > > > > -dain > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
