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
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[2]
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 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:
[1] http://incubator.apache.org/servicemix/how-does-servicemix-compare-to-mule.html
[2] https://jxta-jxse.dev.java.net/issues/show_bug.cgi?id=42
- [3] http://mule.mulesource.org/jira/browse/MULE-59