Service Design Principles and Patterns
•
0 likes•629 views
webinar presentation http://www.returnonintelligence.ru/webinars/service-design-principles-and-patterns/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Service Design Principles and Patterns
Similar to Service Design Principles and Patterns (20)
More from Return on Intelligence
More from Return on Intelligence (20)
Recently uploaded
Recently uploaded (20)
Service Design Principles and Patterns
- 1. Core Systems Transformation Solutions Service Design Principles and Patterns January, 2014 Service Design Principles and Patterns Andrey Yartsev
- 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. Joint Company SOA appliance example • Business tasks • Different owners of services • Sessions over Internet Bank Company 3 Company 2Company 1 4 Manufacturer o createOrder o getInvoice o setInvoice Supplier o supplyGoods Bank o settle Customer o getGoods 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 Service “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. 8
- 10. Agenda • Service fundamentals • Service design principles • Inventory design patterns • Service design patterns • Composition design patterns 9
- 11. Service design principles SOA Service Loose Coupling Service ComposabilityService Reusability Service Autonomy Service Statelessness Standardized Service contract Service Discoverability Service Abstraction 10
- 12. Service contract: – Interface definition • operations • data types – Behavior attributes • policy assertions – SLA Standardized Service Contract Services within the same service inventory are in compliance with the same contract design standards 11
- 13. • Information about services is limited to service contracts • Service contracts are abstracted to contain only essential information Abstraction Hide information about a service not absolutely required for others to effectively use it. 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. • Coupling types: – to implementation of service logic – to resources of the implementation environment – to vendor technology – to parent business-process – to service composition members Loose Coupling Service contracts impose low consumer coupling requirements 14
- 16. Loose Coupling (consumer-to-contract) Consumer program must call contract only 15 Coupling types: • to implementation of service logic • to resources of the implementation environment • to vendor technology
- 17. • Control over underlying runtime execution environment • Gradual transformation – Reducing shared resources access – Increasing physical isolation Autonomy Freedom and control to make own decisions without the need for external approval or involvement 16
- 18. • Types of state – Session – Context – Business data • Maximize service scalability • State management deferral – Repository – Messages • Empowers composition and reuse Statelessness Reduce system resource consumption due to unnecessary state management processing. 17
- 19. • 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 Discoverability Purpose and capabilities of service are easily discovered and understood. 18
- 20. Reusability • 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 Services are easily reused and recomposed. Reusability – key to achieving high ROI 19
- 21. • Highly efficient and scalable execution environment • Flexible service contract • Requires: – Autonomy – Loose coupling – Statelessness – Discoverability – Reusability Composability Services are effective composition participants 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, enterprise- wide 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. Task Layer – charge customer Entity Layer – account Utility Layer – validate credit card number Layering by Thomas Erl: 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 Isolate logic that is not specific to one purpose into separate services Multi-purpose logic grouped together with single purpose logic results in programs with little or no reuse potential 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 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) How can services state data be persisted and managed without consuming service runtime resources? 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 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" How can service contracts be consistently understood and interpreted? 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
Editor's Notes
- The notion of abstraction is very simple on the surface: hide information about a program not absolutely required for others to effectively use that program. However, applying this principle can raise a series of design-time considerations. Too little or too much of something abstracted away from the outside world can constrain the potential for a program to be repeatedly utilized (reused) by others throughout its lifespan. The first step to attaining the understanding required to determine the right amount of abstraction is to study how this broad design characteristic has been applied in the past The commercial “black box” concept, APIs, and middleware are all historic applications of abstraction that have influenced this principle. • By wrapping commercial software programs into compiled black boxes, a high level of intentional abstraction is attained. • The advent of the commercial API enabled programs to expose specific subsets of their functionality, while continuing to abstract the rest
- Principle Profile Short Definition “Services share standardized contracts.” Long Definition “Services within the same service inventory are in compliance with the same contract design standards.” Goals • To enable services with a meaningful level of natural interoperability within the boundary of a service inventory. This reduces the need for data transformation because consistent data models are used for information exchange. • To allow the purpose and capabilities of services to be more easily and intuitively understood. The consistency with which service functionality is expressed through service contracts increases interpretability and the overall predictability of service endpoints throughout a service inventory. Note that these goals are further supported by other service-orientation principles as well. Design Characteristics • A service contract (comprised of a technical interface or one or more service description documents) is provided with the service. • The service contract is standardized through the application of design standards. Implementation Requirements The fact that contracts need to be standardized can introduce significant implementation requirements to organizations that do not have a history of using standards. For example: • Design standards and conventions need to ideally be in place prior to the delivery of any service in order to ensure adequately scoped standardization. (For those organizations that have already produced ad-hoc Web services, retro-fitting strategies may need to be employed.) • Formal processes need to be introduced to ensure that services are modeled and designed consistently, incorporating accepted design principles, conventions, and standards. • Because achieving standardized Web service contracts generally requires a “contract first” approach to service- oriented design, the full application of this principle will often demand the use of development tools capable of importing a customized service contract without imposing changes. • Appropriate skill-sets are required to carry out the modeling and design processes with the chosen tools. When working with Web services, the need for a high level of proficiency with XML schema and WSDL languages is practically unavoidable. WS-Policy expertise may also be required. These and other requirements can add up to a noticeable transition effort that goes well beyond technology adoption. Web Service Region of Influence Because this principle is focused solely on the content of the service contract, its influence is limited to the contract and related processing logic within a typical Web service.
- Autonomy in Abstract Autonomy represents the ability to self-govern. Something that is autonomous has the freedom and control to make its own decisions without the need for external approval or involvement. Therefore, the level to which something is autonomous represents the extent to which it is able to act independently. If a software program exists in an autonomous runtime state, it is capable of carrying out its logic independently from outside influences. It therefore must have the control to govern itself at runtime. The more control the program has over its runtime execution environment, the more autonomy it can claim. To achieve increased levels of autonomy requires that program implementations be more isolated so as to increase corresponding levels of independence. The result of achieving enhanced autonomy in software programs is increased reliability and predictability due to the increased independence and isolation in which the programs operate. It is important to acknowledge that for a service, autonomy is a quality that represents its ability to carry out its core service logic independently. The level of a service’s autonomy can be enhanced by increasing the amount of control it has over its runtime execution environment. For simplicity’s sake, we refer to this level of control as a level of autonomy
- Note: Similar process for run-time (dynamical binding)
- Reusability – key to achieving high ROI
- A key emphasis of this principle is to ensure that services are designed to participate as effective members of multiple compositions, even when immediate composition requirements do not exist. Principle Profile Short Definition “Services are composable.” Long Definition “Services are effective composition participants, regardless of the size and complexity of the composition.” Goals When discussing the goals of Service Composability, pretty much all of the goals of Service Reusability apply. This is because service composition often turns out to be a form of service reuse. In fact, you may recall that one of the objectives we listed for the Service Reusability principle was to enable wide-scale service composition. However, above and beyond simply attaining reuse, service composition provides the medium through which we can achieve what is often classified as the ultimate goal of service-oriented computing. By establishing an enterprise comprised of solution logic represented by an inventory of highly reusable services, we provide the means for a large extent of future business automation requirements to be fulfilled through…you guessed it: service composition. Design Characteristics for Composition Member Capabilities Ideally, every service capability (especially those providing reusable logic) is considered a potential composition member. This essentially means that the design characteristics already established by the Service Reusability principle are equally relevant to building effective composition members. Additionally, there are two further characteristics emphasized by this principle: • The service needs to possess a highly efficient execution environment. More so than being able to manage concurrency, the efficiency with which composition members perform their individual processing should be highly tuned. • The service contract needs to be flexible so that it can facilitate different types of data exchange requirements for similar functions. This typically relates to the ability of the contract to exchange the same type of data at different levels of granularity. The manner in which these qualities go beyond mere reuse has to do primarily with the service being capable of optimizing its runtime processing responsibilities in support of multiple, simultaneous compositions. Design Characteristics for Composition Controller Capabilities Composition members will often also need to act as controllers or sub-controllers within different composition configurations. However, services designed as designated controllers are generally alleviated from many of the high-performance demands placed on composition members. These types of services therefore have their own set of design characteristics: • The logic encapsulated by a designated controller will almost always be limited to a single business task. Typically, the task service model is used, resulting in the common characteristics of that model being applied to this type of service. • While designated controllers may be reusable, service reuse is not usually a primary design consideration. Therefore, the design characteristics fostered by Service Reusability are considered and applied where appropriate, but with less of the usual rigor applied to agnostic services. • Statelessness is not always as strictly emphasized on designated controllers as with composition members. Depending on the state deferral options available by the surrounding architecture, designated controllers may sometimes need to be designed to remain fully stateful while the underlying composition members carry out their respective parts of the overall task. Of course, any capability acting as a controller can become a member of a larger composition, which brings the previously listed composition member design characteristics into account as well. Implementation Requirements As demanding as service reuse is on runtime deployment requirements, it pales in comparison to service composition. As a result, hosting runtime environments need to be as scalable and reliable as possible. This typically translates into the need for dedicated, clustered servers with fail-over and the availability of mature runtime service technology. Services implemented as Web services often require standardized implementations of several key WS-* extensions, including those associated with security, reliable messaging, activity management, and cross-service transactions. Web Service Region of Influence for Composition Members Many of the design considerations introduced by this principle have to do with the optimization and tuning of the service architecture in support of effective and efficient composition participation. The potential scope of this principle can essentially encompass all parts of a service acting as a composition member primarily because composition builds on reuse and other design characteristics established by supporting Principles.
- Standardized Service Contract – “Services within the same service inventory are in compliance with the same contract design standards.” • Service Loose Coupling – “Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.” • Service Abstraction – “Service contracts only contain essential information and information about services is limited to what is published in service contracts.” • Service Reusability – “Services contain and express agnostic logic and can be positioned as reusable enterprise resources.” • Service Autonomy – “Services exercise a high level of control over their underlying runtime execution environment.” • Service Statelessness – “Services minimize resource consumption by deferring the management of state information when necessary.” • Service Discoverability – “Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.” • Service Composability – “Services are effective composition participants, regardless of the size and complexity of the composition.”
- Functional service boundaries are modeled as part of a formal analysis process and persist throughout inventory design and governance
- Utility Abstraction Problem: When non-business centric processing logic is packaged together with business-specific logic, it results in the redundant implementation of common utility functions across different services. Solution: A service layer dedicated to utility processing is established, providing reusable utility services for use by other services in the inventory. Entity Abstraction Problem: Bundling both process-agnostic and process-specific business logic into the same service eventually results in the creation of redundant agnostic business logic across multiple services. Solution: An agnostic business service layer can be established, dedicated to services that base their functional context on existing business entities. Process Abstraction Problem: Grouping task-centric logic together with task-agnostic logic hinders the governance of the task-specific logic and the reuse of the agnostic logic. Solution: A dedicated parent business process service layer is established to support governance independence and the positioning of task services as potential enterprise resources.
- Service-Oriented Analysis and Service Modeling To effectively deliver standardized services in support of building a service inventory, it is recommended that organizations adopt a methodology specific to SOA and consisting of structured analysis and design processes. Within SOA projects, these processes are centered around the accurate expression of business logic through technology, which requires that business analysts play a more active role in defining the conceptual design of solution logic. This guarantees a higher degree of alignment between the documented business models and their implementation as services. Agnostic business services especially benefit from hands-on involvement of business subject matter experts, as the improved accuracy of their business representation increases their overall longevity once deployed. Service-oriented analysis establishes a formal analysis process completed jointly by business analysts and technology architects. Service modeling, a sub-process of serviceoriented analysis, produces conceptual service definitions called service candidates. Iterations through the service-oriented analysis and service modeling processes result in the gradual creation of a collection of service candidates documented as part of a service inventory blueprint. Service-Oriented Design The service-oriented design process uses a set of predefined service candidates from the service inventory blueprint as a starting point from which they are shaped into actual physical service contracts. When carrying out service-oriented design, a clear distinction is made between service candidates and services. The former represents a conceptual service that has not been implemented, whereas the latter refers to a physical service.
- Functional Decomposition Problem: To solve a large, complex business problem a corresponding amount of solution logic needs to be created, resulting in a selfcontained application with traditional governance and reusability constraints. Solution: The large business problem can be broken down into a set of smaller, related problems, allowing the required solution logic to also be decomposed into a corresponding set of smaller, related solution logic units. Service Encapsulation Problem: Solution logic designed for a single application environment is typically limited in its potential to interoperate with or be leveraged by other parts of an enterprise. Solution: Solution logic can be encapsulated by a service so that it is positioned as an enterprise resource capable of functioning beyond the boundary for which it is initially delivered.
- Agnostic Context Problem: Multi-purpose logic grouped together with single purpose logic results in programs with little or no reuse potential that introduce waste and redundancy into an enterprise. Solution: Isolate logic that is not specific to one purpose into separate services with distinct agnostic contexts. Non-Agnostic Context Problem: Non-agnostic logic that is not service-oriented can inhibit the effectiveness of service compositions that utilize agnostic services. Solution: Non-agnostic solution logic suitable for service encapsulation can be located within services that reside as official members of a service inventory.
- State Repository Problem: Large amounts of state data cached to support the activity within a running service composition can consume too much memory, especially for long-running activities, thereby decreasing scalability. Solution: State data can be temporarily written to and then later retrieved from a dedicated state repository. Stateful Services Problem: State data associated with a particular service activity can impose a great deal of runtime state management responsibility upon service compositions, thereby reducing their scalability. Solution: State data is managed and stored by intentionally stateful utility services. Service Grid Problem: State data deferred via State Repository or Stateful Services can be subject to performance bottlenecks and failure, especially when exposed to high-usage volumes. Solution: State data is deferred to a collection of stateful system services that form a grid that provides high scalability and fault tolerance through memory replication and redundancy and supporting infrastructure. Partial State Deferral Problem: Service capabilities may be required to store and manage large amounts of state data, resulting in increased memory consumption and reduced scalability. Solution: Even when services are required to remain stateful, a subset of their state data can be temporarily deferred.
- Service contract defines: the purpose and function of its operations the messages that need to be exchanged in order to engage the operations data models used to define the structure of the messages (and associated validation rules used to ensure the integrity of data passed to and from the messages) information about how and where the service can be accessed
- The Strict Strategy (New Change, New Contract) The simplest approach to Web service contract versioning is to require that a new version of a contract be issued whenever any kind of change is made to any part of the contract. Pros and Cons The benefit of this strategy is that you have full control over the evolution of the service contract, 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, you are guaranteeing that all existing service consumers will no longer be compatible with any new version of the contract. Consumers will only be able to continue communicating with the Web service while the old contract remains available alongside the new version or 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 minimizing the impact of changes to Web service contracts is to allow compatible changes to occur without forcing a new contract version, while not attempting to support forwards compatibility at all Pros and Cons The primary advantage to this approach is that it can be used to accommodate a variety of changes while consistently retaining the contract’s backwards compatibility. However, when compatible changes are made, these changes become permanent and cannot be reversed without introducing an incompatible change. Therefore, a governance process is required during which each proposed change is evaluated so that contracts do not become overly bloated or convoluted. This is an especially important consideration for agnostic services that are heavily reused. The Loose Strategy (Backwards and Forwards Compatibility) As with the previous two approaches, this strategy requires that incompatible changes result in a new service contract version. The difference here is in how service contracts are initially designed.
- Data Confidentiality Problem: Within service compositions, data is often required to pass through one or more intermediaries. Point-to-point security protocols, such as those frequently used at the transport-layer, may allow messages containing sensitive information to be intercepted and viewed by such intermediaries. Solution: The message contents are encrypted independently from the transport, ensuring that only intended recipients can access the protected data.
- Data Origin Authentication Problem: The intermediary processing layers generally required by service compositions can expose sensitive data when security is limited to point-to-point protocols, such as those used with transportlayer security. Solution: A message can be digitally signed so that the recipient services can verify that it originated from the expected consumer and that it has not been tampered with during transit. Direct Authentication Problem: Some of the capabilities offered by a service may be intended for specific groups of consumers or may involve the transmission of sensitive data. Attackers that access this data could use it to compromise the service or the IT enterprise itself. Solution: Service capabilities require that consumers provide credentials that can be authenticated against an identity store. Brokered Authentication Problem: Requiring the use of Direct Authentication (656) can be impractical or even impossible when consumers and services do not trust each other or when consumers are required to access multiple services as part of the same runtime activity. Solution: An authentication broker with a centralized identity store assumes the responsibility for authenticating the consumer and issuing a token that the consumer can use to access the service.