Take it from someone who used JXTA to launch their startup a year ago this month (when it was hinted at by Sun):
JXTA isn't there yet for application development Note: I do hope it succeeds and I hope these things listed have been fixed, but be aware of what you are getting into beforehand... O The communications layer is *very* slow. In fact, I believe Sun was trying to use it internally but gave up because it had up to a 5 min latency for a message! O The API needs lots of work. Now, there are some really smart folks working on the team, but whoever started the APIs early really locked them into something painful. You can't start and stop JXTA as a communication library, you have to launch JXTA, then launch your application via a factory interface they wrote for launching apps. O The client is bound to a proxy called a rendevouz (discovery happens here), which is powerful in that you could use it to pierce double firewalls and such, but is painful because it (at one point at least) had a 5 connection limit. Its not ready for anything real yet, unless they done some work on it in the last few months. O They don't have a concept of a user, so there is no way to do anything around presence or user-uniqueness (because, what does presence really mean if you aren't a unique user within the core framework?). Although this sounds simple, imagine try to determine if you delivered once and only once over JMS to a client that has not concept of uniqueness.. How do you know, since the pipe uuid of the client can change with each connection it recreates after a failure? O The protocol is really lose, so you could easily get into the same trouble with JXTA clients as JMS clients, unless you write a specification above JXTA that defines the messages to be exchanged between clients. Imagine RMI defining headers for the protocol, but not the serialization mechanism. This is what you get with JXTA - a basic communication framework that allows the content to be anything. So, it won't solve any more problems than standardizing on JMS protocols would. Anyway, just a few observations from someone who has already been there. I think JXTA would really benefit from the JBossMX, but there would have to be a *lot* of rework and specification rewrite for the JXTA team. In the end, I could see that it would be worth it and would help JXTA to succeed, since the Jboss team has a very clean and stable codebase to work from. James > -----Original Message----- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 15, 2002 9:30 AM > To: Paul McLachlan > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Ubiquitity - embedded JBoss and JXTA > > > I talked with the JXTA guys for like an hour at JBossOne. They were > very interested in the JBossMX core with dynamic services. I > think JXTA > could be easily plugged into JBoss, but the the best place would be a > transport for JMS. Where do you think it would be most useful? > > -dain > > Paul McLachlan wrote: > > > Sun has just published an article in the JDC comparing JMS and JXTA. > > Since they build both technologies they do not have a > vested interest in > > recommending one over the other. Have a look at: > > > > > > > > > http://developer.java.sun.com/developer/technicalArticles/peer/index2. > > html > > > > > > > > If time is constrained, just read the conclusions. A few points to > > note > > are: > > > > > > > > 1. JMS is enterprise focussed, not internet focused > > > > * JMS communication is restricted to within a single > firewall domain. > > * JMS communication is restricted to a single transport. > > * JMS communication requires static binding between peers. > > * JMS does not specify security mechanisms under client control > > * JMS is tied to Java (just like RMI is tied to Java), JXTA is > > language and transport protocol independent > > > > Note as well that JMS is tied to vendor implementations. JXTA is > > free, > > open source, and most importantly vendor independent. That > means that > > one suppliers version of JXTA will always talk to another > suppliers. > > The same is not true of JMS, since it defines the messaging > API and not > > the message protocol itself. So one suppliers JMS will not talk to > > another suppliers JMS, so you become tied to a vendor. > > > > > > > > Has anyone thought of implementing JXTA with JBoss? > > > > > > > > Paul. > > > > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/j> boss-user > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
