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 v
 > From: Mark Baker [mailto:distobj@a...] <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. 
|
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
|
|||||||||
