RE: WS-Addr issues

Hi Savas,

Essentially you are arguing for embedding the method name inside the input
data. This is what is wrong about SOAP-RPC, IMO. Typically the
infrastructure figures out what piece of application logic needs to process
the message and hands the message body to the application logic to process.
The message envelope structure nicely supports this layering. SOAP-RPC and
the idea of embedding operation name somewhere inside the body breaks this
by forcing the body to be inspected to figure out what operation to invoke.
I was arguing against the SOAP-RPC approach, not against RPC in general or
the notion that messages have "intent" associated with them.

As many have already said, there is a lot of value on agreeing that the
message intent can be found in a single place; the worse that can happen is
that it is redundantly encoded in more than one place, which seems a little
price to pay for avoiding the current confusion of dispatching mechanisms.

Paco



                                                                                                                                                
                      "Savas Parastatidis"                                                                                                      
                      <Savas.Parastatidis@newca        To:       Francisco Curbera/Watson/IBM@IBMUS, "Mark Little" <mark.little@arjuna.com>     
                      stle.ac.uk>                      cc:       <public-ws-addressing@w3.org>                                                  
                                                       Subject:  RE: WS-Addr issues                                                             
                      11/04/2004 10:02 AM                                                                                                       
                                                                                                                                                




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 Friday, 5 November 2004 02:48:12 UTC