RE: WS-Addr issues

If I understand Marc's To and Action proposals, he's suggesting they
both be made optional.  This is like making HTTP's location and
operation protocol parts optional.  

The whole point of having standardized mandatory protocol elements is to
enable re-use above it.  Having any kind of optionality enormously
complicates the WS-A processors job.

The only thing that I can think of that meets in the middle is if
somehow there was a transport specific ws-a binding or mep.  So the
infoset always had action/to, but the wire might have them outside of
the actual soap header.  I think that is a new soap mep (the ws-a http
soap request/response mnep?) because soap 1.2 doesn't recognize
serializing the infoset into the transport specific areas.  I think that
is a horrendous bug, but that's the way it is.  

Cheers,
Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Marc Hadley
> Sent: Thursday, November 04, 2004 8:24 AM
> To: Francisco Curbera
> Cc: public-ws-addressing@w3.org; Mark Little; public-ws-addressing-
> request@w3.org; Savas Parastatidis
> Subject: Re: WS-Addr issues
> 
> 
> On Nov 4, 2004, at 10:50 AM, Francisco Curbera wrote:
> >
> > Action is not part of the EPR; I guess you mean make it an optional
> > message
> > header.
> 
> Exactly.
> 
> >  Still, I guess your point is like the one about recognizing that
> > the <To> information may be carried by the transport: you do agree
it
> > must
> > be there but you argue it may be found in many different places
(body,
> > SOAPAction, etc...). I would still disagree, however: this just
makes
> > everything much more complicated than is really needed.
> >
> I'd argue that specifying the same information in multiple places
> complicates things...
> 
> Marc.
> 
> >
> >                       Marc Hadley
> >                       <Marc.Hadley@Sun.COM>           To:
Savas
> > Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
> >                       Sent by:                        cc:
> > Francisco Curbera/Watson/IBM@IBMUS, public-ws-addressing@w3.org,
Mark
> > Little
> >                       public-ws-addressing-req
> > <mark.little@arjuna.com>
> >                       uest@w3.org                     Subject:  Re:
> > WS-Addr issues
> >
> >
> >                       11/04/2004 10:27 AM
> >
> >
> >
> >
> >
> >
> > I agree with the desire to make action an optional part of an EPR.
This
> > would echo the resolution made by the XMLP WG [1] a couple of years
ago
> > wrt SOAPAction (now the action parameter of the application/soap+xml
> > media type).
> >
> > If a service mints an EPR that contains a URI then a consumer of
that
> > service would be expected to provide it, if a service mints an EPR
> > without a URI then it would be omitted. This way services can be the
> > arbiter of what information they require in messages they receive.
> >
> > I see no value in mandating the inclusion of action in EPRs for
> > services that make no use of it.
> >
> > Marc.
> >
> > [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x95
> >
> > On Nov 4, 2004, at 10:02 AM, Savas Parastatidis wrote:
> >
> >>
> >> Dear Paco,
> >>
> >>>
> >>> The idea that the intent of the message is *always* embedded in
the
> >> body
> >>> of
> >>> the message smells like SOAP-RPC in sheep clothes to me. I am not
> >> saying
> >>> that will never be the case, but you need to allow for the case in
> >> which
> >>> the same document type is used in different interactions - for
> >> example, a
> >>> customerInfo document could be sent as input to both an "update"
and
> >>> a
> >>> "create" operations.This "document centric" model is actually very
> >>> frequent
> >>> (it is no uncommon in CICS applications for example). To support
this
> >>> model
> >>> you need either an Action header or something functionally
> >>> equivalent.
> >>>
> >>
> >> I can see this argument. However, if one has designed a service to
> >> expose an RPC-like interface, it won't matter whether the RPC
> >> information is split between the header and the body; it'll still
be
> >> RPC. It's just that wsa:action would expose the RPC dispatching
> >> mechanism in the header instead of the body.
> >>
> >> An exchange that uses messages like the one bellow is still
> >> document-centric but leaves all the dispatching and processing
> >> decisions
> >> to the end-recipient (the service logic) and it doesn't require the
> >> inspection of headers.
> >>
> >> <soap:Envelope>
> >>   <soap:Header>
> >>     ...
> >>   </soap:Header>
> >>   <soap:Body>
> >>     <CustomerInfo>
> >>       <CustomerId>1234</CustomerId>
> >>       <CustomerName>Paco</CustomerName>
> >>     </CustomerInfo>
> >>   </soap:Body>
> >> </soapEnvelope>
> >>
> >> In this example, the service logic could infer that since a
customer
> >> id
> >> is provided, this is a request to update the information and not to
> >> create a new one. However, I see your point that there may be
> >> situations
> >> where you would need that additional information. I see two
possible
> >> alternative ways to record that information while staying within a
> >> document-centric view of the world...
> >>
> >> Since WS-I imposes (I think) a single child element per soap:Body,
> >> then
> >> one could have different child elements of the same document type.
> >>
> >> <xsd:element name="CustomerInfoUpdateRequest"
> >> type="customer:CustomerInfo" />
> >> <xsd:element name="CustomerInfoCreateRequest"
> >> type="customer:CustomerInfo" />
> >>
> >> Alternatively the information is encoded in the document itself. I
> >> think
> >> this simulates the way business forms work in real life.
> >>
> >> <CustomerInformationDocument>
> >>   <CustomerNew>true</CustomerNew>
> >>   <CustomerName>Savas</CustomerName>
> >> </CustomerInformationDocument>
> >>
> >>
> >> So, why not make wsa:action optional to allow for all possible
> >> scenarios? But then the problems with having wsa:action optional
would
> >> be interoperability and complexity of the specification. What would
> >> the
> >> lack of a wsa:action header mean for a service that expects it?
> >>
> >> Just few more thoughts
> >>
> >> Best regards,
> >> .savas.
> >>
> >>
> >>
> > ---
> > Marc Hadley <marc.hadley at sun.com>
> > Web Technologies and Standards, Sun Microsystems.
> >
> >
> >
> >
> >
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
>

Received on Thursday, 4 November 2004 16:47:28 UTC