Anne,
That was our belief as well (that <soapenv:Body> should contain only one
<full> element), but somehow we've been having trouble getting consistent
behavior between Axis 1.4 and Axis 2 (notably the "acceptFEvent" operation
wrapping that 1.4 seems to require). In the very short term I need to know
that the WSDL we have specifies the outgoing service we are producing,
which is a <soapenv:Body> containing a single <full> element, so it sounds
like we have the right definition for that, it has just been problematic to
test. Unfortunately we have not spent enough time with WS to understand
all the subtleties therein and as usual are under tight time
constraints. I will defer to Derek to continue the testing when he returns
since I need to continue work on another project.
Thanks,
--Zack
At 08:33 AM 8/26/2006 -0400, you wrote:
Actually, both are wrong.
According to your WSDL, the child element of the <soapenv:Body> should
be <full>, and there should be only one <full> element, not two.
A SOAP engine should only auto-generate the method-name wrapper
element when using RPC style. (If you are using document style, then
you as the developer need to ensure that each operation has a unique
signature. If you were to follow the wrapped convention, then you
would define a wrapper element for your message which has the same
loacl name as the operation.)
Another error that I see is that the <message-header> and
<event-reference> elements and their children are qualified in both
messages, but your schema clearly specifies that they should not be
qualified (elementFormDefault="unqualified").
Are you absolutely certain that your tests were made from these WSDL
and schema? If so, there's something seriously wrong with both Axis
1.4 *and* Axis2. I have not seen Axis1.4 make this type of error.
Anne
On 8/25/06, Derek <[EMAIL PROTECTED]> wrote:
Hi, folks.
I recently noticed a some strange discrepancies in how Axis handles the
operation name versus how Axis2 does. I'm not sure if these are bugs or just
a failure in my understanding.
Basically, when I have a particular WSDL, as follows:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="FDefinitions"
targetNamespace="http://www.c-corp.com/wsdl/2004-10-01/F";
xmlns:tns="http://www.c-corp.com/wsdl/2004-10-01/F";
xmlns:c="http://www.c-corp.com/wsdl/2004-10-01/c";
xmlns:F="http://www.dummy-temp-address";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
<types>
<xs:schema targetNamespace="http://www.c-corp.com/wsdl/2004-10-01/F";>
<xs:import namespace="http://www.dummy-temp-address";
schemaLocation="F.xsd"/>
<xs:element name="return" type="xs:string"/>
<xs:element name="failure" type="xs:string"/>
</xs:schema>
<xs:schema targetNamespace="http://www.c-corp.com/wsdl/2004-10-01/c";>
<xs:element name="CPassword" type="xs:string"/>
<xs:element name="CLogin" type="xs:string"/>
</xs:schema>
</types>
<message name="FEvent">
<part name="contents" element="F:full"/>
</message>
<message name="FResponse">
<part name="return" element="tns:return"/>
</message>
<message name="CPassword">
<part name="CPassword" element="c:CPassword"/>
</message>
<message name="CLogin">
<part name="CLogin" element="c:CLogin"/>
</message>
<message name="Failure">
<part name="faultDetail" element="tns:failure"/>
</message>
<portType name="FPortType">
<documentation>F Port Type</documentation>
<operation name="acceptFEvent" parameterOrder="contents">
<input name="acceptFEventRequest" message="tns:FEvent"/>
<output name="acceptFEventResponse" message="tns:FResponse"/>
<fault name="Failure" message="tns:Failure"/>
</operation>
</portType>
<binding name="FSoapBinding" type="tns:FPortType">
<documentation>F Soap Binding</documentation>
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="acceptFEvent">
<soap:operation soapAction="acceptFEventAction"/>
<input>
<soap:header message="tns:CLogin" part="CLogin" use="literal"/>
<soap:header message="tns:CPassword" part="CPassword"
use="literal"/>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
<fault name="Failure">
<soap:fault name="Failure" use="literal"/>
</fault>
</operation>
</binding>
<service name="FService">
<documentation>F Web Service</documentation>
<port name="FPort" binding="tns:FSoapBinding">
<soap:address
location="http://localhost:8080/axis/services/FService"/>
</port>
</service>
</definitions>
My WSDL references the following XML schema:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.dummy-temp-address";
xmlns="http://www.dummy-temp-address";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:c="http://www.c-corp.com/schemas/c/schema_annotation";
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
version="DRAFT">
<xs:element name="full" type="Full"/>
<xs:complexType name="Full">
<xs:sequence>
<xs:element name="message-header" type="MessageHeader"/>
<xs:element name="event-reference" type="EventReference"/>
<xs:any/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MessageHeader">
<xs:sequence>
<xs:any/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EventReference">
<xs:sequence>
<xs:element name="event-id" type="xs:string"/>
<xs:element name="update" type="xs:unsignedInt"/>
<xs:element name="response-plan-id" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
When I use my client code to create and send this message in Axis 1.4, I get
a message that looks like this:
POST /axis/services/FService HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.3
Host: 127.0.0.1
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 10458
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><soapenv:Header><cauth
:CLogin soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next";
soapenv:mustUnderstand="0"
xmlns:cauth="http://www.c-corp.com/wsdl/2004-10-01/c";>admin</cauth:CLogin><c
auth:CPassword soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next";
soapenv:mustUnderstand="0"
xmlns:cauth="http://www.c-corp.com/wsdl/2004-10-01/c";>admin</cauth:CPassword
></soapenv:Header><soapenv:Body><ns1:acceptFEvent
xmlns="http://www.c-corp.com/wsdl/2004-10-01/f";
xmlns:ns1="http://www.c-corp.com/wsdl/2004-10-01/f";>
<ns2:full xmlns="http://www.dummy-temp-address";
xmlns:ns2="http://www.dummy-temp-address";>
<ns2:message-header>
<ns2:sender>
<ns2:organization-id>QSenderOrganizationID</ns2:organization-id>
<ns2:center-id>QSenderCenterID</ns2:center-id>
</ns2:sender>
<ns2:message-type-version>1</ns2:message-type-version>
<ns2:message-number>435</ns2:message-number>
<ns2:message-time-stamp>
<ns2:date>20040625</ns2:date>
<ns2:time>201225</ns2:time>
<ns2:utc-offset>-0400</ns2:utc-offset>
</ns2:message-time-stamp>
<ns2:message-expiry-time>
<ns2:date>20040625</ns2:date>
<ns2:time>221222</ns2:time>
<ns2:utc-offset>-0400</ns2:utc-offset>
</ns2:message-expiry-time>
</ns2:message-header>
<ns2:event-reference>
<ns2:event-id>1234</ns2:event-id>
<ns2:update>1</ns2:update>
</ns2:event-reference>
<ns2:event-indicators>
<ns2:event-indicator>
<ns2:priority>4</ns2:priority>
</ns2:event-indicator>
</ns2:event-indicators>
<ns2:headline>
<ns2:headline>
<ns2:incident>accident</ns2:incident>
</ns2:headline>
</ns2:headline>
<ns2:details>
</ns2:details>
</ns2:full>
</ns1:acceptFEvent></soapenv:Body></soapenv:Envelope>
However, when I do the same thing in the current Axis2 nightly build
(XMLBeans binding), I get this:
POST /axis2/services/FService HTTP/1.1
SOAPAction: acceptFEventAction
User-Agent: Axis2
Host: 127.0.0.1
Content-Length: 8785
Content-Type: text/xml; charset=UTF-8
<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";><soapenv:Header><C
Login
xmlns="http://www.c-corp.com/wsdl/2004-10-01/c";>admin</CLogin></soapenv:Head
er><soapenv:Body><full xmlns="http://www.dummy-temp-address";><full>
<message-header>
<sender>
<organization-id>QSenderOrganizationID</organization-id>
<center-id>QSenderCenterID</center-id>
</sender>
<message-type-version>1</message-type-version>
<message-number>435</message-number>
<message-time-stamp>
<date>20040625</date>
<time>201225</time>
<utc-offset>-0400</utc-offset>
</message-time-stamp>
<message-expiry-time>
<date>20040625</date>
<time>221222</time>
<utc-offset>-0400</utc-offset>
</message-expiry-time>
</message-header>
<event-reference>
<event-id>1234</event-id>
<update>1</update>
</event-reference>
<event-indicators>
<event-indicator>
<priority>4</priority>
</event-indicator>
</event-indicators>
<headline>
<headline>
<incident>accident</incident>
</headline>
</headline>
<details>
</details>
</full></full></soapenv:Body></soapenv:Envelope>
There are several issues here:
1) The Axis2 version of the generated XML does not seem to include the
'acceptFEvent' element around the top-level message binding, which the Axis
1.4 did. I recall from discussions on the list that this seems to be
expected behavior (something about the signature for each operation needing
to be different, and sometimes having to use the SOAPAction field to
disambiguate). However, I am a bit astounded at such a significant
difference appearing between versions. It seems that no messages that were
accepted by Axis 1.4 could be accepted by Axis2, or vice versa, for the same
WSDL! I am at a loss to explain why I haven't heard more people complaining
about this. Which version of the SOAP message is correct, and under what
conditions? Is there a way to get both versions of Axis to do one or the
other behavior (preferably the correct one)? We were expecting to have a
single client be able to send an identical message to either Axis1.4 or
Axis2, but this seems not to be possible...?
2) The doubled 'full' element in the Axis2 message seems to be being
generated somehow by the following code:
protected ReturnDocument executeTest (
final String targetEndpoint,
final CLoginDocument login,
final CPasswordDocument password )
throws Exception
{
final FServiceStub service = new FServiceStub( null, targetEndpoint );
final Options options = service._getServiceClient().getOptions();
options.setProperty(
org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE );
service._getServiceClient().setOptions( options );
final FullDocument full = Full.Factory.newInstance();
full.setFull( getSituation() );
return service.acceptFEvent( full, login, password );
}
private Full getSituation ()
throws XmlException
{
return Full.Factory.parse(
" <full xmlns=\"http://www.dummy-temp-address\";>\n" +
" <message-header>\n" +
... and so forth ...
" </details>\n" +
" </full>\n" );
}
I am at a loss as to how there could be two nested levels of 'full' elements
generated by this code. Shouldn't there just be one? As far as I can tell,
my WSDL specifies just one. If I remove the top-level 'full' from the
getSituation() method, the 'parse' method throws an exception, so it seems
that I am passing in the XML that Axis2 expects. Axis 1.4 seems to generate
just one level of 'full', but Axis2 seems to generate two, one inside the
other. Is this a bug? If so, again, why haven't I heard people mentioning
it? (It seems to be a pretty blatant error which would affect almost all use
of XMLBeans binding).
Any insight on the above problems would be appreciated. My company is under
some time pressure to answer these questions.
Note that I am about to go on vacation for the next week, but a coworker of
mine will be monitoring the list for any answers to these issues that
listmembers can provide.
Thanks in advance!
Derek
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
