[
Lists Home |
Date Index |
Thread Index
]
> From: Mark Baker [mailto:distobj@acm.org]
<snip/>
> You draw the line where you require agreement on "intent" that is not
> an intent defined by the application protocol.
This is completely meaningless. You are insisting there are no such things
are a protocol except that at the transport layer. That is patently
ridiculous. The whole SOAP model is based on protocol layers. When there is
a standard way of representing authentication and authorization info in a
SOAP header, that will be part of a protocol. There is no reason why you
cannot layer protocol upon protocol and let the higher level protocols
remain blissfully ignorant of the lower level protocols. Insisting that
these higher level protocols cannot be true protocols is really a rather
narrow and needlessly constraining notion.
> You can buy CDs with an HTML form using HTTP POST without the word
> "purchase" or "buy" needing to be part of the message. In other
> words, POST suffices as an intent for that operation. Why do you
> think that is?
Again, meaningless. POST does *not* suffice for that operation. If I use
such a form, I am not interested in POSTing data to a server. I am
interested in buying something. And there better be something on that form
that tells me what it is going to do. Whether it is the word "purchase" or
"buy" is secondary, as long as there is something there I can understand.
And by the way, that form probably does not just have one action verb
associated with it. It will have one or more "buy this item" actions, a "use
this credit card" action, and a "ship to this address" action, among others.
Just because the HTTP server thinks that all that is going on is a POST
action, doesn't mean that there aren't very relevant actions happening,
here, at a higher layer. Surely, this is not a difficult concept to
understand. I don't believe in a glass ceiling for protocol layers. You can
keep piling them on until you get to a rich enough model to solve the
problem at hand.
We have numerous installations of our software that are interacting with CRM
and ERP systems across the web, engaging in collaborative workflows,
synchronizing information across systems without exposing internal
implementation details or data models. We have users using portals that
redirect the user to various sites on the net, doing single sign-on in the
process, maintaining the same look-and-feel so that the user is left with
the illusion that they are working within the same application. And while
working in the application, actions they undertake kick off workflows that
involve interactions between services behind the scenes.
We've been doing this for a few years, now. And I have to say, that although
most of our implementations are not using the latest and greatest (typically
just XML 1.0, no namespaces, no SOAP), they are doing things far more
sophisticated than many of the visions for web services I hear expressed can
support. The model you propose could not possibly support the sorts of use
cases that we are routinely supporting for our customers.
I don't agree with your artificial conceptual boundaries as to what can be
protocol and what can be data. But for the sake of argument, I'll allow that
you are right. If you are, then I will say we will continue to mix protocol
and data, because doing so is allowing us to address business requirements
with robust, efficient, and easy to implement solutions. Your model cannot
support our requirements, so it is useless to us. And if web services
protocols cannot support the sort of rich messaging that we routinely
employ, then these protocols will fail.
It is not up to the problems to adapt to some idealized theoretical notion
of the right solution. It is for the solution to prove that it can solve the
real world problems. If it cannot, it is not the problems that are wrong.
|
