« ReSharper 2.0 has been released! | Main | Windows Live Writer (beta) Test »
13.06.06
Reasoning about SOA statements - 2 Services
This is the second issue of a five part series.
- In “Service-oriented architecture” I reasoned about the concept and definition of “Service-oriented architecture”.
Today I would like to elaborate on Services. In the first issue I described Services as little as being part of the Service-oriented paradigm. But what are Services after all?
Services are what we are confronted with each day. Take for instance the postal service. If you want to sent a parcel from A to B, you go to the postal service office, fill out a form including the sender (you) and the receiver. You hand over the parcel with the form to the clerk. You will surely greet the clerk, maybe talk about the weather and you might even tell him what service you ask of him, although it isn’t really necessary. Why isn’t it necessary? Because by receiving the parcel along with the form the clerk simply knows what to do. He might not know about the whole process, but he knows everything about his task in the process chain. The best thing is, that you don’t need to know anything about the clerk’s job nor the process at all. You are asking for a service, which will (hopefully) be performed by the postal service’s service capabilities. And all you need to do is to send the service a message containing the payload (the parcel) and some infrastructure information (the form containing the sender’s and receiver’s addresses). But I’m getting ahead of things.
This example shows that a Service is represented by:
- a measurable (business) value -> delivery of parcel
- a result produced by the service’s capabilities -> delivery of goods/letters/…
- a published (and well known) interface -> postal service office, clerk and form
- a service level agreement (delivery time, …) and a policy (dangerous goods are not allowed for delivery, sanctity of the mail, …)
- a service boundary (you don’t care about the process and the process is hidden from you)
- its autonomy (the delivery is the responsibility of the postal service; no one may influence the process from the outside; the process is realized by the postal service’s own means or unrelated means instructed by the postal service)
The first two points may be combined into “a measurable capability”. It is important to note, that a service is not defined by its process! The process is interchangeable and merely provides a means for implementing the service’s capabilities. Today business processes are changed continuously - they are optimized, outsourced, replaced by more efficient alternatives and so on. By representing a service by its capabilities these changes may be realized in time and IT departments will be able to keep pace with the ever changing demands of todays business.
There are two other important aspects of a service: first a service is triggered by a message and second, a service responds with a message. Both messages are abstract representations of actions and deliverables. A request message may request a certain service or service operation and at the same time provide data, which are necessary for processing the request. A response message contains the service result and may also trigger certain actions within the consumer. In both cases the message captures data at a certain moment of time. The data is also most probably a transformed, refined or customized version of the data representation within the service boundaries suitable for the consumer’s needs.
In the next issue I will use these observations for describing the relationship between SOA and Web Services.
Posted by Hartmut Wilms at 13.06.06 22:25