This article
(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.
Posts
2 comments:
Chris,
these observations are at the heart of some of the problems I have with SOA as usually described.
First of all, as a general rule, one record keeping system (that is, something that deals with ACID local transactions) must never call another system to complete a transaciton. There are many reasons for this, but primarily scaling and reliability. A deeper reason is transaction control and an even deeper one is span of semantics. Essentially, you do ACID locally and BASE across the domain.
Given this rule, we can distinguish services to people from services to record keeping (RK) systems. People services are always synchronous, RK services are always asynchronous. People services can be read-only requests or change requests, RK services are only ever for changes.
The point here is that a service between RK systems is always a business event. Unfortunately, the integration APIs that are exposed by RK systems are never business events, they are technical events at best. This is why our business customers often find it hard to understand the business systems we give them.
Once you eliminate the read-only services from your panoply of services and aggregate the technical events into proper business events, your universe of events should start to shrink significantly. Typically, I have found that a user interaction has five read only requests for each change request.
In addition, we need to recognise that the same business event can have multiple instantiations. We did the integration architecture for an SAP install at a bank and SAP had analysed 120 one-way interfaces to other systems. We did an endpoint analysis of these interfaces and there were only 30 business events at the SAP end. So they were planning to implement each business event four times. The worst I saw was an accounts receivable system at a credit card company that had 120 interfaces and only 12 different business events.
John
It has taken me a while. Your points about business events vs interfaces is a good one, John. Although at some level, the same business event can be processed by lots of downstream business "processes" my guess is that this is often NOT the reason.
It is amazing what happens when you classify interfaces according to the business events that they represent. It suddenly points up massive redundancy.
I have reopened Tony Hoare's work on Communicating sequential Processes - because it would be useful to have event handlers that actually behaved according to some sensible formalisms.
Post a Comment