Java Reference
In-Depth Information
get {
this.RaiseExceptionIfNecessary();
return ((int)(this.results[0]));
}
}
}
There are a number of things to note in this file. Let's compare and contrast this proxy with
one generated in Java EE 5:
▪ The Java version provides multiple constructors: an empty one that uses the WSDL loc-
ation you passed the tool, and another one that allows client classes to pass in a differ-
ent URL. This is really important during the development life cycle. But in this C# class,
there is only one constructor, and the class is declared
partial
. This is a .NET idiom that
allows you to split the construction of classes across two files. It is an extensibility mech-
anism that potentially allows you to override the location of the WSDL URL by using a
different class that sort of appends a constructor to this one.
▪ By default, asynchronous methods are generated invoking the
add
operation. You didn't
tell the tool to do that, and the WSDL doesn't specify it. The asynchronous work is imple-
mented using event handler methods.
▪ A C# property is generated for the response type. The schema for the
add
result looks like
this:
<xs:complexType name="addResponse">
<xs:sequence>
<xs:element name="return" type="xs:int" />
</xs:sequence>
</xs:complexType>
That XML schema type generates in a read-only C# property called
Result
on the proxy.
You can use this property in a caller to get the sum of the
add
operation.
▪ The Java EE 5 proxy mechanism is modeled after .NET. In .NET the metacodes between
the square brackets are called attributes. In Java, of course, you use the
@
sign and call
them annotations. But the idea is the same, and you can see how similar they are. Consider
the
SOAPDocumentMethodAttribute
, which allows you to specify the namespace and the
parameter style and use.
Now that you have generated a proxy and understand what it's doing, let's put it to work in an
application:
