Java Reference
In-Depth Information
Start from Schema
This is a somewhat rarer solution, but one that I have used successfully in the past. With this
model, you do not start from WSDL or from Java, but begin by defining your business docu-
ments in XML Schema. Starting from either WSDL or Java gives you a more process-orien-
ted view: you write operations or methods first and you're starting from verbs. When starting
from schema, there are no verbs, only nouns, so your focus is more on the business documents
that your service must exchange. Here are the steps involved:
1. Write a set of XML schemas that represent the data types your business model requires.
2. Use JAXB to generate Java classes based on the schemas.
3. Create an annotated service endpoint implementation in Java. This implementation refers
to the JAXB-generated types in the method signatures. If you use a document/literal bare
style, each type will be used only once within the service. If you use a wrapped style, you
will need to create wrapper elements.
4. Package and deploy the application, allowing the tool to generate the WSDL.
5. Perform runtime validation during marshaling against the schemas.
With the “Start from Schema” view, your SOA becomes more about a document exchange
and less about performing remote procedure calls, which can be an advantage in the long run
when building orchestrations around your services. This method encourages you to primar-
ily focus on your business documents, such as Invoice, Purchase Order, Customer, and Credit
Application. Your service then becomes more of an intake for such documents, serving as a
facade for possibly complex enterprise workflows.
The “Start from Schema” approach works well with a document/literal style and use. RPC,
like start from Java, can in subtle ways lead you toward considering your service from the
view of parameter lists. This is generally not desirable with an enterprise SOA context be-
cause it is not business document-oriented, and you can end up with a service that is less likely
a candidate for reuse.
Of course, there are disadvantages to this approach. One is added complexity. You cannot rely
on certain constructs you've become not only accustomed to, but adamant about using within
your Java code, such as
toString
,
equals
, and
hashcode
implementations (without custom-
ization using third-party tools). In fact, if you are using this approach, it will become import-
ant to use data binding customization in order to ensure that you are not at the mercy of tool
defaults.
Another danger to this approach is a susceptibility to tight coupling . By putting schemas at
the forefront, you risk tightly coupling services together within composite applications if they
