Service Orientation Design Principles 1 1

Service-Orientation Design Principles

Standardized Service Contract

“Services within the same service inventory are in compliance with the same contract design standards.”

Services express their purpose and capabilities via a service contract. The Standardized Service Contract design principle is perhaps the most fundamental part of service-orientation in that it essentially requires that specific considerations be taken into account when designing a service’s public technical interface and assessing the nature and quantity of content that will be published as part of a service’s official contract.

A great deal of emphasis is placed on specific aspects of contract design, including the manner in which services express functionality, how data types and data models are defined, and how policies are asserted and attached. There is a constant focus on ensuring that service contracts are both optimized, appropriately granular, and standardized to ensure that the endpoints established by services are consistent, reliable, and governable.

Service Orientation Design Principles 1 2

Figure: Using Web service contract documents (WSDL, XML schema, and WS-Policy definitions) as an example, this illustration highlights the areas that are typically affected by the application of this design principle.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased Federation, Increased Vendor Diversification Options, Increased Business and Technology Alignment, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Agnostic Capability, Asynchronous Queuing, Canonical Expression, Canonical Protocol, Canonical Schema, Canonical Versioning, Capability Composition, Capability Recomposition, Compatible Change, Concurrent Contracts, Contract Centralization, Contract Denormalization, Data Format Transformation, Data Model Transformation, Decomposed Capability, Decoupled Contract, Distributed Capability, Domain Inventory, Dual Protocols, Enterprise Inventory, Event-Driven Messaging, Inventory Endpoint, Legacy Wrapper, Message Screening, Non-Agnostic Context, Partial Validation, Policy Centralization, Protocol Bridging, Schema Centralization, Service Callback, Service Facade, Service Messaging, Service Refactoring, State Messaging, Termination Notification, Validation Abstraction, Version Identification

Service Loose Coupling

“Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.”

Coupling refers to a connection or relationship between two things. A measure of coupling is comparable to a level of dependency. This principle advocates the creation of a specific type of relationship within and outside of service boundaries, with a constant emphasis on reducing (“loosening”) dependencies between the service contract, its implementation, and its service consumers.

The principle of Service Loose Coupling promotes the independent design and evolution of a service’s logic and implementation while still guaranteeing baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences.

Service Loose Coupling 1 3

Figure: Coupling represents a core design consideration that spans both intra and inter-service design.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased Federation, Increased Vendor Diversification Options, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Asynchronous Queuing, Capability Composition, Capability Recomposition, Compatible Change, Compensating Service Transaction, Concurrent Contracts, Contract Centralization, Contract Denormalization, Data Format Transformation, Decoupled Contract, Dual Protocols, Entity Abstraction, Event-Driven Messaging, File Gateway, Intermediate Routing, Inventory Endpoint, Legacy Wrapper, Messaging Metadata, Multi-Channel Endpoint, Partial Validation, Policy Centralization, Process Abstraction, Proxy Capability, Schema Centralization, Service Agent, Service Callback, Service Decomposition, Service Facade, Service_instance_routing, Service Messaging, Service Perimeter Guard, Service Refactoring, Trusted Subsystem, UI Mediator, Utility Abstraction, Validation Abstraction

Read More:  Service-Orientation in the Real World

Service-Orientation Design Principles

“Service contracts only contain essential information and information about services is limited to what is published in service contracts.”

Abstraction ties into many aspects of service-orientation. On a fundamental level, this principle emphasizes the need to hide as much of the underlying details of a service as possible. Doing so directly enables and preserves the previously described loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions.

Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

Service Orientation Design Principles 02 1 4

Figure: The level of suitable abstraction can be closely related to the nature of the logic being encpasulated by the service.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased Federation, Increased Vendor Diversification Options, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Capability Composition, Capability Recomposition, Decomposed Capability, Domain Inventory, Dual Protocols, Enterprise Inventory, Entity Abstraction, Exception Shielding, Inventory Endpoint, Legacy Wrapper, Policy Centralization, Process Abstraction, Service Perimeter Guard, Service Refactoring, Utility Abstraction, Validation Abstraction

Service Reusability

“Services contain and express agnostic logic and can be positioned as reusable enterprise resources.”

Reuse is strongly emphasized within service-orientation; so much so, that it becomes a core part of typical service analysis and design processes, and also forms the basis for key service models. The advent of mature, non-proprietary service technology has provided the opportunity to maximize the reuse potential of multi-purpose logic on an unprecedented level.

The principle of Service Reusability emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

Service Reusability 1 5

Figure: When designing services for reuse, traditional application design approaches are married with techniques from the well established field of commercial product design.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased Business and Technology Alignment, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Agnostic Capability, Agnostic Context, Agnostic Sub-Controller, Capability Composition, Capability Recomposition, Composition Autonomy, Concurrent Contracts, Cross-Domain Utility Layer, Data Model Transformation, Entity Abstraction, Intermediate Routing, Logic Centralization, Multi-Channel Endpoint, Rules Centralization, Service Agent, Service Layers, Utility Abstraction

Service Autonomy

“Services exercise a high level of control over their underlying runtime execution environment.”

For services to carry out their capabilities consistently and reliably, their underlying solution logic needs to have a significant degree of control over its environment and resources. The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability.

This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

Service Autonomy 1 6

