Guillaume, The problem with this solution are two-fold.
a) It is arbitrarily based on SOAP convention b) It contradicts the solution to the same problem that is explicitly codified in the JBI specification This is really a serious problem because it forces all components that hope to interact with something like servicemix-http to not conform to the JBI specification. At the very least, there should be an option of supporting the spec. -maciej On 9/5/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Yes, WS-I BP 1.1 supports RPC literal, so there will be several parts in the message, but they are all wrapped inside an element with the operation name. This lead to a single child for the soap body element. Currently, servicemix-http passes this child as the content of the normalized message. On 9/5/06, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > > I think Maciej meant "RPC literal" (non-encoded XML), which leads to > multiple parts and is allowed by WS-I BP 1.1. > > alex > > > Guillaume Nodet wrote: > > See > > > http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute > > > > > > it seems pretty clear for me, but maybe i misread it. > > > > On 9/5/06, Maciej Szefler <[EMAIL PROTECTED]> wrote: > >> > >> I don't recall there being anything in WSI-BP that prohibits the > >> usage of > >> RPC-literal encoding, which results in multiple parts. > >> > >> -mbs > >> > >> On 9/5/06, Alex Boisvert <[EMAIL PROTECTED]> wrote: > >> > > >> > > >> > 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 > >> > >> > >> > >> > >> > > > >> > > > >> > > >> > > >> > >> > > > > > > -- Cheers, Guillaume Nodet
