Java Reference
In-Depth Information
teroperable, as well as less portable between SOAP implementations. Document/literal is
the recommended combination for an interoperable web service.
Design your EJB web service so that it creates minimal network traffic. Avoid sending
large objects over the wire. It's best to send an ID or reference to an object instead of send-
ing the entire object. All objects sent via SOAP are serialized into XML. The XML rep-
resentation of data can be quite large, making SOAP messages much more expensive than
retrieving the object in the target location. In addition, if your EJB involves a long-running
transaction, avoid exposing it as a web service, or mark it as not returning a value so that it
can be invoked in a more asynchronous manner.
Use JAX-WS data types as the method parameters for your web service to give it inter-
operability with heterogeneous web services. Suppose you have an object graph involving
Collection
s,
HashMap
s, and
List
s as web service parameters. Using these data types
in the WSDL makes your application less interoperable. Test your application to make sure
it complies with the WS-I Basic Profile if interoperability is important for your application.
There are several mechanisms to secure your web services. You must weigh your security
requirements against performance, because security comes with a high cost. The perform-
ance costs of end-to-end security are commonly higher than the initial perceived costs. This
is true in general of system/application security, but even more so with regard to web ser-
vices that are designed to be shared with unknown client applications. Now that you're fa-
miliar with JAX-WS, let's shift gears and dig into RESTful web services using JAX-RS.
8.3. Exposing EJBs using REST (JAX-RS)
In the first half of the chapter we examined SOAP-based web services. In this half we
switch gears and dive into RESTful web services. The last few years have seen RESTful
web services explode dramatically and with good reason. The RESTful approach has a
feeling of “back to the basics” when compared with SOAP. SOAP has been out for over a
decade and thus has expanded far beyond its humble beginnings as a simple and standard
approach for exchanging XML messages. SOAP used to officially stand for Simple Object
Access Protocol, but now it's officially referred to as SOAP with the full title having been
dropped from the specifications, and it's definitely no longer simple.
