With some recent discussions on SOA, ESB, and managing its complexity, I thought I'd write about some relevant points (at least, the ones I find quite relevant) and some questions.
Web Services and SOA
How do you know you're doing SOA? The common answer is, when you're using web services. Unfortunately, web services have nothing to do with SOA.
Web services were not created because of SOA! Yup, that's right. It was not created because of SOA.
SOA was first coined by Gartner back in 1996 (see note), long before any web services technology were even developed.
Web services were created to get heterogeneous enterprise packages and systems (mostly from big vendors like Oracle, IBM, Microsoft) to talk to each other in an interoperable way. The W3C started the web services group sometime in 2002 to do just that, and they came up with the web services standards that we know today (e.g. SOAP, WSDL).
W3C was not thinking of SOA when the web services group was developing standards. Unfortunately, the industry mistakenly thought that web services are for service-oriented architecture (SOA). Simply because of the word "service"—web services, service-oriented architecture. Duh?
Tenets of Service Orientation
Like object-orientation, the industry gave service-orientation a spin and (by doing) learned some lessons. In doing OO, we've come to understand that it's not just about inheritance. We've come to favor composition over inheritance, and we program to an interface, not to an implementation. In doing service-orientation, we've come to apply some design guidelines. One of them is Don Box's Four Tenets of Service Orientation. It originally appeared back in 2004 when Don Box published an article on MSDN called "A Guide to developing and Running Connected Systems with Indigo" (Indigo is what's known today as Windows Communication Foundation or WCF for short).
Don defined the following four (4) tenets:
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- Service compatibility is determined based on policy
Although it is showing its age, I still find it quite relevant. I think most people make the mistake of focusing on the technology of SOA, and forgetting about the underlying design principles of service-orientation. It seems that most are making the mistake of using some kind of ESB (or some other SOA-based tool) as a reason an excuse to implement SOA correctly.
One of the tenets indicate that (service) boundaries are explicit. So, how do we mark the boundaries of a service? What's a service in the first place?
The word 'boundary' (in boundaries are explicit) reminded me of a website (Should I Use SOA?) that Edge showed me a while back. It will ask you if you're Amazon. If you answered 'No', it shows a page that says you should not be using SOA, as it is too early. It goes on to explain something about separating services, getting the proper breakdown, and aligning team boundaries with service boundaries.
In service-orientation, I like Udi Dahan's definition of a service in service-orientation.
A service is the technical authority for a specific business capability.- The Known Unknowns of SOA - from Udi Dahan's Blog
Any piece of data or rule must be owned by only one service.
It's really about business capability. And there is a strong emphasis on encapsulation such that any piece of data or rule must be owned by only one service
.
So, if in my organization, we have the business capability of showing a catalog of products, and that is separate from pricing, does this mean we have to mark the boundaries along those lines of separation?
Or say, if in an organization, the HR owns the employee and employment data, and another group owns the customer data, does this mean that we have a service for HR to own all employee/employment data and rules, while another service owns all the customer data? What if a former employee becomes a customer, or vice-versa?
Here's another thought. Since services in service-orientation are built around a specific business capability, I remember reading an interview with Werner Vogels, Chief Technology Officer at Amazon where he mentions that Amazon applies the motto You build it, you run it
. Here, the team that develops the product (is this a service? a business capability?) is responsible for maintaining it in production for its entire life-cycle. All products are services managed by the teams that built them. The team is dedicated to each product throughout its life-cycle and the organization is built around product management instead of project management.
- an interview with Werner Vogels, Chief Technology Officer at Amazon
There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
If service-orientation is about business capability, wouldn't DDD (as it emphasizes business-domain) be appropriate to determine the 'boundaries' and the separation?
If services are autonomous, does it mean it shouldn't be relying on other services to function properly?
When I read services share schema and contract, not class, I ask myself, isn't this programming to an interface, not to an implementation?
Are your (SOA) services following (or breaking) any of the four (4) tenets?
There's so much more to service-orientation than I could write in this post. I hope to write more in the coming months.
Service-Orientation vs. Object-Orientation
Don Box explains:
Service-orientation is an important complement to object-orientation that applies the lessons learned from component software, message-oriented middleware and distributed object computing. Service-orientation differs from object-orientation primarily in how it defines the term "application." Object-oriented development focuses on applications that are built from interdependent class libraries. Service-oriented development focuses on systems that are built from a set of autonomous services.
- A Guide to Developing and Running Connected Systems with Indigo(Indigo is what's known today as Windows Communication Foundation or WCF for short)
Another point of difference is with how messages are communicated. In service-orientation, services send and receive data (no attached behavior). In OO, objects can send messages that contain data and behavior. In service-orientation, since services can be implemented using different platforms, it can only safely send/receive data (without behavior).
In Closing
I still have a lot to learn in service-orientation and in SOA. Writing this post has helped me clear things up. I think it's good to see that the industry is building on good things that worked (like service-orientation emphasizing on boundaries and autonomy, which I think was building on top of OO's encapsulation). I hope to write more about this as I do more SOA.
