[
Lists Home |
Date Index |
Thread Index
]
Len Bullard wrote:
>> Still mystified by this thread.
Roger replies:
>Len, I always greatly appreciate your informative, philosophical, and
>humorous comments.
Thanks. I can sing too. I can't dance. :-)
>Yes, this is an attempt to influence how web services will be designed
>and the nature of XML messages.
Then we should be careful here. Best practices aren't forced.
They evolve from existing practice, IMHO.
So far your best practices pages have high quality and are very valuable.
I'm not trying to get you to stop doing that, but sometimes we on XML-Dev
get wrapped around our philosophies and works. The "negotiate out the
noise" thread was quickly shanghaied into a promotion of RDDL and almost
never touched other solutions. If we called that a best practice, we'd
be fooling ourselves and possibly others. It may be a best technique,
but it isn't well-practiced.
>I am very concerned that people will
>use web services simply as another way to do tightly coupled RPC, i.e.,
>procedure name plus parameters. I think that XML-based web services
>should provide a new paradigm, where the focus is on the data and
>business processes.
I agree but am not concerned. The kinds of things Amy said she
wanted to do seem questionable to me from the standpoint that over time,
I've come to realize that the phrase "The Network IS the Computer" is
wrong. It is a network of computers, routers, languages, databases,
people, people, and more people. Web services have to account
for that, not just RPC at the fine grain of adding integers. There
are edge cases, but are best practices defined for the edge cases
other than to suggest where the edge might be?
>I think that this involves a rather large mental
>shift, from this mentality:
>- call this routine with these parameters, get these results back,
>to this mentality:
>- here's business data, let me find one or more services that can
>operate on the data.
I think we agree. See UDDI. Some have made that shift and a lot of
their thinking is summarized by Adam Bosworth's papers on coarse
transactions. Others made that shift back in the CALS era when
it was observed that use of SGML would enable processing of business
documents as long as the type of the document did not mandate the
processes to be applied. Straightforward but the web infrastructure
was required to make that a reality on the network instead of on
9-track tapes.
One should have an expectation as to what will be returned, but that
can vary by node to which sent or the service offered. It is
important to understand the complexity of handling broadcast requests.
In human systems, the contents of the document indicate the allowable ranges of
responses. Discovery is complicated by the possibility that the
owner of the portal to the service is not the owner of the service
itself. One may not care, but middlemen can add cost. Yet these different
kinds of information are packaged in the same document. That part
doesn't matter if the port to which the data is sent only expects
certain kinds of documents and can tell if it gets one of these
either by the type (eg, MIME, extension, etc) or opens it and
reads the DOCTYPE or trusts the root to tell it (if there is one;
it won't work if the language doesn't have a root; it might have
another kind of data item, see #VRML utf8. Or it can just parse
and throw an exception. That would be miserable though if one
is trying to operate blindly. In short, it is better to know
before one sends the document that one is sending RFP to the
proposal staff instead of the janitorial staff. The Port Knows.
>I am looking/searching for a paradigm which will FORCE developers to
>make that mental shift. I have a gut feeling that requiring the
>separation of the data from the action will be such a driving force.
Force humans? Or force the computers? I see your point but I think
they are there already. That is why I believe it prudent to review
the extant practices before we work on the best practices. Are you
trying to subdivide below the level of the document?
>Now back to the issue at hand .. I take it from your comments that you
>question the role of multiple actions? /Roger
No. I question the neccesity of specifying that in the message
if a single action implicitly says all that must be said to
enable a predictable response. The two things I would want
would be a way to specify the gesture/action: Request for RFP
and a way to indicate the document types I expect to be returned.
On the other hand, if I can discover a description of a service
that tells me these things, I just send to that port.
len
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
