This glossary supports the following titles:
SOA Design Patterns
Web Service Contract Design & Versioning for SOA
SOA Principles of Service Design
Service-Oriented Architecture: Concepts, Technology, and Design
Modern SOA Infrastructure: Technology, Design, and Governance
SOA with REST
Next Generation SOA: A Real-World Guide to Modern Service-Oriented Computing
SOA with .NET & Azure
SOA with Java
SOA Governance
SOA Security: Practices, Patterns, and Technologies for Securing Services
SOA and Cloud Computing: Practices, Patterns, Technologies
This glossary also supports the SOA Certified Professional (SOACP) program.
For more information, visit: www.soacp.com
and
www.soaschool.com
|
|
|
design-time autonomy
|
Regardless of whether a service has control over its runtime execution environment, multiple service consumers will form design-time dependencies on it. This can restrict the ability to evolve a service in response to future change requirements. The level of freedom service owners have to make changes to a service over its lifetime can be referred to as design-time autonomy.
Once consumer programs programmatically bind themselves to a service’s contract, the service can no longer escape its obligation to that contract. We therefore automatically lose a degree of control over how the service could be evolved. However, given that baseline constraint, we can still strive to maximize the level of attainable design-time autonomy.
There are several aspects of SOA that drive the need for this quality:
• the ability to scale a service in response to higher usage demands
• the option to further modify or enhance a service’s hosting environment
• the freedom to augment, upgrade, or replace the technology of a service in response
to new requirements or a desire to leverage new innovations
All of these forms of design-time autonomy can be attained by applying the Service Loose Coupling principle to avoid negative forms of service coupling.
See also:
- runtime autonomy
- Service Autonomy
- Service Loose Coupling
|
|
