Service design principles and patterns
•
12 gostaram•4,226 visualizações
This document outlines principles and patterns for service-oriented architecture (SOA) design. It begins with an introduction and agenda, then covers service fundamentals like loose coupling and statelessness. Major sections discuss service design principles like autonomy and standardized contracts, inventory design patterns like normalization and layers, individual service design patterns like agnostic capabilities and messaging, and composition design patterns like routing and security. The goal is to discover principles for effective service-oriented design and how patterns support those principles.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Service design principles and patterns
Semelhante a Service design principles and patterns (20)
Mais de Return on Intelligence
Mais de Return on Intelligence (16)
Último
Último (20)
Service design principles and patterns
- 1. Core Systems Transformation Solutions Service Design Principles and Patterns Andrey Yartsev January, 2014
- 2. Trainer contacts • Andrey Yartsev • developer • E-mail : Andrey.Yartsev@returnonintelligence.com 1
- 3. Goals • Discover service design principles and how they are supported by patterns 2
- 4. Agenda • • • • • Service fundamentals Service design principles Service inventory design patterns Service design patterns Service composition design patterns 3
- 5. SOA appliance example Joint Company Company 1 Company 2 Customer Supplier o getGoods Company 3 Manufacturer o createOrder o getInvoice o setInvoice o supplyGoods Bank Bank o settle • • • Business tasks Different owners of services Sessions over Internet 4 4
- 7. SOA Definition Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. OASIS 6
- 8. Service Implementation Mediums • Component (CORBA, JEE, .NET) • Web service • REST service 7
- 9. SOA Capability “Capability” vs. “Operation” vs. “Method” – A service capability represents a specific function of a service through which the service can be invoked – A service operation specifically refers to a capability within a service that is implemented as a Web service – A service method represents a capability that is part of a service that exists as a component. Service 8
- 10. Agenda • • • • • Service fundamentals Service design principles Inventory design patterns Service design patterns Composition design patterns 9
- 11. Service design principles Service Composability Service Reusability Service Loose Coupling Service Autonomy SOA Service Statelessness Standardized Service contract Service Discoverability Service Abstraction 10
- 12. Standardized Service Contract Services within the same service inventory are in compliance with the same contract design standards Service contract: – Interface definition • operations • data types – Behavior attributes • policy assertions – SLA 11
- 13. Abstraction Hide information about a service not absolutely required for others to effectively use it. • Information about services is limited to service contracts • Service contracts are abstracted to contain only essential information 12
- 14. Standardized Service Contract • design standard for all contracts • Introduce formal process of design • “contract first” approach to service-oriented design • high level of proficiency with XML schema, WSDL and WS-* stack 13
- 15. Loose Coupling Service contracts impose low consumer coupling requirements • Coupling types: – to implementation of service logic – to resources of the implementation environment – to vendor technology – to parent business-process – to service composition members 14
- 16. Loose Coupling (consumer-to-contract) Consumer program must call contract only Coupling types: • to implementation of service logic • to resources of the implementation environment • to vendor technology 15
- 17. Autonomy Freedom and control to make own decisions without the need for external approval or involvement • Control over underlying runtime execution environment • Gradual transformation – Reducing shared resources access – Increasing physical isolation 16
- 18. Statelessness Reduce system resource consumption due to unnecessary state management processing. • Types of state – Session – Context – Business data • Maximize service scalability • State management deferral – Repository – Messages • Empowers composition and reuse 17
- 19. Discoverability Purpose and capabilities of service are easily discovered and understood. • Services are supplemented with meta- data – Functional – Quality of Service • Service Repository for effective discovery and interpretation • Service Registry for effective run-time discovery and binding 18
- 20. Reusability Services are easily reused and recomposed. • Inventory of reusable enterprise resources • Defined by an agnostic functional context • The service logic is highly generic • Solid version control system • The service logic can be accessed concurrently Reusability – key to achieving high ROI 19
- 21. Composability Services are effective composition participants • Highly efficient and scalable execution environment • Flexible service contract • Requires: – Autonomy – Loose coupling – Statelessness – Discoverability – Reusability 20
- 22. Compositions • Placement of flow logic – Client system • Tight coupling – Wrapper client web-service • Platform specific implementation • Complex implementation – Business process execution frameworks • BPMN – modeling • BPEL - execution 21
- 24. Agenda • • • • • Service fundamentals Service design principles Inventory design patterns Service design patterns Composition design patterns 23
- 25. Enterprise Inventory, Domain Inventory How can services be delivered to maximize recomposition, reuse, discoverability? Services for multiple solutions are designed within a standardized, enterprisewide inventory Domain inventory - domain-specific inventory where services • Standardized • Governed • Managed. 24
- 26. Service Normalization, Logic Centralization How can a service inventory avoid redundant service logic? Normalization: - Service-Oriented Analysis - service boundary alignment - defined how to: add, change, remove service in the inventory Centralization: - access to reusable functionality is limited to official agnostic services 25
- 27. Service Layers How can the services in an inventory be organized based on functional commonality? The inventory is structured into two or more logical service layers for abstracting logic based on a common functional type. Layering by Thomas Erl: Task Layer – charge customer Entity Layer – account Utility Layer – validate credit card number 26
- 28. Centralization patterns Policy Centralization • policy assertions are isolated and applied to multiple services. Contract Centralization: • access to service logic is limited to the service contract Metadata Centralization: • Service metadata is published in a central registry Rules Centralization • storage and management of business rules must be centralized. 27
- 29. Agenda • • • • Service design principles Inventory design patterns Service design patterns Composition design patterns 28
- 30. Service-Oriented Analysis and Design Define Analysis Scope Identify Affected Systems Perform Service Modeling Process result is a Service Candidate that is input for Service-Oriented Design 29
- 31. Service Identification Functional Decomposition • Large business problem is broken down in to a set a smaller ones Service Encapsulation • Logic encapsulated as service is an enterprise wide resource accessible for reuse 30
- 32. Agnostic/Non Agnostic Context Multi-purpose logic grouped together with single purpose logic results in programs with little or no reuse potential Isolate logic that is not specific to one purpose into separate services High reuse Low redundancy o Design complexity o Governance issues Non-agnostic logic can be located within official services but it’s not required 31
- 33. Agnostic Capability How can multipurpose service logic be made effectively consumable and composable? Agnostic service capabilities address common concerns not specific to any one problem. 32
- 34. State Management How can services state data be persisted and managed without consuming service runtime resources? Approaches: • • • Intentionally stateful utility services Partial state deferral Shared state repository (temporary cache) • Dedicated state repository with regular replication to central storage Scaling: • Grid technology(e.g. in-memory grids) 33
- 35. Autonomy patterns • Redundant implementation • Service data Replication 34
- 36. Service contract • What service does • How service can be accessed • Where service can be accessed 35
- 37. Partial Validation, Validation Abstraction How can unnecessary data validation be avoided? – Validate the relevant subset of the data and ignore the remainder How can service contract easily adapt to validation logic changes? – Business rules abstraction – business rules engines 36
- 38. Decoupled Contract How can a service express its capabilities independently of its implementation? • contract is physically decoupled from its implementation. • contract first approach • Contract MUST NOT be generated at runtime 37
- 39. Canonical Expression How can service contracts be consistently understood and interpreted? Naming conventions: • canonical namespaces : http://<globally unique namespace root>/<domain name>/ WSDL/<subject>-v<minor version> • upper-cased complex types and lower-cased elements • capabilities canonical names : addXXX, getXXX etc. • versioning in names • <wsdl:service> must include "Service" into name: e.g: "IncidentRegistrationService_v1_0" 38
- 40. Canonical Schema, Schema centralization How can services be designed to avoid data model transformation? Schemas are shared across multiple contracts: - introduce data models for common information sets - apply design standards - Service-Oriented Analysis Examples: ISO 20022, HL7 etc. 39
- 41. Canonical Versioning How can service contracts within the same service inventory be versioned with minimal impact? Versioning standard: • Version Identifiers • Versioning strategy • Contract lifecycle • introduction • change process • decommission 40
- 42. Version Identification How can consumers be made aware of service contract version information? Major/Minor Versioning: • A major change - incompatible change • A minor change - compatible change Versioning information is expressed as part of the service contract – WSDL, XSD, Policy. Versioning objects: • Namespaces • Artifact names • Endpoint names, etc. 41
- 43. Compatible/Incompatible Change Some changes to the service contract can be backwards or forward compatible, thereby avoiding negative consumer impacts Backwards compatibility: WSDL - adding operation XSD – adding optional element Policy - adding optional assertion Forwards compatibility: XSD – using wildcards(xsd:any, xsd:anyAttribute) 42
- 44. Versioning Strategy Strict(new change, new contract) Any compatible or incompatible changes result in a new version of the service contract. Flexible(backwards compatibility) Any incompatible change results in a new version of the service contract Loose(backwards and forwards) Any incompatible change results in a new version of the service contract Strategy Strict Flexible Loose Strictness high medium low Governance high medium high Complexity low medium high 43
- 45. Agenda • • • • • Service fundamentals Service design principles Inventory design patterns Service design patterns Composition design patterns 44
- 46. Service Messaging, Messaging Metadata How can a service interoperate without forming persistent, tightly coupled connections? • Established Message Framework(MOM) • Designed service to use messaging middleware • Supplemented message with activity-specific metadata 45
- 47. Capability Composition How can a service capability solve a problem that requires logic outside of the service boundary? Capability is designed to compose one or more capabilities in other services 46
- 48. Service Agent How can event-driven logic be separated and governed independently? • Authentication, Authorization • Logging • Audit • Load balancing • Other utility logic Service Agent has no published contract 47
- 49. Intermediate Routing How can dynamic runtime factors affect the path of a message? • Content based routing • Load Balancing • Fail-over routing (redundancy) 48
- 50. State Messaging How can a service remain stateless while participating in stateful interaction? Approaches: • Custom headers • WS-Addressing extension Risks: • Lost message - Lost State • Privacy of state data is under jeopardy • Bandwidth extension 49
- 51. Service Interaction Security • Data Confidentiality – Encryption • XML-Encryption (WS-Security) 50
- 52. Service Interaction Security • Data Origin Authentication – Digital Signature • XML Signature (WS-Security) – Non-Repudiation • Authentication – Direct authentication • Shared secret – Brokered Authentication • WS-Security and WS-Trust (Tokens: Kerberos, X.509 PKI, SAML) 51
- 53. Transformation • Data Model Transformation – XSLT • Data Format Transformation • Service Agent – CSV -> XML – CSV -> compressed XML • Protocol Bridging – HTTP <-> JMS – SOAP 1.1 <-> SOAP 1.2 – SOAP <-> XML 52
- 54. Sources: • • • • • Thomas Erl – SOA: Design patterns Thomas Erl – SOA: Principles of Service Design Thomas Erl – Web Service Contract Design and Versioning for SOA www.soapatterns.com www.soamethodology.com • BEA White Paper – BEA’s SOA Reference Architecture 53
- 56. Vocabulary • Design Principle – Design principle represents a highly recommended guideline for shaping solution logic in a certain way and with certain goals in mind. These goals are usually associated with establishing one or more specific design characteristics. • Design pattern describes a common problem and provides a corresponding solution 55
Notas do Editor
- 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.”
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.