Jason Bloomberg’s recent post - Are Services Nouns or Verbs? - discusses whether services should represent verbs or nouns.
It's possible to design Services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?
Jason is using an example of a service approving a pending insurance policy in order to explain a difference between "noun" and "verb" type of services.
...following the OO approach, we might have an insurance policy object with several operations, including one that approves the policy, as the following pseudo code illustrates:myPolicy = new Policy (); ... successOrFailure = myPolicy.approve ();
... it is certainly possible to create a Policy Service as an Entity Service that has an approve operation that works more or less like the example above, with one fundamental difference: because Services are fundamentally stateless, you don't instantiate them. Here, then, is pseudo code that represents how an Entity Service would tackle the same functionality:request to create new policy, specifying create policy operation --> Policy Service --> response with policy number 12345
request to approve policy 12345, specifying approve policy operation --> Policy Service --> response with success or failure
Although this is a typical approach to services design, well-aligned with OO practices, Jason points out that there is:
...another way of offering the same functionality as the Entity Service above where the Services represent verbs rather than nouns, what we call Task Services. Here is the pseudo code for this situation:request to create new policy --> createNewPolicy Service --> response with policy number 12345
request to approve policy 12345 -- > approvePolicy Service --> response with success or failure
In this example, neither Task Service has any operations, but rather the functionality of each Service is understood from the context of the Service. After all, what would an approvePolicy Service do but approve policies?
In Jason’s opinion:
Both Entity and Task Services help architects connect the dots between legacy capabilities on the one hand, and flexible process requirements on the other... Entity Services... directly abstract underlying legacy capabilities... the Task Services, [represent] abstractions of individual operations belonging to underlying Entity Services. The... Process Services... are typically compositions of Task Services. In other words, Process Services are interfaces to SOBAs, and when those SOBAs are compositions of properly designed Task Services, they will exhibit process isomorphism.
Jason completes his post by stating:
As is usually the case, architects have several options at their disposal, and knowing which option is appropriate often depends on the business problem, an example of the "right tool for the job" principle. If the business problem is process-centric, say, a need to streamline or optimize the policy issuance process, then implementing SOBAs as compositions of Task Services will facilitate process flexibility. In other cases, the business problem is more information-centric than process-centric, for example, putting consolidated customer information on a call center rep's screen. In such instances the architect's focus may be on an Entity Service, because the rep is dealing with a particular customer and must be able to interact with that customer in a flexible way.
Although Jason tries to note (several times) the differences between SOA and OO in his post, the post itself is a testament of how much our OO experiences impact our SOA understanding. Let’s start from definitions. According to Wikipedia:
- Noun: a part of speech inflected for case, signifying a concrete or abstract entity.
- Verb: a part of speech without case inflection, but inflected for tense, person and number, signifying an activity or process performed or undergone.
Following Jason’s explanation that "Services are fundamentally stateless", they can’t represent an entity. In his example, a Policy service is not an entity service, but rather a collection of methods supporting operations (verbs) on any policy. This is similar to a stateless session bean (J2EE), which can hardly be called a noun. So, at the end of the day, Service is never a noun, its either a verb or a collection of verbs and the difference between what Jason calls Entity and Task services is the amount of methods that they are exposing.
