Principle #2Enforce the Separation of Management Concerns from Business Concerns in the Web Service Interface
When building a Web service, one of our first concerns is what business operation it must support, for example, order placement or quote requests. Let's call this the "business interface." We also need to think about the "management" or "operational" interface to the Web service, such as operations for figuring out its current state of health and whether or not it needs management intervention.
These two types of interfaces, business interface and management interface, should be separated. There may be a WSDL description of the business interface that is separate from that for the management interface, so that developers can clearly identify when they are using these different operations.
Separation benefits overall operations for the following reasons:
- Management operations need not be present in each WSDL-described business interface that the Web service supports, thus reducing both duplication and the opportunities for errors.
- When management and business operations are mixed it makes it difficult to compare Web service interfaces. Comparison might be needed to validate interface contents, or to match contents with the version of a Web service.
- Other client applications may see, and therefore attempt to use, the management operations that are visible if they are contained in the business interface. It may be desirable to set different restrictions on clients who can manage a service as opposed to those who can use it.
- Management operations may not be published in the same way as business operations. Many Web service interfaces are published in a registry, but management interfaces are typically thought of as private.
- When management and business methods are mixed, you cannot achieve separation of concerns in the security area. For security paradigms, it is often desirable to hide certain interfaces from clients.
It is also desirable that both business- and management-oriented interfaces should be exposed through WSDL and contacted through SOAP messaging. This maintains uniformity of the Web service programming environment and helps lower the overall cost of development of the Web services platform.
Such a "management-oriented" WSDL may well become a standard that applies to all robust Web services in the future, as the same management operations will apply to most Web services. Development teams should consider creating such a common management WSDL for integrating their separate efforts in Web services development, so as to be ready for that standard.