Using JXTA vs. Mule ESB for Distributed Network Applications

Discussions

News: Using JXTA vs. Mule ESB for Distributed Network Applications

  1. Network applications are all over the place it seems yet their use is still increasing in popularity. This article highlights the pros and cons of using Mule or JXTA and contrast them to determine what is the best solution for a distributed network application. This article also highlights the differences and similarities to gain a better understanding of both and to open a discussion about the idea of Mule (or any ESB) supporting a technology like JXTA to gain its advantages if they are deemed beneficial. First off, why Mule? Why not ServiceMix or another ESB? I chose Mule just because externally Mule and SeviceMix appear to be the same and their only differences appear to be under the hood. JXTA is an open source peer-to-peer protocol used to send text/binary messages or streams over unreliable disparate networks to peers belonging to specific groups. Strictly speaking, JXTA is a set of open XML-based protocols used to create logical networks on top of physical networks. JXTA has several bindings that implement these open XML protocols to accommodate different platforms, such as jxta-jxse, jxta-c and jxta-jxme. Mule is an Enterprise Service Bus used for send, transforming and routing text/binary/POJOs to one or many endpoints on unreliable disparate networks. Both Mule and JXTA have overlapping features such as providing network independence or a platform to abstract the network from the application. They also provide communication and services to a group of authorized peers over secure channels and the ability to emulate various network topologies: P2P, client/server, service buses. So how are they different? The most obvious difference is that Mule is a "high-level" technology designed for quick implementation to solve many distributed application problems like having two legacy applications communicate over a network with each other in different data formats or protocols. JXTA, in comparison, is a "low-level" platform that provides a set of its own networking protocols that the developer must implement to communicate with its remote peers. As you might expect, JXTA has a higher learning curve and has more parts to manage than Mule does, but as you also might expect, JXTA provides finer control over the network semantics and can reach peers through more firewall and NAT configurations than Mule. Topological comparison between both technologies for sending data through firewalls: * IMAGE 1 * IMAGE 2 JXTA - Pros * Creates P2P Networks with Peers and Service Grouping * Autonomously find peers and resources on the network even across firewalls * Create your own groups of peers and devices across different networks * Secure communications * Exchange messages independent of the network topology JXTA - Cons * Stable release is lacking some performance and convenience enhancements. * Nightly release is pretty much needed but some functionality is broken at the time this article is being published * Some complexity to accomplish tasks * Non-transparent API and steeper learning curve Mule - Pros * Easy to Setup, Use and Configure. * Can talk to other applications like C and PHP over various network protocols. * Passing Business Objects over the network (instead of packets and streams). * Abstracts the transportation protocol * Can connect 2 endpoints with different output formats together. Mule - Cons * Can't do peer discovery * Can't do sharing or Advertising of resources * Can't communicate through a firewall without possibly changing the firewall rules on the client side. Both have in common: * Polling external peers from behind firewalls to establish a 2-way connection. * Documentation is lacking and is still being developed and written. Conclusion: In a distributed network application, it is necessary to be as independent of client side firewall rules as much as possible. This is where the 2 technologies differ. JXTA can work from behind a very restrictive firewall by utilizing relay peers and back-channel polling; the bare minimum would have to at least allow out-bound port 80 but can block all in-coming. Mule sometimes needs to expose in-coming ports on both client and server side. If you are distributing your network application on an internal or private network where you, the developer, has control over the firewall & NAT rules, then Mule would be a good choice, but if your applications will be distributed behind multiple unknown firewall & NAT configurations, then JXTA would be a better choice. Ideally, we would want one networking framework to take care of both of these. Possibly in the future, an ESB vendor could provide support for JXTA. Ryan Smith is the Lead Developer on Distributed Networking projects at his current employer: S&H Solutions. He can be reached through his website: http://ryanjustinsmith.com/ or on IRC under the /nick AlphaOmega in the #esb and #jxta channels on irc.freenode.net.

    Threaded Messages (18)

  2. Ryan, I think you missed the point here. When you mention Mule 'communicating' to external systems or peers, that doesn't make much sense, as it's your transport that defines the rules and doing communication. The truth is Mule would use a local JXTA peer, which would in turn cross the boundaries as needed, with JXTA becoming one of Mule's transports. There's this old JIRA http://mule.mulesource.org/jira/browse/MULE-59 mentioning JXTA, but we didn't go with it at the time.
  3. Right. I don't understand the sense of the article either. You could also use a decent JMS implementation as transport to cross firewalls. Also, to cross firewalls (out on one side, in at the other) you'd need to open at least one inbound port of them or need to place a node outside both firewalls... Or do I miss something? -- Andreas
  4. Also, to cross firewalls (out on one side, in at the other) you'd need to open at least one inbound port of them or need to place a node outside both firewalls...
    Or use UDP ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid
  5. Cameron, Good link. UDP is great for broadcasting presence or doing video/audio data transfers since a few packets being lost here or there is ok. UDP is not guaranteed. But in the case where data integrity is crucial (zero packet loss), we must use TCP or a layer on top of UDP to ensure reliability. The closest thing i have found so far is: https://jxtacast.dev.java.net/ jxtacast is an application written on top of JXTA to send packets via udp and reassemble them on the other side. If any packets are lost in transmission, they are re-sent until the full transfer is complete. I also found https://rmp.dev.java.net/ which is a stab at reliable multicasting udp packets.
  6. UDP[ Go to top ]

    UDP is great for broadcasting presence or doing video/audio data transfers since a few packets being lost here or there is ok. UDP is not guaranteed. But in the case where data integrity is crucial (zero packet loss), we must use TCP or a layer on top of UDP to ensure reliability.
    Right. Keep in mind that TCP and UDP both use the same underlying IP datagrams for communication, it's just the question of who handles resends, flow control, etc. In the TCP case, it is done for you, e.g. by the network stack. (We use UDP for all our data transfer requirements, because it lets us flow information much more efficiently and effectively in a peer to peer cluster than TCP/IP could do, although with Java NIO combined with TOE cards, you could probably get close.) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  7. And what most people do not understand is that TCP alone is not enough for reliable communication. When you write something to the stream, and your write call returns successful, you can not be sure that the destination application processed the data. Just think of the situation where the receiving application finished the read call and crashes. You can only be sure the other side received (processed) the message if you receive an acknowledgement. And even that might fail if the acknowledgement comes from your communication layer, the message still might fail to reach the business (persistent) layer. Writing reliable distributed applications is far from being trivial.
  8. Hi Ryan, Mule does support http and udp and a load of others - http://mule.mulesource.org/display/MULE/Transports+Guide. It was interesting to read your analysis, but I looks like you're comparing apples and oranges here. (you do allude to this by stating that Mule is a higher level technology than jxta). It would make sense to have jxta transport for Mule so that we could support discovery. But since we haven't had any expertise on the team for jxta, we haven't implemented it. It would be complimentary to the project. Cheers, Ross
  9. Ross, You're right about the apples and oranges. It's actually funny, because I used the same phrasing in my original post to TSS but *someone* took that part out ;) If you go to my website, its on my original article there, the first sentence is: "After reading the title of this article you might be saying to yourself, "Mule is an ESB and JXTA is a P2P platform. Apples vs. Oranges" " Oh Well, maybe one day ill have have editor rights ^_^
  10. Or use UDP ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: Data Grid
    Yeah, but there is this little initial step before UDP can be used... I don't read much of you anymore, Cameron. Too busy? ;-) -- Andreas
  11. busy?[ Go to top ]

    Yeah, but there is this little initial step before UDP can be used...
    True, true. Speaking for Coherence, six years on and we're _still_ investing pretty heavily in that "initial step". The problem is that TCP/IP is usually "good enough", so it has had the effect of cheating the world out of having anything better. Personally, having looked at TCP/IP in detail, I think it's relatively atrocious from a technical point of view, but 30+ years on and it usually works well enough that most people don't have to look at it in detail.
    I don't read much of you anymore, Cameron. Too busy? ;-)
    Yeah, but it's not _all_ fun and games. Lately, I've been working on getting some bleeding edge technologies to work for me ;-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  12. Andrew, Thanks for the reply to my article. As far as I know about Mule, I can configure my Mule transport to talk over vm:// http:// ftp:// soap:// or any number of protocols that mule supports. So lets assume for a moment that Mule didn't support the http:// protocol for transport. Would it be trivial to then define a transport that can talk over http:// using Mule? My guess is it wouldn't be all that easy but I could be wrong. You tell me :) In the last few sentences in the article, I made note of the MULE-59 JXTA issue there, and it looks like the reason the JXTA support was not worth pursuing was because of too many overlapping features. While this is true for the most part, as i stated in the beginning of the article, I came to the conclusion that there were relay/routing features that Mule was lacking compared to JXTA. Is it easy to define a transport that talks to jxta:// peers without Mule supporting the jxta p2p protocol? Just thinking about that seems like it would be pretty messy without native Mule support.
  13. target="_blank">http:// protocol for transport. Would it be trivial to then define a transport that can talk over http:// using Mule?
    My guess is it wouldn't be all that easy but I could be wrong. You tell me
    Ryan, the moment you figured out how to get a discrete message out of JXTA (listener, polling, etc.) and into JXTA world, you've got most of the stuff done. Really, if the concept confused you before, have a look at http://mule.mulesource.org/display/MULE/Transport+Archetype The archetype has been published in public m2 repos for some time, and is also available as m2 plugin, thus. This wizart will guide you through the process and generate most of the plumbing code (not that much code indeed, but helps anyway :) At the moment original JXTA jira was resolved as Won't Fix, it made sense, and today JavaSpaces/GigaSpaces integration serves the purpose. There's nothing wrong with JXTA as long as there are people using it. JXTA integration can be revisited, and we are finishing the infrastructure tests for a big launch of MuleForge where e.g. you can host this project (by now there are around 3rd-party projects hosted already). Mule's idea is to let one use best-of-breed technologies and remove as much integration burden out of one's way as possible. Not replace them. Much like Spring configures your system, Groovy glues existing Java libs and removes much of the complexity. Hope I've got a new convert here today :) Andrew
  14. tests for a big launch of MuleForge where e.g. you can host this project (by now there are around 3rd-party projects hosted already).
    Missed out the number somehow, it's 20.
  15. Andrew, Already converted. I like your idea of MuleForge and think JXTA would be a great candidate. But I was surprised to learn Mule & ServiceMix didn't already support a peer to peer transport protocol: http://mule.codehaus.org/display/MULE/Transports+Guide http://incubator.apache.org/servicemix/components-list.html Maybe I thought p2p was more popular than it really was? ActiveMQ says they support JXTA pretty much: http://activemq.apache.org/topologies.html (at the bottom) Maybe this is a step in the right direction? Ideally, as a developer, I would like to send data/invoke services over JXTA through Mule, and configure a JXTA transport with a couple(cough) lines of xml. From what I know, Mule is a great ESB and JXTA is a great p2p protocol. And from what I've read here, it seems like its worth adding support, ..wink,wink,nudge,nudge...so count this as +1. I wouldn't mind trying to get something started on MuleForge for JXTA. Maybe others see a value in using an ESB over p2p as well... Thanks for the replies so far :)
  16. JXTA on MuleForge[ Go to top ]

    Ryan, I think it's time to move the discussion to the user mailing list ;) We can discuss the submission/infrastructure details and get you started. Cheers, Andrew
  17. Re: JXTA on MuleForge[ Go to top ]

    Andrew, Indeed. When i get home, I'll contact you on the dev list. Thanks again for the responses here. -Ryan
  18. Ryan, I have been using Mule for a while and am a big fan of it. Mule provides a higher level abstraction to JXTA. JXTA is more of a P2P specification and of course the implementation provided by the RI, whereas Mule is a service mediation and orchestration framework. There is nothing stopping you from having a Mule connector for JXTA. However, the JXTA protocols support a rich set of P2P semantics like discovery, resolution, pipes etc, compared to the out of the box transports supported by Mule. One thing you may be interested in is Fabric3 (http://www.fabric3.org), it is an OSS SCA (http://www.osoa.org) implementation, as well as a federated service provisoning and governance framework. We have a pluggable discovery model within F3 for federated peers in a managed domain and currently we use JXTA as the implementation protocol. We had the 01 release out last week and you can find the distros here, http://fabric3.codehaus.org/Downloads There is also documentation here on federated service provisoning which internally uses JXTA PDP for discovery and PRP for messaging, http://fabric3.codehaus.org/Distributed+Domain+Tutorial This demo was presented at TSSJS Vegas and Barcelona as well as JavaOne. You can find the slides here, http://docs.codehaus.org/download/attachments/77960/TSSJS_2007.europe.final.pdf?version=1 BTW we are also talking to the Mule guys on having a joint venture on supporting SCA within Mule. Ross, I hope you don't mind me mentioning this here. Kind regards Meeraj (Sorry, I have been using a friend's account to post this reply, for some reason my TSS account id doesn't seem to be working)
  19. There is also documentation here on federated service provisoning which internally uses JXTA PDP for discovery and PRP for messaging
    Meeraj, Thanks for the links. Looks like an interesting project and that's keen to use JXTA for the discovery. JXTA has 6 protocols, and you are using 2 of them. The one JXTA protocol this article focuses on is the ERP (Endpoint Routing Protocol) which returns route info ( a list of relay peers to use for routing messages properly around firewalls/nats) but from what I understand after talking to Malveaux on the #jxta channel on irc, you could easily have to implement 4 or 5 of the protocols to get Relay working properly. Right now, I'm setting out to attempt a JXTA transport for Mule on MuleForge (wish me luck) If all goes well, i'll be able to implement all 6 jxta p2p protocols https://jxta-spec.dev.java.net/nonav/JXTAProtocols.html -Ryan