cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: isGET in interceptors...
Date Wed, 06 Dec 2006 15:02:52 GMT
On 12/6/06, James Mao <james.mao@iona.com> wrote:
>
> > Sorry to interrupt this ongoing discussion ...
> > Can someone cast some lights on the differences between
> > the HTTP Binding (derived from the WSDL 2 spec) and the GET
> > stuff ?
> Actually the HTTP Binding in CXF is a RESTful service implementation,
> see the wiki page
> http://cwiki.apache.org/confluence/display/CXF20DOC/REST+Style+Services
> In HTTP Binding we do have GET verb implementation. and currently the
> implementation is based on XML binding. as Dan said, the client part is
> not finished yet.
>
> And the isGET we implemented in CXF,  in the initial, has nothing to do
> with HTTP binding.
> The idea basically is to skip the marshall/unmarshall in the client
> side, and unmarshal in the server side. (so the invocation will return
> as fast as possible, but i don't know how fast it can be, i don't have
> data show you here, we can do a test later when the http binding client
> part finished)
> SOAP 1.2 do support GET and i think isGET implement the spec. right?

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.

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.


> >
> > I know how the WSDL 2 Http binding works.  It is imho very powerful
> > and support all the REST stuff needed.  The main benefit is that
> > the marshaling / unmarshaling code is the same than for standard
> > SOAP requests.  When receiving an HTTP request, depending on the
> > operation and the WSDL2 binding, an xml document will be constructed
> > which will be *compliant* with the WSDL abstract definition.  This allow
> > to work with all the jaxws features like accessing the xml message, etc..
> > As a side point, it should be easy to integrate into JBI for example ;)
> >
> I know little about WSDL2 HTTP binding, but from your description that
> even the GET need to use the POST method to send/receive the data.
> If the construction of the document just happen in the server side? that
> make more sense to me.
> The benefit i can see in this approach is to reuse the SOAP binding
> implementation.
>
> As i said before, if the isGET conflict with the WSDL2 implementation or
> any others, we definitely should fix this as soon as possible.
> It's OK, it's just an idea ;)
>
> Cheers,
> James.
> > On 12/6/06, Dan Diephouse <dan@envoisolutions.com> wrote:
> >> On 12/5/06, James Mao <james.mao@iona.com> wrote:
> >> >
> >> > 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.
> >>
> >>
> >> I haven't implemented the client side of the HTTP binding yet, but I
> >> would
> >> expect the process to be the reverse. First JAXB would serialize to a
> >> document. Then a URL would be constructed with the parameters.
> >>
> >> A Document is just a giant hashmap, so don't think of it as imposing
> >> some
> >> huge performance penalty.
> >>
> >> If the client also will have marshall/unmarshall, how can you say that
> >> > it's a HTTP GET approach?
> >>
> >>
> >> Well, A URL is constructed from the marshalled document.
> >>
> >> 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?
> >> >
> >>
> >> No. See above - its the reverse process of synthesizing a document.
> >>
> >> > 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.)
> >>
> >>
> >>  OK, I'll buy that. I was more referring to HTTP GET'ing of SOAP as
> >> opposed
> >> to GET'ing of a non SOAP message. Yes, people will HTTP GET normal XML
> >> messages. However, I stand by my statement that the synthesis of the
> >> document isn't really a huge deal.
> >>
> >> >
> >> *snip*
> >>
> >> 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.
> >>
> >>
> >> Its not blocking my work, but I would like it cleaned up for the next
> >> release. And there is no time like the present :-)
> >>
> >> 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.
> >>
> >>
> >> We could always an interceptor right at the beginning that does this:
> >>
> >> if (isGet()) {
> >>   add all the get interceptors
> >> } else {
> >>   add all the post interceptors
> >> }
> >>
> >> > 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?
> >>
> >>
> >> Yeah, I forgot, sorry. This is another reason we should go with the
> >> document
> >> synthesis approach.
> >>
> >>
> >> > 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 this is is strictly because of performance reasons?
> >>
> >> The *only* real difference between the way you are doing things and the
> >> document synthesis approach amounts to this code:
> >>
> >> DocumentBuilder builder = DOMUtils.getDocumentBuilder();
> >> Document doc = builder.newDocumentI();
> >> Element el = builder.createElementNS(rootQName)
> >>
> >> for (XmlSchemaElement element : requestSequence) {
> >>   String val = getPartFromURI(part);
> >>   Element child = builder.createElementNS(element.getName());
> >>   child.appendNode(builder.createTextNode(val);
> >>   el.appendNode(child);
> >> }
> >>
> >> For just a couple values this won't take much time at all. Both
> >> approaches
> >> need to parse the URIs. Both approaches need to parse the text into
> >> numbers/ints/etc. But the above reuses our databinding code and has a
> >> cleaner code path.
> >>
> >> - Dan
> >>
> >>
> >>
> >> --
> >> Dan Diephouse
> >> Envoi Solutions
> >> http://envoisolutions.com | http://netzooid.com/blog
> >>
> >>
> >
> >
>
>


-- 
Cheers,
Guillaume Nodet

Mime
View raw message