Figure: Autonomy on a service level raises key design characteristics that are especially relevant when individual services are assembled into complex compositions. In this example services within a composition hiearchy are identified according to their respective service models.

Related Service-Orientation Computing Goals

Read More:  Introduction to Service-Orientation

Increased Intrinsic Interoperability, Increased Vendor Diversification Options, Increased Business and Technology Alignment, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Canonical Resources, Capability Composition, Capability Recomposition, Composition Autonomy, Distributed Capability, Dual Protocols, Event-Driven Messaging, Process Centralization, Redundant Implementation, Service DataReplication, Service Normalization

Service Statelessness

“Services minimize resource consumption by deferring the management of state information when necessary.”

The management of excessive state information can compromise the availability of a service and undermine its scalability potential. Services are therefore ideally designed to remain stateful only when required. Applying the principle of Service Statelessness requires that measures of realistically attainable statelessness be assessed, based on the adequacy of the surrounding technology architecture to provide state management delegation and deferral options.

Service Statelessness 1 7

Figure: Incorporating a balanced and targeted measure of state management deferral can significantly enhance the scalability of individual services, an important design consideration for services that are shared across multiple compositions.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Asynchronous Queuing, Atomic Service Transaction, Capability Composition, Capability Recomposition, Messaging Metadata, Partial State Deferral, Process Centralization, Service Grid, Service Instance Routing, State Messaging, State Repository, Stateful Services

Service Discoverability

“Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.”

For services to be positioned as IT assets with repeatable ROI they need to be easily identified and understood when opportunities for reuse present themselves. The service design therefore needs to take the “communications quality” of the service and its individual capabilities into account, regardless of whether a discovery mechanism (such as a service registry) is an immediate part of the environment.

Service Discoverability 1 8

Figure: The application of this design principle results in the improvement of a service’s discoverability and interpretability as a result of increasing the communications quality of all published service meta information.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased Business and Technology Alignment, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Related SOA Patterns

Canonical Expression, Capability Composition, Capability Recomposition, Metadata Centralization

Service Composability

“Services are effective composition participants, regardless of the size and complexity of the composition.”

As the sophistication of service-oriented solutions continues to grow, so does the complexity of underlying service composition configurations. The ability to effectively compose services is a critical requirement for achieving some of the most fundamental goals of service-oriented computing.

Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition. The principle of Service Composability addresses this requirement by ensuring that a variety of considerations are taken into account.

Service Composability 1 9

Figure: The Service Composability design principle helps determine how to carry out a separation of concerns in support of service-orientation. The services that result from the illustrated decomposition of solution logic are assembled to solve Problem A. However, the ultimate, strategic benefit comes with the ability to continually recompose these services to help solve additional problems in the future.

Related Service-Orientation Computing Goals

Increased Intrinsic Interoperability, Increased Business and Technology Alignment, Increased ROI, Increased Organizational Agility, Reduced IT Burden

Read More:  Effects of Service-Orientation on the Enterprise

Related SOA Patterns

Agnostic Capability, Agnostic Sub-Controller, Brokered Authentication, Capability Composition, Capability Recomposition, Composition Autonomy, Cross-Domain Utility Layer, Data Confidentiality, Data Model Transformation, Data Origin Authentication, Direct Authentication, Domain Inventory, Dual Protocols, Enterprise Inventory, Entity Abstraction, Intermediate Routing, Logic Centralization, Non-Agnostic Context, Process Abstraction, Process Centralization, Protocol Bridging, Reliable Messaging, Service Callback, Service Decomposition, Service Instance Routing, Service Layers, State Messaging, Utility Abstraction

Service-Orientation and Interoperability

One item that may appear to be absent from the preceding list is a principle along the lines of “Services are Interoperable.” The reason this does not exist as a separate principle is because interoperability is fundamental to every one of the principles we just described. Therefore, in relation to service-oriented computing, stating that services must be interoperable is just about as evident as stating that services must exist. Each of the eight principles supports or contributes to interoperability in some manner. Below are just a few examples:

– Service contracts are standardized to guarantee a baseline measure of interoperability associated with the harmonization of data models.

– Reducing the degree of service coupling fosters interoperability by making individual services less dependent on others and therefore more open for invocation by different service consumers.

– Abstracting details about the service limits all interoperation to the service contract, increasing the long-term consistency of interoperability by allowing underlying service logic to evolve more independently.

– Designing services for reuse implies a high-level of required interoperability between the service and numerous potential service consumers.

– By raising a service’s individual autonomy its behavior becomes more consistently predictable, increasing its reuse potential and thereby its attainable level of interoperability.

– Through an emphasis on stateless design, the availability and scalability of services increase, allowing them to interoperate more frequently and reliably.

– Service Discoverability simply allows services to be more easily located by those who want to potentially interoperate with them.

– Finally, for services to be effectively composable they must be interoperable. The success of fulfilling composability requirements is often tied directly to the extent to which services are standardized and cross-service data exchange is optimized.

A fundamental goal of applying service-orientation is for interoperability to become a natural by-product, ideally to the extent that a level of intrinsic interoperability is established as a common and expected service design characteristic.

Of course, as with any other design characteristic, there are levels of interoperability a service can attain. The ultimate measure is generally determined by the extent to which service-orientation principles have been consistently and successfully realized (and, of course, the maturity level of the underlying technology platform).

Note that increased intrinsic interoperability is one of the key strategic goals associated with service-oriented computing.