The Service Network

Today, there are largely three camps when it comes to web service architectures: The SOA guys, The Bus guys and The Protocol Network guys.

The SOA guys
The SOA guys were the original 'web service' people. They viewed the new paradigm as a ubiquitous service based system that would utilize the architectural pattern known as SOA (Producer, Consumer and Directory). The SOA guys are the people that build UDDI servers and SOAP platforms. They have taken the best of the CORBA world, learned some lessons and reapplied it to a new set of protocols that are accepted by MS and IBM. The SOA guys rarely mention a 'network topology', but their implicit topology is point-to-point (my consumer directly calls your producer).

The Bus guys
The Bus guys are the people who believe in messaging. Ultimately, messages and services go hand in hand. Some people put more emphasis on the service (SOA guys), while other put more emphasis on the message (Bus guys). The Bus guys also love asynchronous communication - thus, they loves queues or any other store and forward mechanism. Unfortunately, most of the Bus guys come from the JMS world and largely their stuff doesn't interoperate (think ESB). The Bus people usually think that the web services network topology is hub and spoke.

The Protocol Network guys
The Protocol Network guys are the people who treat web services more like networking protocols. These guys put emphasis on two things: wire protocols and policies. They see everything as a policy on a protocol. These guys love specs like ws-addressing, ws-discovery and ws-policy. The Service Network guys see the network topology as being adaptive based on the state of the network. They rely on routers, load balancers and other devices that have knowledge about the running services to make informed decisions on the fly.

The reality of is that most large companies will need a hybrid of all three. They will embrace a standard SOA triangular pattern, but letting a Protocol Network make routing decisions at run-time, with the messages often ending up in queue. I continue to consult to my clients about the convergence of the three paradigms. This convergence is what I call the Service Network.

The Service Network is a message-based, service-based and protocol-based computing model.
- It leverages the SOA model to decouple producers and consumers and to provide lookup capabilities for self-describing services.
- It leverages the Bus model to provide asynchronous communications for long-running processes.
- It leverages the Protocol Network to provide runtime decision making about locating and executing a service on the network based on the service network conditions.

Another way of looking at these models is:
- SOA decouples software units (consumer and producer)
- Bus decouples software in time (synchronous = time-coupling)
- Protocol Network decouples software from hardware (run a service on some machine)

The goal of the service network is to provide all three forms of decoupling.