On 11/12/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > > 1. One reads the human readable documentation from web page about > > the > > > semantics of the data & operations in the service > > > > So the people in the US, India, UK and Kazakstan all make different > > assumptions about what that actually means.... > > Sure. Though, in Khazakstan, they'll shoot a dog and through a party > first. ;-) [sorry borat on the brain] > > > > 2. One downloads the schemas off a link from that documentation, > > and > > > notes the URIs for accessing documents and/or to processing > > documents. > > > > Manual step v automatic. > > How is this automated? In SOAP/WS, One has to know where to get the > WSDL. Or the UDDI server to get the WSDL. And one has to (typically) > generate proxies & data bindings out of that. That's typically done > via an IDE (i.e. a tool-assisted manual step).
Which is a good thing IMO. > > I've worked with both kinds of toolsets (HTTP+XML and SOAP/WS) and I > don't see a material difference, except that WSDL generates an RPC > style interface typically... Which is easier for the 80%+ of developer out there. > > > > 3. One uses an HTTP stack to access the URIs. > > > > Manual step v automatic > > Again, I'm completely at a loss as to how this is any more manual than > invoking an operation on a SOAP web service. In one I'm coding in Java/C# to make the call on another object (automatic) and its parsing all the XML for me (automatic), in the other I'm calling a port (manual) and doing the XML work myself (manual). Now for some developers the later could be quicker, but for the majority the former will be much simpler. > > > > > > > 4. All returned documents are hypermedia -- i.e. have potentially > > > dereferencable URIs baked into them. > > > > Manual step v automatic (WS-*.... use BPEL). > > Not in practice. WS-BPEL 2.0 isn't even an approved standard yet. Fair enough, but we are using WS-BPEL in its 1.1 incarnations on several projects already. > > And there isn't, nor will there be, any implementation of BPEL, in my > experience, that "just works" without requiring significant manual > intervention to bind it to your specific runtime environment (whether > WSIF, JBI, SCA, etc.) They are improving, but its certainly a task for the "few" rather than the many to get it all working right. > > I have many other thoughts on why BPEL is stillborn, but this isn't the > thread for that ;-) > > > > 5. Accessing further information in the system is accomplished via > > HTTP > > > operations on the URIs retrieved from prior representations - it > > > doesn't require specialized knowledge of a custom identifier > > system or > > > set of operations on those identifiers. > > > > It does require specialised knowledge of the specific custom > > identifiers created for that project > > Not if they are URIs (unless one is using generative URIs). Don't lets get started on opaque v sensible URIs, and I'll go for the later everytime, even if that isn't "pure" REST. > > > > 1. If one moves a resource location, there's a built-in redirect > > in > > > the transfer protocol. > > > > Same as SOAP over HTTP, or indeed SOAP over JMS > > The endpoint, yes. A specific resource? Not likely. Why not? For SOAP/WSDL access is via the end point not to the specific resource, so moving resource location should be simple config. > > > > 2. If a human wants a human-readable view of the information, > > they > > > possibly can use a browser to access the same URIs (and get HTML > > > instead of XML or whatnot, via content negotiation). > > > > Similar to WSDL and a tool which can covert it to a graphic > > representation that is very easy to use. > > > > Things that suggest people read XML documents are not IMO very good, > > XML is butt ugly and not something I'd like people to have to trawl > > through, particularly if using industry standard schemas. > > I was suggesting they read something useful, like HTML. Not XML (that > would be for an automated agent). I'd argue that pictures are better than HTML, but you could of course use SVG to generate that. So we are agreed its even then? > > > > 3. If new media types emerge to communicate the same semantics, > > one > > > can specify & agree upon them without re-specifying the > > identifiers or > > > operations. (via content negotiation) > > > > How do you do that? An example would help me here. > > In HTTP, one can provide an in-order list of preferred MIME media types > via the Accept: header. > > This assumes the server can support multiple media types for a given > resource, but it enables independent evolution of clients to > newer/preferred media types. So how does this help me accept invoice at first and then invoice-summary and financial statements? > > > > 4. New participants can arrive without requiring change control > > on the > > > other participants (since all information is referenced via URI). > > > > Same as WSDL/SOAP, I can add loads of consumers of a service without > > impacting anyone, and a new producer can be added without impacting > > anyone either... > > Fair enough. I was referring to new participants providing specific > resources instead of a new participant that has to support the entire > WSDL interface. Ah right, yup that is a bit harder in SOAP. To be honest I'd put resource stuff behind the SOAP interface so new resources would be added behind that one interface. > > Cheers > Stu > > __________________________________________________________ > Have a burning question? > Go to www.Answers.yahoo.com and get answers from real people who know. >
