Consider the First Fallacy: in fact, the reliability of a network can be measured. While edge-to-edge reliability cannot be easily assured in something as fluid as the Internet, LAN and WAN reliability measures are routinely tracked and expressed in percentage of downtime. By the same token, the speed of light can be measured, as can switching speeds, opto-electric conversion speeds, and other inflators of latency. Bandwidth too can be measured (see Fig. 10.1), as can transport cost, network administration and application porting costs.

Figure 10.1. Bandwidth and latency

In fact, all of Deutsch's fallacies—or rather the extent to which the assumptions that constitute them turn out to be untrue—can be measured. And any process that can be measured presumably provides opportunities for process improvement, hence added value. Consideration of the way in which a given middleware approach would reduce the impact of sometimes onerous reality, as specified by Deutsch, is therefore of value to software developers.

As “A Note on Distributed Computing” suggests, NDC developers may choose to ignore some aspects of reality in order to make simplifying design assumptions. So too can NDC frameworks. A framework can acknowledge a reality in one of two ways: either by masking the constraint or by exposing it through interfaces. If a framework masks the constraint, it must provide an extensible means of engineering around the constraint. If it exposes the constraint, developers are made aware of the need for mindful application adaptations.

For example, take the Eighth Fallacy: the network is homogeneous. The architects of Jini network technology initially made the simplifying assumption that a JVM with RMI would be everywhere. The problem of network heterogeneity would be masked from developers, even as the Jini approach acknowledged the fallacy. While the assumption may have been flawed from a (then) small-footprint-device perspective, it was reasonable for some applications and would allow work on a pioneering network platform to commence. And acknowledging the fallacy with a meaningful design choice meant that a more organic platform could emerge.

But note too the inherent risk. Even though we may acknowledge every fallacy at some juncture, as we must, there is no guarantee that the application will actually succeed in acknowledging the fallacy as the fitscape around it evolves. To the extent that WUS-style interoperability can give rise to an essentially homogeneous environment on the message level, the Jini approach to homogeneity, which is presumed to be orthogonal to XML wrappers, seems more brittle. So even while Jini would acknowledge the reality of a heterogeneous environment by assuming the homogenizing presence of a JVM everywhere, it ignores the reality of the early 21st century network, in which this homogenizing presence does not exist. By relative comparison, WUS acknowledges that reality where Jini ignores it, and this is reflected in relative levels of investment.

It is often unclear exactly where a framework may draw a line with respect to Deutsch's fallacies. Security is an area that must evolve as rapidly as increasing processor capabilities require; the more computing capability available to any random user, the more likely that computing capability will be used to inappropriately compromise current encryption mechanisms. So while solutions may currently exist or are envisioned, none of the cited NDC frameworks offer long-term clarity in regard to the false assumption that the network is secure. Nor can it be argued that any of the frameworks effectively mask this fallacy.

The hard lessons of network security have become of utmost importance to our evolving global community in the early 21st century. One such lesson is that the viability of a service depends as much on the relationship between service provider and user as it does on the nature of the service itself. Another is that security and trust are at the top of every company's list of obstacles, slowing broad adoption of all NDC frameworks.

If we would examine WUS from the perspective of network reliability, we must examine how WUS interfaces behave in the absence of it. Recall that WUS would essentially transform standard Internet pages into messages. Messaging in general and asynchronous messaging in particular are critically important to network reliability. A loosely coupled distributed architecture, like one expressed in an asynchronous messaging system, is ideal because it allows nodes on the network to fail without disrupting the overall correctness of NDC operation or the viability of an arbitrary message.

In NDC communications among enterprises and across business entities, the use of vanilla Web Services over HTTP does not yet suffice, because of the absence of a standardized asynchronous messaging capability. Nodes are sometimes temporarily unreachable, the reality of which we cannot ignore. In this sense, Web Services will benefit from a union with Java API for XML Messaging (JAXM) and its asynchronous messaging capabilities (discussed in Chapter 6). Interfaces will always need data transformation and end-to-end guaranteed delivery, along with all the other enterprise needs such as scalability and security. If the lack of rigor in vanilla Web Services is not addressed by more powerful mechanisms, such as JAXM-based messaging providers, the framework will ultimately flounder.

