We Keep Coding

Java SOAP WebService - How to accept single input parameter

I'm developing a SOAP based Webservice API which would be used by a third party system. WSDL file and endpoint URL would be shared with them and they invoke my Web service by passing an input parameter and get the response back
So far, I have created the Web Service API including WSDL, Services Classes, Helper Classes, DAO, Ibatis) and tested using SOAP UI by passing the input parameter, the request hits the databse and returning the response fine. Attached the WSDL file and SOAP request and response.
I got two questions,
The 3rd Party system is asking for an API documentation and SOAP Envelope. What should I give?
The 3rd party system has to invoke my service by passing the input parameter sQuoteRef. How would they usually do it? I'm not concerned about the client code here but how would the request from 3rd party look like and what changes I should make in my WSDL or Java classes to receive the input parameter and pass on to my service class?
Any inputs would be helpful in completing my task. Many Thanks!
WSDL File
<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="EmpService" targetNamespace="http://emp.provider.integration.gi.sample.ie/EmpService/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://Emp.provider.integration.gi.sample.ie/EmpService/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<xsd:schema targetNamespace="http://Emp.provider.integration.gi.sample.ie/EmpService/">
<xsd:element name="EmpRequestVO">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="sQuoteRef" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="EmpResponseVO">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="sQuoteStatus" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="GetEmpTransactionSoapIn">
<wsdl:part element="tns:EmpRequestVO" name="parameters"/>
</wsdl:message>
<wsdl:message name="GetEmpTransactionSoapOut">
<wsdl:part element="tns:EmpResponseVO" name="parameters"/>
</wsdl:message>
<wsdl:portType name="EmpServiceSoap">
<wsdl:operation name="getEmpTransaction">
<wsdl:input message="tns:GetEmpTransactionSoapIn"/>
<wsdl:output message="tns:GetEmpTransactionSoapOut"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="EmpServiceSoap" type="tns:EmpServiceSoap">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getEmpTransaction">
<soap:operation soapAction="getEmpTransaction" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="PLUSEmpServices">
<wsdl:port binding="tns:EmpServiceSoap" name="EmpServiceSOAP">
<soap:address location="http://localhost:9080/WebServices/services/EmpServiceSOAP"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
End Point URL
http://localhost:9080/PLUSEmpServices/services/EmpServiceSOAP
SOAP REQUEST in SOAP UI
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtw="http://emp.provider.integration.gi.sample.ie/EmpService/">
<soapenv:Header/>
<soapenv:Body>
<rtw:EmpRequestVO>
<sQuoteRef>12123118</sQuoteRef>
</rtw:EmpRequestVO>
</soapenv:Body>
</soapenv:Envelope>
SOAP RESPONSE in SOAP UI
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<p900:EmpResponseVO xmlns:p900="http://emp.provider.integration.gi.sample.ie/EmpService/">
<sQuoteStatus>Active</sQuoteStatus>
</p900:EmpResponseVO>
</soapenv:Body>
</soapenv:Envelope>

The 3rd Party system is asking for an API documentation and SOAP Envelope. What should I give?
To start APIs integration with external parties, your clients require a technical API document that will be a reference to complete APIs integration and a base for any technical communication between the teams. The technical document may includes the following details:
Brief description for different available web-services APIs and their requirements.
APIs communications flow. This will be useful in case the clients need to call more than one services in specific sequence. Including flow diagram will be possible option to explain the system flow.
Test environment details like WSDL URL and access credentials like username, password, agent code, etc.
Detailed description for all fields needed to send a valid request to the server. Fields details may include the following:
a. Filed name.
b. Description.
c. Data Type.
d. Max length.
e. Mandatory, Optional or Conditional.
f. Possible values if any.
All possible response codes a long with their description sent by server API to client API which indicates the successful or failure of transaction process(s). For example (0000 means Success, E001 means validation error, E002 system error, 9999 unknown error, etc.).
Note: Response codes should cover various rejection cases.
Security Section that explain how the data is exchange securely between client and server application.
a. Mention additional Encryption mechanism for part or all request data if any.
b. Communication type with the client wither it is over VPN or accessed public
over https URL. Note the URL you mentioned in your question is deployed in your local machine and it will not be available publicly.
Sample SOAP request(s) and response(s) xml format for all available API’s web methods.
Mention any additional rules or constrains on APIs connectivity.
The 3rd party system has to invoke my service by passing the input parameter sQuoteRef. How would they usually do it? I'm not concerned about the client code here but how would the request from 3rd party look like and what changes I should make in my WSDL or Java classes to receive the input parameter and pass on to my service class?
If I understand you correctly your are asking how should I change WSDL or Java classes to accept client request correctly ? Usually the server side API has the upper hand in XML format need to be exchanged and in your case it should be mentioned in WSDL. So the client will create a valid request as per definition mentioned in server WSDL URL.
Further reading that my be useful on how to generate WSDL from Java classes:
Eclipse WSDL generator (from java class)?
SOAP fault handling in java

