1. Network Protocols
2. Transport Protocols
3. Firewalls
4. Network Address Translation (NAT)

At a higher level, there are more logic-related issues such as:

1. How are services advertised by providers?
2. How are providers found by consumers?
3. How do providers understand what services a provider offers?
4. What are the rules for initiating service behavior?

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.

	Figure 1. The Web Services Communication Platform

Figure 1 illustrates the fundamental elements in the Web services framework, and their relationship to one another. As the transport protocol, HTTP handles the network issues. Higher-level data is tunneled via HTTP as its payload. HTTP, of course, is the request-response transport protocol that enables the Web, and it dictates a network protocol of TCP/IP. Firewalls and NAT essentially become a non-issue with HTTP, because HTTP traffic commonly travels across port 80, a recognized port that most firewalls leave open for inbound traffic, port-forwarding as necessary to the desired Web server (which gets around the NAT problem).

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.

	Figure 2. The JXTA Communication Platform

JXTA does not mandate the network or transport protocols, how discovery of peers is done, how messages are propagated, or even the format used to encode messages between peers. Practically speaking however, the JXTA 1.0 implementation does offer several methods of discovery, defines propagation scopes, and uses XML as the encoding format.

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
I used the word "versus" in the preceding subheading simply so I could refute it. These technologies don't compete; on the Java platform, they complement each other. There are obvious areas of JXTA that are subject to definition by the implementer—these aren't because Web services are superior to JXTA, but because JXTA to some degree is operating at a lower level than Web services, providing additional P2P functionality.

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
One quick word about J2EE needs to be mentioned: the Web Services Development Pack for Java and the JXTA Java implementation will almost inevitably find their way into J2EE. The J2EE architecture suffers in a very specific area because of its relatively centralized underpinnings: wide area, high-volume deployments. Web services and JXTA lay the foundation for solutions to these problems. (See the companion article, "Does JXTA Add Web Services Leverage to Sun?")

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.