RE: lots of WS reading material
From: Paul Prescod [mailto:paul@p...] >100 people can run in the wrong way and I still won't follow them. I'm not asking you to. I'm saying, it ain't just MS running in that direction. So flaming in their direction just wastes coal. >I think it is incorrect to say that SOAP is an architecture. SOAP is a >syntax that can be adapted to a variety of architectures. That's an interesting point. XML is a syntax too. That seems to be a successful place to start. >The interoperable variant of SOAP uses an RPC architecture and even most >backers of SOAP agree that this is not where it will end up. They >haven't articulated where it will end up but they are clear that it is >not RPC. Ok. So if the RPC is an interim step, then articulating the next one would be the most useful way to steer the debate. I think that is what you and Tim et al are doing. Dave, what would be the next step for SOAP? Still, if SOAP RPC is on the auction block, why is so much attention being paid to it? Because it is a familiar way to program and efficient. It allows a lot of local control at the expense of making those controls understandable to interested qualified observers (cost of API maintenance and publishing). The Internet has room for it and it may just be an evolutionary dead end. That's life in the ecotones; hot and fast change. On the other hand, is the issue that it might thrive like kudzu and choke out better crops? (For those who never visited the American south: kudzu was not native here. It was brought in to control soil erosion. Then it thrived and took over any ground not otherwise plowed seasonally. The same bright types put alligators in the wildlife refuges locally to keep the beaver population down because they kept building dams across waterways. Now fishermen carry rifles when they fish. And so it goes. Ecosystem management is dirty business if the results obtained have side effects.) >Nevertheless, I have trouble understanding how your article relates to >any of the following documents: a) my original Google article, b) Dave's >rebuttal, c) my counter. That isn't my point. My point is that these two approaches can exist side by side and it is the buyer that must beware. Otherwise, much fury here and not much progress except where the technical points are being illuminated. That you are doing brilliantly. >If you've reviewed all three articles do you agree or disagree that 1) >there are substantive technical issues raised 2) Google could have >chosen a better technology for their API and 3) they should now correct >their mistake by *at the least* adding a URI-based mechanism for >retrieving query results? Google has provided a useful testbed to the SOAP implementors. I think one should let them explore it and then find out for themselves how substantial the technical issues are. As you have said, the URI based mechanisms are ubiquitous so no one has to look far to find a test case for that. len
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