Vanilla Web Services effectively ignore the first of Deutsch's fallacies. When modified by extensions, such as JAXM or those envisioned in the ebXML community, the fallacy is acknowledged and mechanisms may be offered. But not so with vanilla WUS.

This is true of bandwidth considerations as well; XML is not terse. The same footprint arguments that marginalized the early Jini efforts apply in full measure to WUS XML data streams and parsing requirements.

The vanilla WUS stack is vulnerable; as a result, developers that produce applications based on Web Services must rely upon collaborative security solutions, composed by hand from existing technologies such as SSL and IPSec. While these approaches may secure messages exchanged within SOAP, they undermine the dynamic potential of Web Services precisely because they demand a high degree of static coordination and collaboration between partners and among nodes. It is likely that a more robust set of standards will emerge to address WUS security concerns, but it is not clear that any extension to a framework that is based entirely on the demands of interoperability between platforms can ever really offer baked-in security.

Asynchronous messaging capabilities are key to reliable networking, which provides the opportunity to manage a changing network topology on some level. To the extent that early WUS suffers from a synchronous view, its ignorance of the Fifth Fallacy (Topology doesn't change) is also betrayed. Any notion of self-healing must then become platform specific, which is not as interesting or as cost effective, as one that is more open.

The false assumption of a single administrator is also ignored by vanilla WUS. It is expected that simple, SOAP-wrapped messages can be effectively knitted together through a repository of independent components; this assumes either terribly adaptable software (something akin to a clever computer virus) or a certain level of hands-on production, albeit through accommodating point-and-click tools.

Think of the Semantic Web, which would harvest meaning from information dynamically. Now take away RDF, ontologies, and any notion of a standardized general-purpose agent mechanism; what remains is XML, SOAP, and the promise of Web Services with all the work we've taken away to be done by hand, page by page, by NDC workers. Do you believe the output of all those human-bound fitscapes will always play together well? The more interesting a Web Service is from a business-value perspective, the more likely it is to require significant effort to implement. Witness the activities in various quarters which would provide a Web Services interaction layer on top of existing legacy interfaces. This will take time, resources, and commitment to design, implement, test, release and promote, and will often require extensive testing with partners.

When it comes to transport cost, the Seventh Fallacy, recall that vanilla Web Services use HTTP, which rides TCP, which serves in the Transport layer of the OSI 7-layer conceptual model. Recall further the relationship of WUS to the OSI model, as shown in Figure 10.2.

Figure 10.2. WUS and the OSI 7-layer stack

If there are no transport issues beyond those resolved by TCP, the model is fine. But what happens when there is an application-level need for other kinds of transport services? The cost of those services, in processing time, network chatter, and the absence of asynchronous reliability, are high. Once again, in order to actually move beyond the reality barrier of transport cost at the Application layer, we require significant extensions. Whether proprietary, such as Microsoft's BizTalk, or community-driven, such as ebXML and JAXM, transport issues at a higher conceptual layer must be economically resolved at an NDC application layer. And HTTP is not the answer.

When it comes to interoperability, WUS technology has set the standard. As long as XML is agreed to be the means by which data can be described, the combination of a simple, extensible wrapper for networked objects with XML as the descriptive mechanism is a powerful metaphor. Add base-level repository functions, and interoperability is fully encompassed. To that extent, vanilla Web Services as shown in Figure 10.3 pay homage to Deutsch's Eighth Fallacy, even as they sidestep many of the others.

Figure 10.3. Vanilla Web Services and WUS plus ebXML/JAXM

Web Services must evolve. Perhaps (as in e-commerce) a few new companies will emerge, lured by the range of temporary niches exposed by the behemoth battles of a fitscape characterized by a highly competitive oligopoly, but the bulk of the business will ultimately go to existing service providers. Those with pockets deep enough to endure the large investments and slow ramp-up times that are likely to be typical of new Web Services will be the only winners in the end.

The first iteration of the Jini vision required RMI-enabled JVM implementations, bound to the first standard release of J2SE. Non-JVM devices might be proxied into the Jini network and were enabled as such, but a JVM was required at some juncture and there was no standardized proxy structure. Later work on a surrogate interface that would enable Jini services to and from non-JVM nodes found a home in the PAN space with Bluetooth devices. But at their heart, Jini networks dance to a JVM beat, and Deutsch's Eighth Fallacy is both acknowledged and ignored.

To the credit of the Jini community, the vision of a surrogate architecture and its potential for surrogate hosts that would extend to limited devices an organic interconnected world, addresses any Eighth Fallacy exposure. The same is true for network topology, because the surrogate design acknowledges wireless behavior at the level of the surrogate host.

In addition to the speed of light, network gnomes, and routing bingo, the latency of messages is bound to messaging infrastructure. Just as vanilla Web Services can sidestep latency issues with the addition of an asynchronous messaging provider approach like JAXM, the more synchronous RMI protocols provide the pipe to what is effectively a messaging provider in the Jini network LUS. Between RMI, leasing, and the LUS, an asynchronous, distributed transaction model emerges, belying its synchronous dependency. And if we're asynchronous, why do we care about latency?

In general, latency is the time wasted by one component in a system as it waits for another component. In NDC, the amount of time it takes a packet to travel from one node to another is included. Together, latency and bandwidth define the speed and capacity of a network. Leases provide the means to transcend the constraints of network latency.

With respect to bandwidth, Java bytecode is relatively terse even when marshaled, and while it may not be fair to compare portable behavior with portable data characteristics, interoperability must include both. The extent to which Jini LUSs expose services that are bound to extensible Java objects speaks well to bandwidth considerations. Leasing, with dynamic time increments, allows for a self-tuning network when it comes to bandwidth utilization. The Third Fallacy too is acknowledged by the Jini vision.

Even while the Java platform is inherently more secure than previous approaches to NDC, applications cannot play in the wild with some abandon unless aspects of security are baked in at the protocol level; this, at least, is the view of some of the efforts that would spoof-proof the Jini environment.

The Davis project is an effort by the Jini team at Sun to address the need for a Jini technology security architecture and will ultimately result in a Jini Technology Starter Kit release from Sun. This kit will include a network security programming model allowing applications written in the Java programming language to make use of network security mechanisms in conjunction with RMI. It will also contain other components to support remote object export and configuration programming models and will provide a security policy for dynamically granting permissions at runtime. A secure version of a customizable implementation of the RMI programming model, called Jini extensible remote invocation, will also be provided. These facilities will form the basis on which security will be added to Jini technology-enabled applications and services.

But as we have said, security is always a moving target. While the efforts of the Jini community with respect to the fallacies are laudable, the inherently nonsecure environment that flows and congeals with GFN aplomb around the network metaphor presents one of the fundamental challenges to NDC developers today. No matter which framework or approach is chosen, security matters will continue to require application evolution.

An inherently unreliable network is expected with a p2p approach. As with vanilla WUS, there is no general mechanism for reliable messaging, but the general topology of each framework suggests how it will be achieved. WUS will most likely use centralized mechanisms to create highly available systems, such as clustered application servers with load balancing and hot-swappable services. Peer systems will use distributed peers running the same service in a redundant manner, with the first available peer that receives the message responding to the request. Generally, a p2p approach gives rise to organic attributes akin to the Jini approach, but with an entirely different architecture. Recovering from partial network failure is a capability exhibited by both. Hence, Deutsch's First Fallacy is acknowledged by p2p.

Systemic behavioral patterns frequently emerge in p2p networks. Consider the phenomenon of access, for example, the “the more popular an item is, the easier it is to obtain” pattern is routinely observed in p2p-enabled approaches. Another is the previously cited phenomenon of cascading searches, which has an implication in the time domain as well as the value domain. Latency, which is already nonzero, can be magnified by the messaging requirements of search ripples, which may exponentially bloat lightweight network chatter. But this is not to suggest that the platform ignores Deutsch's Second Fallacy. Quite the contrary; it is understood that network latency exists, and the search ripples may take time to settle, so a certain level of latency should be expected. The JXTA specifications reflect this reality. By the same token, chatter is chatter; Project JXTA ignores Deutsch's Third Fallacy.

One of the interesting developments in the p2p space is the growing of “webs of trust”; in essence, one peer can loan its credentials to another peer. This innovation may be significant in a general NDC security sense and may one day find its way into other frameworks, like Web Services. But for our comparison, it is unclear if p2p realistically has advantages for or offers insights into security beyond those of any other approach.

As with the Jini network, p2p systems expect intermittent nodes, dynamic network links, and essentially changing topologies. Indeed, to the extent that Project JXTA protocols can ride HTTP through firewalls, much in the way of putative network topology can be ignored. Couple this aspect of Project JXTA with an incubator-ready GFN bias and the network can potentially take on forms not yet envisioned with respect to value. From a developer's perspective, p2p understands the fluid nature of network topology, but there is as much danger as there is potential for yet more ephemeralization in the topology-busting p2p vision.

To the extent that organic software attributes give rise to self-healing capabilities in networks, the need for arbitrary system and network administration is theoretically reduced. Deutsch's Sixth Fallacy is interesting in that regard. This assumption is false both because there are many administrators and because there are none. If the future is to include myriad personal, intelligent devices, all of which interact with myriad networks, the software that binds them must also be capable of adapting to an unpredictable world of users. The alternative is a ballooning of help-desk requests well beyond the limits of any cost-effective business model.

It can be said that Project JXTA acknowledges Deutsch's Sixth Fallacy even as it winks at the firewall, allowing JXTA peers to discover JXTA services well-hidden otherwise. When it comes to administrators, there are always either many or none; take your pick. Interoperability is an application-level choice. The first wave of Web Services will emphasize moving information from one company's server to another's, but WUS will fail to capture mission-critical information at vital touchpoints—employee desktops, EmNets, and wireless nodes. This is prime p2p real estate.

With respect to transport cost, recall that JXTA can play at a variety of layers on the OSI 7-layer stack. Project JXTA provides an inherent flexibility in regard to the OSI 7 model, as shown in Figure 10.4, that is not available with any other NDC framework.

Figure 10.4. Project JXTA and the OSI 7 stack

It is difficult to generalize about transport costs, because the needs of NDC applications invariably require the ability to intercede on some issues historically identified as germane to that datacom layer. Clearly, it is not viable to replace legacy protocols with each new application. But by the same token, as new services are envisioned, the repackaging, reliability, security, marshalling, and routing of application data will be of interest to those services. If, for example, my framework of choice relies entirely on HTTP or a similar protocol, any transport work my application may need to undertake must be within the session constraints of the underlying protocol. Network chatter and performance impact is the result. The distinct advantage of Project JXTA is the absence of assumption with respect to the Transport layer; it can be bound to HTTP as easily as to UDP, or even replace TCP if application demands are such as to require those lengths, without breaking JXTA protocols. To that end, Project JXTA acknowledges the cost of transport with a flexible design; vanilla WUS does not.

If all we did was examine the basis for messaging in Project JXTA, we would conclude that the pipe metaphor was insufficient for a truly reliable NDC system to emerge, due in no small part to the essentially synchronous nature of the pipe. But the JXTA protocols bring other potential dimensions to bear, and those accord more asynchronous benefits. A messaging provider approach based on JXTA peer, peer group, and rendezvous protocols is something we can imagine as easily as we can a JAXM-based service attached to a WUS network—or even to a JXTA network.