ServiceDesignPrinciples-WUG.ppt

376 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
376
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ServiceDesignPrinciples-WUG.ppt

  1. 1. Service Design Principles So, what exactly are the characteristics and attributes of good services? Dave Artus, John Catlin developerWorks: SOA realization: Service design principles http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design/
  2. 2. Contributors <ul><li>Peter Kovari – peter.kovari@uk.ibm.com </li></ul>
  3. 3. Agenda <ul><li>What is a Service – Review </li></ul><ul><li>Considering Service Design Decisions </li></ul><ul><li>Design Principles – Reference </li></ul>
  4. 4. Services enable a common view of heterogenous systems Legacy Packages Component Systems Interfaces and Transformation Employee Order Customer Choreography and Composition Process Layer Service Layer Application Layer
  5. 5. Definitions we can work with… <ul><li>Operations: </li></ul><ul><ul><li>Comparable to object-oriented (OO) methods. </li></ul></ul><ul><ul><li>Specific, structured interface, and return structured responses . </li></ul></ul><ul><ul><li>The execution of a specific operation might involve invocation of additional operations. </li></ul></ul><ul><li>Services: </li></ul><ul><ul><li>Logical groupings of operations . </li></ul></ul><ul><ul><li>Example: CustomerProfiling service may have operations such as </li></ul></ul><ul><ul><ul><li>Lookup customer by telephone number, </li></ul></ul></ul><ul><ul><ul><li>List customers by name and postal code </li></ul></ul></ul><ul><ul><ul><li>Save data for new customer. </li></ul></ul></ul><ul><li>Business Processes: </li></ul><ul><ul><li>Potentially long running set of actions performed with specific business goals in mind. </li></ul></ul><ul><ul><li>Typically encompass multiple service invocations. </li></ul></ul><ul><ul><li>The sequencing, selection, and execution of operations is termed service or process choreography. </li></ul></ul>
  6. 6. Agenda <ul><li>What is a Service – Review </li></ul><ul><li>Considering Service Design Decisions </li></ul><ul><li>Design Principles – Reference </li></ul>
  7. 7. Excuse me sir, are you a service? AccountRecordService { int find(String accountId, String dataHost ); String getSurname(); String getPostCode(); // etc. void setAddress(String address); // etc void save(); } PhoneNumberService { int find(String accountId, String dataHost ); String getHomeNumber(); String getMobileNumber(); // etc. void setHomeNumber(String number); // etc void save(); }
  8. 8. Things to consider! <ul><li>How many operations? </li></ul><ul><ul><li>updateTelephone(), updateAddress(), updatePostcode() </li></ul></ul><ul><li>How many parameters? </li></ul><ul><ul><li>updateAddress(number, street, village, town, region, country) </li></ul></ul><ul><li>Style of Interaction </li></ul><ul><ul><li>Stateful or Stateless </li></ul></ul><ul><ul><li>Command style { setCommand(), setX(), setY(), execute() } </li></ul></ul><ul><li>Semantic level </li></ul><ul><ul><li>Names are important </li></ul></ul><ul><ul><ul><li>insertAccountRecord() or createCustomer() </li></ul></ul></ul><ul><li>Sequence of operations </li></ul><ul><ul><li>‘ Fire and Forget’ vs. ‘Fire Now, Ask Later’ vs. ‘Tell Me Now’! </li></ul></ul>
  9. 9. Why do we need design principles? Who is benefiting from them? <ul><li>Increase </li></ul><ul><ul><li>Consumability </li></ul></ul><ul><ul><li>Adaptability </li></ul></ul><ul><ul><li>Versatility </li></ul></ul><ul><li>We are guiding the Service designer (provider) to make consistent design decisions. </li></ul><ul><ul><li>This lecture is about the interfaces not the implementation. </li></ul></ul><ul><li>The consumer benefits by making his life easier. </li></ul><ul><ul><li>Choreography is not necessarily done by a technician. </li></ul></ul>
  10. 10. Meta :: Consistent Design Decisions <ul><li>Concept </li></ul><ul><ul><li>Design decisions should be consistent, and made against a consistent set of design principles. </li></ul></ul><ul><ul><li>This is fundamental; if you don’t agree with this, then you probably don’t agree that design principles are a good idea. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Consistency of design decisions across services: </li></ul><ul><ul><li>Benefits service comprehension (understanding). </li></ul></ul><ul><ul><li>Benefits service implementation (application). </li></ul></ul><ul><ul><li>Benefits service usage (interaction). </li></ul></ul><ul><ul><li>Benefits architecture and design stability . </li></ul></ul><ul><li>Lack of consistency of design decisions across services: </li></ul><ul><ul><li>Is detrimental to comprehension. </li></ul></ul><ul><ul><li>Is detrimental to consistent implementation of services and service clients. </li></ul></ul><ul><ul><li>Facilitates design decay (loss of design integrity over time). </li></ul></ul>
  11. 11. Reality; Holistic Equilibrium <ul><li>Context </li></ul><ul><ul><li>The design approach for each service, and each SOA of services, needs to select principles based on the design context. </li></ul></ul><ul><li>Balance </li></ul><ul><ul><li>The application of design principles requires balanced , weighted , design decisions. </li></ul></ul><ul><ul><li>You decide if , when , and how , to adopt them. </li></ul></ul><ul><li>for example; Service Granularity : </li></ul><ul><ul><li>The appropriate service granularity is an equilibrium of design decisions – specific for your project. </li></ul></ul><ul><ul><li>If you get this ‘other stuff’ right (i.e. follow the design principles), then you will default to the ‘right granularity’ of service for your context. </li></ul></ul>
  12. 12. Naming is important… Invoke that! ZettuylService { int wibble(int, int, String); int wobble(int); boolean wrubble(int); void quibble(int) void quash(int) Stuff[] getStuff(int );. void quite(int); Things[] getThings(int); void hinge(int, int); int henge(int , Stuff) } <ul><li>The service naming shall be understandable for domain experts. </li></ul><ul><ul><li>Use business concepts rather than technical ones where applicable! </li></ul></ul>
  13. 13. Easier? ExpenseService { int approveClaimItem(int claimId, int itemId, String comment); int createClaim(String userId); boolean auditClaim(int claimId); void approveClaim(claimId) void returnClaim(claimId) ClaimItemDetails[] getClaimItems(int );. void payClaim(int claimId); ClaimErrors[] validateClaim(int claimId); void removeClaimItem(int claimId, int itemId); int addClaimItem(int claimId, ClaimItemDetails details) }
  14. 14. Consumability :: Domain Named Services <ul><li>Concept </li></ul><ul><ul><li>Services should be name appropriately for the consumers. Business Processes and Business Services should be named in business domain language. Technical Services should be named in technical domain language 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well named services: </li></ul><ul><ul><li>Benefit comprehension for service consumers. </li></ul></ul><ul><li>Poorly named services: </li></ul><ul><ul><li>Burden comprehension. </li></ul></ul><ul><ul><li>[1] named as technical services, not by technical solutions (i.e. use the solution abstraction principle) </li></ul></ul>
  15. 15. Consumability :: Semantic Naming <ul><li>Concept </li></ul><ul><ul><li>Services, operations, and operation parameters, should be named using language that conveys the meaning of the operations to the consumer, and should represent the operation actions 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well named services: </li></ul><ul><ul><li>Benefit comprehension of service consumers and service maintainers by implying the service semantic or behaviour, and service interaction patterns. </li></ul></ul><ul><li>Poorly named services: </li></ul><ul><ul><li>Burden comprehension and degrade semantic integrity. </li></ul></ul><ul><ul><li>[1] actions, not solutions. </li></ul></ul>
  16. 16. <schema … xmlns:xsd=…> <element name=“StrongerAddress&quot;> <complexType> <sequence> <element name=“line1&quot; type=&quot;xsd:string&quot;/> <element name=“line2&quot; type=&quot;xsd:string&quot;/> <element name=“city&quot; type=&quot;xsd:string&quot;/> <element name=“state&quot; type=&quot;xsd:string&quot;/> <element name=“country&quot; type=&quot;xsd:string&quot;/> <element name=“postcode&quot; type=&quot;xsd:string&quot;/> </sequence> </complexType> </element> </schema> Which of these is better? Why? Operation Parameter Types <schema … xmlns:xsd=…> <element name=“WeakAddress&quot;> <complexType> <sequence> <xsd:any/> </sequence> </complexType> </element> </schema> <schema … xmlns:xsd=…> <element name=“StrongerAddress&quot;> <complexType> <sequence> <element name=“line1&quot; type=&quot;xsd:string&quot;/> <element name=“line2&quot; type=&quot;xsd:string&quot;/> <element name=“city&quot; type=&quot;xsd:string&quot;/> <element name=“state&quot; type=&quot;xsd:string&quot;/> <element name=“country&quot; type=&quot;xsd:string&quot;/> <element name=“postcode&quot; type=&quot;xsd:string&quot;/> </sequence> </complexType> </element> </schema>
  17. 17. Consumability :: Strong Typed Parameters <ul><li>Concept </li></ul><ul><ul><li>Service operation parameters should be strongly typed. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Strongly typed parameter lists: </li></ul><ul><ul><li>Facilitate maintenance of semantic and design integrity over engineering change cycles. </li></ul></ul><ul><li>Weakly typed parameter lists: </li></ul><ul><ul><li>Facilitate semantic integrity degradation, design integrity decay, and subsequent comprehension issues for both service developers and service consumers. </li></ul></ul>
  18. 18. Operation Parameter Granularity <ul><li>updateAddress(Address address) </li></ul><ul><li>or </li></ul><ul><li>updateAddress(String line1, String line2, String city, String state, String country, String postcode, …, ..., …) </li></ul><ul><li>This maps to the Document, not RPC, style of Web Services </li></ul>
  19. 19. Adaptability :: Domain Differentiated Parameters <ul><li>Concept </li></ul><ul><ul><li>Differentiate between, and separate, Business Domain arguments and Solution Domain arguments 1 in service operation interfaces. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Domain differentiated parameters: </li></ul><ul><ul><li>Aids phased adoption by separating business and solution concerns, and facilitating ‘dissociation of concerns’. </li></ul></ul><ul><li>Non domain differentiated parameters: </li></ul><ul><ul><li>Will hinder SOA adoption (i.e. bite you) if you have to factor session based incumbent systems and components into services. </li></ul></ul><ul><ul><li>1 for example; to maintain continuity of context flow design from presentation layers, through services, to legacy systems, when both the presentation layer and the legacy systems are out of scope for change! </li></ul></ul>
  20. 20. Control stateful aspects of service interactions Transaction or process identifiers Stateful Stateless Service Client: What's Bruce's balance? Service Provider: £x Service Client: What's his credit limit? Service Provider: £y Service Client: What's Bruce's balance? Service Provider: £x Service Client: What's Bruce's credit limit? Service Provider: £y Part of the business data (the fact that we're dealing with Bruce) is implied in the sequence All the business data is defined in the interface Each instance of a shared sequence of activity should be uniquely identified, for example through a transaction ID or customer ID, and that identity should form part of all service calls.
  21. 21. Adaptability :: Stateless Implementations <ul><li>Concept </li></ul><ul><ul><li>Service implementations should not hold conversational state (client interaction specific information) across multiple requests. </li></ul></ul><ul><ul><ul><li>Communicate complete information at each request. </li></ul></ul></ul><ul><ul><li>Each operation should be functionally discrete (separate, independent). </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Stateless services: </li></ul><ul><ul><li>Benefit adaptability by virtue of independence between a clients successes service requests and the service instance that fulfils each request. This is an enabler for improved runtime qualities (for example; service request throughput, concurrent service requests) via increased service instance deployments (i.e. client service independence). </li></ul></ul><ul><li>Stateful services: </li></ul><ul><ul><li>Hinder adaptability as a consequence of tight dependency (coupling) between a clients successive service requests, and the need for a specific service instance to fulfil the set of associated service requests (i.e. client-service affinity). </li></ul></ul>
  22. 22. Control stateful aspects of service interactions Sequence of operations Load Fire Use naming and documentation and defensive programming to help consumer. This is an opportunity to define and share a process definition. Aim No, wait a minute … aim, fire, load …
  23. 23. Control stateful aspects of service interactions Sequence of operations Load Fire Aim Use naming and documentation and defensive programming to help consumer. This is an opportunity to define and share a process definition. ShootAt (ammo, target)
  24. 24. Consumability :: Implicit Usage Dynamic <ul><li>Concept </li></ul><ul><ul><li>Services interfaces should have implicit interaction patterns. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Implicit usage dynamic services: </li></ul><ul><ul><li>Benefit consumability by supporting clearly implied, or well understood, patterns of interaction between the service consumer and the service. </li></ul></ul><ul><li>Ambiguous usage dynamic services: </li></ul><ul><ul><li>Hinder consumability. </li></ul></ul>
  25. 25. Interaction Dynamics Think of the difference between applying for a mortgage over the phone or by post ... Service-like - the interaction is not dependent on the identity of the service provider - i.e. the completed application form can be returned to a different branch than the one that provided it. API-like, or component-like - the interaction is dependent on the specific representative of the estate agent - i.e. the identity of the service provider. <ul><li>By post: </li></ul><ul><ul><li>Client requests application form </li></ul></ul><ul><ul><li>Provider sends it </li></ul></ul><ul><ul><li>Client fills it in and returns it </li></ul></ul><ul><ul><li>Provider says &quot;yes&quot; or &quot;no&quot; </li></ul></ul><ul><li>By phone: </li></ul><ul><ul><li>Client calls provider </li></ul></ul><ul><ul><li>Provider says &quot;Hello, how can we help&quot; </li></ul></ul><ul><ul><li>&quot;I'd like a mortgage please&quot; </li></ul></ul><ul><ul><li>&quot;What's your name&quot; </li></ul></ul><ul><ul><li>&quot;John Smith&quot; </li></ul></ul><ul><ul><li>&quot;What's the property address&quot; </li></ul></ul><ul><ul><li>&quot;27 ...&quot; </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><ul><li>&quot;... OK, your mortgage agreement number is 12345, I'll post the rest of the details&quot; </li></ul></ul>
  26. 26. Versatility :: Call Sequence Resilient <ul><li>Concept </li></ul><ul><ul><li>Service operations should be resilient to out-of-sequence invocation 1,2 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Independent call sequences: </li></ul><ul><ul><li>Benefit versatility by broadening potential usage scenarios for the service. </li></ul></ul><ul><li>Dependent call sequences: </li></ul><ul><ul><li>Burden versatility by restricting usage scenarios for the service. </li></ul></ul><ul><ul><li>[1] this does not conflict with the principle Consumability::Implict Usage Dynamic, which guides usage, rather than fixing usage. </li></ul></ul><ul><ul><li>[2] State Transition models need attainment of transition conditions (states) before a process or system changes condition, but, exceptions aside, this is probably a concern for a business process, not for a business service (a tricky one, right?) </li></ul></ul>
  27. 27. Dependency between operations and state… ExpenseService { int approveClaimItem(int claimId, int itemId, String comment); int createClaim(String userId); boolean auditClaim(int claimId); void approveClaim(claimId) void returnClaim(claimId) ClaimItemDetails[] getClaimItems(int );. void payClaim(int claimId); ClaimErrors[] validateClaim(int claimId); void removeClaimItem(int claimId, int itemId); int addClaimItem(int claimId, ClaimItemDetails details) } Some operations are invalid in some contexts
  28. 28. Control stateful aspects of service interactions 1/5 ClaimProcessService { submitClaim(); approveClaim() recordClaimCompletion() } Expense Processing submitted approved completed
  29. 29. Control stateful aspects of service interactions 2/5 ClaimProcessService { submitClaim(); approveClaim() recordClaimCompletion() } Expense Processing submitted approved completed Claim Entry ClaimEntryService { int createClaim(String userId); int addClaimItem(int claimId, ClaimItemDetails details) int modifyClaimItem(int claimId, ClaimItemDetails details); ClaimItemDetails[] getClaimItems(int );. ClaimErrors[] validateClaim(int claimId); void removeClaimItem(int claimId, int itemId); void submitClaim(claim id); } add add ready working created invalid
  30. 30. Control stateful aspects of service interactions 3/5 ClaimProcessService { submitClaim(); approveClaim() recordClaimCompletion() } Expense Processing submitted approved completed ClaimEntryService { int createClaim(String userId) // ... } ClaimApprovalService { int approveClaimItem(int claimId, int itemId, String comment); boolean auditClaim(int claimId); void approveClaim(claimId) void returnClaim(claimId) ClaimErrors[] validateClaim(int claimId); }
  31. 31. Control stateful aspects of service interactions 4/5 ClaimProcessService { submitClaim(); approveClaim() recordClaimCompletion() } Expense Processing submitted approved completed ClaimEntryService { int createClaim(String userId) // ... } ClaimApprovalService { int approveClaimItem(); //.... } ClaimPaymentService { int payClaim(); //.... }
  32. 32. Stateful Business Activity Stateful Business Activity Stateful Business Activity Event Event Persist Business Data Persist Business Data Persist Business Data Persist Business Data Event Stateful Business Activity Capturing service dependencies by explicitly modelling stateful interactions One of the causes of inflexibility in applications is over-tight coupling between stateful processes (e.g. application workflow and business process). Control stateful aspects of service interactions 5/5
  33. 33. Consumability :: High Cohesion <ul><li>Concept </li></ul><ul><ul><li>Services interfaces should be concise, related, and complete sets of operations. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Cohesive services: </li></ul><ul><ul><li>Benefit consumability by assisting comprehension by being concise and complete; providing every operation that is needed for the supported use cases for the targeted consumer. All of the interface operations seem appropriate for the consumer. </li></ul></ul><ul><li>Un-cohesive services: </li></ul><ul><ul><li>Hinder consumability by hindering comprehension (providing confusion) by exposing tenuously related, or unrelated, operations to the consumer. </li></ul></ul>
  34. 34. Resource Coupling and Monopolisation 1/2 <ul><li>&quot;Loosely coupled&quot; means many things to many people, but doesn't tend to imply: </li></ul><ul><ul><li>A service provider locking database records on behalf of a service requester who has just requested access to customer data in order to make an update. </li></ul></ul><ul><ul><li>Passing object references or database cursors to service requesters who request access to data. </li></ul></ul><ul><li>So, &quot;loosely coupled&quot; does imply: </li></ul><ul><ul><li>Pass by value - passing copies of data. </li></ul></ul><ul><ul><li>Highly optimistic transaction models - &quot;I have this old copy of your data, and I'd like to make this change to it - would that be OK?&quot; </li></ul></ul>
  35. 35. Resource Coupling and Monopolisation 2/2 <ul><li>Optimistic locking </li></ul><ul><ul><li>Send update requests with a copy of the original data </li></ul></ul><ul><ul><li>Use an update counter, version number or timestamp of the version of data on which the update was based </li></ul></ul><ul><li>Optimistic locking is only useful when the chances of failure are small </li></ul><ul><ul><li>e.g. good for changing a customer's address, bad for ordering stock at the current stock price. </li></ul></ul><ul><li>The chances of failure can be reduced by including more sophisticated pre-conditions </li></ul><ul><ul><li>e.g. minimum and maximum acceptable stock price for the transaction </li></ul></ul><ul><li>When designing, acknowledge a time-delayed model. </li></ul><ul><ul><li>decide on and make explicit what you want checked. </li></ul></ul>
  36. 36. Performance :: Efficient Resource Utilisation <ul><li>Concept </li></ul><ul><ul><li>Service implementations should be optimistic, brief and courteous with resource usage. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Optimistic (loose) resource usage: </li></ul><ul><ul><li>Facilitate higher system performance qualities; concurrency, scalability and availability, through courteous use of resources. </li></ul></ul><ul><li>Pessimistic (tight) resource usage: </li></ul><ul><ul><li>Hinder higher system performance qualities through resource monopolisation and obstruction; locking and blocking. </li></ul></ul>
  37. 37. Service Description WSDL is not the only fruit <ul><li>WSDL provides a machine readable Service Description </li></ul><ul><ul><li>Suitable for code generation </li></ul></ul><ul><ul><li>Humans infer additional information </li></ul></ul><ul><li>Semantics cannot always reliably be inferred </li></ul><ul><ul><li>Outcome delivery </li></ul></ul><ul><ul><li>Operation sequencing </li></ul></ul><ul><ul><li>Inter-field validation </li></ul></ul><ul><ul><li>Quality of service </li></ul></ul><ul><ul><li>Recovery scenarios </li></ul></ul><ul><li>High quality documentation is needed </li></ul>
  38. 38. Versatility :: Implementation Technology Agnostic <ul><li>Concept </li></ul><ul><ul><li>Services should not imply or represent any implementation technology by their interface design. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Good technology agnostic services: </li></ul><ul><ul><li>Benefit versatility by enabling mixed technology (heterogeneous) solutions. </li></ul></ul><ul><ul><ul><li>Use WSDL and XSD </li></ul></ul></ul><ul><li>Poor technology agnostic services: </li></ul><ul><ul><li>Hinder versatility by tightly coupling client and service implementation technologies. </li></ul></ul><ul><ul><ul><li>For example, by exposing implementation technology specific data types or context representations. </li></ul></ul></ul>
  39. 39. <ul><li>A Service operation is intended for reuse </li></ul><ul><ul><li>It will be choreographed </li></ul></ul><ul><ul><li>It may be invoked asynchronously </li></ul></ul><ul><ul><li>Successive invocations may not </li></ul></ul><ul><ul><ul><li>Be on the same machine </li></ul></ul></ul><ul><ul><ul><li>In the same process </li></ul></ul></ul><ul><ul><li>Even if a process invokes two operations in the same service sequentially, we cannot assume that they will happen in rapid succession. </li></ul></ul>Service Usage Context and Scenarios Reuse
  40. 40. Versatility :: Factor for Reuse <ul><li>Concept </li></ul><ul><ul><li>A service interface should be designed with reuse in mind. </li></ul></ul><ul><ul><li>Anticipate reuse scenarios. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well factored service interfaces: </li></ul><ul><ul><li>Anticipate usage scenarios, and consequently facilitate reuse. </li></ul></ul><ul><li>Poorly factored service interfaces: </li></ul><ul><ul><li>Hinder reuse and encourage functional duplication, which can result in architectural decay (loss of architectural integrity over time). </li></ul></ul>
  41. 41. <ul><li>Once I've given out the data I don't know what will happen to it, or when </li></ul><ul><li>Once I've received the data it's potentially out of date </li></ul><ul><ul><li>getBalance() </li></ul></ul><ul><ul><li>getRecentTransactions() </li></ul></ul><ul><li>Some transaction models can be applied that recognise pass by value explicitly: </li></ul><ul><ul><li>Insert vs. Update </li></ul></ul><ul><ul><ul><li>Think insert rather than update wherever possible. </li></ul></ul></ul><ul><ul><ul><li>Think inserts for which the order of execution is unimportant wherever possible. e.g. think &quot;request an addition / subtraction to balance&quot; rather than &quot;set the balance to&quot; </li></ul></ul></ul><ul><li>Update Request vs. Update </li></ul><ul><ul><li>Treat update requests as entities, e.g. a &quot;Customer Details Update Request&quot; entity contains requested changes to a &quot;Customer Details&quot; entity. </li></ul></ul><ul><ul><li>If each update request has a recognisable identity (e.g. userid, process / transaction id, time etc.), this provides a technique to manage conflicts or the receipt of idempotent requests. </li></ul></ul>Service Usage Context and Scenarios Resource dependencies
  42. 42. Adaptability :: Factored Resource Dependencies <ul><li>Concept </li></ul><ul><ul><li>Minimise crosscutting resource dependencies between services 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well factored services: </li></ul><ul><ul><li>Benefit adaptability and versatility by reducing the complexity of dependency networks on resources underlying services, thus changes in underlying resources have less complicated ramifications. </li></ul></ul><ul><li>Poorly factored services: </li></ul><ul><ul><li>Hinder adaptability and versatility by increasing complexity and complicating change ramifications. </li></ul></ul><ul><ul><li>[1] application resources, data, other services,... any dependency. </li></ul></ul>
  43. 43. <ul><li>Operations may be implemented using other services </li></ul><ul><ul><li>Hence completion may be delayed </li></ul></ul><ul><li>Operation may have been invoked “Fire-and-Forget” </li></ul><ul><ul><li>How report outcome? </li></ul></ul><ul><li>Offer a request ACK </li></ul><ul><ul><li>“ Your request was understood and will be processed eventually” </li></ul></ul><ul><ul><li>Can immediately report malformed requests </li></ul></ul><ul><li>Outcome reported later </li></ul><ul><ul><li>Perhaps using event notification </li></ul></ul><ul><ul><li>Perhaps permitting polling for status/progress </li></ul></ul><ul><ul><li>How is the request identified/correlated? </li></ul></ul>Service Usage Context and Scenarios Invocation characteristics
  44. 44. Consumability :: Factored by Consumer <ul><li>Concept </li></ul><ul><ul><li>Services should be factored for classes of consumer. </li></ul></ul><ul><ul><ul><li>For example; Business Services, Technical Services. </li></ul></ul></ul><ul><ul><ul><li>AKA; Separation of Concerns (along consumer classification boundaries). </li></ul></ul></ul><ul><li>Consequences </li></ul><ul><li>Well consumer factored services: </li></ul><ul><ul><li>Benefit consumability by focus on (specialising in) the needs of sets of consumers. </li></ul></ul><ul><li>Poorly consumer factored services: </li></ul><ul><ul><li>Hinder comprehension, and thus hinder consumability, by exposing non pertinent operations. </li></ul></ul>
  45. 45. <ul><li>The calling process may encounter subsequent problems </li></ul><ul><ul><li>Consider whether to provide compensation operations </li></ul></ul><ul><li>Your operation may fail </li></ul><ul><ul><li>What semantics do you provide? </li></ul></ul><ul><ul><li>Always rollback? </li></ul></ul><ul><ul><ul><li>Maybe cannot unsend an email </li></ul></ul></ul>Service Usage Context and Scenarios Exception handling
  46. 46. Agenda <ul><li>What is a Service – Review </li></ul><ul><li>Considering Service Design Decisions </li></ul><ul><li>Design Principles – Reference </li></ul>
  47. 47. Design Principles <ul><li>Assertion; SOA Concepts govern Service Design </li></ul><ul><ul><li>The Service Oriented Architecture is the operational context for Services and Processes, … </li></ul></ul><ul><ul><li>… therefore the Principles for Service Design are governed by the Principles for SOA Design ; they complement by necessity. </li></ul></ul>
  48. 48. Reality; Holistic Equilibrium <ul><li>Context </li></ul><ul><ul><li>The design approach for each service, and each SOA of services, needs to select principles based on the design context. </li></ul></ul><ul><li>Balance </li></ul><ul><ul><li>The application of design principles requires balanced , weighted , design decisions. </li></ul></ul><ul><ul><li>You decide if , when , and how , to adopt them. </li></ul></ul><ul><li>for example; Service Granularity : </li></ul><ul><ul><li>The appropriate service granularity is an equilibrium of design decisions for specific for your project. </li></ul></ul><ul><ul><li>If you get this ‘other stuff’ right (i.e. follow the design principles), then you will default to the ‘right granularity’ of service for your context. </li></ul></ul>
  49. 49. Meta :: Consistent Design Decisions <ul><li>Concept </li></ul><ul><ul><li>Design decisions should be consistent, and made against a consistent set of design principles. </li></ul></ul><ul><ul><li>This is fundamental; if you don’t agree with this, then you probably don’t agree that design principles are a good idea. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Consistency of design decisions across services: </li></ul><ul><ul><li>Benefits service comprehension (understanding). </li></ul></ul><ul><ul><li>Benefits service implementation (application). </li></ul></ul><ul><ul><li>Benefits service usage (interaction). </li></ul></ul><ul><ul><li>Benefits architecture and design stability . </li></ul></ul><ul><li>Lack of consistency of design decisions across services: </li></ul><ul><ul><li>Is detrimental to comprehension. </li></ul></ul><ul><ul><li>Is detrimental to consistent implementation of services and service clients. </li></ul></ul><ul><ul><li>Facilitates design decay (loss of design integrity over time). </li></ul></ul>
  50. 50. Consumability :: Execution Environment Abstraction <ul><li>Concept </li></ul><ul><ul><li>The SOA runtime environment (e.g. middleware, service containers, and service busses) complexity should not be intrusive to the service consumers, or to the service implementers. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>A well abstracted runtime environment: </li></ul><ul><ul><li>Benefits service implementers by allowing them to focus on problem domain code, rather than infrastructure code (i.e. not writing middleware interaction code). </li></ul></ul><ul><ul><li>Lowers the level of comprehension of Enterprise Software System Architecture needed by service implementers (domain software developers). </li></ul></ul><ul><ul><li>Lowers the level of comprehension of Enterprise Software System Architecture needed by service consumers (domain software developers). </li></ul></ul><ul><ul><li>Facilitates rapid service development cycles. </li></ul></ul><ul><li>A poorly abstracted runtime environment: </li></ul><ul><ul><li>Increases the level of comprehension of Enterprise Software Systems required by, and consequently increases the level of skill set needed for, software developers. </li></ul></ul><ul><ul><li>Burdens service development cycles. </li></ul></ul>
  51. 51. Adaptability :: Solution Abstraction <ul><li>Concept </li></ul><ul><ul><li>Services should not imply or represent any implementation solution design by their interface. </li></ul></ul><ul><ul><li>They should imply a concept, not any specific instance. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well abstracted services: </li></ul><ul><ul><li>Benefit adaptability by virtue of their separation of the semantics, the structure, and the dynamics of an interface from the implementation mechanisms of a service, thus facilitating implementation change. </li></ul></ul><ul><li>Poorly abstracted services: </li></ul><ul><ul><li>Hinder adaptability by implying implementation details (technologies, dependencies, mechanisms), and consequently making change problematic. </li></ul></ul><ul><ul><li>Can lead to divergence in implied implementation characteristics from concrete implementations, resulting in loss of semantic integrity between the service and the service consumer over service change cycles. </li></ul></ul>+Example
  52. 52. Solution Abstraction Examples <ul><li>Poor Example? </li></ul><ul><ul><li>Implementation Specific... </li></ul></ul><ul><ul><li>RelateService.CreateCase </li></ul></ul><ul><li>Better Example? </li></ul><ul><ul><li>Implementation Agnostic... </li></ul></ul><ul><ul><li>CRMService.CreateCase </li></ul></ul><ul><ul><li>(poor?) CRMService.CreateRelateCase </li></ul></ul><ul><li>Also consider... </li></ul><ul><ul><li>3GServiceManagement.Activate3GFeature(...); vs.... </li></ul></ul><ul><ul><li>ServiceManagement.Activate3GFeature(...); vs.... </li></ul></ul><ul><ul><li>ServiceManagement.ActiveFeature(...); </li></ul></ul><ul><ul><li>(poor?) ServiceManagement.Command([in]xsdAny args, [ret]xsdAny args); </li></ul></ul>
  53. 53. Consumability :: Consistent Abstraction <ul><li>Concept </li></ul><ul><ul><li>Each service interface should expose an even (consistent) level of abstraction of operations. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Evenly abstracted services: </li></ul><ul><ul><li>Aid comprehension and consumability by targeting consistent levels of usage scenario. </li></ul></ul><ul><li>Unevenly abstracted services: </li></ul><ul><ul><li>Hinder consumability and comprehension. </li></ul></ul>
  54. 54. Adaptability :: Solution Encapsulation <ul><li>Concept </li></ul><ul><ul><li>Services should not physically expose any implementation details or deployment details at their interface design. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well encapsulated services: </li></ul><ul><ul><li>Benefit adaptability by decoupling the service implementation characteristics and service deployment characteristics from the client implementation. In circumstance where an implementation specific or a deployment specific characteristic needs to be changed, then the client remains unaffected. </li></ul></ul><ul><li>Poorly encapsulated services: </li></ul><ul><ul><li>Hinder adaptability as a consequence of coupling the client with the service implementation characteristics or service deployment characteristics. In circumstances where an implementation specific or a deployment specific characteristic needs to be changed, then both the client implementation and the service implementation need to be changed. </li></ul></ul>+Example
  55. 55. Solution Encapsulations Examples <ul><li>Poor Example? </li></ul><ul><ul><li>Implementation Exposed... </li></ul></ul><ul><ul><li>CRMService.CreateCase([in]Case aNewCase, [in]String databaseName); </li></ul></ul><ul><ul><li>CRMService.CreateCase([in]Case aNewCase, [in]String requestQueue); </li></ul></ul><ul><li>Better Example? </li></ul><ul><ul><li>Implementation Encapsulated... </li></ul></ul><ul><ul><li>CRMService.CreateCase([in]Case aNewCase); </li></ul></ul><ul><li>Also consider... </li></ul><ul><ul><li>Does this break encapsulation?... </li></ul></ul><ul><ul><li>CRMService.CreateCase([in]Case aNewCase, [in]Context someContext); </li></ul></ul>
  56. 56. Adaptability :: Domain Differentiated Parameters <ul><li>Concept </li></ul><ul><ul><li>Differentiate between, and separate, Business Domain arguments and Solution Domain arguments 1 in service operation interfaces. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Domain differentiated parameters: </li></ul><ul><ul><li>Aids phased adoption by separating business and solution concerns, and facilitating ‘dissociation of concerns’. </li></ul></ul><ul><li>Non domain differentiated parameters: </li></ul><ul><ul><li>Will hinder SOA adoption (i.e. bite you) if you have to factor session based incumbent systems and components into services. </li></ul></ul><ul><ul><li>1 for example; to maintain continuity of context flow design from presentation layers, through services, to legacy systems, when both the presentation layer and the legacy systems are out of scope for change! </li></ul></ul>
  57. 57. Versatility :: Implementation Technology Agnostic <ul><li>Concept </li></ul><ul><ul><li>Services should not imply or represent any implementation technology by their interface design. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Good technology agnostic services: </li></ul><ul><ul><li>Benefit versatility by enabling mixed technology (heterogeneous) solutions. </li></ul></ul><ul><ul><ul><li>Use WSDL and XSD </li></ul></ul></ul><ul><li>Poor technology agnostic services: </li></ul><ul><ul><li>Hinder versatility by tightly coupling client and service implementation technologies. </li></ul></ul><ul><ul><ul><li>For example, by exposing implementation technology specific data types or context representations. </li></ul></ul></ul>+Example
  58. 58. Technology Agnostic Examples <ul><li>Poor Example? </li></ul><ul><ul><li>Java Implementation Technology Exposed... </li></ul></ul><ul><ul><li>CRMService.GetInteractions([in]java.lang.String caseID, [ret]java.utils.Collection caseInteractions); </li></ul></ul><ul><li>Better Example? </li></ul><ul><ul><li>No Implementation Technology Exposed... </li></ul></ul><ul><ul><li>CRMService.GetInteractions([in]xsd:string caseID, [ret] caseInteraction[] caseInteractions); </li></ul></ul>
  59. 59. Adaptability :: Invocation Protocol Agnostic <ul><li>Concept </li></ul><ul><ul><li>Service interfaces or implementations should not be dependent on any specific communication or transport protocol 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Invocation protocol agnostic services: </li></ul><ul><ul><li>Benefit adaptability by decoupling the service and client implementation from the service invocation protocol, thus facilitating invocation protocol options based on QOS needs. </li></ul></ul><ul><li>Invocation protocol specific services: </li></ul><ul><ul><li>Hinder adaptability by limiting (constraining) deployment options. </li></ul></ul><ul><ul><li>[1] protocol should be a deployment decision based on required qualities of service, not bound to service design, interface design, or client design. </li></ul></ul>
  60. 60. Versatility :: Operational Isolation <ul><li>Concept </li></ul><ul><ul><li>Services should be capable of being independently isolated (taken offline) for operational and maintenance activities 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Isolatable services: </li></ul><ul><ul><li>Benefit operational versatility by allowing minimal disruption to the system service level in the event of production maintenance. </li></ul></ul><ul><li>Non-isolatable services: </li></ul><ul><ul><li>Hinder operational versatility by increasing the ‘service down’ impact of production system maintenance. </li></ul></ul><ul><ul><li>[1] this has implications for deployment unit packaging and service dependency networks </li></ul></ul>
  61. 61. Adaptability :: Factored Resource Dependencies <ul><li>Concept </li></ul><ul><ul><li>Minimise crosscutting resource dependencies between services 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well factored services: </li></ul><ul><ul><li>Benefit adaptability and versatility by reducing the complexity of dependency networks on resources underlying services, thus changes in underlying resources have less complicated ramifications. </li></ul></ul><ul><li>Poorly factored services: </li></ul><ul><ul><li>Hinder adaptability and versatility by increasing complexity and complicating change ramifications. </li></ul></ul><ul><ul><li>[1] application resources, data, other services,... any dependency. </li></ul></ul>
  62. 62. Performance :: Efficient Resource Utilisation <ul><li>Concept </li></ul><ul><ul><li>Service implementations should be optimistic, brief and courteous with resource usage. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Optimistic (loose) resource usage: </li></ul><ul><ul><li>Facilitate higher system performance qualities; concurrency, scalability and availability, through courteous use of resources. </li></ul></ul><ul><li>Pessimistic (tight) resource usage: </li></ul><ul><ul><li>Hinder higher system performance qualities through resource monopolisation and obstruction; locking and blocking. </li></ul></ul>
  63. 63. Versatility :: Differentiate Services and Processes <ul><li>Concept </li></ul><ul><ul><li>Processes should be utilisations of services; Services should be well factored discrete elements of reusable functionality 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Differentiated processes and services: </li></ul><ul><ul><li>Benefits incremental adoption of SOA technologies (e.g. WebSphere Process Server) in SOA migration scenarios. </li></ul></ul><ul><li>Non-differentiated processes and services: </li></ul><ul><ul><li>Hinders …. </li></ul></ul><ul><ul><li>[1] i.e. processes are a manifestation of service usage/reuse. </li></ul></ul><ul><ul><li>Processes appear as Services (web services) from the perspective of their clients. </li></ul></ul>
  64. 64. Integrity :: Immutable Interfaces <ul><li>Concept </li></ul><ul><ul><li>Once published to a production system, service interfaces should be immutable (should not be changed). Any change forces a new service 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Immutable services: </li></ul><ul><ul><li>Benefit system integrity by ensuring the binding contract between client and service cannot be inadvertently broken. </li></ul></ul><ul><ul><li>Forces proper consideration of, and adoption of, managed change, version control, and configuration management mechanisms. </li></ul></ul><ul><li>Mutable services: </li></ul><ul><ul><li>Risk system binding integrity failures. </li></ul></ul><ul><ul><li>[1] This does not mean that services cannot be deprecated. </li></ul></ul>
  65. 65. Consumability :: Factored by Consumer <ul><li>Concept </li></ul><ul><ul><li>Services should be factored for classes of consumer. </li></ul></ul><ul><ul><ul><li>For example; Business Services, Technical Services. </li></ul></ul></ul><ul><ul><ul><li>AKA; Separation of Concerns (along consumer classification boundaries). </li></ul></ul></ul><ul><li>Consequences </li></ul><ul><li>Well consumer factored services: </li></ul><ul><ul><li>Benefit consumability by focus on (specialising in) the needs of sets of consumers. </li></ul></ul><ul><li>Poorly consumer factored services: </li></ul><ul><ul><li>Hinder comprehension, and thus hinder consumability, by exposing non pertinent operations. </li></ul></ul>
  66. 66. Consumability :: Domain Named Services <ul><li>Concept </li></ul><ul><ul><li>Services should be name appropriately for the consumers. Business Processes and Business Services should be named in business domain language. Technical Services should be named in technical domain language 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well named services: </li></ul><ul><ul><li>Benefit comprehension for service consumers. </li></ul></ul><ul><li>Poorly named services: </li></ul><ul><ul><li>Burden comprehension. </li></ul></ul><ul><ul><li>[1] named as technical services, not by technical solutions (i.e. use the solution abstraction principle) </li></ul></ul>
  67. 67. Consumability :: Semantic Naming <ul><li>Concept </li></ul><ul><ul><li>Services, operations, and operation parameters, should be named using language that conveys the meaning of the operations to the consumer, and should represent the operation actions 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well named services: </li></ul><ul><ul><li>Benefit comprehension of service consumers and service maintainers by implying the service semantic or behaviour, and service interaction patterns. </li></ul></ul><ul><li>Poorly named services: </li></ul><ul><ul><li>Burden comprehension and degrade semantic integrity. </li></ul></ul><ul><ul><li>[1] actions, not solutions. </li></ul></ul>
  68. 68. Consumability :: Implicit Usage Dynamic <ul><li>Concept </li></ul><ul><ul><li>Services interfaces should have implicit interaction patterns. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Implicit usage dynamic services: </li></ul><ul><ul><li>Benefit consumability by supporting clearly implied, or well understood, patterns of interaction between the service consumer and the service. </li></ul></ul><ul><li>Ambiguous usage dynamic services: </li></ul><ul><ul><li>Hinder consumability. </li></ul></ul>+Example
  69. 69. Implicit Usage Dynamic Examples <ul><li>Poor Example? </li></ul><ul><ul><li>Implied usage?... </li></ul></ul><ul><ul><li>CRMService.GetThings(...); </li></ul></ul><ul><ul><li>CRMService.DoStuff(...); </li></ul></ul><ul><ul><li>CRMService.Add(...); </li></ul></ul><ul><ul><li>CRMService.Create(...); </li></ul></ul><ul><li>Better Example? </li></ul><ul><ul><li>Implied usage?... </li></ul></ul><ul><ul><li>CRMService.CreateInteractionCase(...); </li></ul></ul><ul><ul><li>CRMService.AddCaseInteraction(...); </li></ul></ul><ul><ul><li>(?) CRMService.NotifyCustomer(...); </li></ul></ul>
  70. 70. Versatility :: Call Sequence Resilient <ul><li>Concept </li></ul><ul><ul><li>Service operations should not be resilient out-of-sequence invocation 1,2 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Independent call sequences: </li></ul><ul><ul><li>Benefit versatility by broadening potential usage scenarios for the service. </li></ul></ul><ul><li>Dependent call sequences: </li></ul><ul><ul><li>Burden versatility by restricting usage scenarios for the service. </li></ul></ul><ul><ul><li>[1] this does not conflict with the principle Consumability::Implict Usage Dynamic, which guides usage, rather than fixing usage. </li></ul></ul><ul><ul><li>[2] State Transition models need attainment of transition conditions (states) before a process or system changes condition, but, exceptions aside, this is probably a concern for a business process, not for a business service (a tricky one, right?) </li></ul></ul>
  71. 71. Consumability :: High Cohesion <ul><li>Concept </li></ul><ul><ul><li>Services interfaces should be concise, related, and complete sets of operations. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Cohesive services: </li></ul><ul><ul><li>Benefit consumability by assisting comprehension by being concise and complete; providing every operation that is needed for the supported use cases for the targeted consumer. All of the interface operations seem appropriate for the consumer. </li></ul></ul><ul><li>Un-cohesive services: </li></ul><ul><ul><li>Hinder consumability by hindering comprehension (providing confusion) by exposing tenuously related, or unrelated, operations to the consumer. </li></ul></ul>+Example
  72. 72. Cohesion Examples <ul><li>Poor Example? </li></ul><ul><li>FooService </li></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>createClaim(...) </li></ul></ul><ul><ul><li>addClaimItem(...) </li></ul></ul><ul><ul><li>modifyClaimItem(...) </li></ul></ul><ul><ul><li>getClaimItems(...) </li></ul></ul><ul><ul><li>validateClaim(...) </li></ul></ul><ul><ul><li>removeClaimItem(...) </li></ul></ul><ul><ul><li>approveClaimItem(...) </li></ul></ul><ul><ul><li>approveClaim(...) </li></ul></ul><ul><ul><li>returnClaim(...) </li></ul></ul><ul><ul><li>createCRMCase(...) </li></ul></ul><ul><ul><li>addCRMCaseIntercation(...) </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><li>Better Example? </li></ul><ul><ul><li>ClaimEntryService </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>createClaim(...) </li></ul></ul><ul><ul><li>addClaimItem(...) </li></ul></ul><ul><ul><li>modifyClaimItem(...) </li></ul></ul><ul><ul><li>getClaimItems(...) </li></ul></ul><ul><ul><li>validateClaim(...) </li></ul></ul><ul><ul><li>removeClaimItem(...) </li></ul></ul><ul><ul><li>submitClaim(...) </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><ul><li>ClaimApprovalService </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>getClaimItems(...) </li></ul></ul><ul><ul><li>approveClaimItem(...) </li></ul></ul><ul><ul><li>validateClaim(...) </li></ul></ul><ul><ul><li>approveClaim(...) </li></ul></ul><ul><ul><li>returnClaim(...) </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><ul><li>ClaimPaymentService </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>payClaim(...) </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><li>Better Example? </li></ul><ul><li>ClaimService </li></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>createClaim(...) </li></ul></ul><ul><ul><li>addClaimItem(...) </li></ul></ul><ul><ul><li>modifyClaimItem(...) </li></ul></ul><ul><ul><li>getClaimItems(...) </li></ul></ul><ul><ul><li>validateClaim(...) </li></ul></ul><ul><ul><li>removeClaimItem(...) </li></ul></ul><ul><ul><li>submitClaim (...) </li></ul></ul><ul><ul><li>approveClaimItem(...) </li></ul></ul><ul><ul><li>approveClaim(...) </li></ul></ul><ul><ul><li>returnClaim(...) </li></ul></ul><ul><ul><li>payClaim (...) </li></ul></ul><ul><ul><li>} </li></ul></ul><ul><ul><li>CRMService </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>createCase(...) </li></ul></ul><ul><ul><li>addInteraction(...) </li></ul></ul><ul><ul><li>} </li></ul></ul>
  73. 73. Versatility :: Factor for Reuse <ul><li>Concept </li></ul><ul><ul><li>A service interface should be designed with reuse in mind. </li></ul></ul><ul><ul><li>Anticipate reuse scenarios. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Well factored service interfaces: </li></ul><ul><ul><li>Anticipate usage scenarios, and consequently facilitate reuse. </li></ul></ul><ul><li>Poorly factored service interfaces: </li></ul><ul><ul><li>Hinder reuse and encourage functional duplication, which can result in architectural decay (loss of architectural integrity over time). </li></ul></ul>
  74. 74. Adaptability :: Stateless Implementations <ul><li>Concept </li></ul><ul><ul><li>Service implementations should not hold conversational state (client interaction specific information) across multiple requests. </li></ul></ul><ul><ul><ul><li>Communicate complete information at each request. </li></ul></ul></ul><ul><ul><li>Each operation should be functionally discrete (separate, independent). </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Stateless services: </li></ul><ul><ul><li>Benefit adaptability by virtue of independence between a clients successes service requests and the service instance that fulfils each request. This is an enabler for improved runtime qualities (for example; service request throughput, concurrent service requests) via increased service instance deployments (i.e. client service independence). </li></ul></ul><ul><li>Stateful services: </li></ul><ul><ul><li>Hinder adaptability as a consequence of tight dependency (coupling) between a clients successive service requests, and the need for a specific service instance to fulfil the set of associated service requests (i.e. client-service affinity). </li></ul></ul>+Example
  75. 75. Stateless Examples <ul><li>Poor Example? </li></ul><ul><ul><li>stateful... </li></ul></ul><ul><ul><li>CRMService.CreateInteractionCase([in]cusomter); </li></ul></ul><ul><ul><li>CRMService.OpenInteractionCase(); </li></ul></ul><ul><ul><li>CRMService.AddCaseInteraction([in]interaction); </li></ul></ul><ul><ul><li>CRMService.SaveInteractionCase(); </li></ul></ul><ul><li>Better Example? </li></ul><ul><ul><li>stateless... </li></ul></ul><ul><ul><li>CRMService.CreateInteractionCase([in]cusomter, [out]caseID); </li></ul></ul><ul><ul><li>CRMService.AddCaseInteraction([in]caseID, [in]interaction); </li></ul></ul>
  76. 76. Consumability :: Strong Typed Parameters <ul><li>Concept </li></ul><ul><ul><li>Service operation parameters should be strongly typed. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Strongly typed parameter lists: </li></ul><ul><ul><li>Facilitate maintenance of semantic and design integrity over engineering change cycles. </li></ul></ul><ul><li>Weakly typed parameter lists: </li></ul><ul><ul><li>Facilitate semantic integrity degradation, design integrity decay, and subsequent comprehension issues for both service developers and service consumers. </li></ul></ul>+Example
  77. 77. Strong Typed Parameters Examples <ul><li>Also Consider... </li></ul><ul><ul><li>Should data types be versioned? </li></ul></ul><ul><ul><li>Should data types be canonical? </li></ul></ul><ul><li>Weak Typed Example... </li></ul><ul><li><schema … xmlns:xsd=…> </li></ul><ul><li><element name=“WeakAddress&quot;> </li></ul><ul><li><complexType> </li></ul><ul><li><sequence> </li></ul><ul><li><xsd:any/> </li></ul><ul><li></sequence> </li></ul><ul><li></complexType> </li></ul><ul><li></element> </li></ul><ul><li></schema> </li></ul><ul><li>Stronger Typed Example... </li></ul><ul><li><schema … xmlns:xsd=…> </li></ul><ul><li><element name=“StrongerAddress&quot;> </li></ul><ul><li><complexType> </li></ul><ul><li><sequence> </li></ul><ul><li><element name=“line1&quot; type=&quot;xsd:string&quot;/> </li></ul><ul><li><element name=“line2&quot; type=&quot;xsd:string&quot;/> </li></ul><ul><li><element name=“city&quot; type=&quot;xsd:string&quot;/> </li></ul><ul><li><element name=“state&quot; type=&quot;xsd:string&quot;/> </li></ul><ul><li><element name=“country&quot; type=&quot;xsd:string&quot;/> </li></ul><ul><li><element name=“postcode&quot; type=&quot;xsd:string&quot;/> </li></ul><ul><li></sequence> </li></ul><ul><li></complexType> </li></ul><ul><li></element> </li></ul><ul><li></schema> </li></ul>
  78. 78. Consumability :: Coarse Semantic Parameters <ul><li>Concept </li></ul><ul><ul><li>Service operation parameters should be coarse grained, and allied to the operation semantics 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Coarse gained parameter lists: </li></ul><ul><ul><li>Benefit consumability and comprehension with concise and semantic signatures. </li></ul></ul><ul><li>Small grained parameter lists: </li></ul><ul><ul><li>Burden consumability and comprehension with clumsy, verbose signatures, resulting in ugly formatted, difficult to read code. </li></ul></ul><ul><ul><li>[1] this translates to as coarse grained as possible whilst maintaining semantic integrity within the context of the service operation. </li></ul></ul>+Example
  79. 79. Coarse Semantic Parameters Examples <ul><li>Fine Grained Example... </li></ul><ul><ul><li>Customer.SetDetails( string id, string title, string firstName, string secondName, string surname, string address1, string address2, string city, string region, string country, string postCode, string email, string homePhone, string workPhone, string cellPhone); </li></ul></ul><ul><li>Coarse Grained Examples... </li></ul><ul><ul><li>Cusomter.SetDetails(cusomterDetailsType details); </li></ul></ul><ul><ul><li>Cusomter.SetContactDetails(cusomterContactDetailsType details); </li></ul></ul><ul><ul><li>Cusomter.SetAddressDetails(cusomterAddressDetailsType details); </li></ul></ul><ul><ul><li>Cusomter.SetIdentityDetails(cusomterIdentityDetailsType details); </li></ul></ul><ul><li>Also Consider... </li></ul><ul><ul><li>Should compound data types be versioned? </li></ul></ul><ul><ul><li>Should compound data types be canonical? </li></ul></ul>
  80. 80. Efficiency :: Concise Information Exchange <ul><li>Concept </li></ul><ul><ul><li>Services operations should only consume operation pertinent information. </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Concise exchange: </li></ul><ul><ul><li>Benefit performance and conserves network and server (service) capacity by exchanging only pertinent information between the service consumer and the service provider. </li></ul></ul><ul><li>Verbose exchange: </li></ul><ul><ul><li>Hinders performance (latency; unproductive time) and capacity through inefficient (unnecessary) use of network and CPU. </li></ul></ul>+Example
  81. 81. Concise Information Exchange Examples <ul><li>Verbose Examples... </li></ul><ul><ul><li>Customer.SetContactDetails( string id, string title, string firstName, string secondName, string surname, string address1, string address2, string city, string region, string country, string postCode, string email, string homePhone, string workPhone, string cellPhone); </li></ul></ul><ul><ul><li>Cusomter.SetContactDetails(cusomterDetailsType details); </li></ul></ul><ul><li>Concise Examples... </li></ul><ul><ul><li>Cusomter.SetContactDetails(cusomterContactDetailsType details); </li></ul></ul><ul><ul><li>Cusomter.SetHomePhoneNumber( string id, string phoneNumber); </li></ul></ul><ul><li>Also consider... </li></ul><ul><ul><li>The use of null or optional arguments; is this good practice? </li></ul></ul><ul><ul><li>The relationship between conciseness and coarseness of operations; what are the use cases? </li></ul></ul>
  82. 82. Versatility :: Deployment Location Agnostic <ul><li>Concept </li></ul><ul><ul><li>Service interfaces or implementations should not be dependent on any specific deployment location 1 . </li></ul></ul><ul><li>Consequences </li></ul><ul><li>Location agnostic services: </li></ul><ul><ul><li>Benefit adaptability by facilitating deployment topology options. </li></ul></ul><ul><li>Location specific services: </li></ul><ul><ul><li>Hinder adaptability by limiting (constraining) deployment topology options. </li></ul></ul><ul><ul><li>[1] deployment location independence and deployment location affinity are two different issues (possible vs. appropriate). </li></ul></ul>
  83. 83. Summary; (some) Aspects of Service Design Consideration <ul><li>Meta :: Consistent Design Decisions </li></ul><ul><li>Consumability :: Execution Environment Abstraction </li></ul><ul><li>Consumability :: Factored by Consumer </li></ul><ul><li>Consumability :: Domain Named Services </li></ul><ul><li>Consumability :: Implicit Usage Dynamic </li></ul><ul><li>Consumability :: High Cohesion </li></ul><ul><li>Consumability :: Semantic Operations </li></ul><ul><li>Consumability :: Coarse Semantic Parameters </li></ul><ul><li>Consumability :: Strong Typed Parameters </li></ul><ul><li>Consumability :: Consistent Abstraction </li></ul><ul><li>Adaptability :: Solution Abstraction </li></ul><ul><li>Adaptability :: Encapsulation </li></ul><ul><li>Adaptability :: Invocation Protocol Agnostic </li></ul><ul><li>Adaptability :: Factored Resource Dependencies </li></ul><ul><li>Adaptability :: Stateless Implementations </li></ul><ul><li>Versatility :: Technology Agnostic </li></ul><ul><li>Versatility :: Operational Isolation </li></ul><ul><li>Versatility :: Differentiate Services and Processes </li></ul><ul><li>Versatility :: Factor for Reuse </li></ul><ul><li>Versatility :: Call Sequence Independent </li></ul><ul><li>Versatility :: Timing Independent </li></ul><ul><li>Versatility :: Deployment Location Agnostic </li></ul><ul><li>Integrity :: Immutable Interfaces </li></ul><ul><li>Performance :: Efficient Resource Utilisation </li></ul><ul><li>Efficiency :: Concise Information Exchange </li></ul>
  84. 84. Reality; Holistic Equilibrium <ul><li>Context </li></ul><ul><ul><li>The design approach for each service, and each SOA of services, needs to select principles based on the design context. </li></ul></ul><ul><li>Balance </li></ul><ul><ul><li>The application of design principles requires balanced , weighted , design decisions. </li></ul></ul><ul><ul><li>You decide if , when , and how , to adopt them. </li></ul></ul><ul><li>It’s not easy! </li></ul>
  85. 85. Reuse, reuse, reuse… <ul><li>Plagiarism : </li></ul><ul><ul><li>Unacknowledged Research </li></ul></ul><ul><li>Many of the preceding definitions come from : </li></ul><ul><ul><li>http://www-106.ibm.com/developerworks/library/ws-soad1/ </li></ul></ul><ul><ul><li>Zimmerman, Kroqdal and Gee </li></ul></ul>Plagiarise, plagiarise, let no-one’s work evade your eyes. Tom Lehrer .

×