|
http://www.devx.com/javaSR/articles/ohearne/ohearne-1.asp JXTA and Web services have a lot in common. Take a detailed look at the communications platform behind each technology and see why JXTA is influencing the present and future of Java Web services. by Bradley S. O'Hearne |
|
In the beginning, a computer was created. But it was not good for that computer to exist alone, and so another computer was created. Computers were fruitful and multiplied, and countless networks emerged. Of course there is quite a bit more to it than that, but as these networks have grown more complex, the software applications that utilize them have had to address these ever-changing complexities.
I can recall that only a very few years ago, the hottest technology that could be boasted on a software developer's resume was experience with "distributed applications," and frequently, this phrase was more descriptively listed as "enterprise distributed applications." But examine this phrase, and the word "enterprise" gives away our collective industry predisposition toward distributed development. Such development was still fairly confined within an enterprise. This phase was bound to be short-lived, as the increased interconnection of networks has made the individual network appear as a microscopic dot from the stratosphere of the Internet. Distributed development no longer pertains to a cozy meadow inside the enterprise split rail fence; rather, it is millions of square miles extending into parts unknown. Applications are now faced with complexities previously non-existent, and two very popular technologies have emerged to address these issues: Web services and JXTA (an acronym representing the word "juxtapose"), Sun Microsystem's open peer-to-peer (P2P) initiative. Web services and JXTA address different problems, if only high-level design goals are considered, but a closer examination of their aims and architectures show there are more than cursory similarities between the two. These similarities bode well for those of us in the Java world, as the technological trifecta of Web services, JXTA, and J2EE will make the Java platform difficult to compete with.
Problem Domains JXTA on the other hand, is a P2P technology, focused on efficient use of the Internet ecosystem's collective natural resources. The collective processing power connected to the Internet far surpasses that which is utilized, and both the use of bandwidth and navigation of information gravitate toward heavily beaten paths and congested repositories, respectively. Put simply, the common methods of addressing the Internet (centralized servers and datacenters, centralized search engines and portals) aren't scaling proportionately to the growth of the Internet, and P2P seeks to solve this by using the cooperation of peers to accomplish various behaviors (i.e. services). However, while the formally stated problem domains look dissimilar, consider the pragmatic challenges facing the goals of both Web services and JXTA. These challenges are:
While the problem domains appear different, the major problems that must be solved by both Web services and JXTA are very similar. The answer lies in an open communications protocol, which both Web services and JXTA provide. An examination of the Web services and JXTA architectures will reveal that even under the microscope, Web services and JXTA share much in common.
Communication Architectures
At a higher level, there are more logic-related issues such as:
A successful communications protocol must address these. And continuing further, the aforementioned platform dependencies must be transcended. Let's examine both Web services and JXTA, and see how they address these issues.
Moving deeper into the illustration, the general Web services payload contained within an HTTP message bears an XML format. XML is an open markup language and hence, has no inherent platform dependencies. At a more detailed level, SOAP (Simple Object Access Protocol) is a specification that defines a standard exchange format for XML messages, and a way to perform remote procedure calls (RPCs). UDDI (Universal Description, Discovery and Integration Service), a SOAP-based message specification, provides a means for dynamic discovery of other Web services. And finally, WSDL (Web Services Definition Language) describes the capabilities of a Web service, and where and how to invoke the service. (Earlier pieces in this special report address these technologies in more detail. Essentially, there's one other detail worth mentioning here, and that is that Web services in general will be advertised and queried from a centralized registry of some type, which will facilitate the process of connecting providers and consumers of services. In a nutshell, that's the Web service communication platform. Figure 2 illustrates the fundamental elements in the JXTA communication framework. JXTA is essentially a collection of protocols, six of which have currently been defined, though more may emerge in the future. At its core, JXTA defines most notably the concepts of peers, advertisements, messages, peer groups, and pipes (all described in detail in the JXTA specification). JXTA is a bit less determinate than Web services in areas, and intentionally so, allowing for varied implementations, and platform independence.
The aforementioned network issues become a bit more troublesome in P2P, as it focuses on decentralization. However, JXTA 1.0 offers LAN-based discovery (multicast), discovery through invitation, cascaded discovery (peer viewing of another peer's already-discovered peers), and discovery via known rendezvous points (similar to a Web service registry). Rendezvous points specifically help to navigate the firewall and NAT issues. Peer Discovery Protocol allows for discovery of peers and advertising of services, which help to pair providers and consumers of these services. Initiating service behavior, as in RPCs, is a higher-level issue not defined by the JXTA spec. It might appear that JXTA has left certain issues unaddressed (network protocol and transport protocol, for example), but a better way to state this is that JXTA does not preclude alternate implementations. As long as the fundamental communication protocols are upheld, JXTA is, in theory, network/transport-protocol agnostic. However, it is reasonable to assume that a JXTA implementation used across the Internet might well use an HTTP transport protocol for the exact same reasons that the Web services framework does, to bypass firewall and NAT issues.
Web Services versus JXTA While Web services are sure to gain rapid acceptance as a design shift within the enterprise, there is a huge barrier to widespread usage of Web services on the Internet due to the politics of Web service discovery, as it relates to control of centralized UDDI registries (which is a large discussion of its own, and outside the scope of this article). However, JXTA's P2P underpinnings can steer around these issues, and provide alternatives for service discovery and communication. In addition, JXTA may provide more efficient scaling alternatives for Web services.
Enter J2EE Though their problem domains are different, Web services and JXTA are very similar in architecture because they both have to address common issues. The JXTA specification addresses a somewhat lower level of communication than Web services, and hence, it may provide the foundation for extension of Web services functionality in the future. J2EE is sure to absorb these two technologies, providing new avenues for developers to pursue as distributed applications become truly distributed across the Internet.
|
