Hi Nodet，
As far as I understand the SOAP 1.2 spec, the GET HTTP verb is used
for the SOAP Response MEP, which means there is no input message,
but only a response message. So this is part of the SOAP binding
and, as you said, there is no relationship with the HTTP binding.
Yes i agree, in SOAP1.2 GET HTTP verb, there is no input message, but
has the HTTP GET request, right?
So, that's how current isGET works， you can use browser to get the
response message back.
So uri scheme we used is
http://localhost/SoapContext/SoapPort/greetMe/me/CXF or
http://localhost/SoapContext/SoapPort/greetMe/?me=CXF
And the basic idea is that other language can also consume the service ,
for example, for PHP , you can use the curl to GET the response message
from the service.
And eventually, the isGET not only support SOAP1.2, but support SOAP1.1
and XML binding as well.
As far as the code is concerned, I don't know how is the plan to support
policies definition at the operation level (or is it already done ?),
but I don't
really understand how it would be possible without changing the
interceptor
chain dynamically, or by defining a tree of interceptors (instead of a
list), where
a subtree would be picked given the ongoing operation. This is the
same problem
for the GET / POST problem on the SOAP binding: an operation can be
mapped
to a GET request, while another one would be mapped to a POST request.
So you need to select a subtree of the interceptor chain here.
Because it's GET, so the client side is just URLConnection, or the
client is the browser, there is a URIMappingInterceptor sit in the
server side,
the isGET will skip all the interceptors not necessary in GET
processing, it's the URIMapping interceptor to dispatch the invocation.
the rest is as same as the POST processing.
I'm OK with the changing the chain dynamically, they both works. if we
change the chain dynamically, then for both the SOAP binding and XML
binding and any other binding to filter the interceptors dynamically, i
mean the maintenance cost is same. but this approach do have a benefit,
the benefit is that all the isGET logic in the same place, if we want to
add some configuration for this function, it'll be more easier. But the
other side is, it'll be harder to change the chain if the interceptor is
coarse-grained, that means we want some part of the logic of the
inteceptor, but in some conditions we want to exclude the interceptors,
but yes, you can break down the interceptors into pieces to work around
the problem. So there's pros and cons.
Cheers,
James.
