.gif)
This post is motivated by an article on Carlo Poli’s Blog on the foundation of architecting Service Orientation.
The Essence Of Ideas
There, he clearly identifies a highly misunderstood way of designing services by focusing them from the technical point of view and declaring the use of web services als “SOA”.
From that on, system decomposition is introduced as the first step in service orientation, as systems are annotated with functions and responsibilites. This leads to declared service interaction patterns as provider, consumer and that is the defined contract. Thinking of interaction patterns is stated as the key to good service contract design.
The Building Blocks
From the, rather short, summary above, I conclude that Carlo introduced three building blocks of service orientation:
- A service is nothing defined from the technical perspective
- System decomposition and role definition is a major step
- Service Interaction Pattern are key to defining a good service contract
To roll on the discussion, here is my point of view:
The Basic Concept
Service orientation is something business oriented. The evolution of service orientation is mainly triggered by the IT need to implement business functionality in shorter cyclies under more pressure in ever-changing environments. In todays’ heterogeneous infrastructures, interoperability is key to delivering business functionality.
Service orientation is triggered by delivering business functionality faster, cheaper and more flexible
From that on, I totally agree on the fact that service definition must not be anything technical. Delivering business functionality means that IT delivers changes the way how the business works, how the underlying business processes work. From a process management point of view, that means the building blocks of business is altered.
Addressing business process needs from that direction directly leads to defining services from the business level, as the business process modeller defines the blocks which are to be altered.
To deliver a sound service-oriented architecture and –solution, IT has to think like the business works and needs to understand, how applications are used and how they add up to support the business.
System Decomposition
When it comes to process definition, which is the foundation of service orientation, decomposing the business is an essential step to define the proper functionality. It is mandatory to focus first on the underlying busines process which is to be modeled. From that on, the building blocks need to be identified. These are business related functions as also as technical functionality (authentication, etc.) In the process of decomposition, it is always necessary to define, which functionality is externalized into a separate service and which functionality is implemented in the service itself.
Decisions of that kind are never easy to make and mostly need refinement. Typically, when focusing on a concrete requirement to implement, the business functionality has to take precedence, as this is the ultimate goal of IT: supporting the business. Nevertheless, ongoing projects and improvements may make it necessary (or open the opportunity) to refine the strategy and therefore externalize more functionality.
Service-orientation is ultimately about re-use
To ease the decision whether to externalize or the internalize functionality, keep in mind that service-orientation is ultimately about reuse. If functionality can be reused, externalize it!
Service Interaction Patterns
Carlo states that deciding on the service interaction pattern is the key to good service contract design. So, what is a service about: A service is about delivering a specific functionality on a specific manner. To fulfill this, a service needs informations of some sort and results in some sort of data (or not). That is a contract.
A service contract is about data being delivered to a service, data being delivered from that service and any non-functional which my be about performance, among others
Everything else is about interaction. The web service standards offer a wide range of possible messaging contracts, which are for example:
- In-Only
- In-Out
- Out-Only
This is about how a service is used. It makes up an essential part of the service design, but not the contract essentially as a service can offer different types of interactions.
Therefor, I’d like to distinguish between service contract and interaction pattern.
Spaghetti Communications
Spaghetti code is for sure known by many of us 😉 In terms of service-orientation, spaghetti communication can happen pretty easy, as Carlo states, when it comes to different patterns, being combined without care.
The work around this anti-pattern, a top-down design helps. When using a multi-tier architecture for service-calls, spaghetti can be easily identified. In a sound service-oriented architecture, one gets layers of functionality. Those layers can be:
- Wrapper services for legacy systems
- Simple business services (shopping carts, et cetera)
- Complex business services (order processes, et cetera)
- …
The task of the architect is to define those layers and to decompose a business requirement to match those layers, keeping into focus existing services which can be re-used to leverage earlier investments.
If the architect sees communication links between those layers, another design iteration should be started, as the functionality was not clearly enough decomposed.
Summary
In this article I tried to clarify that service-orientation is nothing technical, but comes from a business demand for faster and easier change. From this need, services need to be designed according the businesses building blocks.
When designing a service-oriented solution, re-use of existing functionality is the goal to achieve. For that, decomposition shall match a multi-tier architecture, which leverages basic services and advises service-composition to enable complex solutions from those which already exist.
When thinking of service contracts and interaction, it is mandatory to distinguish two things:
- Data, a service needs to operate and the outcome of service calls and
- Messaging patterns, by which a service is called and can call other services
When modeling both separately, the core functionality of the service and the way it can be embedded into the whole architecture are honored without missing the other one.