I do agree.  I do not really question this need for wsdl 1.1,
but I' d like to find how you will handle soap headers in WSDL 2,
and i think JBI components will have to retrieve the headers from
the message properties and not from the xml content.
This is also true for optional soap headers in WSDL 1.1 that are not
mapped to message parts.

On a side not, if the soap request contains more than one header for
a particular QName, I guess they should all be put inside one single part
of the wrapped message, right ?

Just trying to find how it will look at the end ;)

On 9/5/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:

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.1jbi
> > >> > 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
>
>




--
Cheers,
Guillaume Nodet

Reply via email to