changing WS-Addressing version for proxies to submission

michal.stochmialek's picture
ESB is by default working on final version of WS-Addressing for proxies
and for default sequencies. For example when I'll send a message (see below)
to 'http://url/soap/example':


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<soapenv:Header>
<wsa:MessageID soapenv:mustUnderstand="0">uuid:96144820-451d-11d9-834f-97eb4a63d5ac</wsa:MessageID>
<wsa:To soapenv:mustUnderstand="0">http://www.example.pl/service/1.0</wsa:To>
<wsa:From soapenv:mustUnderstand="0">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>
</wsa:From>
</soapenv:Header>
<soapenv:Body>
<k:request xmlns:k="http://www.example.pl/service/1.0/types">
</k:request>
</soapenv:Body>
</soapenv:Envelope>



using this synapse.xml/proxy:

<sequence name="log">
<log level="custom" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<property name="date" expression="get-property('SYSTEM_DATE', 'yyyy.MM.dd HH:mm:ss:SSS z')"/>
<property name="text" expression="get-property('logmessage')"/>

<property name="messageID-xpath" expression="$header/wsa:MessageID" />
<property name="from-xpath" expression="$header/wsa:From/wsa:Address"/>
<property name="to-xpath" expression="$header/wsa:To"/>

<property name="messageID" expression="get-property('MessageID')" />
<property name="from" expression="get-property('From')"/>
<property name="to" expression="get-property('To')"/>
</log>
</sequence>

<proxy name="example" transports="http">
<target>
<inSequence>
<property name="logmessage" value="request"/>
<sequence key="log"/>
<drop/>
</inSequence>
</target>
</proxy>


I'm getting a log message like the one below:


- date = 2009.01.14 11:52:39:468 CET, text = request, messageID-xpath = uuid:961
44820-451d-11d9-834f-97eb4a63d5ac, from-xpath = http://schemas.xmlsoap.org/ws/20
04/03/addressing/role/anonymous, to-xpath = http://www.example.pl/service/1.0, m
essageID = urn:uuid:9DEB8073B2D934C6851231930359478, from = , to = /soap/example


Although getting headers' value using get-property doesn't return values from soap header, using xpath (with WSA Submission NS) is working correctly.



When you change WSA's namespace to final in source message like that:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:MessageID soapenv:mustUnderstand="0">uuid:96144820-451d-11d9-834f-97eb4a63d5ac</wsa:MessageID>
<wsa:To soapenv:mustUnderstand="0">http://www.example.pl/service/1.0</wsa:To>
<wsa:From soapenv:mustUnderstand="0">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>
</wsa:From>
<wsa:Action>http://www.example.pl/service/1.0/request</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<k:request xmlns:k="http://www.example.pl/service/1.0/types">
</k:request>
</soapenv:Body>
</soapenv:Envelope>



Then I'm getting this log message. As you can see, headers' values are available
using get-property.

- date = 2009.01.14 12:02:30:937 CET, text = request, messageID-xpath = , from-x
path = , to-xpath = , messageID = uuid:96144820-451d-11d9-834f-97eb4a63d5ac, fro
m = http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous, to = http:/
/www.example.pl/service/1.0



That's a big issue for me, since synapse isn't recognizing WS-Addressing in Submission at all.
I have to hack property response headers (for faults and responses) myself using transformation mediators.
Which is not easy, since header mediator supports only flat values and xlst mediator
have problems when transforming whole message.



The version of WS-Addressing can be changed for endpoints, but can it be changed for proxies?


Michal Stochmialek
R&D Leader, eurobank
michal.stochmialek's picture

the cause

Ok, I've found the cause of the issue. We are using WS-Addressing submission from 2004/03, but Axis/Synapse recognizes 2004/08. When I've change NS to the one below, everything is working fine. http://schemas.xmlsoap.org/ws/2004/08/addressing Is there a way to change to the older version of submission? Michal Stochmialek R&D Leader, eurobank
ruwan's picture

Hi Michal, I am sorry there

Hi Michal, I am sorry there is no direct means of doing this, unless you go through an another proxy layer to switch the addressing version. If you could elaborate on your exact requirements, I could help you to get that working with the ESB. Thanks, Ruwan Linton
ruwan's picture

By having a look at the

By having a look at the query once again, I don't think you need to switch to the new addressing version within ESB. ESB can understand the submission version of the addressing headers as well. Please elaborate on your requirement, I will try my best to help you get through this. If you cannot send this information in public please use my email [ruwan AT wso2 DOT com] Thanks, Ruwan Linton
michal.stochmialek's picture

Ruwan, There are at least

