Java Reference
In-Depth Information
2. Generate client-side code using
wsimport
. Among other things, this will generate a ser-
vice interface for each
portType
.
3. Implement each interface by writing your web service implementation class. That means
doing something like this:
@WebService
(endpointInterface="com.soacookbook.MyGeneratedInterface",
wsdlLocation="/META-INF/wsdl/MyWsdl.wsdl")
public class MyService implements MyGeneratedInterface { ... }
4. Deploy the service endpoint implementation to a JAX-WS-compatible container.
In this example, the endpoint interface is specified as a fully qualified name of the interface
that
wsimport
generated, written as a string. The WSDL location property allows you to spe-
cify either a relative or an absolute URI. If relative, it must be in META-INF/wsdl.
One benefit to this approach is that the vendor implementation is obligated to inform you if
the service implementation you created does not actually conform to the WSDL.
In order to round out the implementation, you can use JSR-181 (Web Services Metadata) an-
notations to specify the concrete aspect of the WSDL, such as protocol binding.
Because the purpose of web services is to develop a strong contract that is free of implement-
ation dependencies, this may seem like a good approach. And while its theoretical purity may
be attractive, for many Java developers, it can be a difficult way to start. If you have little
experience with WSDL, the thought of writing one by hand is daunting. They are not simple
documents to create, in particular because considerable knowledge about how web services
work under the hood is required to understand the implications of your choices. In part this
is due to the fact that Java IDEs are very powerful, and readily perform sophisticated code
refactorings at the click of a button. On the other hand, tools that can perform even basic re-
factoring of XML schemas or WSDLs are hard to come by at any price.
So despite the fact that the “Start from Contract” method can be very powerful, Java deve-
lopers often shy away from it because their core competency is in Java, not WSDL. However,
although WSDL is complex, perhaps overly complex, it can certainly be learned. A given
WSDL instance document itself is complicated by the fact that choices such as parameter style
and use change the structural features of the document. But conceptually WSDL will reflect
only a few basic constructs, making it relatively straightforward to read and write.
XML Schema, on the other hand, is nearly as rich and expressive as many programming lan-
guages. There are a wide variety of advanced features that will not comfortably find their way
into an interface definition that can easily interoperate as a web service. Fluency in schema
can be an important prerequisite for this approach.
