You want to build services that are reusable across projects and initiatives. That is the aspiration at least. How do you make sure that your services are reusable? Here is my top 10 list to achieve this goal:
- Make sure your services are interoperable across platforms. What do i mean by this? you don’t want platform specific data structures, parameters, header values, etc. in your service contract. You also want to use a tool like WSDL Analyzer to ensure that your interfaces are compliant with Web Services Interoperability guidelines.
- Minimize (if possible avoid) building services specific to a target consumer -whether it is a process, human, or an external application. When you build point solutions you are not building reusable ones!
- Decouple transport logic from services logic. You don’t want your service to be only available via HTTP. Most enterprises that need guaranteed delivery, scalability, and asynchronous processing will want your service to be accessible via a reliable messaging transport such as JMS. So don’t make your service tightly coupled with a transport
- Avoid naming schema elements after particular systems or technologies. Your element names and complex data types should be domain relevant and be descriptive. e.g. don’t use names such as MyEntity or customer001!
- Separate authentication from core services logic – you want to decouple the core services logic from how you authenticate the service request. This will give you the flexibility to support multiple authentication mechanisms (e.g. for a real time invocation the authentication might be a userid/encrypted password vs. a messaging invocation could be based on authentication set on a particular queue) or switch technologies altogether (e.g. change authentication from using LDAP tokens to X509 certificates).
- Encapsulate data object so they can use a separate schema: You don’t want to mix web method or service interface level elements with data object related elements. If you keep these separate, it will facilitate reuse of data objects across services (e.g. getCustomer and updateCustomer could both use a Customer data schema definition).
- Reuse data types across schema contracts – You should always be consistent with types within your domain and your organization across conracts. A customer name or gender cannot have one set of definitions in one schema and a different one in another schema. Reuse of complex data types will be tricky and you might be forced to use a custom definition on each instance but you can at least adopt this practice for simple data types.
- Design services to support multiple access patterns – This practice is essential for services that need to be accessed in both real-time and an event driven fashion. For instance, you have a getCustomer service capability that can be accessed on-demand as well as for publishing updates to customer data for a set of interested parties.
- Keep your service capabilities stateless – Avoid complex web of calls to manage state and keep your interface stateless. Sure it will make the interface bulkier but it is far easier to reuse a stateless service than a stateful one!
- Publish standard events from your business processes – Don’t build point to point integrations with downstream systems that need notifications from your business processes. Instead for each business process support a standard list of events you will publish. Any interested party can subscribe to the standard events and act accordingly to consume.
If you have additional practices and design techniques please contribute!