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 > > > > > > > > >
