SOA Best Practices - Developing and Deploying a Service

Web services open the door to new integration opportunities and the quality of the interface they expose is very important. For example, changing an interface after it has been deployed can be a costly and messy task. So, it is very important to pay attention to reliability, quality and extensibility of the service. These are some of the points you can consider when designing and developing a service.

1. Operation and data contracts should be designed in such a way that if possible, you can extend them without affecting existing consumers of the service.

• If the existing contracts cannot be extended, consider developing a different service for new business requirements or new service clients. 
• It is very important to make sure that the service consumers are not blocked from using your service after modifying or adding new functionality to your service. This ensures the quality and reliability of your service. 

2. Design against an Interface not vice versa. Design the service interface first rather than building application logics and then expressing that functionality through an appropriate service interface.

• If you design interfaces first and know the purpose of those interfaces, it is easy to start writing business functionalities under it. This also ensures the consistency and reusability of service interface design. 

3. Implement validation logic to check all input based on value, range and type; and reject all invalid data. 

• If your service consumers call your service with invalid requests, your service may fail to respond or throw an exception inside your business logics and it may very difficult to debug the issue. 
• If you do not capture invalid inputs and notify the service consumers for the service failure, your service consumers may not know the reason why they did not get a valid response. 

4. Expose your WCF service both with basicHttpBinding and wsHttpBinding so that wide range of clients can consume it.

• Non .NET/legacy clients only able to consume your service using basicHttpBinding. 

5. Try to use request objects instead of passing multiple parameters.

• Having multiple parameters can make it hard to maintain your service and it is also hard for your service consumers to call your service. 

6. Returns an appropriate sized subset of the data rather than returning large amount of the data in one call.

• It can result in service timeout and also can frustrate the consumers of your service due to latency of the response. 

7. Use a meaningful, business specific name as the service name.

• Consumers of your service should be able to easily recognize your service based on its main business functionality. 
• Consistent naming convention helps service consumers to easily recognize your service. 
• A consistent set of services that cleanly establishes the level of clarity between the services enables easier interoperability and reuse. 

8. If possible, always publish the service to UDDI, so the service consumers can access the service by service name.

• If the consumers of your service are not calling your service using UDDI service name, your consumers may not able to access your service in case the host of your service or the name of your service is changed.