This blogpost is part of a larger blog post series. Get the overview of the content here.
But messaging alone is not enough! We need to decompose our system. Service Orientation can help us with that. Service Orientation or Service Oriented Architecture was first used in 1996 when Roy Schulte and Yeffim V. Natiz from Gartner defined it as “a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes”. Unfortunately the term SOA has become a loaded term filled with misconceptions and hype. I stick with Arnon Rotem-Gal-Oz definition:
Service-oriented architecture (SOA) is an architectural style for building systems based on interactions of loosely coupled, coarse-grained, and autonomous components called services. […]
Unfortunately the term service is pretty overloaded these days. That’s why we have to define what a service is not. A service that has only functionality like a check if an order is valid is a function and not a service. Also when talking about services in the software industry people immediately think about web services. In SOA the term service has nothing to do with a web service. It is neither a class but more an autonomous bunch of components which belong together regarding business functionality. Nor is it a something, which has only operations like create, read, update and delete. That is a database and also not a service. SOA is also not a set of technologies. It is technology-independent with a slight preference for messaging. The larger the granularity of a component gets, the harder it is to reuse it. Therefore SOA cannot be consider a reuse strategy. Of course SOA will allow your services to evolve over time and adapt, you don’t need to start from scratch every time. You cannot buy SOA, but of course tool vendors will tell you the contrary. IT and business alignment is something we want to achieve with SOA, but it isn’t what SOA is.
The advice I can give is that every time you hear the term service in SOA related topics just replace it with the word “thing” or “box”. Let us describe the characteristics of this “thing” in the SOA world:
The “thing” is the technical authority for a specific business capability. For example if we talk about a sales “thing” then all data which belongs to the sales business capability remains within the “thing” itself. This holds also true for all business rules attached to this business capability. After we have identified all “things” in our business domain, nothing is left over in our business domain but clearly identified to which “thing” it belongs. So everything is contained within a “thing”.
There are four tenets describing real service orientation – or shall we describe it as “thing” orientation? A “thing” needs to be autonomous meaning that it cannot rely on anything else in order to be operational. It also needs to have explicit boundaries. It must be crystal clear what belongs to it and what doesn’t. It only shares contract and schema but not classes or types between others. Therefore none of its behaviors can be used outside of it but only their effects can be observed. If interaction is necessary between “things” this has to be controlled by policies.
So far the conceptual side of “things”, from the technical side a “thing” is responsible for its own availability and scalability, it may communicate over multiple protocols and transports and it may have multiple endpoints.
Before we dig deeper into the characteristics of a “thing” we need to talk about the explicit boundaries of a “thing” and what contracts actually mean but this is a subject for another blog post.
[…] Services are not webservices […]