Java: Invoke web service using Axis2 stub class

I'm new to web services. With all difficulty I have generated a simple 'Hello World' web service :D. I want to invoke the web service using java. The web service has a hard coded value shown as the output. Here is what I have tried.
I have created a new Dynamic web Project in Eclipse for web service client.
To this project generated stub classes for the web service using Axis2 and Eclipse.
I am not able to understand what the generated stub class basically contain, and how to use the stub class to invoke the webservice.
The stub class generated has too many lines of code. which i cannot paste it here; Is there any particular class that i need to concentrate on inorder to invoke a method in the webservice?
Part of the wsdl look like this
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://sample.com/Webservice/wsTest" targetNamespace="http://sample.com/Webservice/wsTest">
<xsd:element name="test" type="tns:test"/>
<xsd:element name="testResponse" type="tns:testResponse"/>
<xsd:complexType name="test">
<xsd:sequence></xsd:sequence>
</xsd:complexType>
<xsd:complexType name="testResponse">
<xsd:sequence>
<xsd:element name="outputString" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</wsdl:types>
<wsdl:message name="wsTest_PortType_test">
<wsdl:part name="parameters" element="tns:test"></wsdl:part>
</wsdl:message>
Could you please let me know how to invoke a web service using Java in eclipse.
Later part: In case my webservice has input(eg: web service for addition) how do i pass the request parameters and get an output as a response.

I think this will definitely helps you
Just go through step by step procedure according to it,then you can achieve easily your Requirement.
the Link is here:
http://www.ibm.com/developerworks/webservices/library/ws-apacheaxis/index.html?ca=dat

WSDL abstract vs concrete messages

I am learning about WSDL from online documentation and came across definitions about abstract message and concrete message:
Message definitions are always considered to be an abstract definition
of the message content. A message binding describes how the abstract
content is mapped into a concrete format.
However, in some cases, the abstract definition may match the concrete representation very closely or exactly for one or more bindings, so those binding(s) will supply
little or no mapping information.
However, another binding of the same message definition may require extensive mapping information. For this reason, it is not until the binding is inspected that one can
determine "how abstract" the message really is.
Please help me in understanding what the above definition means? Can you please provide some examples for the same.
When we call a message as Abstract and when it will be called as concrete in WSDL terms?

The message part is considered abstract as it does not really define how the content formatting of the actual SOAP message will look like. Please have a look at this IBM article which does a great job on presenting the differences between the available binding styles in WSDL.
Taking the example from this article where the WSDL contract should define a method like public void myMethod(int x, float y); you can declare something like that in the WSDL contract:
<message name="myMethodRequest">
<part name="x" type="xsd:int"/>
<part name="y" type="xsd:float"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
Here you just declare the expected elements of a message but you don't really define here how the actual SOAP message matching this definition looks like. This happens in the binding section.
WSDL offers here RPC/encoded ...
<soap:envelope>
<soap:body>
<myMethod>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
... RPC/literal ...
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
... and Document/literal
<soap:envelope>
<soap:body>
<xElement>5</xElement>
<yElement>5.0</yElement>
</soap:body>
</soap:envelope>
Document/literal is actually not complete here as you furthermore create own types for xsd:int and xsd:float and use this types instead of these types as your message type:
<types>
<schema>
<element name="xElement" type="xsd:int"/>
<element name="yElement" type="xsd:float"/>
</schema>
</types>
<message name="myMethodRequest">
<part name="x" element="xElement"/>
<part name="y" element="yElement"/>
</message>
<message name="empty"/>
<!-- same port type -->
<portType name="PT">
...
<binding ... />
Every method has its strength and its weaknesses - please have a look on the IBM article for further information therefore. Due to the limitations and weaknesses RPC/encoded, RPC/literal and document/literal bare are not used that often - instead a modification of document/literal is used - document/literal wrapped. Here the advantages of all styles are thrown into one single style - which has its further limits of only allowing one <part .../> element for a message:
<types>
<schema>
<element name="myMethod">
<complexType>
<sequence>
<element name="x" type="xsd:int"/>
<element name="y" type="xsd:float"/>
</sequence>
</complexType>
</element>
<element name="myMethodResponse">
<complexType/>
</element>
</schema>
</types>
<message name="myMethodRequest">
<part name="parameters" element="myMethod"/>
</message>
<message name="empty">
<part name="parameters" element="myMethodResponse"/>
</message>
<!-- again same port type -->
<binding ... />
This results in a SOAP message like this:
<soap:envelope>
<soap:body>
<myMethod>
<x>5</x>
<y>5.0</y>
</myMethod>
</soap:body>
</soap:envelope>
However, document/literal wrapped is not really part of the WSDL:
In document/literal style of messaging, there exists a pattern which
is known as wrapped-document/literal. This is just a pattern, and is
not a part of WSDL specification. This pattern has a mention in JSR
224 (JAX-WS: Java API for XML based web services). (Source)
Hope this also answers somehow your other questions: 1, 2
Furthermore, the actual transportation may happen on different protocols like HTTP, JMS, SMTP, ..., as already explained by #Namphibian and #JqueryLearner. This happens within the binding section where you define which protocol and binding style (RPC or document) should be used for which operations:
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://example.com/getTerm"/>
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
HTH

