cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <james....@iona.com>
Subject Re: isGET in interceptors...
Date Wed, 06 Dec 2006 11:23:00 GMT

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


Mime
View raw message