View Source

h3. Motivation

Service behavior should be predictable and not produce bi-effects in other services

h3. Argumentation

* Ensure that a services does its thing and not everything else..
* Improved evolve ability of the service, as the impacts of change is understood.

h3. Exceptions/special cases


h3. Definitions

{tip}
If(!totto)

Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system. The emergent behavior of a system consisting of components should be controlled strictly by formal definitions of its logic and not by side effects resulting from poor integration, i.e. non-orthogonal design of modules and interfaces. Orthogonality reduces testing and development time because it is easier to verify designs that neither cause side effects nor depend on them.


{tip}

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}