Abstract WSDL contains messages without the transport protocol
Concrete WSDl is abstract WSDl plus transport protocol
Transport protocol may be JMS or HTTP

How does webservice application know soap call for a particular method,without using operation name in soap message?

Document/literal WSDL for myMethod
<types>
<schema>
<element name="xElement" type="xsd:int"/>
<element name="yElement" type="xsd:float"/>
</schema>
</types>
<message name="myMethodRequest">
<part name="x" element="xElement"/>
<part name="y" element="yElement"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<binding .../>
Document/literal SOAP message for myMethod
<soap:envelope>
<soap:body>
<xElement>5</xElement>
<yElement>5.0</yElement>
</soap:body>
</soap:envelope>
How does web service engine know above soap message for a particular method ?
How server application know which method soap message is calling on?
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ link for reference

Server will identify method based on parameter types and annotated with #Webmethod.
In case of two similar method, server will call last method specified in wsdl.

Consume Axis2 Web Services in Visual Studio 2008

I'm having a bit of trouble getting Visual Studio to play nicely with my Axis2 web service. The problem is very strange, although not a show stopper. If anything it is just annoying, and I'd really appreciate a way around this.
The problem is that when using the web service in C# code, none of the parameters or return values are in their native data types. So instead of just being able to call, for example:
string timeDiff = MyWebService.GetServerTimeDifference(LocalTime)
Console.WriteLine(timeDiff);
I have to write
MyWebService.GetServerTimeDifference request = new MyWebService.GetServerTimeDifference();
request.#LocalTime = LocalTime;
Console.WriteLine(MyWebService.GetServerTimeDifference(request).#return);
As you can tell, this gets very annoying very quickly. The strange thing is that when creating the Web Reference to the web service, all of the data types and parameters are correctly shown in the service discovery page. I have tried modifying the WSDL file for the web service to remove anything which may be confusing visual studio, but so far I haven't been able to get this to work as it should.
I read somewhere that this is a Visual Studio and/or .Net problem in the de-serialization process, rather than a problem with the web service itself. I'm thinking this may be true, as the web service can be consumed correctly within NetBeans.
The Web Service is written in Java and hosted on an axis2 / Tomcat server, but the client software will be written in C# .Net 2.0.
Anyway - has anybody experienced this before? I have been unable to find the page where I read about the de-serialization problem again, so if anybody has anything to say which could help me out I'd very much appreciate it.

I suggest you define your WSDL using the document/literal/wrapped style, which as far as I know seems to be the best fit when you want interoperability.
This makes your service implementation behave well with WCF, that is used by Viusual Studio 2008 when you define a Service Reference.
It is possible to modify the WSDL specifikation for your service without breaking an existing implementation, but don't count on it.
The tricky part, though, is that you have to use some special lingo in your WSDL so that WCF will not snap out of generating nice wrappers as you requested. In your case, the automatically generated client code seems to fall back to the document/literal style, where you create and initialize "structs" that you feed to your client service method.
In essence, what you need to do is to:
Define your wsdl:types using XML Schema element.
Stick to a reasonable subset of XML Schema constructs when defining types (see the WCF documentation for a list).
Declare all elements of object-type (such as xsd:token, xsd:NMTOKEN, xsd:base64Binary, ...) as nillable="true" - plain types such as xsd:int should not be nillable.
Be prepared that the first element in a sequence used as an answer will be returned from the service call while the rest will be passed as out parameters - this typically makes an xsd:int status a suitable candidate as first in sequence.
Define your wsdl:message using wsdl:part named parameters (not parameter, not param, it has to be parameters) and using the element attribute
Define the style of the soap:operation in the wsdl:binding as "document".
Declare wsdl:input and wsdl:output to use "literal" SOAP encoding.
Play with your WSDL file and use svcutil to generate the client code. You will get warnings if there are errors in your WSDL file and if you look into the generated code, you will see comments that may point to why the wrapping style fails.
Some code may be of use here. This is a stripped down WSDL describing a service with one method GetVersionInformation that returns the triplet {"1.0", 1, 0} - effectively being the version of the interface using major and minor version numbers.
<wsdl:definitions
targetNamespace="http://tempuri.org"
xmlns:tns="http://tempuri.org"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<xsd:schema
elementFormDefault="qualified"
targetNamespace="http://tempuri.org"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- Wrapper elements. Conventions apply to wrapper element names! -->
<xsd:element name="GetVersionInformation" nillable="true" type="tns:VoidType" />
<xsd:element name="GetVersionInformationResponse" nillable="true" type="tns:VersionInformationType" />
<!-- Just a void type -->
<xsd:complexType name="VoidType">
<xsd:sequence />
</xsd:complexType>
<!-- Major and minor version information -->
<xsd:complexType name="VersionInformationType">
<xsd:sequence>
<xsd:element nillable="true" minOccurs="1" maxOccurs="1" name="version" type="xsd:NMTOKEN" />
<xsd:element minOccurs="1" maxOccurs="1" name="major" type="xsd:int" />
<xsd:element minOccurs="1" maxOccurs="1" name="minor" type="xsd:int" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</wsdl:types>
<!-- GetVersionInformation -->
<wsdl:message name="GetVersionInformationSoapIn">
<wsdl:part name="parameters" element="tns:GetVersionInformation" />
</wsdl:message>
<wsdl:message name="GetVersionInformationSoapOut">
<wsdl:part name="parameters" element="tns:GetVersionInformationResponse" />
</wsdl:message>
<!-- Port type -->
<wsdl:portType name="MyServicePortType">
<wsdl:operation name="GetVersionInformation">
<wsdl:input message="tns:GetVersionInformationSoapIn" />
<wsdl:output message="tns:GetVersionInformationSoapOut" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="MyServiceSOAP11Binding" type="tns:MyServicePortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<wsdl:operation name="GetVersionInformation">
<wsdl:input>
<soap:body use="literal" parts="parameters" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="MyServiceSOAP12Binding" type="tns:MyServicePortType">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<wsdl:operation name="GetVersionInformation">
<wsdl:input>
<soap12:body use="literal" parts="parameters" />
</wsdl:input>
<wsdl:output>
<soap12:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="MyService">
<wsdl:port name="MyServiceSOAP11port" binding="tns:MyServiceSOAP11Binding">
<soap:address location="http://localhost:80/mojo/services/MyService" />
</wsdl:port>
<wsdl:port name="MyServiceSOAP12port" binding="tns:MyServiceSOAP12Binding">
<soap12:address location="http://localhost:80/mojo/services/MyService" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
You may generate client code for this WSDL, using:
svcutil /t:code /serializer:DataContractSerializer /s /out:MyService.cs /n:*,MyService /ixt MyService.wsdl
Further, calling this code from C# would be like this:
// The endpointConfigurationName must match the corresponding entry
// in app.config, with the following content:
//
// <configuration>
// <system.serviceModel>
// <bindings>
// <basicHttpBinding>
// <binding name="MyServiceSOAP11Binding" ...>
// </binding>
// .../...
// </basicHttpBinding>
// </bindings>
// <client>
// <endpoint
/// ... binding="basicHttpBinding"
// ... bindingConfiguration="MyServiceSOAP11Binding"
// ... name="MyServiceSOAP11port" />
// </client>
// </system.serviceModel>
// </configuration>
//
string endpointConfigurationName = "MyServiceSOAP11port";
string wsEndpoint = "http://localhost/mojo/services/MyService";
MyService.MyServicePortTypeClient wsClient = null;
try
{
wsClient = new MyService.MyServicePortTypeClient(endpointConfigurationName, wsEndpoint);
}
catch (InvalidOperationException ioe)
{
// Possibly a problem with the configuration
// Inform(Logging.LogLevel.WARNING, "Potential problem with configuration: " + ioe.Message);
return;
}
string wsUsername = "John";
string wsPassword = "Doe";
if (!String.IsNullOrEmpty(wsUsername) && !String.IsNullOrEmpty(wsPassword))
{
UserNamePasswordClientCredential credentials = wsClient.ClientCredentials.UserName;
credentials.UserName = wsUsername;
credentials.Password = wsPassword;
}
try
{
int major;
int minor;
string version = wsClient.GetVersionInformation(out major, out minor);
// Inform(Logging.LogLevel.DEBUG, "Service has version " + version);
}
catch (System.ServiceModel.EndpointNotFoundException enfe)
{
// string info = "Could not contact MyService: " + enfe.Message;
// Inform(Logging.LogLevel.ERROR, info);
return;
}
catch (System.ServiceModel.FaultException fe)
{
// string info = "Could not contact MyService: " + fe.Message;
// Inform(Logging.LogLevel.ERROR, info);
return;
}
While we are at it, why not also implement the service using Axis2. First, we need a service specification (services.xml in our AAR):
<serviceGroup name="MyServices">
<service name="MyService" scope="application">
<description>My Service - document/literal wrapped style, suited for .NET integration</description>
<!-- Service methods -->
<operation name="GetVersionInformation">
<messageReceiver class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
<actionMapping>http://tempuri.org/MyServicePortType/GetVersionInformationRequest</actionMapping>
</operation>
<!-- Use WS-Adressing, ... -->
<module ref="addressing" />
<!-- Service implementation -->
<parameter name="ServiceClass">com.mycompany.services.MyService</parameter>
</service>
<service name="MyOtherService" scope="application" >
.../...
</service>
</serviceGroup>
And our server implementation, using AXIOM:
package com.mycompany.services.MyService;
import javax.xml.stream.XMLStreamException;
import javax.xml.namespace.QName;
import org.apache.axiom.om.*;
import org.apache.axis2.context.ServiceContext;
import org.apache.log4j.Logger;
public class MyService {
public static final Integer MAJOR_VERSION = 1;
public static final Integer MINOR_VERSION = 0;
public static final String NAMESPACE = "http://tempuri.org";
public static final String NAMESPACE_ALIAS = "tns";
public static final String GET_VERSION_INFORMATION_RESPONSE_ELEMENT_NAME = "GetVersionInformationResponse";
private ServiceContext serviceContext = null;
private String serviceName = null;
private static final Logger log = Logger.getLogger("SERVICE");
public void init(ServiceContext serviceContext) throws Exception {
this.serviceContext = serviceContext;
serviceName = serviceContext.getName();
}
public OMElement GetVersionInformation(OMElement element) throws XMLStreamException {
// --- Handle request ---
String version = "" + MAJOR_VERSION + "." + MINOR_VERSION;
if (log.isDebugEnabled()) {
log.debug("Retrieving version information: " + version);
}
// --- Prepare response ---
OMFactory factory = OMAbstractFactory.getOMFactory();
OMNamespace omNs = factory.createOMNamespace(NAMESPACE, NAMESPACE_ALIAS);
//
OMElement response = factory.createOMElement(GET_VERSION_INFORMATION_RESPONSE_ELEMENT_NAME, omNs);
{
OMElement value;
{
value = factory.createOMElement("version", omNs);
value.addChild(factory.createOMText(value, version));
response.addChild(value);
}
{
value = factory.createOMElement("major", omNs);
value.addChild(factory.createOMText(value, "" + MAJOR_VERSION));
response.addChild(value);
}
{
value = factory.createOMElement("minor", omNs);
value.addChild(factory.createOMText(value, "" + MINOR_VERSION));
response.addChild(value);
}
}
return response;
}
}
Axis2 and Axiom are really nice to work with. If you are having problems to generate your C# client, revisit your WSDL - it is unlikely that the problem resides with Axis2. By the way, the "Adressing" module that we refer to in the service configuration is usually added by default, but there are other modules that may be used to handle other parts of the WS-I standard.

I read somewhere that this is a Visual
Studio and/or .Net problem in the
de-serialization process, rather than
a problem with the web service itself.
I'm thinking this may be true, as the
web service can be consumed correctly
within NetBeans.
I have had this problem before - it's a .Net problem. My approach was to take a sledgehammer to the ant as it were and re-write the service in .Net