OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Categories of Web Service messages: data-oriented vs act

[ 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.


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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS