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
.