Hi Steve!
Forgive my confusion here, there are so many WS-* specs, and so little
consistency.
Heh. :) And so many usage patterns of the specs that are there, even...
I was under the belief that with doc/lit SOAP, all you need are docs;
SOAPAction can and should be null.
Not necessarily. SOAPAction is commonly used to dispatch on a per-operation
or even per-message basis, and this isn't changed by RPC-ness or
doc/lit-ness. There might be operation-specific values regardless.
It's true that if you are JUST thinking about SOAP the protocol, as opposed
to a service as declared in a WSDL, you could just drop some content into a
message and send away without knowing anything else. However, the common
case today is in fact a service that is either described by WSDL or at least
looks a lot like the WSDL model - even though it may be doc/lit, there are
still "operations" which have semantics associated with them, which in
addition to what they *do*, might include different per-operation policies,
etc.... So Axis2 wants to know what operation you're using so that it can
engage any operation-specific Modules, for instance.
That said, there are certainly use cases where you don't know/care what
operation is in use, so I think you have a point. However, operations are
also where MEPs live - so you do somehow need to tell Axis2 that a response
is expected for in/out MEPs......
but if I try and use Call.invokeBlocking("", data) then I get told off.
What should I be putting there?
We could make the operation arg optional, and also provide
invokeBlocking(data), which would simply use whatever global settings are in
effect for Modules, policy, etc. I guess we'd default to the req/resp MEP?
Alternately, you could just create a new OperationDescription()....
--Glen
