On 2002.11.08 17:35:42 -0500 Matt Munz wrote: > > > Imagine a world where jboss is installed everywhere - client and > server. > ;) > > You're talking about (more evenly) distributed systems (a.k.a. P2P)? I > think you're still going to need a delineation of roles -- some nodes are > going to be thicker than others. You don't want to start up an entire > JBoss > stack just to run JNotepad (fictional). Likewise, I'd imagine you don't > want all of your client side applications running in the same JVM. It > seems > to me that a measure of fault tolerance is worth the extra memory use (by > starting up separate VMs) in this case (although I'm interested in > arguments > to the contrary). > > It seems to me that when you're designing a node in a distributed system, > you start out by defining the role/functionality. Then take the most > minimal JBoss kernel. Then start stacking on functionality until you > have > what you want. > > What makes this better than client-server, IMO, is that all nodes > (should) > share a common architecture. That way, server-side code can easily be > pushed to the client for added performance. So JNotepad uses a > Web-service > based remote spellchecker. You like it? OK, download spellchecker.sar, > and > any "server" modules that it depends on. > > What makes this worse than client-server is that it doesn't exist yet, > AFAIK
Hard to know. We do have the minimal jboss configuration, which is a good starting place: as I recall basically all it can do is deploy .sars. AFAIK however none of our clients are adapted well to live in this environment and make use of it (although I have some plans in this direction for transaction propagation). I think the difference between what Dain is proposing and the j2ee client container is that the j2ee client container is expected to start first, before your app, whereas my understanding of Dain's proposal is that the jmx/container services start when you first look something up in jndi. It's a lot easier for me to think about the container starting first, and I think it will provide less surprising performance, but I'm not sure we can require or enforce it in any practical way. Did I get Dain's idea right? Any other ideas? thanks david jencks > :) ... > > - Matt > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of James > Higginbotham > Sent: Friday, November 08, 2002 4:42 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JMX on the client side? > > > > I think James had more esoteric plans... > > > > -danch > > > > Right.. I'm not talking about Jboss proper, I'm speaking of a rich > client platform that uses jboss as its service arch kernel. Imagine a > world where jboss is installed everywhere - client and server. ;) > > James > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
