Java Reference
In-Depth Information
WARNING
You must rely on considerable generation of code when working with modern web services, whether
you decide to generate schema and WSDL or Java. But the bottom line with generation of any kind
is that you should never generate what you don't understand. Generation is wonderful, and saves lots
of time and trouble, but it can cause a lot of trouble if you get in over your head.
It is common to hear the term “contract” used to refer solely to the WSDL. I and others con-
sider the “contract” to include not only all of the elements within the WSDL, such as data
types, operations, bindings, and policies, but also items external to the WSDL. For services,
and SOA in particular, a service contract is not only the WSDL, but it can also include items
such as policies, service-level agreements, user authorizations, and other items that might be
presented from an enterprise registry/repository.
On a practical level, your organization might benefit from having a published WSDL released
early in the project, so that client- and server-side development teams can work independently.
Another key benefit to starting from WSDL is that XML schema affords a far richer set of
data types than many programming languages. Starting from WSDL, you can offer a set of
type options, maximizing interoperability.
Start from Java and WSDL
This approach takes a realistic middle road. If you have a mature organization with a large
catalog of diverse systems that your SOA intends to interconnect, you might find yourself
needing to implement your web services atop legacy systems that provide their own APIs
and schema sets. Your service implementation Java class might use annotations such as
@We-
bMethod.operationName
to associate an operation defined in the WSDL to a particular meth-
od of the class.
WARNING
The “Start from WSDL and Java” model, outlined in JSR 181, is optional. Because vendors are not
required to support it, using this development model could limit your portability.
This approach can prove very difficult to maintain because once you've generated classes us-
ing the tools, you still need to manually tweak a variety of resources. The “Start from Java”
approach, by distinction, gives you considerable flexibility during the development process
because you can all but forget about the WSDL and the schemas it uses, and focus on your
business logic. Starting from WSDL, you can focus on only the contract. But starting from
both requires that you keep your eye on more than one moving part.
