[
Lists Home |
Date Index |
Thread Index
]
True. That would be orchestration or choreography,
yet another set of overlapping terms meant to extend
concepts that are ambiguous to begin with.
Turtles all, but hey, this is the web.
However, you are closer to definition three and that is
the one that stands apart because it does concern itself
with sharable business processes rather than the implementation
in the code. It is fun to watch terms start in business
or sales work their way into the code vocabularies and
vice versa. I think that is part of how product evolution
works (chaos or uncertainty as an engine). It also provides
moments of great comedy. I was in training for an internal
system the other day where one of the selections in a
choice list was "Not in The Vision". It was considered
more polite than "No" or "Declined" or the former
"Ain't Gonna Happen". I await with delightful anticipation
the reactions of customers who see that.
The biggest flaw in the thinking of analysts is the assumption
that what they see or hear as policy has a basis in rationality
in all cases. When accepting business processes as sharable,
that is a very dangerous assumption, so sharing services is
inherently less dangerous than sharing processes. On the other
hand, in a system built up over outsourced components, services
and processes, the legal principles are such that he who offers
the process assumes the duty and then, the opaqueness of the
service makes it difficult to manage the risk. It will be
interesting to see the outcome of negligence torts based on
*respondeat superior* where the system is SOA-conforming.
Robin says: "I was more worried about "discrete services" invoked from a
"provider" in order to perform a "certain task"."
That is actually the problem in a nutshell.
len
-----Original Message-----
From: W. E. Perry [mailto:wperry@fiduciary.com]
... SOA is most emphatically not about the design of the processes
themselves:
|
