Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Categories of Web Service messages: data-oriented vs act
 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> 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
