(Can SOA Give You Good Service) identifies some of the troubles with
words when dealing with all the Service terms.
I found it a very helpful article indeed because it helps keep Service and SOA on the straight and narrow. Nice call out of the Web Service vs Service.
Interesting observation that "A service is a logical representation of a repeatable business activity that has a specified outcome (e.g. check customer credit; provide weather data; consolidate drilling reports). It is self-contained, may be composed of other services, and is a "black box" to its consumers."
Nowhere in this definition is there any requirement to get an answer back, except
maybe a status of "yup, I've done that" or "No couldn't do it, sorry". For sure
a result could come back. For sure some system state may be changed (perhaps because
of a side effect), but the key is that it is a black box. Where we do see some confusion is in granularity. I occasionally here the word operation being applied to Services.
So in your example "Check Customer Credit" above, is that really a Service invocation
or is an invocation of an operation on another Service (perhaps a Customer Management service)?
Just dealing with the granularity would help me in understanding the kinds of numbers
that are bandied about at conferences. "We have over 3000 services" vs "We have
40 services (and 3000 operations). Is that simply a packaging issue? Coming back
to the whole WS-something discussion, you make a telling point that "A Web service
is a software system designed to support interoperable machine-to-machine interaction
over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards".
First up this says machine-to-machine. And while the computer at which a user is sitting, operating the browser is most definitely a machine, I am not convinced that WS-something is the most appropriate way of managing that interaction. It may be, but the point is not proven. Secondly, it is not completely clear to me when services actually need to be exposed (assuming that we have defined service correctly). So how much WSDL wrapping do I do? And why? In some ways - especially for internal code, WSDL wrapped service invocation is just really expensive function or subroutine calling. So even though we can define what a service is, it is harder to define what a service isn't, and harder still to choose the right architectural approach to allow for machine/machine interoperability, and human/system interoperability.