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/11/29 20:03:25 UTC
isGET in interceptors...
Hi James,
I noticed you put isGET in several interceptors, including the
AbstractPhaseInterceptor to detect the HTTP get case. I don't think we
should be doing that as those interceptors shouldn't have to be aware of
whether or not it is a GET invocation or not. One way around this might be
to add an interceptor which removes the unncessary interceptors from the
chain for the HTTP GET case...
public classSoapHttpInterceptor {
public void handleMessage(Message m) {
if (isGET()) {
message.getChain().remove(MultipartMessageInterceptor.class.getName()));
...
}
}
}
There might be other ways as well - but I really don't think having isGET
everywhere is the right way to handle things
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: isGET in interceptors...
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 12/15/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I'm not quite sure that there is a need to change the chain
> dynamically at all. Why not considering a tree instead of
> a simple list ? Depending on some conditions (HTTP VERB,
> operation QName, ...), a branch of the tree would be used.
> I guess this may need a bit of design, but would allow a clean
> separation of interceptors between, while allowing a static
> interceptor chain.
I'm not sure I follow. I'm reluctant to introduce some kind of dependency on
HTTP verbs into the core of CXF.
As I said in a previous mail, I don't really see how policies can
> be applied on a per operation level without allowing different
> interceptor chain (or all interceptors would have to check if
> they should be applied, which is the current case with the GET
> problem).
> Would it be too complex ? Or there is no real use case for that ?
I don't know that this is a per-operation issue. We're trying to use the
same BindingOperation for both POST and GET, so I don't see how applying a
policy at that level would help. I do think we need to be able to apply
policies at the operation level though and we already have some hooks for
that. Namely message.getContextualProperty() which searches the message,
exchange, operation, operation, binding, etc.
Can you explain a little more what you mean?
On 12/15/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> > On 12/7/06, James Mao <ja...@iona.com> wrote:
> > >
> > >
> > > I'm OK with the changing the chain dynamically, they both works. if we
> > > change the chain dynamically, then for both the SOAP binding and XML
> > > binding and any other binding to filter the interceptors dynamically,
> i
> > > mean the maintenance cost is same. but this approach do have a
> benefit,
> > > the benefit is that all the isGET logic in the same place, if we want
> to
> > > add some configuration for this function, it'll be more easier. But
> the
> > > other side is, it'll be harder to change the chain if the interceptor
> is
> > > coarse-grained, that means we want some part of the logic of the
> > > inteceptor, but in some conditions we want to exclude the
> interceptors,
> > > but yes, you can break down the interceptors into pieces to work
> around
> > > the problem. So there's pros and cons.
> >
> >
> > Can you please justify the performance benefit of this if we go down
> this
> > route? As noted in the previous email if we have a dynamic interceptor
> > removal, than we still have problems if a user adds an interceptor and
> they
> > aren't aware they need to look for the isGET case.
> >
> > I think we should synthesize a document, and unless you can provide some
> > compelling performance reason I don't see any reason not too. You
> haven't
> > shown anything to back up your reasoning that there is a performance
> issue.
> >
> > - 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: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
Hi Nodet,
> I'm not quite sure that there is a need to change the chain
> dynamically at all.
I don't like the idea neither, and it's the last solution i would like
to try. (And i think DanD also agreed on it)
> Why not considering a tree instead of
> a simple list ?
> Depending on some conditions (HTTP VERB,
> operation QName, ...), a branch of the tree would be used.
> I guess this may need a bit of design, but would allow a clean
> separation of interceptors between, while allowing a static
> interceptor chain.
I think you are right, it's could be tree, and it's not just for HTTP
verb, in some cases we need to dispatch the message in different route.
for example, CXF-147 <http://issues.apache.org/jira/browse/CXF-147> the
mixed bare/wrapped style can be benefit from this approach. and also
CXF-35 <http://issues.apache.org/jira/browse/CXF-35> Support multiple
services/bindings on the same endpoint
<http://issues.apache.org/jira/browse/CXF-35>
I think maybe we should have something call connectors, and the
connectors basically have two interfaces one for the IN interceptor, and
one for OUT interceptor(s), and we can use connectors to chain the
interceptors, so it's the connector to decide which way/exit to go
depending on the message it accepted from the IN interceptor(just like a
switch). but i'm not sure will that works? as you said we need a bit of
design.
current chain is getting more and more complex, we even have sub chain
concept now, it's getting debug more and more difficult. to be honest i
don't like. maybe we should think more about this.
Cheers,
James.
> As I said in a previous mail, I don't really see how policies can
> be applied on a per operation level without allowing different
> interceptor chain (or all interceptors would have to check if
> they should be applied, which is the current case with the GET
> problem).
> Would it be too complex ? Or there is no real use case for that ?
>
> On 12/15/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>> On 12/7/06, James Mao <ja...@iona.com> wrote:
>> >
>> >
>> > I'm OK with the changing the chain dynamically, they both works. if we
>> > change the chain dynamically, then for both the SOAP binding and XML
>> > binding and any other binding to filter the interceptors
>> dynamically, i
>> > mean the maintenance cost is same. but this approach do have a
>> benefit,
>> > the benefit is that all the isGET logic in the same place, if we
>> want to
>> > add some configuration for this function, it'll be more easier. But
>> the
>> > other side is, it'll be harder to change the chain if the
>> interceptor is
>> > coarse-grained, that means we want some part of the logic of the
>> > inteceptor, but in some conditions we want to exclude the
>> interceptors,
>> > but yes, you can break down the interceptors into pieces to work
>> around
>> > the problem. So there's pros and cons.
>>
>>
>> Can you please justify the performance benefit of this if we go down
>> this
>> route? As noted in the previous email if we have a dynamic interceptor
>> removal, than we still have problems if a user adds an interceptor
>> and they
>> aren't aware they need to look for the isGET case.
>>
>> I think we should synthesize a document, and unless you can provide some
>> compelling performance reason I don't see any reason not too. You
>> haven't
>> shown anything to back up your reasoning that there is a performance
>> issue.
>>
>> - Dan
>>
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>
>
>
Re: isGET in interceptors...
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm not quite sure that there is a need to change the chain
dynamically at all. Why not considering a tree instead of
a simple list ? Depending on some conditions (HTTP VERB,
operation QName, ...), a branch of the tree would be used.
I guess this may need a bit of design, but would allow a clean
separation of interceptors between, while allowing a static
interceptor chain.
As I said in a previous mail, I don't really see how policies can
be applied on a per operation level without allowing different
interceptor chain (or all interceptors would have to check if
they should be applied, which is the current case with the GET
problem).
Would it be too complex ? Or there is no real use case for that ?
On 12/15/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> On 12/7/06, James Mao <ja...@iona.com> wrote:
> >
> >
> > I'm OK with the changing the chain dynamically, they both works. if we
> > change the chain dynamically, then for both the SOAP binding and XML
> > binding and any other binding to filter the interceptors dynamically, i
> > mean the maintenance cost is same. but this approach do have a benefit,
> > the benefit is that all the isGET logic in the same place, if we want to
> > add some configuration for this function, it'll be more easier. But the
> > other side is, it'll be harder to change the chain if the interceptor is
> > coarse-grained, that means we want some part of the logic of the
> > inteceptor, but in some conditions we want to exclude the interceptors,
> > but yes, you can break down the interceptors into pieces to work around
> > the problem. So there's pros and cons.
>
>
> Can you please justify the performance benefit of this if we go down this
> route? As noted in the previous email if we have a dynamic interceptor
> removal, than we still have problems if a user adds an interceptor and they
> aren't aware they need to look for the isGET case.
>
> I think we should synthesize a document, and unless you can provide some
> compelling performance reason I don't see any reason not too. You haven't
> shown anything to back up your reasoning that there is a performance issue.
>
> - Dan
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
>
--
Cheers,
Guillaume Nodet
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
>>
>> I'm OK with the changing the chain dynamically, they both works. if we
>> change the chain dynamically, then for both the SOAP binding and XML
>> binding and any other binding to filter the interceptors dynamically, i
>> mean the maintenance cost is same. but this approach do have a benefit,
>> the benefit is that all the isGET logic in the same place, if we want to
>> add some configuration for this function, it'll be more easier. But the
>> other side is, it'll be harder to change the chain if the interceptor is
>> coarse-grained, that means we want some part of the logic of the
>> inteceptor, but in some conditions we want to exclude the interceptors,
>> but yes, you can break down the interceptors into pieces to work around
>> the problem. So there's pros and cons.
>
>
> Can you please justify the performance benefit of this if we go down this
> route? As noted in the previous email if we have a dynamic interceptor
> removal, than we still have problems if a user adds an interceptor and
> they
> aren't aware they need to look for the isGET case.
>
> I think we should synthesize a document, and unless you can provide some
> compelling performance reason I don't see any reason not too. You haven't
> shown anything to back up your reasoning that there is a performance
> issue.
I can provide the performance result as along as you finished the client
part, i thought you haven't finished the client part of the http
binding. am i right?
And i think we can find another way, a better solution for this. i'm
thinking of it, but since i'm working on tooling refactoring, so please
give me a few days on it.
But i dont' think to synthesize a document is a good solution for this
(especially you have to synthesize the doc in both the client and server
side as far as i understood).
So if that's true, i think they are different user scenario. but may be
i'm wrong. because i have not seen a real demo to show how the whole GET
works in the http binding. maybe you can provide a demo to show how it
works? and it'll be easier for us (especially for me) to understand if
they are the same or different scenario. and it'll also easier for me to
test the performance.
BTW, the current hello_world demo(XML binding, SOAP11 binding and SOAP12
binding) already included the GET support.
And if you add the demo, please also add the GET HttpBinding support for
both the xml binding and soap1.1 and soap1.2 binding. I'll give it a try.
Thanks in advance.
James.
Re: isGET in interceptors...
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 12/7/06, James Mao <ja...@iona.com> wrote:
>
>
> I'm OK with the changing the chain dynamically, they both works. if we
> change the chain dynamically, then for both the SOAP binding and XML
> binding and any other binding to filter the interceptors dynamically, i
> mean the maintenance cost is same. but this approach do have a benefit,
> the benefit is that all the isGET logic in the same place, if we want to
> add some configuration for this function, it'll be more easier. But the
> other side is, it'll be harder to change the chain if the interceptor is
> coarse-grained, that means we want some part of the logic of the
> inteceptor, but in some conditions we want to exclude the interceptors,
> but yes, you can break down the interceptors into pieces to work around
> the problem. So there's pros and cons.
Can you please justify the performance benefit of this if we go down this
route? As noted in the previous email if we have a dynamic interceptor
removal, than we still have problems if a user adds an interceptor and they
aren't aware they need to look for the isGET case.
I think we should synthesize a document, and unless you can provide some
compelling performance reason I don't see any reason not too. You haven't
shown anything to back up your reasoning that there is a performance issue.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
Hi Nodet，
> As far as I understand the SOAP 1.2 spec, the GET HTTP verb is used
> for the SOAP Response MEP, which means there is no input message,
> but only a response message. So this is part of the SOAP binding
> and, as you said, there is no relationship with the HTTP binding.
Yes i agree, in SOAP1.2 GET HTTP verb, there is no input message, but
has the HTTP GET request, right?
So, that's how current isGET works， you can use browser to get the
response message back.
So uri scheme we used is
http://localhost/SoapContext/SoapPort/greetMe/me/CXF or
http://localhost/SoapContext/SoapPort/greetMe/?me=CXF
And the basic idea is that other language can also consume the service ,
for example, for PHP , you can use the curl to GET the response message
from the service.
And eventually, the isGET not only support SOAP1.2, but support SOAP1.1
and XML binding as well.
>
> As far as the code is concerned, I don't know how is the plan to support
> policies definition at the operation level (or is it already done ?),
> but I don't
> really understand how it would be possible without changing the
> interceptor
> chain dynamically, or by defining a tree of interceptors (instead of a
> list), where
> a subtree would be picked given the ongoing operation. This is the
> same problem
> for the GET / POST problem on the SOAP binding: an operation can be
> mapped
> to a GET request, while another one would be mapped to a POST request.
> So you need to select a subtree of the interceptor chain here.
>
Because it's GET, so the client side is just URLConnection, or the
client is the browser, there is a URIMappingInterceptor sit in the
server side,
the isGET will skip all the interceptors not necessary in GET
processing, it's the URIMapping interceptor to dispatch the invocation.
the rest is as same as the POST processing.
I'm OK with the changing the chain dynamically, they both works. if we
change the chain dynamically, then for both the SOAP binding and XML
binding and any other binding to filter the interceptors dynamically, i
mean the maintenance cost is same. but this approach do have a benefit,
the benefit is that all the isGET logic in the same place, if we want to
add some configuration for this function, it'll be more easier. But the
other side is, it'll be harder to change the chain if the interceptor is
coarse-grained, that means we want some part of the logic of the
inteceptor, but in some conditions we want to exclude the interceptors,
but yes, you can break down the interceptors into pieces to work around
the problem. So there's pros and cons.
Cheers,
James.
Re: isGET in interceptors...
Posted by Guillaume Nodet <gn...@gmail.com>.
On 12/6/06, James Mao <ja...@iona.com> wrote:
>
> > 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?
As far as I understand the SOAP 1.2 spec, the GET HTTP verb is used
for the SOAP Response MEP, which means there is no input message,
but only a response message. So this is part of the SOAP binding
and, as you said, there is no relationship with the HTTP binding.
As far as the code is concerned, I don't know how is the plan to support
policies definition at the operation level (or is it already done ?),
but I don't
really understand how it would be possible without changing the interceptor
chain dynamically, or by defining a tree of interceptors (instead of a
list), where
a subtree would be picked given the ongoing operation. This is the same problem
for the GET / POST problem on the SOAP binding: an operation can be mapped
to a GET request, while another one would be mapped to a POST request.
So you need to select a subtree of the interceptor chain here.
> >
> > 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 <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
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
> 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 <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
>>
>>
>
>
Re: isGET in interceptors...
Posted by Sergey Beryozkin <se...@iona.com>.
> 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
Re: isGET in interceptors...
Posted by Guillaume Nodet <gn...@gmail.com>.
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
Re: isGET in interceptors...
Posted by Dan Diephouse <da...@envoisolutions.com>.
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
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
Hi Dan,
>
>
> No, I mean they have different code paths. The interceptors needed for
> the
> GET case are different than for the POST case. And hence they should have
> operate as a different Binding.
Different code path is fine to me.
>
>>
>> >> >
>> >> > I think we need to come up with a better way. My preference would
>> >> be to
>> >> > unify the code in the HTTP binding and the current HTTP GET/POST
>> for
>> >> > the XML
>> >> > & SOAP bindings.
>> >> The HTTP GET we implemented and the HTTP binding are different
>> things,
>> i
>> >> don't think we need to combine.
>> >> If it's GET, there is no need to synthesizes a document, that will
>> slow
>> >> down the processing.
>> >
>> >
>> > As I mentioned above, I don't really see squeezing out top performance
>> of
>> > SOAP HTTP GET a goal. I doubt this makes more than a 10% difference.
>> I don't have a test result for this. but think about there is no
>> marshall/unmarshall in the client side ,
>> and there is no unmarshall in the service side, there is only marshal
>> happen in the service side.
>> If we synthesizes a document, there will have marshall/unmarshall in the
>> client side, and there will have marshall/unmarshall in the service
>> side. am i correct?
>
>
> Yup.
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.
If the client also will have marshall/unmarshall, how can you say that
it's a HTTP GET approach?
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?
>
> I mean, that's will degrade the performance, and i don't like it, as a
>> GET i suppose it's quicker and simpler than normal invocation, and i
>> think that the big benefit we use GET, right?
>> otherwise, why people select GET?
>
>
> 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.)
>
>>
>> > I'm not saying that is hard to understand. I'm saying that IMO it
>> isn't
>> > clean code, it mixes concerns, and is bad for code maintainability.
>> >
>> > All this debating isn't relevant if we make SOAP+GET a separate
>> > binding on
>> > the service with its own interceptors. See my proposal on the mailing
>> > list
>> > for how this might work. My other proposal is that we just make
>> > synthesize a
>> > document like the HTTP Binding. I'm OK with either of those options,
>> > but I'm
>> > really not OK with the current way for the reasons I mentioned above.
>> >
>> As i said to synthesize a document is really not a good way to do this.
>> seems that change the chain dynamically better than synthesize a
>> document, but as is said it's not that good too, for example, sometimes
>> we want to use an interceptor, but we need to skip the interceptor in
>> some cases.
>>
>
> And from a maintenance point view, i really didn't see any difference.
>>
>
> I do - we no longer have to muck with isGET in the normal interceptor
> chain.
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.
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.
>
>
> I'm open to change. and i think we can find a better solution. right?
>
>
> To recap, the problems with the current solution:
> 1. It requires all the other interceptors to be aware of whether or not
> there is a GET operation going on. The code is supposed to be transport
> agnostic, so this is bad from a code cleanliness and maintenance point of
> view.
> 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?
> 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 the most important thing is that we can keep the GET as fast as it
>> could be. and make user easier to use the service, no extra learning
>> curve.
>> Any implementation can achieve this goal, is a good implementation.
>> If we can improve the current implementation and also achieve the goal
>> that's a correct thing to do.
>>
>
> Why is performance of SOAP HTTP GET so important to you? Most of the XML
> performance issues are in actually parsing the XML text. Constructing a
> Document and passing it into JAXB take a very small amount of time. I
> think
> your concern with performance here is very unfounded.
>
> My preferred solution is to just synthesize a document. I doubt there is
> more than a 10% performance difference. Feel free to prove me
> otherwise, but
> it the 10% difference in the GET case is just not worth it for the
> problems
> I outlined above.
Cheers,
James.
Re: isGET in interceptors...
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 12/3/06, James Mao <ja...@iona.com> wrote:
>
> Hi Dan
> >
> > There are maintenance issues with both isGET and changing the chain
> > dynamically.
> Agreed
> > After thinking about this today, I think its because you're
> > making things harder by combining two bindings into one. GET is really a
> > separate WSDL binding and I think we should treat it as so within CXF as
> > well. See my proposal on the mailing list about this, but I think its
> > wrong
> > to mix the GET and POST bindings together.
> I'm not quite understand why there's a problem of mixing the GET and
> POST together? You mean when user want to use GET, he should configure the
> service as a
> GET service， and configure the POST as POST service?
No, I mean they have different code paths. The interceptors needed for the
GET case are different than for the POST case. And hence they should have
operate as a different Binding.
>
> >> >
> >> > I think we need to come up with a better way. My preference would
> >> be to
> >> > unify the code in the HTTP binding and the current HTTP GET/POST for
> >> > the XML
> >> > & SOAP bindings.
> >> The HTTP GET we implemented and the HTTP binding are different things,
> i
> >> don't think we need to combine.
> >> If it's GET, there is no need to synthesizes a document, that will slow
> >> down the processing.
> >
> >
> > As I mentioned above, I don't really see squeezing out top performance
> of
> > SOAP HTTP GET a goal. I doubt this makes more than a 10% difference.
> I don't have a test result for this. but think about there is no
> marshall/unmarshall in the client side ,
> and there is no unmarshall in the service side, there is only marshal
> happen in the service side.
> If we synthesizes a document, there will have marshall/unmarshall in the
> client side, and there will have marshall/unmarshall in the service
> side. am i correct?
Yup.
I mean, that's will degrade the performance, and i don't like it, as a
> GET i suppose it's quicker and simpler than normal invocation, and i
> think that the big benefit we use GET, right?
> otherwise, why people select GET?
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'm not saying that is hard to understand. I'm saying that IMO it isn't
> > clean code, it mixes concerns, and is bad for code maintainability.
> >
> > All this debating isn't relevant if we make SOAP+GET a separate
> > binding on
> > the service with its own interceptors. See my proposal on the mailing
> > list
> > for how this might work. My other proposal is that we just make
> > synthesize a
> > document like the HTTP Binding. I'm OK with either of those options,
> > but I'm
> > really not OK with the current way for the reasons I mentioned above.
> >
> As i said to synthesize a document is really not a good way to do this.
> seems that change the chain dynamically better than synthesize a
> document, but as is said it's not that good too, for example, sometimes
> we want to use an interceptor, but we need to skip the interceptor in
> some cases.
>
And from a maintenance point view, i really didn't see any difference.
>
I do - we no longer have to muck with isGET in the normal interceptor chain.
I'm open to change. and i think we can find a better solution. right?
To recap, the problems with the current solution:
1. It requires all the other interceptors to be aware of whether or not
there is a GET operation going on. The code is supposed to be transport
agnostic, so this is bad from a code cleanliness and maintenance point of
view.
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
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.
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
And the most important thing is that we can keep the GET as fast as it
> could be. and make user easier to use the service, no extra learning
> curve.
> Any implementation can achieve this goal, is a good implementation.
> If we can improve the current implementation and also achieve the goal
> that's a correct thing to do.
>
Why is performance of SOAP HTTP GET so important to you? Most of the XML
performance issues are in actually parsing the XML text. Constructing a
Document and passing it into JAXB take a very small amount of time. I think
your concern with performance here is very unfounded.
My preferred solution is to just synthesize a document. I doubt there is
more than a 10% performance difference. Feel free to prove me otherwise, but
it the 10% difference in the GET case is just not worth it for the problems
I outlined above.
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
Hi Dan
>
> There are maintenance issues with both isGET and changing the chain
> dynamically.
Agreed
> After thinking about this today, I think its because you're
> making things harder by combining two bindings into one. GET is really a
> separate WSDL binding and I think we should treat it as so within CXF as
> well. See my proposal on the mailing list about this, but I think its
> wrong
> to mix the GET and POST bindings together.
I'm not quite understand why there's a problem of mixing the GET and
POST together?
You mean when user want to use GET, he should configure the service as a
GET service，
and configure the POST as POST service?
>
>> >
>> > I think we need to come up with a better way. My preference would
>> be to
>> > unify the code in the HTTP binding and the current HTTP GET/POST for
>> > the XML
>> > & SOAP bindings.
>> The HTTP GET we implemented and the HTTP binding are different things, i
>> don't think we need to combine.
>> If it's GET, there is no need to synthesizes a document, that will slow
>> down the processing.
>
>
> As I mentioned above, I don't really see squeezing out top performance of
> SOAP HTTP GET a goal. I doubt this makes more than a 10% difference.
I don't have a test result for this. but think about there is no
marshall/unmarshall in the client side ,
and there is no unmarshall in the service side, there is only marshal
happen in the service side.
If we synthesizes a document, there will have marshall/unmarshall in the
client side, and there will have marshall/unmarshall in the service
side. am i correct?
I mean, that's will degrade the performance, and i don't like it, as a
GET i suppose it's quicker and simpler than normal invocation, and i
think that the big benefit we use GET, right?
otherwise, why people select GET?
>
> I'm not saying that is hard to understand. I'm saying that IMO it isn't
> clean code, it mixes concerns, and is bad for code maintainability.
>
> All this debating isn't relevant if we make SOAP+GET a separate
> binding on
> the service with its own interceptors. See my proposal on the mailing
> list
> for how this might work. My other proposal is that we just make
> synthesize a
> document like the HTTP Binding. I'm OK with either of those options,
> but I'm
> really not OK with the current way for the reasons I mentioned above.
>
As i said to synthesize a document is really not a good way to do this.
seems that change the chain dynamically better than synthesize a
document, but as is said it's not that good too, for example, sometimes
we want to use an interceptor, but we need to skip the interceptor in
some cases.
And from a maintenance point view, i really didn't see any difference.
I'm open to change. and i think we can find a better solution. right?
And the most important thing is that we can keep the GET as fast as it
could be. and make user easier to use the service, no extra learning curve.
Any implementation can achieve this goal, is a good implementation.
If we can improve the current implementation and also achieve the goal
that's a correct thing to do.
Cheers,
James.
Re: isGET in interceptors...
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi James,
On 11/30/06, James Mao <ja...@iona.com> wrote:
>
> Hi Dan,
>
> >
> > Not to me. Now we have 9 different references to isGET scattered
> > throughout
> > the codebase. What happens when users write their own interceptors?
> > They're
> > going to be surprised to find that their interceptor breaks GET usage.
> > We've
> > just made things harder from a developer and user's perspective.
> User will not care about this, they got the feature, they gonna enjoy it.
> For a developer, they also like an easy way to do things, isGET is
> easier to understand than introduce another interceptor, and change the
> chain dynamically,
> that's harder to understand and and harder to debug, and harder to
> maintain
There are maintenance issues with both isGET and changing the chain
dynamically. After thinking about this today, I think its because you're
making things harder by combining two bindings into one. GET is really a
separate WSDL binding and I think we should treat it as so within CXF as
well. See my proposal on the mailing list about this, but I think its wrong
to mix the GET and POST bindings together.
>
> >
> > And I think to remove the interceptors dynamically also cause the
> >> performance issue.
> >
> >
> > I don't think it will be that much of a performance hit. Also, I don't
> > really care about the performance of the SOAP HTTP GET case. Its a
> > secondary
> > concern of ours.
> I didn't say a *LOT*, what i said is *better*
> *Performance* definitely is a *feature* in my mind, don't need to put it
> in the first place, but if we have a good performance, there's no reason
> to change it back to a bad performance.
Performance of SOAP HTTP GET doesn't not trump maintainable and clean code
IMO.
> >
> > I think we need to come up with a better way. My preference would be to
> > unify the code in the HTTP binding and the current HTTP GET/POST for
> > the XML
> > & SOAP bindings.
> The HTTP GET we implemented and the HTTP binding are different things, i
> don't think we need to combine.
> If it's GET, there is no need to synthesizes a document, that will slow
> down the processing.
As I mentioned above, I don't really see squeezing out top performance of
SOAP HTTP GET a goal. I doubt this makes more than a 10% difference.
And I think that's two different use scenario, the HTTP binding require
> user to add extra annotation(extra learning curve, and need to know how
> the mapping works, then you will add documentation, explanations do have
> cost), in isGET way, they don't
> What user need to now is that he/she can use URLConnection invoke the
> service directly, that's *all* he/she need to know, simple, easy, and fast
> For a developer, there's nothing more he/she need to do, almost done for
> them, what he/she need to know is understand what isGET mean, that thing
> can understand in seconds, right?
I'm not saying that we should require annotations for SOAP+GET, I'm saying
that we could just reuse the code to synthesize the document from the URL
parameters and do a similar thing with SOAP+GET case.
So, all in all, the only thing in common is that they all used the GET,
> but that's not the reason we need to combine, they are really two
> different use scenario.
> If someone can not understand what isGET means, i'll be surprised. Let
> me know if there's any problem of isGET that block your work or
> understanding.
I'm not saying that is hard to understand. I'm saying that IMO it isn't
clean code, it mixes concerns, and is bad for code maintainability.
All this debating isn't relevant if we make SOAP+GET a separate binding on
the service with its own interceptors. See my proposal on the mailing list
for how this might work. My other proposal is that we just make synthesize a
document like the HTTP Binding. I'm OK with either of those options, but I'm
really not OK with the current way for the reasons I mentioned above.
Regards,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
Hi Dan,
>
> Not to me. Now we have 9 different references to isGET scattered
> throughout
> the codebase. What happens when users write their own interceptors?
> They're
> going to be surprised to find that their interceptor breaks GET usage.
> We've
> just made things harder from a developer and user's perspective.
User will not care about this, they got the feature, they gonna enjoy it.
For a developer, they also like an easy way to do things, isGET is
easier to understand than introduce another interceptor, and change the
chain dynamically,
that's harder to understand and and harder to debug, and harder to maintain
>
>
> And I think to remove the interceptors dynamically also cause the
>> performance issue.
>
>
> I don't think it will be that much of a performance hit. Also, I don't
> really care about the performance of the SOAP HTTP GET case. Its a
> secondary
> concern of ours.
I didn't say a *LOT*, what i said is *better*
*Performance* definitely is a *feature* in my mind, don't need to put it
in the first place, but if we have a good performance, there's no reason
to change it back to a bad performance.
>
> The isGet just boost the processing, it will return fast if it detect
>> it's a GET method and the interceptor has nothing to do with GET.
>> I didn't see any harm to do so, it's just a three check lines, the code
>> is readable, and easy to maintain.
>> And it's extremely fast when you try SOAP GET, or XML GET, i have
>> checked in a demo to show how it works with SOAP12
>> it's in samples/soap12, but you can try other demos as well.
>> Usage:
>> > ant client.get
>>
>> You can even use your favorite browser to GET the service
>>
>> I might think to check in a PHP demo or Ruby demo to show how other
>> language can consume CXF service through the HTTP GET.
>
>
>
> I'm aware of how it works. And I like the feature. But I don't like
> the way
> it was implemented as it has side effects all throughout the code
> base. This
> is part of the reason the HTTP binding just synthesizes a document.
I guess developers and users are all like feature, because it's easy and
fast.
>
> I think we need to come up with a better way. My preference would be to
> unify the code in the HTTP binding and the current HTTP GET/POST for
> the XML
> & SOAP bindings.
The HTTP GET we implemented and the HTTP binding are different things, i
don't think we need to combine.
If it's GET, there is no need to synthesizes a document, that will slow
down the processing.
And I think that's two different use scenario, the HTTP binding require
user to add extra annotation(extra learning curve, and need to know how
the mapping works, then you will add documentation, explanations do have
cost), in isGET way, they don't
What user need to now is that he/she can use URLConnection invoke the
service directly, that's *all* he/she need to know, simple, easy, and fast
For a developer, there's nothing more he/she need to do, almost done for
them, what he/she need to know is understand what isGET mean, that thing
can understand in seconds, right?
So, all in all, the only thing in common is that they all used the GET,
but that's not the reason we need to combine, they are really two
different use scenario.
If someone can not understand what isGET means, i'll be surprised. Let
me know if there's any problem of isGET that block your work or
understanding.
BTW, i have updated the READEM
Thanks,
James.
Re: isGET in interceptors...
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 11/29/06, James Mao <ja...@iona.com> wrote:
>
> Hi Dan,
>
> It's not just SoapHttp, it works for all the *Http Bindings, so
> currently it works for XMLBinding SOAP11 and SOAP12.
> If we do what you said, there still will have several interceptors
> introduced, it increase the complexity in my mind.
> If we add new interceptors, and it's nothing to do with GET, we still
> need to add the interceptor to the exclude list, that cause the maintain
> cost.
> If we just add
> if (isGET()) {
> return;
> }
> That's more easier to understand how the GET works. the way just make
> more sense to me.
Not to me. Now we have 9 different references to isGET scattered throughout
the codebase. What happens when users write their own interceptors? They're
going to be surprised to find that their interceptor breaks GET usage. We've
just made things harder from a developer and user's perspective.
And I think to remove the interceptors dynamically also cause the
> performance issue.
I don't think it will be that much of a performance hit. Also, I don't
really care about the performance of the SOAP HTTP GET case. Its a secondary
concern of ours.
The isGet just boost the processing, it will return fast if it detect
> it's a GET method and the interceptor has nothing to do with GET.
> I didn't see any harm to do so, it's just a three check lines, the code
> is readable, and easy to maintain.
> And it's extremely fast when you try SOAP GET, or XML GET, i have
> checked in a demo to show how it works with SOAP12
> it's in samples/soap12, but you can try other demos as well.
> Usage:
> > ant client.get
>
> You can even use your favorite browser to GET the service
>
> I might think to check in a PHP demo or Ruby demo to show how other
> language can consume CXF service through the HTTP GET.
I'm aware of how it works. And I like the feature. But I don't like the way
it was implemented as it has side effects all throughout the code base. This
is part of the reason the HTTP binding just synthesizes a document.
I think we need to come up with a better way. My preference would be to
unify the code in the HTTP binding and the current HTTP GET/POST for the XML
& SOAP bindings.
I think doing the document synthesis is the best way as you can leverage
your databinding layer then. It has the following advantages:
1. GET with the HTTP binding works with types beyond just the simple Java
types (i.e. it could work with Dates or enumerations)
2. It doesn't scatter HTTP code throughout our codebase
3. It doesn't force developers to know about isGET
4. It leverages the existing databinding to do work for us
5. It creates less code as we don't have two different HTTP GET mapping
mechanisms in the codebase
As I said I really don't care too much about HTTP GET performance. Have you
done performance tests? I doubt that creating a small small document really
creates too much of a hit anyway.
Regards
- Dan
>
>
>
>
> > Hi James,
> > I noticed you put isGET in several interceptors, including the
> > AbstractPhaseInterceptor to detect the HTTP get case. I don't think we
> > should be doing that as those interceptors shouldn't have to be aware of
> > whether or not it is a GET invocation or not. One way around this
> > might be
> > to add an interceptor which removes the unncessary interceptors from the
> > chain for the HTTP GET case...
> >
> > public classSoapHttpInterceptor {
> > public void handleMessage(Message m) {
> > if (isGET()) {
> > message.getChain().remove(MultipartMessageInterceptor.class.getName
> ()));
> > ...
> > }
> > }
> > }
> >
> > There might be other ways as well - but I really don't think having
> isGET
> > everywhere is the right way to handle things
> >
> > Cheers,
> > - Dan
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: isGET in interceptors...
Posted by James Mao <ja...@iona.com>.
Hi Dan,
It's not just SoapHttp, it works for all the *Http Bindings, so
currently it works for XMLBinding SOAP11 and SOAP12.
If we do what you said, there still will have several interceptors
introduced, it increase the complexity in my mind.
If we add new interceptors, and it's nothing to do with GET, we still
need to add the interceptor to the exclude list, that cause the maintain
cost.
If we just add
if (isGET()) {
return;
}
That's more easier to understand how the GET works. the way just make
more sense to me.
And I think to remove the interceptors dynamically also cause the
performance issue.
The isGet just boost the processing, it will return fast if it detect
it's a GET method and the interceptor has nothing to do with GET.
I didn't see any harm to do so, it's just a three check lines, the code
is readable, and easy to maintain.
And it's extremely fast when you try SOAP GET, or XML GET, i have
checked in a demo to show how it works with SOAP12
it's in samples/soap12, but you can try other demos as well.
Usage:
> ant client.get
You can even use your favorite browser to GET the service
I might think to check in a PHP demo or Ruby demo to show how other
language can consume CXF service through the HTTP GET.
Thanks,
James.
> Hi James,
> I noticed you put isGET in several interceptors, including the
> AbstractPhaseInterceptor to detect the HTTP get case. I don't think we
> should be doing that as those interceptors shouldn't have to be aware of
> whether or not it is a GET invocation or not. One way around this
> might be
> to add an interceptor which removes the unncessary interceptors from the
> chain for the HTTP GET case...
>
> public classSoapHttpInterceptor {
> public void handleMessage(Message m) {
> if (isGET()) {
> message.getChain().remove(MultipartMessageInterceptor.class.getName()));
> ...
> }
> }
> }
>
> There might be other ways as well - but I really don't think having isGET
> everywhere is the right way to handle things
>
> Cheers,
> - Dan
>