Cross posting my comment to Radovan
here:
Radovan: I am talking about *THE SAME ISSUES*
being dealt with on different levels. For the SAME REASONS that transparent
intermediaries exist at BOTH the Internet IP level, AND exist at the HTTP level
(think WebSSO, Akamai, and web load balancers), they WILL exist at the SOAP and
BUSINESS LEVEL.
Let me give you an example roughly based on a
composite of several client discussions I've recently had. Global bank needs to
comply with the illegal money laundering (ILM) provisions of the Patriot Act. So
it needs to match every "open account" message going over its global
network against a DB of "bad guys", because the ILM forbids banks from
doing business (offering bank accounts) with bad guys.
So, its plan is to transparently route all
"account open" messages past this new "bad guy matching
service" without having to touch any of the dozens of account management
services this bank has built around the globe. (To be more accurate, this bank
didn't build these account management apps, they acquired them via M&A.)
So here's a perfect example of a service provider
having its messages rerouted without its knowledge in order to add new
functionality to the overall system without having to make changes to the
provider. This is exactly how a Web Services Network should be designed.
Does this reduce the autonomy of the account
management "service providers"? You bet. They no longer unilaterally
decide who can open an account, because this matching intermediary now imposes
its decisions on them. Big deal.
As for your FedEx/DHL example, the way this
should work at a business document level is that I, as the provider, should
indicate that a business report must be delivered to the recipient the next day.
(Note that I have the authority, ie autonomy, to make this timing decision.) I
put the document in my outbox on my desk with a routing slip attached and my
corporation's mail room decides what overnight carrier we use for which
destinations, given the discounting deals we've arranged.
Does this reduce my absolute autonomy? You bet.
I've lost the precious right to decide which overnight delivery service I
prefer. Big deal.
As for your blog "service" example,
check out Feedburner . This
intermediate service is exactly the kind of ["intelligence" in the Web
Services Network] I am talking about. Rather than having my blog rss feed
provider have to know all the different feed formats or having the ability to
track feed pings, etc., I let this rss feed service intermediary, feedburner, do
it for me. I tell feedburner my simple rss feed address for my blog, I put
feedburner's rss feed icons on my blog home page and suddenly, every new rss
subscriber is getting MY rss feed VIA feedburner. What I get (and what I really
want that Radio Userland does not supply) is the ability to see who's reading my
blog via rss. Pretty slick. This is exactly the kind of management in the middle
you seem to be arguing against. Why?
Does this reduce the autonomy of my blog service?
You bet. Now its dependent on feedburner being up and running. Big deal.
The autonomy of web service providers with regard
to the web services network will be more like the "relative autonomy"
of state governments with regard to the US federal government, not the
"absolute autonomy" of a sovereign nation (which these days isn't
really so sovereign itself, what with UN, WTO, etc.). Some decision making
rights will be in the hands of the service providers (the states) and some
decision rights will in the hands of the "network" (the federation).
The network is the federation. Autonomy will be federated autonomy. That's why
I've been writing about SOA as a federated architecture for the past several
years. (For publicly available material see http://radio.weblogs.com/0126951/2004/02/18.html#a98
and http://techupdate.zdnet.com/techupdate/stories/main/Service_Oriented_Architecture_Enables_Global_ITO_print.html
and http://www3.ca.com/Files/IndustryAnalystReports/SOA.pdf)
Autonomy and interdependency (or conformity) are
very relative and very intertwined concepts. This subtle interplay has been
endlessly discussed in various fields from philosophy to economics to sociology
to physics (see the book "Six Degrees"). In sociology, this discussion
goes under the title "Structure and Agency" (See http://en.wikipedia.org/wiki/Structure_and_agency
and http://human.ntu.ac.uk/pgcert/structureandagency.html).
In the IT realm, the structure/agency discussion
often goes under the title "network vs. endpoint" or "network vs.
edge". Given how subtle the thinking and passionate the debate has been in
other disciplines over the duality of structure and agency, I expect no less in
SOA discussions. But lets at least learn something from these prior debates in
these other disciplines and quickly move beyond the shallow debate of absolute
autonomy vs. its absolute interdependency, into a deeper discussion of what
aspects of autonomy should a service provider have and not have under what
circumstances. Or even better, how I can dynamically shift responsibility from
the edge into the network and back again based on various collaborative policy
decisions.
6:16:44 AM 
