On 12/5/06, James Mao <[EMAIL PROTECTED]> 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
