I've been doing some hunting to follow up on my previous posting regarding web service naming conventions and standards. The pickings are slim. Thomas Erl, a Canadian SOA expert and author, mentions some SOA naming conventions in an article he wrote for Oracle entitled Standardizing Service Endpoints.
He prescribes a practical approach, naming services based on the utility (verb), entity (noun) or task/function (verb-noun -- do something to something), dependant on the scope and context of the service. He also warns about ensuring that operations within the service reflect appropriately the scope of the service, and to eliminate redundancy in operation names.
From the article:
- The utility-centric context is found in application services involving operations that encapsulate cross-cutting functions, such as event logging, exception handling, or notification. These reusable services need to be labeled according to a specific processing context, agnostic in terms of any particular solution environment. For example, a utility service might be named Notify.
- An entity-centric context is established in a business service that represents a specific business entity, such as an invoice or a purchase order. The labeling of entity-centric business services is often predetermined by the entity name. For example, a service may simply be named Invoice or Customer.
- Task-centric contexts are required for services modeled to encapsulate process logic. In this case, the thread that ties together the grouped operations is a specific activity being automated by the service logic. Therefore, the use of verbs in service names is common. For example, a task-centric service may be called GetProfile or ProfileRetrieval, if that accurately represents the task's scope.
As with service names, labeling individual service operations is also a process that should be subject to standards and guidelines and for which there are already several best practices.
For example, the naming of the service itself ought to influence how the individual operations are labeled. Because a good service name will already clearly establish a meaning and a context, operation names should be streamlined to avoid the use of redundant wording. Take an operation that retrieves invoice history data for a service named Invoice. This operation does not need to be labeled GetInvoiceHistory, because the invoice context is already established by the service name. GetHistory would be sufficient.
Thomas really helped us move forward with our SOA initiative at CISTI both with a workshop to bootstrap our process, and through his books
Comments