As stated in one very good book about SOA, that I have read, we can define following service types:
| |
Basic Services |
Intermediary Services |
Process-Centric Services |
Public Enterprise Services |
| Description |
Simple data-centric or logic-centric services |
Technology gateways, facades, adapters, and functionality-adding services |
Encapsulate process logic |
Service shared with other enterprise or partner organization |
| Implementation Complexity |
Low to moderate |
Moderate to high |
High |
Service specific |
| State Management |
Stateless |
Stateless |
Stateful |
Service specific |
| Reusability |
High |
Low |
Low |
High |
| Frequency of change |
Low |
Moderate to high |
High |
Low |
| Mandatory Element of SOA |
Yes |
No |
No |
No |
As we can see, the most complex and frequent-changing type of service, which you should build if you want to fully leverage the SOA, is the process centric service. Truly saying since the beginning of SOA I had an architectural problem (or better: challenge) how to build this kind of service in the most effective way. Simply saying, what should be done is a kind of workflow engine with the ability to work in a stateful manner. It is not a trivial task. And one of the basic principles of building SOA based applications is … the simplicity. Do not overdesign! So I have always decided to not to extract the workflow into an independent service but integrating it into front-end component. Ok, I know, bad design but I had to be pragmatic and do my projects in time, budget, scope and quality…
But now we have the WF. Wow, I have followed the development of this library since early betas. It is unbelievable how easy you can build now a process-centric service of big complexity. A service that is really stateful and easy to change, a service where you are able to see and steer your processes. We have finally everything to build fully process-enabled SOA applications. Thanks Microsoft. Something big is about to happen…