In last week’s training, one of the biggest “Aha!” moments for me was an answer to the simple question “What is a service?”
As someone who consumes a lot of guidance from Microsoft’s p&p team, and looks to gurus like Nicholas Allen, Michele Leroux Bustamante and Juval Lowy for all sorts of WCF insights, my working definition of a service has been a very technical one. A service is a cohesive set of functionality described by a contract. In WCF terms, it’s a .NET interface decorated with a [ServiceContract] attribute, along with one or more implementations of that interface.
One of Udi‘s major themes in the training was how writing code is usually the easy part. It’s design that can be hard, and good design is always closely related to the business problem you are solving. The “Aha!” for me was that a service in SOA has very little to do with technology — a service is a business concept. Business services are what SOA is all about. Apparently my mistake is not uncommon.
Bill Poole has written a series of excellent posts on SOA. I highly recommend them as a primer on business services, including how they relate to web services. (In fact, you should just go back to his first post from early 2008 and read them all. It’s well worth a couple hours of your time.) From Bill:
So – the primary concern in SOA is the identification and definition of the architecture’s constituent services. When applying SOA in a business context we are concerned with identifying business services. A business service serves a specific business purpose, and is defined strictly in business terms.
We define the responsibilities of a business service in terms of the cohesive business area/capability the service supports, and we define the interactions with other services in terms of the business events and operations exposed by the service, as well as the service level agreements provided by the service and the policies imposed by the service on its consumers.
A business service is conceptual and maps to a business capability, not to a development artifact. It’s the “Shipping service”, not IShippingService. Asynchronous messaging is the only way that the Shipping service interacts with other business services — as a subscriber (PaymentReceived message) or as a publisher (OrderShipped message). Its internal implementation may include web services that talk to one another synchronously or asynchronously, or that wrap legacy, COTS, or external systems (like an SAP shipping module or a UPS-provided web service). But those web services are not accessible by anything outside of the Shipping service.
The promised benefits of SOA seems much more realizable when you think in terms of business services.
Take loose coupling as one example. We all know that it’s a good thing, and we are told that web services help us achieve it. But how loose is the coupling between a web service and its clients? As long as I don’t change the web service contract, I can change the implementation of the service without affecting any of its clients. There is no direct binary dependency on the service or its interface.
Alas, in the real world, if I change the business rules inside my web service in any significant way, it’s likely that I’ll also have to change the way that clients use it in subtle or not-so-subtle ways. The subtle ones are where the real headaches are, especially when I try to get reuse by having multiple clients accessing my web service from slightly different business contexts.
If the client is using synchronous RPC-style calls to the service, it is temporally coupled to the service — it’s has to wait for the service to finish its work before it can continue. Even if the service uses asynchronous, one-way operations, all too frequently it is receiving what Bill calls command messages, where the client is instructing the service to take some action. That’s a form of coupling, as well — the client can’t fulfill its responsibilities without the service.
Business services interact with other business services solely through asynchronous messaging — primarily event messages. That’s about as loose as it gets.
None of this is to say that web services are bad in any way. They’re a powerful tool in our developer toolbox, and I love what WCF does for me. But web services are an implementation detail within business services.