Web Services
-thoughts on service orientated architectures


Wednesday, June 04, 2003

Updated : Rules for Service Design  

Rules of Service Design


  1. Services are intended to be shared: The value of a service is magnified by the amount of sharing.

  2. Services have a clear purpose: If you cannot clearly explain what the value of the service is to a consumer of services then 1 will not matter much

  3. Services are loosely orchestrated and use other services whenever possible for common tasks: Services are intended to be loosely coupled and should use other services to perform common clearly defined tasks, e.g. authentication, reporting etc.

  4. Services are discoverable and support introspection: To share services the consumers of services need to be able to discover the existence of the service and divine its purpose.

  5. Services plug into a SOA: Once a service has been discovered it needs a framework that provides common services and loose coupling

  6. Services share and play with others well: Services should be well behaved

  7. Services have well defined interfaces and polices: There are two interfaces that are important for services, the technical interface and the business policy interface. The technical interface is typically WSDL, the policy interface is still not defined very well. The consumer and producer of a service both define policies around security, availability, reliability, and in more advanced cases how to handle errors and exception policies.

  8. Services accept well defined input and deliver well defined output: Need to recognize Sean McGrath for this one. Business services should consider themselves as a part of a data flow model.

  9. Services do not have hidden side affects: This is from Programming 101 but it is always worth mentioning. A service should not affect another service except through publicly defined interfaces.

  10. Services are interfaces to or from processes: Services practice implementation hiding. A service exposes and internal process either as the result of a process or the input to a process. When you design a service it is well worth considering how it could be used in another business process.



Thanks to Jeff Schneider for suggestions to improve numbers 3 and 7. This is a work in progress and I will keep updating it as I get more input and more experience with talking about it. It is also a little contrived to get to the number 10 but hey it works for Letterman.

Comments []

posted by John McDowall | 5:43 PM


links
archives