I'm working on that now.
A few comments inline.
On 8/30/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Guillaume Nodet wrote:
> Some existing components
> may already expose a WSDL 1.1 (as WSDL 2.0 is not supported
> yet) which may contain a soap binding. While this is not a good thing,
> we need to cope with them.
How difficult would it be to fix these components? It might be more
worthwhile to attack the problem at the root...
Agreed. I will do it after.
That' s the reason why I don't really like the mechanism to auto-discover
> the WSDL and engage the WSDL 1.1 normalization if the target
> endpoint WSDL contain a soap binding. I think this should be
> configured with a flag on the http consumer endpoint. And existing
> components should be enhanced to use this normalization (but that' s
> another problem).
That's understood. I was looking for feedback on "how" to configure
this behavior. I'll look into adding a flag on the http consumer
endpoint.
The binding model should only be built on top of the wsdl for the current
HttpEndpoint (either consumer or provider). This WSDL can be
explicitely set, or may be auto-generated using the target endpoint
WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL
is generated, we have to:
* check if there is any existing binding infos (for example, if the target
endpoint is a soap provider). In this case, we should use the binding
informations
* else, we need a flag on the http endpoint to set the binding style
(rpc / doc). If the user need to provide a more detailed binding,
then he has to provide it in the wsdl.
Another slight oversight I think, is that the SoapHelper#findOperation
> should
> only check the WSDL for the current endpoint, and this WSDL should be
> modified according to the binding used. We should also provide a way to
> easily configure the binding with default values (let's say just doclit
/
> rpc)
> by setting a flag on the http endpoint.
I'm not sure I follow here. Do you mean that #findOperation should not
check the WSDL of the target ServiceEndpoint? If so, I can remove that.
On the second point, it sounds like fixing the WSDL document is easier
and better than adding configuration on the endpoint... unless I'm
missing something.
See previous comment.
So, while I think this is a really good patch that enhance the current
> http
> component, it is part of a bigger feature. It may even be linked to
WSDL
> 2.0 support, or full rest support.
I'm trying to abstract the SoapBindingModel a bit more to be able to
easily handle a plain HTTP binding.
WSDL 2.0 bindings will require another reformat later i guess.
> If I find enough time (may not be this week), I'll try to handle these
> two
> points
> in a simple way for the moment, so that this great and needed feature
> can be
> used. But if you want to take a look at it, feel free to do so.
>
> Also, I think I have seen some removed / commented features about
> security. I think this is a patch I applied recently...
Ok, I'll double-check.
alex
--
Cheers,
Guillaume Nodet
