EJB, Spring Remoting, and Web Services - Spring Enterprise Recipes: A Problem Solution Approach - page 223

<TemperatureInfo city="Houston" date="2007-12-08">
<min>4.0</min>
<max>13.0</max>
<average>7.0</average>
</TemperatureInfo>
<TemperatureInfo city="Houston" date="2007-12-15">
<min>10.0</min>
<max>18.0</max>
<average>15.0</average>
</TemperatureInfo>
</GetTemperaturesResponse>
After designing the sample request and response messages, you can start creating the contract for
this web service using XSD and WSDL. There are many tools and IDEs that can help generate the default
XSD and WSDL files for an XML document. You only need to carry out a few optimizations to have it fit
your requirements.
Comparison
When developing a contract-last web service, you are actually exposing the internal API of your
application to clients. But this API is likely to be changed—and after it's changed, you will also have to
change the contract of your web service, which may involve changing all the clients. However, if you
design the contract first, it reflects the external API that you want to expose. It's not as likely to need
changing as the internal API.
Although many tools and libraries can expose a Java class/interface as a web service, the fact is that
the contract generated from Java is not always portable to other platforms. For example, a Java map may
not be portable to other programming languages without a similar data structure. Sometimes you have
to change the method signature in order to make a service contract portable. In some cases, it's also
hard to map an object to XML (e.g., an object graph with cyclic references) because there's actually an
impedance mismatch between an object model and an XML model, just like that between an object
model and a relational model.
XML is good at representing complex data structures in a platform- and language-independent way.
A service contract defined with XML is 100 percent portable to any platform. In addition, you can define
constraints in the XSD file for your messages so that they can be validated automatically. For these
reasons, it's more efficient to design a service contract with XML and implement it with a programming
language such as Java. There are many libraries in Java for processing XML efficiently.
From a performance viewpoint, generating a service contract from Java code may lead to an
inefficient design. This is because you might not consider the message granularity carefully, as it's
derived from the method signature directly. In contrast, defining the service contract first is more likely
to lead to an efficient design.
Finally, the biggest reason for choosing the contract-last approach is its simplicity. Exposing a Java
class/interface as a web service doesn't require you to know much about XML, WSDL, SOAP, and so on.
You can expose a web service very quickly.
5-8. Exposing and Invoking Web Services Using XFire
Problem
Because Web Services is a standard and cross-platform application communication technology, you
want to expose a web service from your Java application for clients on different platforms to invoke.