You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2006/12/06 19:04:20 UTC
Linkability in the HTTP Binding (was Re: isGET in interceptors...)
Hi Sergey,
Thanks for that WSDL2 proposal link, that is very interesting and your
example highlights exactly where I am stuck right now.
Currently the HTTP binding has no concept of linkability. How this should be
implemented is very tricky. Your example below highlights integrating it
into the data model. This begs the question - if I'm designing a schema,
should I design it in context of HTTP and resources? If the answer is yes,
than you have a much different schema than you might have with SOAP. It also
makes for a different client API.
But many people don't want to design schemas in the context of HTTP and
URIs. They might share schemas with SOAP service or other departments that
have different resource mappings. So the other option that I can think of is
to somehow make the HTTP binding aware of URIs and references and have some
kind of pointer mechanism. But I'm not sure there is a transparent way to
enable HTTP linkability without affecting your data model.
Abdera (which implements the Atom Publishing Protocol) took the former
approach to this. Their client is completely URI based:
http://incubator.apache.org/abdera/docs/api/index.html?org/apache/abdera/protocol/client/Client.html
I'd really like to integrate an XPointer mechanism into the HTTP binding.
I'm just trying to figure out the most natural way to do so. A couple
questions I've been pondering:
- How do we construct URIs on the server side to give references to other
resources? Some type of URIContext? i.e. uriContext.createURI("/customer/" +
id)?
- Wouldn't that tie our service implementation to the specific resources it
is serving out? Is that desirable?
- Can we do automatic reference creation? i.e. return a collection of
customers, and have some annotation which says "take the ID field and
construct this URI:. @CollectionReference("/customer/{id}")
Hopefully that made some sense. I'm still collecting my thoughts on this.
Regards
- Dan
On 12/6/06, Sergey Beryozkin <se...@iona.com> wrote:
>
> > 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 <da...@envoisolutions.com> wrote:
> >> On 12/5/06, James Mao <ja...@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
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Linkability in the HTTP Binding (was Re: isGET in interceptors...)
Posted by Sergey Beryozkin <se...@iona.com>.
Sorry, may be my last message was a bit too theoretical :-). I jsut wanted to clarify that probably irrespectively of whether we
have SOAP or not, the question is how to represent a reference from a parent resource to some other resource, say we have a
collection of things...Perhaps in case of SOAP one may or may not use WS-Addressing to represent references to other resources , in
headers, or directly inside the collection representation, or use URI, again conveyed in custom headers or inside the collection,
but either way we can link resources at interface and binding level so that even in case of SOAP we don't write :
WS-Addressing ref = Customer.getReference()
CustomerRepo repo = new CustomerRepo(ref)
Either way, it's great you've started looking into this issue...
The reason I also mention WADL is that linkability is something which should be resolved there though I can't confirm...but I doid
hear it was on the map...If it were then perhaps one would be able to use WADL definitionss too (in conjunction with WADL
processor), in addition to other definitions...
Cheers, Sergey
----- Original Message -----
From: "Sergey Beryozkin" <se...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Wednesday, December 06, 2006 6:40 PM
Subject: Re: Linkability in the HTTP Binding (was Re: isGET in interceptors...)
> Hi Dan
>
>> into the data model. This begs the question - if I'm designing a schema,
>> should I design it in context of HTTP and resources? If the answer is yes,
>> than you have a much different schema than you might have with SOAP. It also
>> makes for a different client API.
>
> I think t's all down to the binding and interface level, it's there, say at the interface level, where one can nominate, through
> the XPath expression, that a certain attribute/element value (it doesn't even has to be called 'href') represents a reference to a
> resource whose schema is located either in the same WSDL, perhaps even in the same schema where the parent resource is defined...
>
> So if we have say Customer and CustomerRepo beans then they're annotated the same way, as you propose, but in the (WSDL)contract
> doc, at the interface/binding level we can just link them together through an XPath expression...perhaps using CXF specific WSDL
> extensores...
>
> Cheers, Sergey
>
>> - Can we do automatic reference creation? i.e. return a collection of
>> customers, and have some annotation which says "take the ID field and
>> construct this URI:. @CollectionReference("/customer/{id}")
>
>
>
>> Hi Sergey,
>>
>> Thanks for that WSDL2 proposal link, that is very interesting and your
>> example highlights exactly where I am stuck right now.
>>
>> Currently the HTTP binding has no concept of linkability. How this should be
>> implemented is very tricky. Your example below highlights integrating it
>> into the data model. This begs the question - if I'm designing a schema,
>> should I design it in context of HTTP and resources? If the answer is yes,
>> than you have a much different schema than you might have with SOAP. It also
>> makes for a different client API.
>>
>> But many people don't want to design schemas in the context of HTTP and
>> URIs. They might share schemas with SOAP service or other departments that
>> have different resource mappings. So the other option that I can think of is
>> to somehow make the HTTP binding aware of URIs and references and have some
>> kind of pointer mechanism. But I'm not sure there is a transparent way to
>> enable HTTP linkability without affecting your data model.
>>
>> Abdera (which implements the Atom Publishing Protocol) took the former
>> approach to this. Their client is completely URI based:
>>
>> http://incubator.apache.org/abdera/docs/api/index.html?org/apache/abdera/protocol/client/Client.html
>>
>> I'd really like to integrate an XPointer mechanism into the HTTP binding.
>> I'm just trying to figure out the most natural way to do so. A couple
>> questions I've been pondering:
>> - How do we construct URIs on the server side to give references to other
>> resources? Some type of URIContext? i.e. uriContext.createURI("/customer/" +
>> id)?
>> - Wouldn't that tie our service implementation to the specific resources it
>> is serving out? Is that desirable?
>> - Can we do automatic reference creation? i.e. return a collection of
>> customers, and have some annotation which says "take the ID field and
>> construct this URI:. @CollectionReference("/customer/{id}")
>>
>> Hopefully that made some sense. I'm still collecting my thoughts on this.
>>
>> Regards
>> - Dan
>>
>> On 12/6/06, Sergey Beryozkin <se...@iona.com> wrote:
>>>
>>> > 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 <da...@envoisolutions.com> wrote:
>>> >> On 12/5/06, James Mao <ja...@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
>>>
>>>
>>
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>
Re: Linkability in the HTTP Binding (was Re: isGET in interceptors...)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Dan
> into the data model. This begs the question - if I'm designing a schema,
> should I design it in context of HTTP and resources? If the answer is yes,
> than you have a much different schema than you might have with SOAP. It also
> makes for a different client API.
I think t's all down to the binding and interface level, it's there, say at the interface level, where one can nominate, through the
XPath expression, that a certain attribute/element value (it doesn't even has to be called 'href') represents a reference to a
resource whose schema is located either in the same WSDL, perhaps even in the same schema where the parent resource is defined...
So if we have say Customer and CustomerRepo beans then they're annotated the same way, as you propose, but in the (WSDL)contract
doc, at the interface/binding level we can just link them together through an XPath expression...perhaps using CXF specific WSDL
extensores...
Cheers, Sergey
> - Can we do automatic reference creation? i.e. return a collection of
> customers, and have some annotation which says "take the ID field and
> construct this URI:. @CollectionReference("/customer/{id}")
> Hi Sergey,
>
> Thanks for that WSDL2 proposal link, that is very interesting and your
> example highlights exactly where I am stuck right now.
>
> Currently the HTTP binding has no concept of linkability. How this should be
> implemented is very tricky. Your example below highlights integrating it
> into the data model. This begs the question - if I'm designing a schema,
> should I design it in context of HTTP and resources? If the answer is yes,
> than you have a much different schema than you might have with SOAP. It also
> makes for a different client API.
>
> But many people don't want to design schemas in the context of HTTP and
> URIs. They might share schemas with SOAP service or other departments that
> have different resource mappings. So the other option that I can think of is
> to somehow make the HTTP binding aware of URIs and references and have some
> kind of pointer mechanism. But I'm not sure there is a transparent way to
> enable HTTP linkability without affecting your data model.
>
> Abdera (which implements the Atom Publishing Protocol) took the former
> approach to this. Their client is completely URI based:
>
> http://incubator.apache.org/abdera/docs/api/index.html?org/apache/abdera/protocol/client/Client.html
>
> I'd really like to integrate an XPointer mechanism into the HTTP binding.
> I'm just trying to figure out the most natural way to do so. A couple
> questions I've been pondering:
> - How do we construct URIs on the server side to give references to other
> resources? Some type of URIContext? i.e. uriContext.createURI("/customer/" +
> id)?
> - Wouldn't that tie our service implementation to the specific resources it
> is serving out? Is that desirable?
> - Can we do automatic reference creation? i.e. return a collection of
> customers, and have some annotation which says "take the ID field and
> construct this URI:. @CollectionReference("/customer/{id}")
>
> Hopefully that made some sense. I'm still collecting my thoughts on this.
>
> Regards
> - Dan
>
> On 12/6/06, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> > 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 <da...@envoisolutions.com> wrote:
>> >> On 12/5/06, James Mao <ja...@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
>>
>>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>