Axis 1.2 or 1.3 Putting Service Params in SOAP Header Section
Ray Thomas
Greenhorn
Posts: 7
posted 11 years ago
I am trying to use Axis 1.3 (also tried 1.2) to consume a web service published by Remedy ARSystem. I know the service / WSDL is configured properly and works with at least one test client tool (SOAPSonar) so I somewhat sure the Axis client library is the component that is misbehaving.
The problem is that WSDL2Java produces code that puts the request parameter values in the header section of the soap envelope and not in the body where the server expects them. I haven't been able to find a way to make the Axis generated objects put the request parameters in the service element of the soapenv:body section where they need to be.
Can anyone help me figure out how to make Axis 1.3 work.
Attached below are:
1) A sample of an improperly structured request from Axis
2) A sample of a properly structured request from SOAPSonar
(both captured with Ethereal)
3) The WSDL produced by the Remedy ARSystem web service follow below.
The problem is that WSDL2Java produces code that puts the request parameter values in the header section of the soap envelope and not in the body where the server expects them. I haven't been able to find a way to make the Axis generated objects put the request parameters in the service element of the soapenv:body section where they need to be.
Can anyone help me figure out how to make Axis 1.3 work.
Attached below are:
1) A sample of an improperly structured request from Axis
2) A sample of a properly structured request from SOAPSonar
(both captured with Ethereal)
3) The WSDL produced by the Remedy ARSystem web service follow below.
Peer Reynders
Bartender
Posts: 2968
6
posted 11 years ago
Hmmm....
Try changing the WSDL from
to
and rerun WSDL2Java.
Technically it should not matter but from the behaviour displayed it almost seems like it doesn't realize that the header binding is over and then it includes the document as a header block.
Try changing the WSDL from
to
and rerun WSDL2Java.
Technically it should not matter but from the behaviour displayed it almost seems like it doesn't realize that the header binding is over and then it includes the document as a header block.
Ray Thomas
Greenhorn
Posts: 7
posted 11 years ago
Well, the verdict on that is that, yes, technically the form of the soap:header tag in the WSDL does not matter. I saved the WSDL to a file, altered the soap:header tag to the shorthand form, and ran WSDL2Java on the altered file but the generated classes have the same behavior as before.
I tried removing the soap:header tag completely and regenerated using WSDL2Java and that worked. I still have to add the actual header to the request in the client code that uses the Axis generated classes but at least it works.
Now I'm curious if this is a bug in Axis. Seems like it is not generating the appropriate code to handle the soap:body properly if there is a soap:header present in the WSDL. I searched the bugs for Axis on issues.apache.org but didn't find anything that matched this. Looks like all the effort has shifted to the yet unreleased Axis 2.
The problem that remains is that I don't have control over the published WSDL for the service. Working around this means I need to set up my build (ant task) to retrieve the WSDL to a file, run a transform on it to zap the soap:header tag, and then run WSDL2Java.
Still hoping someone has a better suggestion.
-R
I tried removing the soap:header tag completely and regenerated using WSDL2Java and that worked. I still have to add the actual header to the request in the client code that uses the Axis generated classes but at least it works.
Now I'm curious if this is a bug in Axis. Seems like it is not generating the appropriate code to handle the soap:body properly if there is a soap:header present in the WSDL. I searched the bugs for Axis on issues.apache.org but didn't find anything that matched this. Looks like all the effort has shifted to the yet unreleased Axis 2.
The problem that remains is that I don't have control over the published WSDL for the service. Working around this means I need to set up my build (ant task) to retrieve the WSDL to a file, run a transform on it to zap the soap:header tag, and then run WSDL2Java.
Still hoping someone has a better suggestion.
-R
Peer Reynders
Bartender
Posts: 2968
6
posted 11 years ago
In this particular case the overloading of the same names within the same namespace (used in different contexts) is causing the problem.
Change the WSDL to (i.e. check the part names):
That should move the document into the body - you should also consider making the following change the operation name (i.e. rename Operation OpGetList to OpGetListOp):
it's going to help Axis keep things straight. For document/literal the operation element is dropped in the SOAP message - the document (s
pGetList) implies the operation.
It's not that uncommon that you have to cook the WSDL - really you should only build against a local copy of the WSDL and only replace it when you know it's necessary. Often WSDLs are far from perfect and especially generated WSDLs frequently don't work "as-is" as input to other tools.
Change the WSDL to (i.e. check the part names):
That should move the document into the body - you should also consider making the following change the operation name (i.e. rename Operation OpGetList to OpGetListOp):
it's going to help Axis keep things straight. For document/literal the operation element is dropped in the SOAP message - the document (s
pGetList) implies the operation.It's not that uncommon that you have to cook the WSDL - really you should only build against a local copy of the WSDL and only replace it when you know it's necessary. Often WSDLs are far from perfect and especially generated WSDLs frequently don't work "as-is" as input to other tools.
Ray Thomas
Greenhorn
Posts: 7
posted 11 years ago
Well I'm a little disappointed that that a .NET framework based tool (SOAPSonar) did _not_ require me to "cook" the WSDL in order for it to figure out how to handle it, but Axis did require the WSDL tweak. Hopefully Axis 2.x will have some of this stuff sorted out. An additional bit of irony is that the WSDL is apparently generated on the server end by Axis (not sure which version).
Anyway, since I have very little control over how the WSDL is produced in the commercial server product, I decided to automate the process of getting the WSDL, "cooking" it, and running WSDL2Java. The ant build file and XSL are attached below in case anyone else needs to do the same sort of thing.
Thanks everyone for the help and suggestions.
----------- build.xml ------------------
?xml version="1.0" encoding="UTF-8"?>
<project name="web_services_tutorial" default="axis">
<property name="axis.home" value="/javalibs/axis-1_3" />
<property name="generated.dir" value="javasource_generated" />
<!-- property name="jwsdp.home" value="/jwsdp-1.4" / -->
<path id="axis.classpath">
<fileset dir="${axis.home}/lib" includes="**/*.jar" />
<!-- fileset dir="${jwsdp.home}" includes="jwsdp-shared/lib/activation.jar" / -->
<!-- fileset dir="${jwsdp.home}" includes="jwsdp-shared/lib/mail.jar" / -->
</path>
<taskdef resource="axis-tasks.properties">
<classpath refid="axis.classpath" />
</taskdef>
<target name="axis">
<mkdir dir="temp_wsdl_orig" />
<mkdir dir="temp_wsdl_mod" />
<get src="http://MIDTIER/arsys/WSDL/public/ARSERVER/SimpleTicketView"
dest="temp_wsdl_orig/SimpleTicketView.xml" />
<xslt in="temp_wsdl_orig/SimpleTicketView.xml"
out="temp_wsdl_mod/SimpleTicketView.xml"
style="SimpleTicketView.xsl" />
<axis-wsdl2java
url="temp_wsdl_mod/SimpleTicketView.xml"
output="${generated.dir}"
testcase="true"
verbose="true"
nowrapped="true"
all="true">
<mapping
namespace="http://axis.apache.org/ns/interop"
package="interop" />
<mapping
namespace="urn:SimpleTicketView"
package="com.example.webservice.ars" />
</axis-wsdl2java>
</target>
</project>
------------------- build.xml -----------------
--------------- SimpleTicketView.xsl -----------
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="node()|@*">
<xsl:if test="not(name()='soap:header')">
<xsl:copy>
<xsl:copy-of select="@*" />
<xsl:apply-templates />
</xsl:copy>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
--------------- SimpleTicketView.xsl -----------
Anyway, since I have very little control over how the WSDL is produced in the commercial server product, I decided to automate the process of getting the WSDL, "cooking" it, and running WSDL2Java. The ant build file and XSL are attached below in case anyone else needs to do the same sort of thing.
Thanks everyone for the help and suggestions.
----------- build.xml ------------------
?xml version="1.0" encoding="UTF-8"?>
<project name="web_services_tutorial" default="axis">
<property name="axis.home" value="/javalibs/axis-1_3" />
<property name="generated.dir" value="javasource_generated" />
<!-- property name="jwsdp.home" value="/jwsdp-1.4" / -->
<path id="axis.classpath">
<fileset dir="${axis.home}/lib" includes="**/*.jar" />
<!-- fileset dir="${jwsdp.home}" includes="jwsdp-shared/lib/activation.jar" / -->
<!-- fileset dir="${jwsdp.home}" includes="jwsdp-shared/lib/mail.jar" / -->
</path>
<taskdef resource="axis-tasks.properties">
<classpath refid="axis.classpath" />
</taskdef>
<target name="axis">
<mkdir dir="temp_wsdl_orig" />
<mkdir dir="temp_wsdl_mod" />
<get src="http://MIDTIER/arsys/WSDL/public/ARSERVER/SimpleTicketView"
dest="temp_wsdl_orig/SimpleTicketView.xml" />
<xslt in="temp_wsdl_orig/SimpleTicketView.xml"
out="temp_wsdl_mod/SimpleTicketView.xml"
style="SimpleTicketView.xsl" />
<axis-wsdl2java
url="temp_wsdl_mod/SimpleTicketView.xml"
output="${generated.dir}"
testcase="true"
verbose="true"
nowrapped="true"
all="true">
<mapping
namespace="http://axis.apache.org/ns/interop"
package="interop" />
<mapping
namespace="urn:SimpleTicketView"
package="com.example.webservice.ars" />
</axis-wsdl2java>
</target>
</project>
------------------- build.xml -----------------
--------------- SimpleTicketView.xsl -----------
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="node()|@*">
<xsl:if test="not(name()='soap:header')">
<xsl:copy>
<xsl:copy-of select="@*" />
<xsl:apply-templates />
</xsl:copy>
</xsl:if>
</xsl:template>
</xsl:stylesheet>
--------------- SimpleTicketView.xsl -----------
Peer Reynders
Bartender
Posts: 2968
6
posted 11 years ago
What does that have to do anything?
Its got nothing to do with .NET vs Java.
Let's put this in perspective.
SOAPSonar is a commercially backed Web-service testing product.
If it wouldn't work, they would drown in customer service cases.
If nobody pays for the enterpise product - bye-bye SOAPSonar - including the free version.
Axis is a product by a group of "enthusiasts" who actually make it available to the public so that the public can play with/use it without paying a cent. WSDL2Java is an important aspect of Axis - but in the end its only a small aspect of Axis.
Caveat Emptor - but then again you didn't "buy" anything.
Originally posted by Ray Thomas:
Well I'm a little disappointed that that a .NET framework based tool (SOAPSonar) did _not_ require me to "cook" the WSDL in order for it to figure out how to handle it, but Axis did require the WSDL tweak.
What does that have to do anything?
Its got nothing to do with .NET vs Java.
Let's put this in perspective.
SOAPSonar is a commercially backed Web-service testing product.
If it wouldn't work, they would drown in customer service cases.
If nobody pays for the enterpise product - bye-bye SOAPSonar - including the free version.
Axis is a product by a group of "enthusiasts" who actually make it available to the public so that the public can play with/use it without paying a cent. WSDL2Java is an important aspect of Axis - but in the end its only a small aspect of Axis.
Caveat Emptor - but then again you didn't "buy" anything.
Ray Thomas
Greenhorn
Posts: 7
posted 11 years ago
I feel like Harry Potter uttering the name Voldemort. I didn't mean to ruffle anyone's feathers with the comment about Axis/Java vs. .NET. I'm perfectly aware that Axis is open source, free, community developed, no guarantees, etc. but my general experience with open source libraries, especially ones that have been around a while, and even more especially ones that are published under the Apache Software Foundation umbrella, is that they tend to support somewhat well known technologies (like WSDL) _better_ than the commercial alternatives. So, naturally, when that isn't the case, I'm "a little disappointed." It doesn't matter in the end because I got it to work anyway but I much prefer not having to wrestle with something to get it working. Thankfully there's a place like JavaRanch around where we can all get a helping hand (or lend one) when something puts up a fight.
-R
-R
Van Wiles
Greenhorn
Posts: 1
posted 8 years ago
For the record, the WSDL generated by ARS has an error - the ARAuthenticate message has the same "part" name as the input and output messages to the web service (any ARS generated WSDL). I posted a blog entry on BMC developer network about this here:
http://developer.bmc.com/communities/blogs/van_wiles/2008/11/05/a-little-annoyance-in-ar-web-services
http://developer.bmc.com/communities/blogs/van_wiles/2008/11/05/a-little-annoyance-in-ar-web-services
| Consider Paul's rocket mass heater. |