Some thoughts on Service Naming
Every web service Designer and Developer possibly have come across service naming standards or best practices in one form or the other. While I do not want to dispute the fact that standards are needed for enforcing good practices that goes a long way in software maintainability and manageability, but then trying to follow a standard without completely understanding the philosophy behind it may not produce optimal results. Now, I do not want to get into pros and cons of particular semantics of service naming either, e.g., naming conventions such as using a verb+noun pair for naming a service, using camel case etc. I will pretty much follow those widely used conventions without a debate. I will rather try to throw some lights on the common-sense and practical factors that may make service naming less creative and more predictable. Comments and debates welcome.
So thinking with a clean slate – here are some thoughts. IMHO, a good service name should have the following classic attributes (I would not blame you for thinking that I was influenced by OO programming principles in more than one ways):
Service Naming is part of Service Design. Hence one should understand the complete context, functionality and the Layer of abstraction that the service belongs to in a Service Oriented Architecture. Is it a top-level business orchestration service? Or, is it a much lower level service? Or is it a technical service across business domains? After identifying the Layer a service belongs to, it is easy to
- Predict its usage scope
- Identify its potential consumers
And hence the naming can consider making it contextual to the consumers. After all, service discovery is not too far.
Service Name should attempt to portray the functionality of a service in the light of the overall business process context. So one needs to answer questions like what business logic does the service provide? What business processes does it support? If the service name fails to give you flavor of the business context (or, technical context if it is a technical service) then something is missing. Essentially you should use a verb to represent the actual business task carried out by the service with as much context as possible. Additional context may come from using an appropriate Entity name in the service. Let me site a couple of examples; I would prefer a name that provides more contexts. Lets take the example of service provisioning process for a hypothetical teleco. Let us say a service is used by the process to establish is the customer address is serviceable. This process of customer address validation along with few other steps is generally known as service qualification. Hence QualifyServiceAddress is a better name for our service than something like ValidateAddress because it is contextual to business and has describes the service more accurately.
The other important thing is to use only standard entity names in your Service Name. When I say standard entity names, I assume that an organization-wide data model/information model/business information model already exists. So re-use the same vocabulary and adhere to your organizational standards.
Now as a disclaimer, I think no amount of standard is sufficient to ensure good naming. In many cases just following the semantics, without understanding the principles, beats the whole purpose of naming standards. Let me site some hypothetical examples; you might have come across situations where a new service is being designed to expose or replace a legacy application. The name of the service many a times would be influenced by the application names or process names of the legacy application even when the service interface may exposes a miniscule part of the application. In this case, the service name largely misrepresents its functionality offered. Or, how about a very long verbose service name that attempts to specify the entire business context in its name and does very little. The examples can go on.
