Recently I talked to Technical Architects from several international organisations (from the US and Europe), and have found that despite massive efforts of SOA experts, implementation and delivery teams still 'witched' by the word 'Service' in the Web Service technology name. I do not attribute this statement to REST because it does not pretend to be any other type of services than a resource access/reference representation one.
In the one of the cases, we discussed 9 business services. It appeared that 8 out of 9 'services' were just 'getSomething' entities. That is, in essence, they were remote extensions of the database driver. The argument that was given to me in defence of such "servicesation" was that many applications needed those Somethings and it was very convenient to put a Web Service interface on the object that retrieved the data from the database.
Certainly, it is very convenient and, probably, the right thing to do (unless this design does not create a data access bottleneck) but why it becomes a business service? What 'business' is in it? I resist calling every piece of code that operates with business data (vs. configuration and alike data) a business service even if a business person uses related application. Here is an example of confusion coming from misuse of term 'business service'. Assume, we have a security configuration service that allows on-boarding users into an Entitlement System and assigning them access rights; this service has a Web-based UI. A manager of a business operational team uses this service on a daily basis to manage access of his/her staff to different documents depending on the phase of operational process. If we follow the logic of the authors of mentioned 9 'business services', this security configuration service is a business service. Now tell me what this service is if it is used by a security administrator in the IT Operation Support team? I expect an answer like 'It is the technical utility service'... Welcome to the club!
I hope that the authority of Architect in Technology finally cleans out the terminology glitches and puts things into logical order. That is, when a diagram draws a layer of business services, there are business services in the layer and not RPC-like API (even operating with XML documents).
I agree, the example you gave isn't a business service. It doesn't function as part of any business process or is unlikey to be reused by another department or consumer.
This maybe used in a manage employee process that allows you to call different services to manage an employees details but again this doesn't make it a business service.
I think the problem with services-orientation is that many people have their own opinion about what it is. Hopefully once it matures, a common understanding upon will emerge.
Thank you, Clive, I have the same hope...