P6. A H2A service shall not have internal workflow

h3. Motivation

H2A services are pieces. If the pieces includes a lot of internal workflow, they will loose their abillity for reuse, and are in all practical terms not services but applications.

h3. Argumentation


We create a conflict of responsibility between services when the services start manipulating other services state, which leads to tight coupling between services and recursion conflicts called deadlocks :)

This rule efficiently separates H2A services and H2A applications/mashups.


h3. Exceptions/special cases

* GUI-flow/Wizards

----
h3. Definitions

Workflow is defined to have the following characteristics:
* At least 2 actors
* Often consists of long running transactions

Non workflow examples
* GUI-flow/Wizards

In doubt cases:
* machine actors have to be *external* (async, remote)

Argumentation: normally, we define workflow as a flow between at least two *human* actors. This definition looses meaning as soon as we start to automate some of the human actors. This mean that without our definition, we can have a change of operation/rules to our services invoked on our service run-time, without our knowledge, which does not make much sense..


h3. Status
|| Doc status || [H2A] || [A2A] || [ACS] || [CS] || Last [PAB] discussion ||
| (/) | (+) | (-) | (-) | (-) | 2007.06.08 |


----
h3. PAB discussions

-----

h3. [Design-Time Governance - SOA Design Rules FAQ]

{include:Design-Time Governance - SOA Design Rules FAQ}