Anne, when I send a SOAP message, its meaning depends on the receiver's API semantics, yes?
Is the invocation receiver.method1( item1,item2,item3,shippingAddress,billingAddress) an order? Jan On Friday, February 23, 2007, at 01:24PM, "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: >I'd also like to point out that the message payload (the contents of the ><soap:Body>) is, in fact, self describing, because it is an XML element with >a qualified name. In fact, I would argue that it's much more self describing >than a MIME type typically is. > >Anne > >On 2/22/07, Steve Jones <[EMAIL PROTECTED]> wrote: >> >> On 21/02/07, Jan Algermissen <[EMAIL PROTECTED]<algermissen1971%40mac.com>> >> wrote: >> > >> > >> > >> > >> > >> > >> > Steve, >> > >> > >> > it appears, I did not make myself clear enough: My concern is with the >> message semantics. The depend on the recipients interface semantics and >> thus, whatever I utter does not stand on its own (is not self descriptive) >> and insufficient to make my case in court. >> > >> >> Now there is something around interaction semantics (as per my IEEE >> paper) that isn't covered by the current specs for either WS or REST, >> but that is additional elements. But having a service description, >> having negotiated trust and having a name like "orderPizza" would >> certainly be enough in a court of law as you have made a reasonable >> assumption and the service is clearly engaging in fraud. Caveat >> Emptor doesn't mean you aren't protected from fraud, there is in >> practice no difference between the WS scenario and the phone scenario, >> in fact if the WS scenario has trust verified via a third party then >> there is even more security from a legal perspective in the WS >> scenario. >> >> > >> > Or is there a message in SOA that does not depend on the recipients API >> semantics? >> > >> >> Clearly the impact of any interaction is dependent on the semantics of >> that interaction. In simple old Eiffel and Design by Contract terms >> this means pre/post/invariant conditions, clearly there can also be >> contracts at the service level (SLAs!) but whether you are speaking >> over the phone, a website or via XML document shifting there are >> always semantics to the interaction whether these are explicit, >> implicit or implied. >> >> The key concept in these areas however is _always_ trust, because >> where there certainly isn't a legal case is if you phone up people >> randomly and say "give me a pizza here are my credit card details" >> while you might have a minor case around people defrauding you this >> might be cancelled by your sheer stupidity at engaging where there was >> no trust. >> >> For an interaction to have effect it must have meaning.... therefore >> there can be no interaction without semantics. >> >> > >> > Jan >> > >> > >> > >> > >> > >> > >> > >> > On 21.02.2007, at 11:51, Steve Jones wrote: >> > >> > Assuming you are using SAML and WS-Security and have kept a log of the >> messages then its fine as this will contain both their authentication and >> your own. >> > >> > If however you didn't use security and its an open exchange then you are >> just going to have fun in the courts. This is one of the key things about >> Trust (and one of the reasons that security != HTTPS), before you start a >> transaction you need to trust the other party to deliver or trust that you >> have recourse if something goes wrong. This plays back to something I asked >> at a conference back in 2001 (IIRC) (just after my dad had seen a >> presentation on WS and said "so why is ASCII RPC now a good idea?"). The >> presenter had outlined the holy trinity of WS including UDDI and talked of a >> "business" scenario where you would discover automatically a credit card >> clearance company and select the cheapest one and then complete the >> transaction. My point then was that this is bollocks as ! if that were true >> then I'd set up the world's cheapest credit card clearing company in >> somewhere with no extradition treaties and then fleece the world. >> > >> > Trust and validity are serious and difficult concepts, its fine for >> people to argue about document shifting approach X v Y, but if they don't >> provide a framework for Trust and validity on top of that base then its a >> pointless argument. >> > >> > SAML, WS-Security, WS-Trust and a decent set of audit logs. >> > >> > Steve >> > >> > >> > >> > >> > On 21/02/07, Jan Algermissen < [EMAIL >> > PROTECTED]<algermissen1971%40mac.com>> >> wrote: >> > > >> > > >> > > >> > > >> > > >> > > >> > > Hi, >> > > >> > > if have SOA-ordered a pizza the other day but yesterday I learned I >> > > sold my house..... >> > > >> > > How do I prove in court that my digitally signed pizza order was >> > > indeed a pizza order and not (as the recipient claims) a house sale? >> > > >> > > Jan >> > > >> > > >> > >> > >> > >> > >> > >> >> >
