aspose file tools*
The moose likes Web Services and the fly likes question on client side soap binding stub on wsdl complext type element Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "question on client side soap binding stub on wsdl complext type element" Watch "question on client side soap binding stub on wsdl complext type element" New topic
Author

question on client side soap binding stub on wsdl complext type element

grace smith
Greenhorn

Joined: Jun 14, 2005
Posts: 23
Hello,

In my SEI, I have a function like:
public Member findBySSN(java.lang.String SSN);


In the WSDL, I defined the related element and operation so on as:

....
<simpleType name="socialSecurityNumber">
<restriction base="xsd:string">
<pattern value="\d{3}\d{2}\d{4}"/>
</restriction>
</simpleType>

<element name="findBySSN">
<complexType>
<sequence>
<element name="SSN" nillable="true" type="intf:socialSecurityNumber"/>
</sequence>
</complexType>
</element>


<element name="findBySSNResponse">
<complexType>
<sequence>
<element maxOccurs="unbounded" name="findBySSNReturn" type="tns2:Member"/>
</sequence>
</complexType>
</element>

<wsdl:message name="findBySSNRequest">
<wsdl art element="intf:findBySSN" name="parameters"/>
</wsdl:message>

<wsdl:message name="findBySSNResponse">
<wsdl art element="intf:findBySSNResponse" name="parameters"/>
</wsdl:message>

<wsdl peration name="findBySSN">
<wsdl:input message="intf:findBySSNRequest" name="findBySSNRequest"/>
<wsdl utput message="intf:findBySSNResponse" name="findBySSNResponse"/>
</wsdl peration>

....


The problem is when I create the service client, the client side stub automatic generated a new java type SocialSecurityNumber.java, so when the client code call to the SEI function findBySSN(String ssn), it complains that the type defined is not applicable with the argument type string because the client . soapbindingstub.java generated for the soapbinding on the SEI findBySSN method is actually as this:

public Member findBySSN(SocialSecurityNumber SSN) throws java.rmi.RemoteException{ ....}.


What should I do with this error? Basically, how do I deal with the WSDL complex type to java binding?

Anyone can help me out? Thanks in advance.

-Helen
Watsh Rajneesh
Ranch Hand

Joined: Apr 17, 2006
Posts: 110
You will get a new Javabean SocialSecurityNumber type as you are defining the socialSecurityNumber as a simple-type (restricting xsd:string type). So there are 2 possible solutions, either:
1. You can define the socialSecurityNumber type to be of xsd:string alone (and no restrictions), in which case your socialSecurityNumber will be mapped to java.lang.String type.
2. OR you can generate your java classes (including the SEI) using wsdl2java. So your wsdl remains same and the generated SEI will use the SocialSecurityNumber type as a method arg.


SCJP 5.0 (90%), SCDJWS 1.4 (88%), SCWCD 1.4 (82%), SCBCD 1.3 (85%)
grace smith
Greenhorn

Joined: Jun 14, 2005
Posts: 23
Watsh,

Thanks so much for your quick and helpful reply. Your second suggestion works. I added in the SocialSecurityNumber.java class to my service side package and adjusted the SEI function parameter too, I see it works.

Then I come up with more questions - The way I did not use direct xsd:string type for ssn is because I want to set up the data format rule in the WSDL through the schema so the client will check directly from the WSDL and program at their side for the input parameter validation. but this way seems give the service side programming more burdens- we have to code extra Object due to any simple type we defined in the schema. also as the service code, we still need to check the format of input parameter and define the application exception and map it as the fault to the WSDL. to me, define the complicated complex restricted or extention type in the schema is just offering the convience for the client, right? If we do it simple and just use the basic as xsd:string for the ssn, the client has to figure out the input parameter format at runtime base on the fault we mapped, right?

as your opinion, which way is better?

thanks
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: question on client side soap binding stub on wsdl complext type element