It seems like on this thread, whatever the question, the answer is "uniform interface."
Maybe it' just me. Eric ----- Original Message ---- From: Jan Algermissen <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, February 23, 2007 2:27:52 PM Subject: Re: [service-orientated-architecture] SOA Pizza Order Surprises On 23.02.2007, at 19:46, Glen Daniels wrote: > > Hi Jan, all: > > Jan wrote: >> So, is this an order? >> >> receiver.cancel( >> >> <ns:order xmls:ns="[xsd- target-namespace ]> >> <item1>...</ item1> >> <item2>...</ item2> >> <item3>...</ item3> >> <shippingAddress> ...</shippingAdd ress> >> <billingAddress> ...</billingAddr ess> >> </ns:order> >> ) >> >> >> >> >> And how would you ever be sure that cancel() had the same >> semantics by the time you invoke it as it had when you read >> the WSDL? > > The same way you're sure that POSTing "<cancel>" to > http://RESTsvc. com/PO5432 has the same semantics as it had when you > read > the... um, I guess the human-readable web page describing the purchase > order setup and semantics at RESTsvc.com? Is that any different, > really? No, because what you describe is not REST, it is tunneling RPC a uniform interface (HTTP in this case). Correct use of HTTP would be DELETE http://RESTsvc. com/PO5432 Since DELETE is uniform, the message is self describing. > > As Steve and others have noted, agreement MUST be there at ALL > levels of > the stack (incl semantics and interpretation of particular data > serializations) for a successful interaction. Yes, but the problem is the kind of agreement. It does not help that you and the receiver temporarily agree on some method. The problem is the decentralization: you do not control the recipient and thus have no way to be certain that the agreement persists. The effect is that what you think you say maybe not what the receiver understands you to say when you say it. > That seems to me to be a > truism of computing in general, as much for REST as it is for SOA > as it > is for in-process usage of third-party code libraries. Thus I'm > having > trouble understanding what you're getting at here? If the semantics of a message are not self describing (== are independent from the receiver side in all aspects) and if in addition the receiver is beyond your control, you don't know what you are effectively uttering when you invoke the remote method. Having a uniform interface and standardized message types solves that. Assuming the existence of an Order MIME type, POST /foo Content-type: application/ order+xml <order> ... </order> Means the same thing always and everywhere. You can look it up in the HTTP Specs and the MIME type standard, none of which are changeable by any of the parties. (That is what self descriptiveness is all about). If the receiver could change POST to mean 'cancel' that would not be the case. But with HTTP you cannot do that. (of course the receiver can implement POST to result in a cancel, but this does not change what you said - because the true meaning of POST is not open to interpretation. Jan > > --Glen > > > ------------ --------- --- Yahoo! Groups Sponsor ------------ -------- > ~--> > Something is new at Yahoo! Groups. Check out the enhanced email > design. > http://us.click. yahoo.com/ kOt0.A/gOaOAA/ yQLSAA/NhFolB/ TM > ------------ --------- --------- --------- --------- --------- - > ~-> > > > Yahoo! Groups - Join or create groups, clubs, forums & > communities. Links > > > fullfeatured@ yahoogroups. com > > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
