You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Alex Boisvert <bo...@intalio.com> on 2006/08/25 18:17:03 UTC
Re: servicemix-http and normalization
Hi all,
To follow-up on prior discussion around normalization, I've now created
a patch <https://issues.apache.org/activemq/browse/SM-557> [1] that
provides WSDL 1.1 normalization for the servicemix-http component.
More specifically, the code provides a set of reusable classes for
converting between SOAP 1.1 messages and JBI messages using WSDL 1.1
definitions. This code now sits in the servicemix-soap shared library
and I should mention that it's fairly strict about WS-I BasicProfile
compliance to reduce complexity and encourage people to write
interoperable service definitions.
I have not implemented a flag to turn normalization on/off. It should
be pretty simple but I figured I'd throw it out there to see how people
want to configure this (e.g. in the WSDL?)
Feedback on the patch itself or the configuration aspect would be
appreciated.
cheers,
alex
[1] https://issues.apache.org/activemq/browse/SM-557
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
Great, thx a lot.
I will take a look asap.
On 8/25/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Hi all,
>
> To follow-up on prior discussion around normalization, I've now created
> a patch <https://issues.apache.org/activemq/browse/SM-557> [1] that
> provides WSDL 1.1 normalization for the servicemix-http component.
> More specifically, the code provides a set of reusable classes for
> converting between SOAP 1.1 messages and JBI messages using WSDL 1.1
> definitions. This code now sits in the servicemix-soap shared library
> and I should mention that it's fairly strict about WS-I BasicProfile
> compliance to reduce complexity and encourage people to write
> interoperable service definitions.
>
> I have not implemented a flag to turn normalization on/off. It should
> be pretty simple but I figured I'd throw it out there to see how people
> want to configure this (e.g. in the WSDL?)
>
> Feedback on the patch itself or the configuration aspect would be
> appreciated.
>
> cheers,
> alex
>
> [1] https://issues.apache.org/activemq/browse/SM-557
>
>
>
--
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
>>
>>
>
>
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
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:
> 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>.
I'm working on that now.
A few comments inline.
On 8/30/06, Alex Boisvert <bo...@intalio.com> 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
Re: servicemix-http and normalization
Posted by Alex Boisvert <bo...@intalio.com>.
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...
> 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.
> 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.
> 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.
>
> 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
Re: servicemix-http and normalization
Posted by Guillaume Nodet <gn...@gmail.com>.
I have not had time to fully review the patch, but here are a few remarks.
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.
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).
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.
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.
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...
On 8/25/06, Alex Boisvert <bo...@intalio.com> wrote:
>
> Hi all,
>
> To follow-up on prior discussion around normalization, I've now created
> a patch <https://issues.apache.org/activemq/browse/SM-557> [1] that
> provides WSDL 1.1 normalization for the servicemix-http component.
> More specifically, the code provides a set of reusable classes for
> converting between SOAP 1.1 messages and JBI messages using WSDL 1.1
> definitions. This code now sits in the servicemix-soap shared library
> and I should mention that it's fairly strict about WS-I BasicProfile
> compliance to reduce complexity and encourage people to write
> interoperable service definitions.
>
> I have not implemented a flag to turn normalization on/off. It should
> be pretty simple but I figured I'd throw it out there to see how people
> want to configure this (e.g. in the WSDL?)
>
> Feedback on the patch itself or the configuration aspect would be
> appreciated.
>
> cheers,
> alex
>
> [1] https://issues.apache.org/activemq/browse/SM-557
>
>
>
--
Cheers,
Guillaume Nodet