RE: WS-Addr issues

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.

Received on Thursday, 4 November 2004 15:03:20 UTC