Print
Hits: 4577

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"  Yes, both technologies are quite different and intended to solve different issues, but both can be used to solve many of the same issues each other has been designed to take care of.  Network applications are all over it seems yet their use is still increasing in popularity.  This presentation aims to highlight the pros and cons of using JXTA or Mule and contrast them to determine what is the best solution for a distributed network application.  This article aims to highlight the differences and similarities and to gain a better understanding of both.  This article also aims 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[1] 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 to send, transform and route 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 providing a set of its own networking protocols that the developer must implement in concert to communicate to 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 and more custom control over the network semantics and can reach peers through more firewall and nat configurations than Mule.

 

 JXTA – Pros

 

 JXTA – Cons

 

 Mule – Pros

 

Mule – Cons

 

Both have in common:

 

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 somewhat.  JXTA can work from behind a very restrictive firewall due to 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.[3]  Possibly in the future, an ESB vendor could provide support for JXTA.

 

 References:

Diagrams