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
 65.223.216.181 as permitted sender)
Message-ID: <45751A0A.50104@iona.com>
Date: Tue, 05 Dec 2006 15:04:42 +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>
	 <456E3929.2040200@iona.com>
	 <7b774c950611301122g7afc1fden9a205cfe7f4ba3c5@mail.gmail.com>
	 <456F9FCC.8030401@iona.com>
	 <7b774c950612021403j7283e822sefeb08504a3a74dc@mail.gmail.com>
	 <45738BDA.6000202@iona.com>
 <7b774c950612041146u332877c9l6953ef7ea1dfc472@mail.gmail.com>
In-Reply-To: <7b774c950612041146u332877c9l6953ef7ea1dfc472@mail.gmail.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Dan,
>
>
> No, I mean they have different code paths. The interceptors needed for
> the
> GET case are different than for the POST case. And hence they should have
> operate as a different Binding.
Different code path is fine to me.
>
>>
>> >> >
>> >> > I think we need to come up with a better way. My preference would
>> >> be to
>> >> > unify the code in the HTTP binding and the current HTTP GET/POST
>> for
>> >> > the XML
>> >> > & SOAP bindings.
>> >> The HTTP GET we implemented and the HTTP binding are different
>> things,
>> i
>> >> don't think we need to combine.
>> >> If it's GET, there is no need to synthesizes a document, that will
>> slow
>> >> down the processing.
>> >
>> >
>> > As I mentioned above, I don't really see squeezing out top performance
>> of
>> > SOAP HTTP GET a goal. I doubt this makes more than a 10% difference.
>> I don't have a test result for this. but think about there is no
>> marshall/unmarshall in the client side ,
>> and there is no unmarshall in the service side, there is only marshal
>> happen in the service side.
>> If we synthesizes a document, there will have marshall/unmarshall in the
>> client side, and there will have marshall/unmarshall in the service
>> side. am i correct?
>
>
> Yup.
In synthesizes a document approach , I expect the answer is client side
will have no marshall/unmarsall, but the server side will have a
marshall/unmarsall.
If the client also will have marshall/unmarshall, how can you say that
it's a HTTP GET approach?
If the client need send a document, then must use POST, not GET. am i right?
Then how can you use browser to get the result?
>
> I mean, that's will degrade the performance, and i don't like it, as a
>> GET i suppose it's quicker and simpler than normal invocation, and i
>> think that the big benefit we use GET, right?
>> otherwise, why people select GET?
>
>
> I think people will be using GET primarily for debugging and testing of
> their service. The benefit of GET is that you can use it simply in
> your web
> browser without creating a client. Performance doesn't really matter too
> much the quick testing/debugging.
I don't think so, you can use GET to test/debug, but the main reason is
that other language also can use the GET way to consume the service.
No extra learning, no extra code will be need to consume the service.
For example, I can use PHP to GET the result document, then i can use
any xml lib to parse the doc (DOM, simplexml, XPath etc.)

>
>>
>> > I'm not saying that is hard to understand. I'm saying that IMO it
>> isn't
>> > clean code, it mixes concerns, and is bad for code maintainability.
>> >
>> > All this debating isn't relevant if we make SOAP+GET a separate
>> > binding on
>> > the service with its own interceptors. See my proposal on the mailing
>> > list
>> > for how this might work. My other proposal is that we just make
>> > synthesize a
>> > document like the HTTP Binding. I'm OK with either of those options,
>> > but I'm
>> > really not OK with the current way for the reasons I mentioned above.
>> >
>> As i said to synthesize a document is really not a good way to do this.
>> seems that change the chain dynamically better than synthesize a
>> document, but as is said it's not that good too, for example, sometimes
>> we want to use an interceptor, but we need to skip the interceptor in
>> some cases.
>>
>
> And from a maintenance point view, i really didn't see any difference.
>>
>
> I do - we no longer have to muck with isGET in the normal interceptor
> chain.
I thought about it latterly, and i think, if we really in hurry(i don't
know if it's block anyone's work), i prefer we do this in an
interceptor, and change the chain dynamically.
The reason is that we might need a configure to disable the GET way
later, that's the only specific reason i find why we need it in a
central point.
And we also need to figure out how to deal with the situation that we
might need an interceptor, but we need to pass through in the middle.
>
>
> I'm open to change. and i think we can find a better solution. right?
>
>
> To recap, the problems with the current solution:
> 1. It requires all the other interceptors to be aware of whether or not
> there is a GET operation going on. The code is supposed to be transport
> agnostic, so this is bad from a code cleanliness and maintenance point of
> view.
> 2. If a user writes an interceptor on the incoming side they'll have
> to add
> isGET logic, which is an unexpected concern from a user point of view.
> For
> instance, WS-Security interceptors would need to be aware of whether
> or not
> its a GET operation. This is a bad thing IMO
But in dynamical way you also need to know if this interceptor can be in
the chain or you need to remove the interceptor dynamically, as i also
said before, the maintenance cost is same. and i thought we agreed?
> 3. GET only handles simple Java primitives, it doesn't handle any XSD
> primitive like enums, datetimes, etc. Ideally we should reuse the
> databinding layer instead of writing our own.
>
This is not a big problem, we don't have user report this, if you want,
i can i add this soon.
> The two solutions that I've proposed:
> 1. Synthesize a document
> 2. Create a separate logicial binding with a different set of
> interceptors.
> My proposal on the list about how to handle multiple services/bindings on
> the same endpoint outlines how this could be done
If you really want me to pick up one i prefer to change the chain
dynamically, but not to synthesize a document, i really don't like it.
>
>
> And the most important thing is that we can keep the GET as fast as it
>> could be. and make user easier to use the service, no extra learning
>> curve.
>> Any implementation can achieve this goal, is a good implementation.
>> If we can improve the current implementation and also achieve the goal
>> that's a correct thing to do.
>>
>
> Why is performance of SOAP HTTP GET so important to you? Most of the XML
> performance issues are in actually parsing the XML text. Constructing a
> Document and passing it into JAXB take a very small amount of time. I
> think
> your concern with performance here is very unfounded.
>
> My preferred solution is to just synthesize a document. I doubt there is
> more than a 10% performance difference. Feel free to prove me
> otherwise, but
> it the 10% difference in the GET case is just not worth it for the
> problems
> I outlined above.
Cheers,
James.