English | EN At your service…
Nov 6, 2014
I was talking with some developers about overloaded terminology – like innovation, iteration, and agile – and the word “services” came up. Services means different things based on the context of the conversation, it could be an abstract term for some things that needs to provide some data or processing. It could also mean a technology choice, like a web service. A conversation about services with developers and business folks can get confusing since the concepts are much the same when developing a technical or a business service.
The technology of services has been around for a while, and the design pattern is relatively well known. But, I have found that many developers and architects have forgotten that to gain the benefits of a service, they must design the service in a specific way. Often, you find code that implements some framework, like Representational State Transfer (REST) or Web Services Description Language (WSDL), but the design and implementation is just a tightly coupled, single use remote procedure call (RPC).
So, as a public service, here’s a refresher of some service design principles. Keep these items in mind the next time you design or build a service, technical or otherwise:
- Contract first – Determine how the service will provide and how other services can communicate with it. Sometimes a domain-specific language can be helpful in defining the interface, like a modeling language such as Business Process Execution Language (BPEL).
- Loosely coupled/minimize dependencies – the service should stand on its own and not have a dependency on any other application or service. This principle can be implemented by making sure the service exists for one purpose. The service can interact with other services, but can still provide its purpose without any help.
- Reusability – Some services are what I call “chunky” – they are very large interfaces and returns, and look like a ‘Select *’ query from a huge table. Reusability is not just “everything and the kitchen sink”. It means that many intra- and inter-domain will gain benefit from the service.
- Stateless – The service should be able to finish its work and signal when done. The service should not have to keep track of time or state. That’s not to say that a service can’t be asynchronous … but let some other framework or platform service worry about state and let the service provide its function.
- Discoverable – Within organizations, developers will email interface and functionality notes to others to allow them to use the service. Well, that doesn’t work outside the organization’s walls. Use Universal Description, Discovery Integration (UDDI) to allow others to find the service’s interface and purpose “on-the-fly”.
About the author
