cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: Linkability in the HTTP Binding (was Re: isGET in interceptors...)
Date Wed, 06 Dec 2006 18:40:00 GMT
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 <sergey.beryozkin@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 <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
>>
>>
>
>
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 


Mime
View raw message