Ruwan, There are at least two submission versions of ws-addressing. ESB is understanding "http://schemas.xmlsoap.org/ws/2004/08/addressing", but we are using an older version ("http://schemas.xmlsoap.org/ws/2004/03/addressing"). See the difference in the month number? What our requirement? We need to create a proxy that translates from SOAP 1.1/WS-Addressing Submission/2004/03 (a client side) to a SOAP 1.1 (a server side). There also will be a change in payload (which is not a big issue). inSequence is simple. Just remove WS-Addressing headers. outSequence is the biggest problem. We are not able to set ws-addressing headers in response. I've tried: 1. header mediator - but it only supports flat values. We cannot set <wsa:From><wsa:Address>http://example.com</wsa:From></wsa:Address> using it. 2. xslt mediator - but they don't work for headers: <xslt key="wsa-response.xsl" source="soapenv:Header" /> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"> <xsl:output method="xml" omit-xml-declaration="yes" /> <xsl:template match="/"> <xsl:apply-templates select="soapenv:Header"/> </xsl:template> <xsl:template match="soapenv:Header"> <soapenv:Header> <wsa:MessageID soapenv:mustUnderstand="0"><xsl:value-of select="wsa:MessageID"/>-RESPONSE</wsa:MessageID> <wsa:To soapenv:mustUnderstand="0"><xsl:value-of select="wsa:From/wsa:Address"/></wsa:To> <wsa:From soapenv:mustUnderstand="0"> <wsa:Address><xsl:value-of select="wsa:To"/></wsa:Address> </wsa:From> <wsa:RelatesTo soapenv:mustUnderstand="0" wsa:RelationshipType="wsa:Reply"><xsl:value-of select="wsa:MessageID"/></wsa:RelatesTo> </soapenv:Header> </xsl:template> </xsl:stylesheet> 3. xquery mediator - but they also don't work for headers: <xquery key="wsa-response.xq" target="soapenv:Header"> <variable name="header" type="ELEMENT" expression="soapenv:Header"/> </xquery> <x><![CDATA[ declare namespace soapenv="http://schemas.xmlsoap.org/soap/envelope/" ; declare namespace wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"; declare variable $header as document-node() external; <soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"> <wsa:MessageID soapenv:mustUnderstand="0">{$header//wsa:MessageID/child::text()}-RESPONSE</wsa:MessageID> <wsa:To soapenv:mustUnderstand="0">{$header//wsa:From/wsa:Address/child::text()}</wsa:To> <wsa:From soapenv:mustUnderstand="0"> <wsa:Address>{$header//wsa:To/child::text()}</wsa:Address> </wsa:From> <wsa:RelatesTo soapenv:mustUnderstand="0" wsa:RelationshipType="wsa:Reply">{$header//wsa:MessageID/child::text()}</wsa:RelatesTo> </soapenv:Header> ]]></x> Both XQuery and XSLT removes whole Header element. I've tried on the message in the first post. Any suggestions? Michal Stochmialek R&D Leader, eurobank
asankha's picture

Hi Michael There are two

Hi Michael There are two possible fixes.. add support into the WS-Addressing, if the Submission version is used by other SOAP stacks - this is the proper solution, and should not be that difficult either. >Both XQuery and XSLT removes whole Header element. I've tried on the message in the first post This could be due to WS-A getting engaged on the proxy from the axis2.xml.. after an XSLT/XQ on the out message, try a full Log mediator, and check the output. If you see the correct message, next step will not be that difficult cheers asankha http://adroitlogic.org
michal.stochmialek's picture

> There are two possible

> There are two possible fixes.. add support into the WS-Addressing, if the Submission > version is used by other SOAP stacks - this is the proper solution, and should not be > that difficult either. I would be happy to see this solution implemented. What chances are this will be fixed in a near future? > This could be due to WS-A getting engaged on the proxy from the axis2.xml.. after an > XSLT/XQ on the out message, try a full Log mediator, and check the output. If you see > the correct message, next step will not be that difficult I've checked it already. I'm logging the full message just after transformation. The message in the output doesn't contain headers. Michal Stochmialek R&D Leader, eurobank
asankha's picture

Hi Michal >I would be happy

Hi Michal >I would be happy to see this solution implemented. What chances are this will be fixed in a near future? You could raise a JIRA for this on Axis2 (if one does not exist already) >I've checked it already. I'm logging the full message just after transformation. The message in the output doesn't contain headers. This should work!.. let me try your example and get back to you. My suggestion is to use this right now (I am quite sure this could be made to work) and raise the JIRA so that eventually the issue would be handled better for other users as well.. cheers asankha http://adroitlogic.org
michal.stochmialek's picture

I've create a

I've create a issue: https://issues.apache.org/jira/browse/AXIS2-4211 Michal Stochmialek R&D, eurobank
library project main code
Learn Cloud
Learn
Cloud

The WSO2 Application Server is a reliable application server that can host your enterprise web applications. The WSO2 Application Server as a Service is offered in StratosLive, the WSO2 Platform as a Service. This article explains how a simple web application can be developed and deployed from Carbon Studio to the WSO2 Application Server...

Latest Webinar
Different groups within an organization need to monitor different Key Performance Indicators (KPIs) - An operations team will be interested in the response times of business services and loads of each service,..
Thursday, February 9th 2012, 09.00 AM (PST)

Thursday, February 9th 2012, 10.00 AM (GMT)