Oh yes, good question! The point of mapping headers into message
content is that many applications/frameworks do not give you easy access
(or advise against accessing) message headers.
Take, for example, BPEL processes. BPEL only gives you access to the
abstract message definition. If headers are not defined and mapped into
the content, you can't access them in a portable way.
Maybe we could have a configuration attribute to normalize using WSDL
1.1 or WSDL 2.0? That way, if there are no mapped headers and only one
SOAP body element, then we could have basic support for WSDL 2.0.
I'm very interested in getting full WSDL 1.1 support because that's
what's mostly used and deployed today. The tooling and infrastructure
ecosystem works great with WSDL 1.1 but still has ways to go with WSDL
2.0. With complete WSDL 1.1 support, we can make the most of
ServiceMix today and gradually migrate to WSDL 2.0 when it becomes more
widespread.
alex
Guillaume Nodet wrote:
I have attached an updated patch to the jira
http://issues.apache.org/activemq/secure/ManageAttachments.jspa?id=24443
I still have some questions, now that I have a better understanding of
what
the
patch do. Mainly, I'm questionning the need to the wsdl 1.1 jbi wrapper.
If all services exposed and invoked by servicemix are ws-i basic profile
compliant, there is only one child in the soap body. Other parts that
may be included in the normalized message may come from soap headers.
So we are in the same case as for WSDL 2.0: only one element in the
soap body, and additioanl soap headers. However, for WSDL 2, soap
headers won't be mapped inside the xml content, but should be put
as properties on the message. So i'm not quite sure if headers should
be put inside the content for WSDL 1.1, as it will not be consistent.
I don't really see the point of the wrapper here.
Thoughts ?
On 8/31/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Guillaume Nodet wrote:
> 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.
Ok, that clarifies it.
> 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.
Cool! I might be able to help with WSDL 2.0 as well.
thanks,
alex
