More on this:
It turns out that the client stub that is generated is creating code
that looks like this:
//Style is taken to be "document". No input parameters
// according to the WS-Basic profile in this case we have to send an
empty soap message
org.apache.axiom.soap.SOAPFactory factory =
getFactory(_operationClient.getOptions().getSoapVersionURI());
env = factory.getDefaultEnvelope();
However, what _works_ is to add this line (from the RPC calling style):
env.getBody().addChild(factory.createOMElement("getVersion",
"http://ws.management.ecourier.aciworldwide.com/";, ""));
So, the client and the server disagree as to how this method should be
called. Moreover, PHP SOAP doesn't work with it either; it appears to
be non-interoperable.
Has anyone else done this? How on earth does one create 0-parameter
methods in document/literal (wrapped) web service that will interoperate
with PHP, .NET, and Java?
Chris Rose wrote:
Amila Suriarachchi wrote:
On 10/18/07, *Chris Rose* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I'm trying to tune the code generation and our WSDL for service
methods
with no parameters, which seems to be a fairly ill-documented
process.
I've been all over the place, and I see that there are some bugs in
connection with this (AXIS-3199) which I've started watching, but I
hoped that someone in the community at large can offer some
insight into
this.
The method looks like this:
public VersionBean getVersion ();
Our WSDL (as noted in my comment on the bug report) looks like this:
<xs:element name='getVersion'>
<xs:complexType />
</xs:element>
<xs:element name='getVersionResponse' type='tns:getVersionResponse'/>
<xs:complexType name='getVersionResponse'>
<xs:sequence>
<xs:element minOccurs='0' name='return'
type='ns2:versionBean'/>
</xs:sequence>
</xs:complexType>
<xs:complexType name='version'>
<xs:sequence>
<!-- ... various version fields -->
</xs:sequence>
</xs:complexType>
<xs:complexType name='versionBean'>
<xs:complexContent>
<xs:extension base='ns1:version'>
<xs:sequence/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<message name='Service_getVersion'>
<part element='ns1:getVersion' name='parameters'/>
</message>
<message name='Service_getVersionResponse'>
<part element='ns1:getVersionResponse' name='getVersionResponse'/>
</message>
<portType name='Service'>
<operation name='getVersion' parameterOrder='getVersion'>
<input message='ns1:Service_getVersion'/>
<output message='ns1:Service_getVersionResponse'/>
</operation>
</portType>
What I'd like to see in the generated ServiceSkeletonInterface is a
getVersion() method with the same signature pattern: No parameters.
What I get, instead, is a getVersion (GetVersion getVersion) method,
which is awkward, as we use a reflection-based tool to map these
methods
to their implementation counterparts. Divergence between actual
implementation and interface is a problem, then.
I've tried removing the <input/> message in the operation element,
but
that results in no service whatsoever being generated.
this is a problem with the axis2 adb unwrapping. as a work around you
can remove the
part element from the input message. (Then nothing goes on the soap
boady).
That works from the service side; it generates interfaces that _look_
right, now, but when I invoke the methods in an axis2 client, I get this:
rg.apache.axis2.AxisFault: The endpoint reference (EPR) for the
Operation not found is
http://localhost:8080/ecourier/services/OperationsManagerService and the
WSA Action =
at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at
com.aciworldwide.ecourier.management.ws.client.OperationsManagerServiceStub.findAllApplications(OperationsManagerServiceStub.java:763)
at GetVersion.main(GetVersion.java:69)
How can I make the client build the correct message?
A second problem with the code generation: We run the schema
compiler
multiple times, because we isolate our web services into individual
deployment aars which are then assembled at deployment time into a
final
set of services. What we end up with is things like the
aforementioned
GetVersion class, but with an integer suffix that is... frustrating,
especially when the fact that it's generated in a different package
each
time is taken into account. It looks like the JavaBeanWriter is
doing
this, but the name generation behaviour in it is not amenable to
overriding since it depends extensively on private variables. Has
anyone got a better bean writer implementation they can suggest?
I fixed this issue. please have a look at with a nighly build.
I'm currently using the ADB code generator, if it makes a difference.
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
Amila Suriarachchi,
WSO2 Inc.
--
Chris Rose
Developer Planet Consulting Group
(780) 577-8433
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
