On 23.02.2007, at 17:35, Anne Thomas Manes wrote:
The means by which the application framework enables the
application to send an order to a service is beside the point. Many
frameworks allow the application developer to use an RPC-like
metaphor, but whether the developer is working with an RPC-style
programming model or a messaging programming model, then message on
the wire is explicitly defined by the WSDL/XSD.
Well, that is good for the interaction to succeed, but do you control
the WSDL? There is a huge difference in court between "Here is the
purchase order I sent" and "Here is the message I sent and the WSDL I
read when I constructed the message". The point is that in a
decentralized system that does not employ a uniform interface
constraint, the meaning of what you say isn't all yours.
And the message received by the service provider is something like
this:
<ns:order xmls:ns="[xsd-target-namespace]>
<item1>...</item1>
<item2>...</item2>
<item3>...</item3>
<shippingAddress>...</shippingAddress>
<billingAddress>...</billingAddress>
</ns:order>
Fine, set aside the issue of MIME vs. XSD suitability to establish
semantics this *is* a purchase order. Am I understanding you
correctly that you do imply a uniform interface here? IOW, there
would be no WSDL necessary, because a sandard process-this method
would be sufficient?
Then I am all with you.
My point was targeted towards interactions where the receiver's API
is non-uniform.
Jan
That looks like an order to me, althoug, I would also expect an
element to be included that represents the customer.
The point is, there's a lot more semantic definition if you clearly
specify the allowed input and output message structure than if you
don't.
Anne
On 2/23/07, Jan Algermissen <[EMAIL PROTECTED]> wrote:
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
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
