RE: Sample SOAP message on the wire with Reference Properties and Parameters (without a wrapper!)

So this message walks into a service and says to the endpoint "Hey,
dispatch me".  The endpoint looks at the message and says "we don't
dispatch or service your type around here".  The message says to the
endpoint "Give a message a break, I'm not one of *those* types of
messages.  Let me tell you what type I am...".  The endpoint interrupts
and says "Yeah, whatever buddy, you can go over there".

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Christopher B Ferris
> Sent: Tuesday, November 23, 2004 9:42 AM
> To: Savas Parastatidis
> Cc: Martin Gudgin; public-ws-addressing@w3.org; public-ws-addressing-
> request@w3.org; Rich Salz
> Subject: RE: Sample SOAP message on the wire with Reference Properties
and
> Parameters (without a wrapper!)
> 
> 
> Savas,
> 
> An endpoint goes to the IT Architect. He says: "Hey Doc, it hurts when
I
> publish two endpoint references
> that result in SOAP messages that are indistinguishable from one
another
> and I don't know which policy
> to apply to the messages". The IT Architect replies: "Don't do that."
> 
> :-)
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> public-ws-addressing-request@w3.org wrote on 11/23/2004 11:32:28 AM:
> 
> >
> > <snip />
> >
> > >
> > > But more importantly, if the only entity that can distinguish
between
> > a
> > > prop and a param is the server, then I don't see why the spec has
both
> > > types.  We should be able to drop one (flip a coin:) without any
> > impact
> > > on the installed base -- servers already have the requisite
internal
> > > config and magic to distinguish between the two -- and greatly
> > simplify
> > > things.
> >
> > Hey Rich,
> >
> > I think the reason the authors decided to have both is because of
the
> > need to compare EPRs and associate different metadata with different
> > EPRs but still allow different Params to be sent to a single EPR.
> >
> > The two ReplyTo headers may have different policies associated with
> > them...
> >
> > <ReplyTo>
> >   <Address>http://service1.com</Address>
> >   <RefeferenceProperties>
> >     <customer>urn:id</customer>
> >   </ReferenceProperties>
> >   <ReferenceParameters>
> >     <account>urn:id</account>
> >   </ReferenceParameters>
> > </ReplyTo>
> >
> > <ReplyTo>
> >   <Address>http://service1.com</Address>
> >   <RefeferenceProperties>
> >     <customer>urn:id</customer>
> >     <account>urn:id</account>
> >   </ReferenceProperties>
> > </ReplyTo>
> >
> > The first one allows a service provider to have policies for
specific
> > customers while the other to have policies for the specific account
of a
> > customer.
> >
> > An interesting question is how the receiving endpoint is to know in
this
> > case which of the two set of policies to apply based on the headers
in
> > the SOAP message.
> >
> > Best regards,
> > .savas.
> >
> >
>

Received on Wednesday, 24 November 2004 01:03:11 UTC