Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of James.Mao@iona.com designates
 62.221.12.33 as permitted sender)
Message-ID: <4577882E.2050901@iona.com>
Date: Thu, 07 Dec 2006 11:19:10 +0800
From: James Mao <james.mao@iona.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: isGET in interceptors...
References: <7b774c950611291103y68c2fa70qe05c88d2865d5e71@mail.gmail.com>
	 <7b774c950611301122g7afc1fden9a205cfe7f4ba3c5@mail.gmail.com>
	 <456F9FCC.8030401@iona.com>
	 <7b774c950612021403j7283e822sefeb08504a3a74dc@mail.gmail.com>
	 <45738BDA.6000202@iona.com>
	 <7b774c950612041146u332877c9l6953ef7ea1dfc472@mail.gmail.com>
	 <45751A0A.50104@iona.com>
	 <7b774c950612051927r61d5bd2en7b5c08fce5d0c625@mail.gmail.com>
	 <b23ecedc0612060121s59d3118ai4fc40a7c32a5415@mail.gmail.com>
	 <4576A814.8030904@iona.com>
 <b23ecedc0612060702j7b4a57c5y9c30dbe14efc2ddd@mail.gmail.com>
In-Reply-To: <b23ecedc0612060702j7b4a57c5y9c30dbe14efc2ddd@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.