Java Reference
In-Depth Information
vocation to an implementation of
javax.xml.ws.spi.ServiceDelegate
, which the
Service
class decorates.
NOTE
The Service Provider Interface (SPI) was introduced publicly in Java SE 6, though it was used in-
ternally within the Java APIs since version 1.4. It allows a pluggable architecture by indicating the
name of a class that implements a given interface within the META-INF directory of a JAR. Though
the developer does not need to worry about it, this is how the
ServiceDelegate
implementation is
supplied at runtime.
In the calculator example, the port has one method, to match the single
add
operation defined
in the WSDL. Let's take a step back and unpack this for a moment, as there's a lot going on
here:
@WebMethod
@WebResult(targetNamespace = "")
@RequestWrapper(localName = "add",
targetNamespace = "http://calculator.me.org/",
className = "org.me.calculator.Add")
@ResponseWrapper(localName = "addResponse",
targetNamespace = "http://calculator.me.org/",
className = "org.me.calculator.AddResponse")
public int add(
@WebParam(name = "i", targetNamespace = "")
int i,
@WebParam(name = "j", targetNamespace = "")
int j);
As you can see, your seemingly simple, innocuous
add
method suddenly has a variety of an-
notations adorning it. We'll account for these one by one.
First, your WSDL specifies the following in the messages section:
<message name="add"> <part name="parameters" element="tns:add"></part>
</message>
So the SEI needs to account for this message, and creates an annotation indicating that
the runtime will create a message with a
QName
that contains a local part of
add
, in the
specified namespace. That message is derived from the Java class that is also generated,
org.me.calculator.Add
, which looks like this:
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "add", propOrder = {
"i",
