Re: Action item - Part 2: SOAP request-response, response, request-optional-response ...

> We seem to be converging on the idea that there are transports which are
> inherently request-response in nature.  You can fire, but you can't
> forget, or put another way, there will always be a request and there
> will always be either a response or a failure. However, one may choose
> to put a SOAP envelope on either, neither or both of the request and
> response.

This makes sense.  However, just because the lower-level is
request-response, does not mean that the SOAP layer has to do
anything with that response.  You could define a FAF over HTTP,
just specify that the SOAP layer igfnore any rseponse.  Conversely,
you can also build request-response over "one way" transports --
DNS, RADIUS, and SNMP over UDP are lightweight examples that work
more than well enough to get real work done, and at the other end
of the scale DCE RPC (same protocol as DCOM) shows you can build
full at-most-semantics.  (Kerberos shows you can do it securely,
and SunRPC makes the notion of idempotency explicit.)

> If we can find a case where the client has to dynamically tell the
> server "I MUST get a SOAP response" or "I MUST NOT get a SOAP response"
> then we will need a wire-level MEP signal.  So far I don't know of any
> such case, but I'm not ready to rule it out entirely.

What about multi-party transactions, where the sender and ultimate
recipient might, or might not, be aware of the other parties.
For example:

        A governance/compliance service might be installed in the
        "outbound" enterprise.  Clients can optionally add header
        that categorizes the message (e.g., Sarbox compliance).
        Policies and regulations may change, and clients who never
        added this header might have the intermediary interposted
        without their knowledge.

        On the inbound size, there might be a SOAP gateway in the
        DMZ validating and filtering all traffic.

I know many instances (customers:) of the latter, and I expect to
see things like the former soon.

> Given that the SOAP
> processing model is one-way, I'd think an intermediary /shouldn't/ be
> aware that a given SOAP message is a request or a response, but it's
> highly possible I've missed something.

Depending on the implementation, it might well know the transport
being used.  Many existing management, auditing, and fault detection
systems need to know which is a request, and which is a response.
Right now they generally get that information "for free" because
the traffic is the basic MEP over HTTP.

        /r$

-- 
SOA Appliance Group
IBM Application Integration Middleware
* This address is going away; please use rsalz@us.ibm.com *

Received on Thursday, 12 January 2006 16:17:49 UTC