cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: isGET in interceptors...
Date Mon, 04 Dec 2006 19:46:29 GMT
On 12/3/06, James Mao <james.mao@iona.com> wrote:
>
> Hi Dan
> >
> > There are maintenance issues with both isGET and changing the chain
> > dynamically.
> Agreed
> > After thinking about this today, I think its because you're
> > making things harder by combining two bindings into one. GET is really a
> > separate WSDL binding and I think we should treat it as so within CXF as
> > well. See my proposal on the mailing list about this, but I think its
> > wrong
> > to mix the GET and POST bindings together.
> I'm not quite understand why there's a problem of mixing the GET and
> POST together? You mean when user want to use GET, he should configure the
> service as a
> GET serviceļ¼Œ and configure the POST as POST service?


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.

>
> >> >
> >> > 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.

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'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'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
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.

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


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.

Regards,
- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message