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 Sergey.Beryozkin@iona.com
 designates 62.221.12.33 as permitted sender)
Message-ID: <001401c7195a$eda9d5b0$3901020a@sberyoz>
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>
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>
 <45751A0A.50104@iona.com>
 <7b774c950612051927r61d5bd2en7b5c08fce5d0c625@mail.gmail.com>
 <b23ecedc0612060121s59d3118ai4fc40a7c32a5415@mail.gmail.com>
Subject: Re: isGET in interceptors...
Date: Wed, 6 Dec 2006 17:21:12 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit

> I know how the WSDL 2 Http binding works.  It is imho very powerful
> and support all the REST stuff needed.

How far does it go though ? REST stuff is not about just doing first-entry calls...
Suppose you have a WSDL with a schema describing that the Customer has two fields,
name and a reference to some public repository owned by this customer which one can furher access using HTTP Get/etc... Using WSDL 2 
Http binding you can cause the following pseudo-code be created :

Customer customer = new Customer(...);
String name = customer.getName();
AnyURI repoReference = customer.getRepoReference();

but not :

CustomerRepository repo = customer.getRepoReference();

The problem is that WSDL2 HTTP binding misses what was proposed here awhile back :
http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/att-0088/R085-2003-04-22.html

IMHO WADL, while not a widely supported language can be a very viable and working thing to look at : 
http://weblogs.java.net/blog/mhadley/archive/2006/04/wadl_now_a_sun.html

Cheers, Sergey

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