Peer-to-Peer Services

For several years now, ZapThink has spoken of the “horseless carriage” view of Service-Oriented Architecture (SOA). Just as people thought of early automobiles as carriages, only without the horse, today people are thinking of SOA as traditional integration, only now with Web Services. In retrospect, we know now that cars really don’t need to look much at all like carriages, and once people became comfortable with autos in and of themselves, the industry began to take off. Today, the world of SOA is struggling with the same kind of mental shift, as companies struggle with the right way to deploy Services.

One of the biggest challenges is whether to deploy Services through middleware approaches that leverage a centralized broker or bus of some sort through which Services can connect, or utilize a more distributed approach that treats Services as independent entities on the network, intermediated by distributed points of control. As companies get more comfortable with SOA, it will become increasingly clear that these different approaches will mandate very different styles for building out an infrastructure for SOA. What’s most interesting is that SOA doesn’t impose a particular implementation style such as specifically a client/server, request-response model, but rather allows companies to start thinking about implementation approaches that typically have been applied to solve other, non-integration focused problems.

Peer-to-Peer Services
One of the more interesting approaches to Service interaction is the idea of Services communicating in a peer-to-peer (P2P) fashion, rather than through brokers, buses, or hub-and-spoke approaches. P2P networks enable distributed, lightweight intermediaries to take the place of today’s tightly coupled integration approaches by driving intelligence into the network itself. P2P differs significantly from bus or middleware-centric approaches in that it shuns any centralization of application resources. In a P2P network, any Service can act both as a server by providing functionality to any requester and as a client by accessing other Services. In a P2P environment, each functional unit in the network behaves the same. There is no fixed role for a Service as there would be in a client/server environment, and as such, the endpoints must handle security, reliability, management, and process control on a per-Service basis rather than through a centralized server approach.

In a client/server world, Services are better off the more stable they are. Since the server or bus acts as a container for the Service, constantly shifting around the location or behavior of the Service imposes a cost. However, in a P2P environment, changes in location or behavior do not incur such costs. Indeed, in a P2P environment the network is constantly fluctuating and dynamic, with relationships between Service peers changing as the load or requirements change.

Clearly, there is nothing wrong with Services that sit on a server somewhere, managed centrally by a bus, broker, or hub, but there is also nothing in SOA that mandates that particular implementation style. Indeed, you want your Services to be loosely coupled, composable, constantly changing entities, and therefore, you should be able to deploy them in many ways, with P2P being particularly applicable in scenarios of unpredictable change.

Every Service a Consumer and a Provider
Before we can dig into how SOA can leverage P2P Services, however, it’s important to understand how P2P differs from other implementation styles. In the client/server and n-tier models of interaction, some piece of functionality, exposed either as a Service or through a programmatic API, fulfills the role of a server that provides information to any number of requesting client nodes. Clustering and other approaches centrally manage, secure, and scale the server.

In P2P networks, on the other hand, every node must carry the full responsibility of the server. Each node must be responsible for its own security, reliability, process, and management capabilities. Each node must also carry the responsibility of the client as well. Finally, there is often a centralized registry that helps the nodes find each other, but is lightweight in that it does not participate in the communication between the nodes. Success of technologies like instant messaging and peer-to-peer file exchange have proven P2P networks to be very reliable and secure, even in the face of significant usage.

There are clear synergies between P2P approaches and SOA. When we talk about SOA, we refer to three parties that participate in Service interactions: Service providers that offer Service functionality, Service consumers that utilize that functionality, and Service brokers that serve to intermediate requests between Service consumers and providers. Traditionally, we think of each of these parties as separate entities. However, it is more useful to consider Service consumers and providers as simply different behavioral roles for Services rather than separate pieces of software.

Whenever someone implements a Service provider on a server, they must make certain assumptions as to who will access that Service as well as assumptions of load, security, availability, and transactionality. However, if every participant in the network was both a Service provider and consumer, then scalability, security, and reliability could be a function of the entire network, rather than any one particular node. The more Services there are on the network, the greater the capabilities of that network, and thus the more reliable, secure, and robust it can be.

Another key difference between P2P approaches and traditional integration approaches is that P2P networks only have one thing to deploy — the peer. There is no need to consider separate implementation styles for Service consumers and Service providers. P2P networks also radically change the way that the architecture can handle business process. Centralized approaches predictably orchestrate business process centrally, where a business process runtime engine orchestrates the flow and control of each process. A peer-to-peer approach requires a conversational perspective to business process, in which no one party controls the dialogue, and business process occurs as a result of mutual interest in the conversation outcome.

The Role of the Intermediary in a P2P SOA
Clearly one of the challenges of P2P is that each Service node must carry the weight of the network on its shoulders, introducing significant challenges. For example, there’s likely to be a heterogeneous security infrastructure. Each Service node might exist in different security contexts, requiring different security technologies and approaches. It would be impractical to impose the requirement that every Service node must then comply with the security requirements of every other node on the network.

Furthermore, standards for reliability, management, and messaging continue to be in flux. We might have to update every node as new standards emerge for particular security, process, or management challenges. However, the biggest problem of all is that developers are simply too overwhelmed to have to deal with security, process, reliability, and management challenges every time they build a Service.

One way to tackle these challenges for P2P Services is to use a single runtime environment for containing individual Services, such as some ESBs or the Microsoft Windows Communication Foundation (formerly Indigo). The problem with this approach is that it requires all Services on the network to participate in that particular runtime environment to get the benefits of robust Service control. An alternative approach that is more optimal in environments of heterogeneity is to utilize smart network intermediaries that distribute points of control throughout the network to handle security, reliability, process, and management on behalf of participating Service nodes, freeing Service endpoints to simply provide and consume Service capabilities while delegating quality-of-service and control functions to distributed, lightweight intermediaries.

The ZapThink Take
On closer examination, we find that the distinctions between peer-to-peer and middleware-based approaches for Service implementation are not as well-defined as one might think. Each approach provides a network of Services and a way to handle requests between nodes that serve as consumers or providers. A P2P network indeed consists of many individual client/server connections, and an ESB with distributed Service containers looks a lot like a P2P implementation. However, what matters the most is that in order to maintain the goals of loose coupling and composability of Services in the face of continuous change and heterogeneity, companies must take an implementation-independent view of Services. By abstracting the underlying implementation technology of a Service, we can finally move beyond the horseless carriage phase of SOA and enter a new era of dynamic, flexible distributed computing.