Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Principles of Service Orientation

3,298 views

Published on

Published in: Internet

Principles of Service Orientation

  1. 1. PRINCIPLES OF SERVICE ORIENTATION PROGRAMAÇÃO DE SISTEMAS DISTRIBUIDOS Paulo Gandra de Sousa pag@isep.ipp.pt
  2. 2. Principles of service design 2 ISEP/IPP  Thomas Erl  ISBN: 0132344823  http://www.soaprinciples.com/  http://www.soapatterns.org/
  3. 3. 3 Service Orientation
  4. 4. Service 6 ISEP/IPP  Services are :  Modules of business.  Functionality of application.  The service is successful implemented, when :  reused.  Takes part of compositions
  5. 5. Types of Service 8  Entity Services  Utility Services  Task Services  Orchestrated Task Services
  6. 6. Entity Services 9 ISEP/IPP  Responsible for processing business logic.  Always take part in automation of business processes.  May need to compose other services to carry out its capabilities.  Conventions need to extend to data representation of business and context information delivered by messages to ensure steady interoperability.
  7. 7. Utility Services 10 ISEP/IPP  Cross-cutting functionality  Typicaly not business logic related  Sometimes intentionally designed to violate Service principles
  8. 8. Task Services 11 ISEP/IPP  Task-centric services have a functional scope centered around a business process.  Positioned as composition controllers, and for significantly sized compositions.  Can be needed to defer context data in order to alternate between stateful and stateless conditions.
  9. 9. Orchestrated Task Services 12 ISEP/IPP  Manage an activity during its entire lifespan.  Fully expected to remain stateful.  If the duration of process inactivity exceeds a certain timeout period, state data is stored in a database until it is needed to be revived.
  10. 10. 13 Granularity
  11. 11. Service Granularity 14 ISEP/IPP  the overall quantity of functionality encapsulated by a service.
  12. 12. Capability Granularity 15 ISEP/IPP  The quantity of functionality encapsulated by a specific service capability
  13. 13. Data Granularity 16 ISEP/IPP  the quantity of data exchanged by a specific service capability
  14. 14. Constraint Granularity 17 ISEP/IPP
  15. 15. 18 The 4 tenets of SOA
  16. 16. The four tennets of SOA 19 ISEP/IPP  Boundaries are explicit  Share schema and contract not types  Policy define service compatibility  Services are autonomous
  17. 17. Boundaries are explicit 20 ISEP/IPP  Service boundaries are explicit and the cost of crossing a boundary is “known”  A boundary is the border between the service public interface and its internal implementation  Services interact intentionaly and explicitly by exchanging messages
  18. 18. Share schema and contract not types 21 ISEP/IPP  Services expose schemas defining data structures and contracts defining available operations  Contracts and schema may be independently versioned over time
  19. 19. Policy define service compatibility 22 ISEP/IPP  Policy is the statement of communication requirements necessary for service interaction  Service capabilities and requirements are expressed in terms of a policy expression  A policy can contain multiple assertions
  20. 20. Services are autonomous 23 ISEP/IPP  Services are independently deployed, versioned and managed  Topology of a system evolves over time  Unlike OO, services do not share behavior  Services gracefully handle failure
  21. 21. Principles of Service Orientation 24  Standardized Contracts  Abstraction  Reusability  Autonomy  Autonomy  Coupling  Statelessness
  22. 22. 25 Standardized Contracts
  23. 23. Standardized Contracts 26 ISEP/IPP  Services within the same service inventory are in compliance with the same contract design standards  Contract-first design  Transfromation avoidance
  24. 24. Contract-First Design 27 ISEP/IPP
  25. 25. Avoid Transformation  A fundamental goal of this design principle is transformation avoidance through the standardization of data representation across service contracts. 28 ISEP/IPP
  26. 26. 29 Service Loose Coupling
  27. 27. Loose Coupling 30 ISEP/IPP  Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment
  28. 28. Service contract coupling 31 ISEP/IPP
  29. 29. Service contract coupling  Logic-to-Contract Coupling  Contract-to-Logic Coupling  Contract-to-Technology Coupling  Contract-to- Implementation Coupling  Contract-to-Functional Coupling 32 ISEP/IPP
  30. 30. Consumer coupling 33 ISEP/IPP  Consumer-to-Contract Coupling  Consumer-to-Implementation Coupling
  31. 31. Consumer coupling  Ultimately, undesirable forms of coupling can proliferated to the consumer. 34 ISEP/IPP
  32. 32. 35 Service Abstraction
  33. 33. Service Abstraction 36 ISEP/IPP  Service contracts only contain essential information and information about services is limited to what is published in service contracts
  34. 34. Hiding details  Hide as much as possible  “hidden composition” issue  service consumer are unaware that the service they are invoking encapsulates an entire composition. 37 ISEP/IPP
  35. 35. 38 Service Reusability
  36. 36. Service Reusability 39 ISEP/IPP  Services contain and express agnostic logic and can be positioned as reusable enterprise resources.
  37. 37. 40 Service Autonomy
  38. 38. Service Autonomy 41  Services exercise a high level of control over their underlying runtime execution environment  Services are independent to dominate there own code executions.  Take decisions independently of the external influences or involvement.  The objective is to:  increase reliability and behavioural predictability  increase reuse and composition of the service
  39. 39. Runtime Autonomy 42 ISEP/IPP  the degree of control that a service has over is own processes invocations and executions.  It affects:  Service execution performance;  Service degree of isolation, reliability and security;  The prediction of how a service will act;
  40. 40. Design-Time Autonomy 43 ISEP/IPP  the degree of freedom that a service owner has to change the design or architecture, of his service, over the time.  It helps on:  The scalability of the service;  The update of the “service´s hosting environment”;  The update or replace the technology used by the service;  The performance of the Runtime Autonomy;
  41. 41. Service Contract Autonomy  represents independency of the service contract from the code.  The code behavior can change but it´s signature on the contract can not.  To help create this, the service contract and code need to be normalized. 45 ISEP/IPP
  42. 42. Shared Autonomy  the way in which the other components access and compete for resources of a service with low or non-existing autonomy. 46 ISEP/IPP
  43. 43. Service Logic Autonomy  A.k.a. partially isolated services  Represents how isolated and independents services that use the same resources (databases, directories, etc) work with each other.  Issues associated:  Difficult to implement scalability;  Increases slow Runtime and unpredictable behavior 47 ISEP/IPP
  44. 44. Pure Autonomy (full isolation) 48 ISEP/IPP  represents the full isolation of the entire service that has the control of is own “internal” Runtime.  It has 3 types of isolation:  Functional Isolation – The services are separated, but are hosted in the same server with the same Runtime;  Absolute Isolation – The services are separated physically. Each has its server and Runtime;  Isolated Services at Design-Time – Pure Autonomy gives complete control on the service design, hosting environments and scalability.
  45. 45. Pure Autonomy  Functional isolation  Absolute Isolation 49 ISEP/IPP
  46. 46. 50 Service Statelessness
  47. 47. Statelessness 51  Services minimize resource consumption by deferring the management of state information when necessary
  48. 48. Non-Deferred State Management 52 ISEP/IPP  Low-to-no statelessness.  Remain active and stateful for continuous periods.  Does not require an external state deferral extension
  49. 49. Partially Deferred Memory 53 ISEP/IPP  Reduced statefulness.  Generic model of a Web Server.  The service continues active while retaining some state data.
  50. 50. Partial Deferral State Management 54 ISEP/IPP  Moderate statelessness.  Takes advantage of stateless at certain times.  Not designed to take advantage of every possible opportunity to become stateless.
  51. 51. Internally Deferred State Management 55 ISEP/IPP  High statelessness  Maximizes its opportunities to exist in a stateless condition.  Even when stateful, it defers state data when possible.
  52. 52. 56 Service Discoverability
  53. 53. Service Discoverability  Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted 57 ISEP/IPP
  54. 54. 58 Service Composibility
  55. 55. Service Composibility 59 ISEP/IPP  Services are effective composition participants, regardless of the size and complexity of the composition.  the ability to create and provision complex value added services from other services resulting in composite services.
  56. 56. 60 ISEP/I PP
  57. 57. Service Composition 61 ISEP/IPP
  58. 58. Creating a composable inventory 62 ISEP/IPP
  59. 59. 63 Closings
  60. 60. Service Principles Poster 64 ISEP/IPP http://serviceorientation.com/static/pdf/SOA_Principles_Poster.pdf
  61. 61. Principles of service design 65 ISEP/IPP  Thomas Erl  ISBN: 0132344823  http://www.soaprinciples.com/  http://www.soapatterns.org/
  62. 62. References 66  SOA Principles of Service Design, Thomas Erl.  Principles of Service design: service patterns and anti-patterns. John Evdemon (2005) http://msdn.microsoft.com/en-us/ library/ms954638.aspx
  63. 63. PROGRAMAÇÃO DE SISTEMAS DISTRIBUIDOS Paulo Gandra de Sousa pag@isep.ipp.pt

×