Service design principles and patterns

Editor's Notes

• #23: Standardized Service Contract – “Services within the same service inventory are incompliance with the same contract design standards.”• Service Loose Coupling – “Service contracts impose low consumer coupling requirementsand are themselves decoupled from their surrounding environment.”• Service Abstraction – “Service contracts only contain essential information andinformation about services is limited to what is published in service contracts.”• Service Reusability – “Services contain and express agnostic logic and can be positionedas reusable enterprise resources.”• Service Autonomy – “Services exercise a high level of control over their underlyingruntime execution environment.”• Service Statelessness – “Services minimize resource consumption by deferring themanagement of state information when necessary.”• Service Discoverability – “Services are supplemented with communicative meta databy which they can be effectively discovered and interpreted.”• Service Composability – “Services are effective composition participants, regardlessof the size and complexity of the composition.”
• #30: Service-Oriented Analysis and Service ModelingTo effectively deliver standardized services in support of building a service inventory, itis recommended that organizations adopt a methodology specific to SOA and consistingof structured analysis and design processes.Within SOA projects, these processes are centered around the accurate expression ofbusiness logic through technology, which requires that business analysts play a moreactive role in defining the conceptual design of solution logic. This guarantees a higherdegree of alignment between the documented business models and their implementationas services. Agnostic business services especially benefit from hands-on involvementof business subject matter experts, as the improved accuracy of their businessrepresentation increases their overall longevity once deployed.Service-oriented analysis establishes a formal analysis process completed jointly by businessanalysts and technology architects. Service modeling, a sub-process of serviceorientedanalysis, produces conceptual service definitions called service candidates. Iterationsthrough the service-oriented analysis and service modeling processes result in thegradual creation of a collection of service candidates documented as part of a serviceinventory blueprint.Service-Oriented DesignThe service-oriented design process uses a set of predefined service candidates from theservice inventory blueprint as a starting point from which they are shaped into actualphysical service contracts.When carrying out service-oriented design, a clear distinction is made between servicecandidates and services. The former represents a conceptual service that has not beenimplemented, whereas the latter refers to a physical service.
• #31: Functional DecompositionProblem: To solve a large, complex business problem a correspondingamount of solution logic needs to be created, resulting in a selfcontainedapplication with traditional governance and reusability constraints.Solution: The large business problem can be broken down into a set ofsmaller, related problems, allowing the required solution logic to also bedecomposed into a corresponding set of smaller, related solution logic units.Service EncapsulationProblem: Solution logic designed for a single application environment istypically limited in its potential to interoperate with or beleveraged by other parts of an enterprise.Solution: Solution logic can be encapsulated by a service so that it ispositioned as an enterprise resource capable of functioningbeyond the boundary for which it is initially delivered.
• #32: Agnostic ContextProblem: Multi-purpose logic grouped together with single purpose logicresults in programs with little or no reuse potential thatintroduce waste and redundancy into an enterprise.Solution: Isolate logic that is not specific to one purpose into separateservices with distinct agnostic contexts.Non-Agnostic ContextProblem: Non-agnostic logic that is not service-oriented can inhibit theeffectiveness of service compositions that utilize agnosticservices.Solution: Non-agnostic solution logicsuitable for service encapsulationcan be located within services that reside as official members of aservice inventory.
• #34: State RepositoryProblem: Large amounts of state data cached to support the activity withina running service composition can consume too much memory,especially for long-running activities, thereby decreasingscalability.Solution: State data can be temporarily written to and then later retrievedfrom a dedicated state repository.Stateful ServicesProblem: State data associated with a particular service activity can imposea great deal of runtime state management responsibility uponservice compositions, thereby reducing their scalability.Solution: State data is managed and stored by intentionally stateful utilityservices.Service GridProblem: State data deferred via State Repository or Stateful Services canbe subject to performance bottlenecks and failure, especiallywhen exposed to high-usage volumes.Solution: State data is deferred to a collection of stateful system servicesthat form a grid that provides high scalability and fault tolerancethrough memory replication and redundancy and supportinginfrastructure.Partial State DeferralProblem: Service capabilities may be required to store and manage largeamounts of state data, resulting in increased memoryconsumption and reduced scalability.Solution: Even when services are required to remain stateful, a subset oftheir state data can be temporarily deferred.
• #44: The Strict Strategy (New Change, New Contract)The simplest approach to Web service contract versioning is to require that a newversion of a contract be issued whenever any kind of change is made to any part of thecontract.Pros and ConsThe benefit of this strategy is that you have full control over the evolution of the servicecontract, and because backwards and forwards compatibility are intentionally disregarded,you do not need to concern yourself with the impact of any change in particular(because all changes effectively break the contract).On the downside, by forcing a new namespace upon the contract with each change, youare guaranteeing that all existing service consumers will no longer be compatible withany new version of the contract. Consumers will only be able to continue communicatingwith the Web service while the old contract remains available alongside the new versionor until the consumers themselves are updated to conform to the new contract.The Flexible Strategy (Backwards Compatibility)A common approach used to balance practical considerations with an attempt at minimizingthe impact of changes to Web service contracts is to allow compatible changes tooccur without forcing a new contract version, while not attempting to support forwardscompatibility at allPros and ConsThe primary advantage to this approach is that it can be used to accommodate a varietyof changes while consistently retaining the contract’s backwards compatibility. However,when compatible changes are made, these changes become permanent and cannotbe reversed without introducing an incompatible change. Therefore, a governanceprocess is required during which each proposed change is evaluated so that contracts donot become overly bloated or convoluted. This is an especially important considerationfor agnostic services that are heavily reused.The Loose Strategy (Backwards and Forwards Compatibility)As with the previous two approaches, this strategy requires that incompatible changesresult in a new service contract version. The difference here is in how service contractsare initially designed.
• #51: Data ConfidentialityProblem: Within service compositions, data is often required to passthrough one or more intermediaries. Point-to-point securityprotocols, such as those frequently used at the transport-layer,may allow messages containing sensitive information to beintercepted and viewed by such intermediaries.Solution: The message contents are encrypted independently from thetransport, ensuring that only intended recipients can access theprotected data.
• #52: Data Origin AuthenticationProblem: The intermediary processing layers generally required by servicecompositions can expose sensitive data when security is limitedto point-to-point protocols, such as those used with transportlayersecurity.Solution: A message can be digitally signed so that the recipient servicescan verify that it originated from the expected consumer andthat it has not been tampered with during transit.Direct AuthenticationProblem: Some of the capabilities offered by a service may be intended forspecific groups of consumers or may involve the transmission ofsensitive data. Attackers that access this data could use it tocompromise the service or the IT enterprise itself.Solution: Service capabilities require that consumers provide credentialsthat can be authenticated against an identity store.Brokered AuthenticationProblem: Requiring the use of Direct Authentication (656) can beimpractical or even impossible when consumers and services donot trust each other or when consumers are required to accessmultiple services as part of the same runtime activity.Solution: An authentication broker with a centralized identity storeassumes the responsibility for authenticating the consumer andissuing a token that the consumer can use to access the service.