You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/09/04 16:12:48 UTC
Re: servicemix-http and normalization
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 <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
See also
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Encodings_and_the_use_Attribute
On 9/5/06, Guillaume Nodet <gn...@gmail.com> 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 <mb...@intalio.com> 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 <boisvert@intalio.com > 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 <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Alex Boisvert <bo...@intalio.com>.
Guillaume Nodet wrote:
> 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.
I'll investigate this.
> 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 ?
Aaack! I had thought you could only have one header for a particular
QName but re-reading WS-I BP today proved me wrong.
http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Ordering_Headers
So I would go with you and place them in the same part of the wrapped
message -- although I wouldn't recommend using duplicate headers because
it's likely to confuse any component using abstract message definition.
alex
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <mb...@intalio.com> 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 <gn...@gmail.com> 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 <bo...@intalio.com> 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 <mb...@intalio.com> 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 <bo...@intalio.com> 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 <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Maciej Szefler <mb...@intalio.com>.
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 <gn...@gmail.com> 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 <bo...@intalio.com> 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 <mb...@intalio.com> 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 <bo...@intalio.com> 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 <bo...@intalio.com> 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
>
>
Re: servicemix-http and normalization
Posted by Alex Boisvert <bo...@intalio.com>.
Guillaume Nodet 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.
Yes, and that's the root of the problem. Normalization is left to the
component. Ideally, we'd like to move this code into the bus such that
multiple components can benefit from this normalization and not care
whether the transport message format is Document-style or
Procedural-Style. And it also covers the cases where you can to
access/handle SOAP headers.
alex
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bo...@intalio.com> 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 <mb...@intalio.com> 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 <bo...@intalio.com> 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 <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Alex Boisvert <bo...@intalio.com>.
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 <mb...@intalio.com> 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 <bo...@intalio.com> 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 <bo...@intalio.com> 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
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>>
>>
>
>
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <mb...@intalio.com> 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 <bo...@intalio.com> 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 <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Maciej Szefler <mb...@intalio.com>.
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 <bo...@intalio.com> 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 <bo...@intalio.com> 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
> >>
> >>
> >
> >
>
>
Re: servicemix-http and normalization
Posted by Alex Boisvert <bo...@intalio.com>.
Guillaume Nodet wrote:
> Not sure if I understand you.
> Are you saying you also want to normalize WSDL 2 based soap envelopes
> the same way ? Using WSDL 2, the rpc-lit style does not exist anymore,
> so you only have a single child in the soap body which is described using
> an xml schema.
I'm proposing that we could have configurable normalization paths:
1) SOAP 1.x message described with WSDL 1.1 => WSDL 1.1-wrapped JBI
normalized message
2) SOAP 1.x message described with WSDL 1.1/2.0) => Standard JBI
normalized message
3) SOAP 1.x message described with WSDL 2.0 => WSDL 1.1-wrapped JBI
normalized message
The 2nd case works only if there's only one message part (i.e., SOAP
body) and Document-Literal binding.
The 3rd case isn't supported yet.
alex
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
Not sure if I understand you.
Are you saying you also want to normalize WSDL 2 based soap envelopes
the same way ? Using WSDL 2, the rpc-lit style does not exist anymore,
so you only have a single child in the soap body which is described using
an xml schema.
I' m not quite sure how to use soap headers in WSDL 2, but afaik, a jbi
component will have to retrieve them from the properties on the message.
I guess it would be easier to do the same for WSDL 1.1.
Using WSDL 1.1, soap headers mapped to message parts will be included
in the wrapper, others will still be accessible from the properties.
I' m not a soap expert at all, so please, correct me if I say anything
wrong.
On 9/5/06, Alex Boisvert <bo...@intalio.com> 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 <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Alex Boisvert <bo...@intalio.com>.
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 <bo...@intalio.com> 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
>>
>>
>
>