On 11/27/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > On Nov 27, 2006, at 10:32 AM, Paul Fremantle wrote: > > > On 11/26/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > > I claim it's wrong to invent a new > > > and different application interface in each and every > > application :-) > >
> I never claimed that you don't have to any design work when you use > REST. You don't have to design a new interface with custom > operations. You have to decide on your URIs, data formats, > schemas ... having one part fixed doesn't mean you don't have to care > about the REST. What you say is true. I just think that what you wrote earlier made it sound like more was done for you than is the truth. > You can use XML Schema with REST ... Sure you *can* use Schema, but unfortunately there is no uniform place to put it, no uniform REST API to retrieve it (oh - except in WS implementations like Axis2 :-) ), and no standard for whether the schema applies to posted messages or response messages. > ... given an XML Schema you can use all the data binding tools you > want. A GET on a customer URI that returns a representation that > conforms to that schema is just as easy to process (at least!) as a > GetCustomerData operation. Of course. > If you give me a WSDL, I still to have to either guess at the > semantics, or understand them from some textual description. The same > is true for a RESTful interface. Yes, sure that's true. But of course, because there is no machine readable standard for associating schemas with REST APIs (other than the POX binding in WSDL 2.0) there is much more work to be done by the human author and more possibility of mistake. > > As far as I'm concerned, the *whole* point of SOA over and above > > previous integration systems, is that there is clear metadata about > > the message formats as well as interaction patterns. I notice you didn't respond to this. > > After all, > > MQSeries and JMS also define clearly uniform methods (PUT, GET, > > PUBLISH, SUBSCRIBE) as well. > > > MQ and JMS also define concepts such as queues and topics, so I agree > - they are conceptually similar. But similar to REST, not similar to > CORBA or RMI :-) Of course WSDL defines uniform interfaces too. It has the concept of in, out, fault messages, endpoints, message exchange patterns, and schemas for types. In fact there is just as much uniformity with WSDL as there is with MQ. I think that if you are comparing SOAP with CORBA and RMI then you have a very outdated and mistaken view of SOAP. There are significant differences that make SOAP much more like MQ and JMS, as well as REST. In particular: * SOAP and WSDL inherently support asynchrony. * Ever since WS-I banned SOAP encoding, SOAP is very much document and not object based. * SOAP is based on duck-typing (http://en.wikipedia.org/wiki/Duck_typing), whereas CORBA and RMI are very tightly tied to specific instances of classes which means that they are much more fragile than duck-typed, document-based systems. Most SOAP tools give an object-broker like model to developers, because, wait for it, that is what developers want. The original Axis2 design was fundamentally about giving a very XML-message based view of the world - which is incredibly similar to JMS, MQ, and the XML binding + HTTP GET/POST that you are advocating. The effort to add stubs, skeletons and automatic databinding has been completely driven by user demand. The key benefit of the Axis2 design is that it has a clear demarcation between the stubs and skeletons and the underlying messaging infrastructure - which is completely based on a simple message exchange pattern. So maybe the problem we're having here is that you are stuck in the old (and wrong) view of SOAP, which was driven by a lot of ex-CORBA developers! > No, at least from my perspective we're having a very balanced and > unemotional discussion here :-) :-) Glad to hear it! -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
