Four frequently asked questions in WebService development (1)
WebService development often encounters problems such as WebService and method overloading, circular referencing, data being worn, and so on. This article will give you some good solutions.
AD:WOT2014: User labeling system and user data Operation training session
Any problem needs to start with its roots, so simply say how WebService works. The client calls a WebService method that first needs to wrap the method name and the parameters that need to be passed into XML (that is, the soap package), usually through HTTP to the server side, and then parse the XML on the server side to get the called method name and the arguments passed. The corresponding method of the WebService instance is then called. After the method executes, the returned result is then wrapped into an XML (SOAP response) sent to the client and the client parses the XML to get the returned result. The key thing here is that the process of converting objects and XML into each other is in the middle.
Problem One: WebService and Method overloading
First, WebService does not support method overloading. The following examples illustrate.
For example, define the following WebService interface:
1 @WebService 2 public interface Ihello { 3 @WebMethod 4 public String SayHello (int id);
6 @WebMethod 7 public string SayHello (string name);
9 @WebMethod Ten public String SayHello2 (int id);
@WebMethod public string SayHello2 (int id, string name); 14} |
First Look at Method SayHello () If the client sends the following SOAP request:
1 <soap:Envelope> 2 <soap:Body> 3 <sayHello> 4 <arg0>11</arg0> 5 </sayHello> 6 </soap:Body> 7 </soap:Envelope> |
From the SOAP request we can see that the client needs to call the method SayHello (), passing the argument is 11, but cannot know whether the integer is 11, or the string "11", so it is not possible to determine which method is called.
Next look at SayHello2 (), if the parameters passed by the client include only an ID value, for example:
1 <soap:Envelope> 2 <soap:Body> 3 <sayHello2> 4 <arg0>1</arg0> 5 </sayHello2> 6 </soap:Body> 7 </soap:Envelope> |
It is still not possible to determine which method is called, because the second parameter passed to the client is understood to be null (NULL).
Typically, an exception occurs when you publish a webservice that contains an overloaded method, or when a method is called, the server-side report cannot find the corresponding method.
Question two: Has my data been modified?
First look at the WebService interface:
1 @WebService 2 public interface Ihello {
4 @WebMethod 5 Public String SayHello (IPerson person);
7}
9 public interface IPerson { 10 ... 11}
public class person implements iperson{ 14 ... 15} |
It is important to note that the WebService method SayHello () parameter is an interface, not a concrete class (for example Aegis binding allows direct publishing of such webservice). A person object is passed when the client invokes SayHello (), which implements the IPerson interface. After a series of transformations between XML and the object, the server gets only an instance that implements the IPerson interface, which is not necessarily a person object, and it is possible to throw an exception if you want to force it to be converted to person.
The root of the problem is that Aegis transforms XML into Java objects by generating a "proxy class" Implementation IPerson interface through a tool such as proxy or cglib, and then creating an instance of the proxy class, which is definitely not a person.