I don't recall there being anything in WSI-BP that prohibits the usage of
RPC-literal encoding, which results in multiple parts.
-mbs
On 9/5/06, Alex Boisvert [EMAIL PROTECTED] wrote:
Oh yes, good question! The point of mapping headers into message
content is that many
See
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute
it seems pretty clear for me, but maybe i misread it.
On 9/5/06, Maciej Szefler [EMAIL PROTECTED] wrote:
I don't recall there being anything in WSI-BP that prohibits the usage of
RPC-literal
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
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
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
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
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.
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
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
I'm working on that now.
A few comments inline.
On 8/30/06, Alex Boisvert [EMAIL PROTECTED] 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
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
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
/06, Alex Boisvert [EMAIL PROTECTED] 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
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
Great, thx a lot.
I will take a look asap.
On 8/25/06, Alex Boisvert [EMAIL PROTECTED] 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
Alex,
I suppose the problem is going to be that the components are configurable to
the level which can affect the input/ouput, and therefore it is the final
implementation that needs to generate the WSDL.
A component like the Groovy Component is going to be difficult to provide
WSDL for - it
My suggestion would be to go towards WSDL 1.1. It's a widely accepted
spec with well-defined rules of interoperability if you take into
account the WS-I BasicProfile 1.1. And we have a good mapping defined
in the JBI spec for passing around WSDL 1.1 normalized messages.
I'm not a WS
To tell you the truth, I was secretly hoping to spur a debate around
message normalization. :) The way I understand it, if I start changing
the message format put on the bus, it will most likely break other
components that expect the older format.
I'd be curious to hear what other think
Hi,
I've noticed that servicemix-http simply places the child element of the
SOAP:Body as the content of JBI normalized message. This doesn't seem
to go with the spirit of normalization... I would have expected a WSDL
1.1-wrapper element with message parts if I deployed a WSDL 1.1.
19 matches
Mail list logo
