Java Reference
In-Depth Information
COMMUNITY THOUGHTS ON THE “START FROM JAVA” APPROACH
There have been a number of detractors over the years of the “Start from Java” model, for a few dif-
ferent reasons.
Early web services were largely implemented using RPC/encoded because the SOAP encoding
scheme would generate XML models directly from service provider data structures and duplicate
them for use within client applications. This was expedient, making RPC/encoded a popular ap-
proach. But it also meant that the clients were tightly coupled with the SOAP encoding itself, forcing
clients to regenerate their code if data structures changed. Moreover, SOAP encoding is a serializ-
ation mechanism; because it is driven by SOAP itself, there is little or no use for it outside such a
protocol. Validation is not possible using that scheme, and the resulting data structures are not trans-
ferable.
Modern web services applications employ data binding, which serves as a layer of indirection
between the programmatic representation of a data structure (e.g., a JavaBean) and its XML repres-
entation. The data binding layer, as performed by Castor, BEA's XMLBeans or JAXB (all of which
are Java-XML binding technologies), isolates each of these representations, allowing developers to
maintain independent control over them, using each to its best advantage.
All in all, the new Java web services specs, including JAXB (JSR 222) and JAX-WS 2.1 (JSR 224),
have answered those charges handily. So maybe the reasons for being leery of this approach in the
past years have faded.
Such objections might lead one instead to start from the opposite end of the spectrum: writing
the WSDL by hand and generating the service, which we'll explore in the next section.
Start from contract (WSDL)
For SOAP-based services, the WSDL represents the contract. This model has a single over-
arching paradigm: the WSDL defines the primary features of the contract for the service,
and implementation-independent contracts are one of the cornerstone necessities of SOA. The
contract is not an afterthought, but rather a central concern. With this model, you write the
WSDL yourself by hand, generate a Java code shell for the service implementation, and then
fill in the business logic for the service implementation. This method is also sometimes re-
ferred to as “Contract First.”
You start by taking a preexisting abstract WSDL and pointing it to a tool such as
wsimport
that produces a service endpoint interface in addition to Java classes that represent the schema
definitions and message parts specified in the WSDL. Once the endpoint interface has been
generated, write a Java class that implements that interface. The basic steps are as follows:
1. Write a WSDL representing the service you want to deploy.
