[
Lists Home |
Date Index |
Thread Index
]
Hi Paul,
Paul said:
> Didier, if the variables are not standardized then a client that talks
> to 500 services must code a 500 "template documents". Do you agree or
> disagree?
>
> Therefore the cost of integration of clients and servers scales linearly
> with the number of services. Either this is an acceptable situation or
> it is not. If it is not then you need complete standardization -- you
> must standardize the variable names.
Didier replies:
Yes I agree, due to a lack of standardization you'll probably have to create
as many queries as the number of services you want to connect to. My
solution can only reduce the provider's costs not the client costs. The
client's costs are reduced only when the interface (parameter list, query
or whatever) is standardized. For instance, if all search engines normalize
on RDF or topic maps then they have reduced the access cost, if each one
provide their own SOAP interface or their own URL's parameter list then the
client's adaptation cost are still high.
Paul said:
> That is the case *anyway*. You admit that every client needs to conform
> to the distinct variable names created by each different server vendor.
> In other words: "my way or the highway." There are only two options: "my
> way or the highway" or _complete_ standardization so that "my way" and
> "your way" always align. Standardizing merely the templating format
> still forces the client to conform to the whims of the server: "oops, we
> decided to change a placeholder name today" AND breaks easy addressing
> AND moves compuational effort from the client to the server.
>
Didier replies:
You're right the only best solution that could resolve this "prisoners
dilemma" is some cooperation between the provider and the client and
therefore to standardize the interface and the returned format. However, the
current trend between both the client and the providers is a state of
"non-cooperation" between them. SOAP just re-enforce this issue and URL with
param list cannot help too unless, all the providers in the same service
class agree on a certain interface. But again, the competition dynamics and
Michael Porter five forces are still ruling the marketplace. The vendor
still want to play a game of creating barriers of switching to an other
alternative service and resist giving up control to the clients by being
reduced to a commodity through a single interchangeable interface.
Conclusion: REST or SOAP do not resolve the issue. The issue is resolved
only if all the providers of a service class support the same interface, it
be SOAP or REST based. The main point is not the architectural structure per
se but the interface defined and the data returned, both have to be
standardized to resolve the "prisoners dilemma". I guess that this is the
real issue here. If Google and the other agree on the same interface (i.e.
request and returned data) then whatever they use REST or SOAP as the
underlying architecture we win, otherwise, we (i.e. the clients) loose.
This has been an interesting journey Paul, sometimes we get caught in the
technical aspects and forget that without a win-win contract, in a zero sum
game someone is a winner and someone else is a looser. What made the web a
win-win solution was the fact that, for a moment, everybody (the providers
and the clients) agreed on two basic technologies HTML + HTTP. If there is
anything that we should lobby for is a common interface whatever it is based
on SOAP or REST.
cheers
Didier PH Martin
|
