From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, March 11, 2005 12:59 PM
To: [email protected]
Subject: RE: .NET and Axis
<?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:Body><getComplexTypeResponse xmlns="http://rbc.com"><getComplexTypeReturn><stringValue>Aedemar</stringValue></getComplexTypeReturn></getComplexTypeResponse></soapenv:Body></soapenv:Envelope> </results>
public class MyComplexType implements java.io.Serializable {
private java.lang.String stringValue;
/*** Gets the stringValue value for this MyComplexType.
*
* @return stringValue
*/
public java.lang.String getStringValue() {
return stringValue;
}
/**
* Sets the stringValue value for this MyComplexType.
*
* @param stringValue
*/
public void setStringValue(java.lang.String stringValue) {
this.stringValue = stringValue;
}
<complexType name="MyComplexType">
<sequence>
<element name="stringValue" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://rbc.com")]
public class MyComplexType {
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
public string stringValue;
}
From: Dino Chiesa [mailto:[EMAIL PROTECTED]
Sent: 11 March 2005 5:26
To: [email protected]
Subject: RE: .NET and Axis
Your understanding is not quite right, but first let's deal with the issue you are having.you wrote:> I don't want to use the Axis generated classes for the reasons specified above, but do I have any choice if I want to go to wrapped/literal?Yes, you have a choice. You can specify in-line code attributes on your .NET types to map element names to fields or properties. So you can tell .NET that a <stringValue> element should get mapped to a field named StringValue. Like this:[XmlType(Namespace="urn:ionic.webservices.2005.03.Types")]
public class MyComplexType {
[XmlElement("stringValue", IsNullable=true)]
public string StringValue;
...}By default .NET assumes the element name in the XML is exactly the same as the field (or property name) in the .NET class. But you can specify any mapping you like.Ok, now, getting back to your issue. you wrote:> in order to use a wrapped/literal service to send data between .NET and Axis, the Java Bean property names need to start with an UPPER case character in the XML.Considering what I wrote above, this is obviously not true. A better statement is, "the mapping on the server side between JavaBean property name and XML element name, must agree with the mapping on the client side between XML element name and .NET field or property."In other words, if on the AXIS side you map a JavaBean property named "foo" to an xml element name of <Bananas>, then you have to insure that on the .NET side, <Bananas> maps to the appropriate property or field in your type. And for those of you who care, that property or field name on the .NET side certainly does not have to be "foo", it can be any legal property name. All I am saying is, the mapping has to be consistent. LetA = Java bean property nameB = element nameC = .NET property or field namethen A maps to B, and B maps to C.It sounds complicated, and that is why we rely on WSDL and tools such as WSDL2Java and wsdl.exe to ensure these mappings agree. And in general, if you use the tools to generate code, what you get is A=B=C. This keeps it simple.----By trying to avoid half of the WSDL-to-sourcecode dance, so that you can use your pre-existing types, you violate The First Law of Webservices interop ("start with WSDL first"). This is causingA maps to B and C maps to D.whereB = <stringValue>andC= <StringValue>they are not the same! Ne'er the twain shall meet.I am guessing that you have a WSDL, and you have an independent, pre-existing set of Java types. You might think they agree with each other, but but they apparently do not. If you then generate a .NET client proxy from the WSDL, and then try to marry that client-side proxy to the AXIS Service, it won't work.But you can still get things to work, even if you do start with Java first. (Don't tell anyone I told you this.) It just takes more work on your part, and more understanding of the XML the various webservices stacks generate. Roll up your sleeves.For simple cases, you can actually start with Java code, and generate WSDL from it, and then generate VB or C# code from that WSDL. It appears you are not doing this?If you are a WSDL propellerhead, then you can independently design your Java classes and WSDL, and manually insure they agree with each other. Then generate .NET client-side proxy code from that WSDL . I don't advise this. Too easy to miss something or make mistakes. The tools are there to avoid the need to do this sort of thing.Finally, you can massage the generated .NET code and tweak attributes that do the mapping. Just because it is generated code doesn't mean it is immutable. Obviously this presents implications for long-term maintenance, because every time you change the WSDL, you may need to re-modify the generated code. But whatever, it's an option.-Dino
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 09, 2005 11:58 AM
To: [email protected]
Subject: .NET and AxisHi,
I have posted emails on this topic before but have never really understood the problem I was experiencing until now. Sorry for any misleading mails up to this point. I also apologise in advance for the length of this mail. Hopefully people can understand what I am getting at!
The problem (as I now understand it) is that in order to use a wrapped/literal service to send data between .NET and Axis, the Java Bean property names need to start with an UPPER case character in the XML.
Easier to explain with code I think....
The Java Bean class can have the property name in lower case, e.g., stringValue
private java.lang.String stringValue;
but must serialise it to start with an upper case character, e.g., StringValue
org.apache.axis.description.ElementDesc elemField = new org.apache.axis.description.ElementDesc();
elemField.setFieldName("stringValue");
elemField.setXmlName(new javax.xml.namespace.QName("urn:ionic.webservices.2005.03.Types", "StringValue"));
elemField.setXmlType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "string"));
elemField.setNillable(true);
typeDesc.addFieldDesc(elemField);so that the c# class has properties that start with upper case, e.g., StringValue not stringValue
[System.Xml.Serialization.XmlTypeAttribute(Namespace="urn:ionic.webservices.2005.03.Types")]
public class MyComplexType {
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
public string StringValue;
/// <remarks/>
public int IntValue;
/// <remarks/>
public System.DateTime DateTimeValue;
/// <remarks/>
public System.DateTime Created;
/// <remarks/>
public System.Single FloatValue;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute("ChildObjects", IsNullable=true)]
public MyComplexType[] ChildObjects;
}If I don't include the Axis generated Custom Serializer and Deserializer in my classes (coz I have tons of existing classes that have lots of comments in them and existed before I needed to expose my application using web services), Axis uses org.apache.axis.encoding.ser.BeanDeserializerFactory for the serialization which means that the c# properties are generated with the same case as the Java class, i.e., starting with a lower case letter, and the data is not serialized correctly.
For example, if the following code is executed from a .NET client
CTSOAP service = new CTSOAP();
MyComplexType type = service.getComplexType("caller");
type is not null but type.stringValue is an empty string.
If I use the Axis generated classes, then the properties are serialized and deserialized using properties where the first character is Upper case and this solves the problem.
I don't want to use the Axis generated classes for the reasons specified above, but do I have any choice if I want to go to wrapped/literal?
This problem does not exist for rpc/encoded.
Any comments would be appreciated.
____________________________________________________________
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Ce courrier �lectronique est confidentiel et prot�g�. L'exp�diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d�sign�(s) est interdite. Si vous recevez ce courrier �lectronique par erreur, veuillez m'en aviser imm�diatement, par retour de courrier �lectronique ou par un autre moyen.
============================================================
------------------------------------------------------------
This
e-mail may be privileged and/or confidential, and the sender does not waive any
related rights and obligations. Any distribution, use or copying of this e-mail
or the information it contains by other than an intended recipient is
unauthorized. If you received this e-mail in error, please advise me (by return
e-mail or otherwise) immediately.
Ce courrier �lectronique est
confidentiel et prot�g�. L'exp�diteur ne renonce pas aux droits et obligations
qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des
renseignements qu'il contient par une personne autre que le (les)
destinataire(s) d�sign�(s) est interdite. Si vous recevez ce courrier
�lectronique par erreur, veuillez m'en aviser imm�diatement, par retour de
courrier �lectronique ou par un autre
moyen.
============================================================
