Spec Issue

David asked for the working group to scan the spec and
list the issues (with possible solution(s)) that we would
like to discuss next week - here's an oldie but
a goodie that I'd like to resurface:

SOAPAction
----------
IMHO, the spec is not clear on the exact purpose or meaning
of SOAPAction.  "Intent" is just too vague.  It can mean
anything - which to some people is good because it leaves it
up to the SOAP processor (not the spec) to decide how to use
it.  But at the same time, if someone chooses to use it as
routing information that's wrong.  Also, it isn't clear how it
maps from one transport to another (esp. in the case where
headers are not supported in one of the transports).

Aside from what the spec _does_ actually say about SOAPAction
being used for filtering (which to me is a form of routing)
I believe I've heard 2 other reasons for SOAPActions' existence:

  1 - It indicates that this is a SOAP message
  2 - It gives a "hint" as to the target web service being used

For me, 1 seems like it can be solved through other means (URL
mappings, other HTTP headers...).  #2 is the real one that I
think makes SOAPAction, possibly, useful.  But, since it is
just a "hint" as to the "intent" and not the complete target
web service, it only gives partial help for #2.  I think
implementations that want to do a streaming SOAP processor will
be looking for SOAPAction to really help out a lot by allowing
them to identify the web services as soon as possible, w/o having
to scan ahead for the Body.  However, due to the vagueness of
SOAPAction's definition I don't believe anyone can really count
on being able to fully use it for that purpose.  Nor can they
count on it for non-HTTP transports.

I'd like to propose the following for our discussions next week:
1 - Remove SOAPAction from the spec.
    For migration purposes we can say that if someone chooses to
    use an HTTP header that just happens to be called SOAPAction
    that's fine but the SOAP spec makes no mention of its use.
2 - Add a new attribute to the SOAP-ENV element: "target" or
    "targetNS"  who's defined to have the same value as the
    namespace of the element in the Body that defines the Web
    Service being invoked.  (Note that it might not be the root
    element.)  And the SOAP processor should fault if they don't
    match.  If there is no namespace to match then the attribute
    can be "" or left out.
    (Possible change: should the method name be there too if
     there is a method name?  Should "target" be left more
     flexible to say that "it indicates the target web service" and
     just leave it at that.  Then it can be up to the specific
     implementation to determine whether it should be the
     namespace, namespace+methodName, ns+methodName+correlationID
     or something else - but whatever it is it needs to be
     something that is verifiable. My worry with this is that
     it could end up being just as vague as SOAPAction.  More
     discussions needed on this one but I like the idea of
     keeping it more open.  The key would be that no matter
     which way we went it MUST be something that is verifiable
     once we have read the entire envelope.)
This keeps around the 2nd reason for having SOAPAction but also
narrows its definition such that:
 - it is explicit as to its use and content
 - it is part of the SOAP Envelope so we don't need to worry
   about what to do when we switch between transports

Enough for now, we can poke fun at this next week.  8-)

-Dug

Received on Tuesday, 29 May 2001 14:19:01 UTC