Exposing EJBs as web services - EJB 3 in Action - page 305

• Protocol handlers (@ javax.xml.ws.handler.soap.SOAPHandler ),
which operate on the message context properties and protocol-specific messages
Now that we've covered the basic JAX-WS annotations, let's review how to effectively use
SOAP from EJB.
8.2.6. Using EJB SOAP web services effectively
The combination of JAX-WS and EJB makes it almost too easy to expose business logic
as web services. After reading this section, you might be tempted to expose every bean via
SOAP. But there are many pitfalls that you must be careful of. Just like sprinkling syn-
chronize throughout your code base won't make your code thread-safe, decorating your
classes with @WebService won't turn your application into an overnight SOA success.
Let's look at how you should approach EJB and SOAP.
The first consideration should be to determine whether it's necessary to expose beans to
external systems and then determine whether the external systems require interoperability.
If not, JMS or Java RMI is probably a better alternative. These technologies have much
less overhead—both in terms of network traffic and in terms of processing the messages.
XML is expensive to transmit and process. If you're providing services to third parties,
then SOAP is a good solution; if you need to connect to Java systems internally, use RMI
or JMS.
If you choose to expose services using SOAP, expose only the method that needs to be
exposed. If you have a fairly rich object graph, you'll probably want to pass back DTOs
and limit the amount of data exchanged via web services. You don't want JAXB serializing
most of your database into an XML document. In the case of ActionBazaar, a web service
request for an item shouldn't retrieve the list of all of the bidders along with the bidders'
usernames and passwords.
Analyze whether you need RPC-oriented or document-oriented web services. You can use
the @SOAPBinding annotation to control the style for your EJB web service. RPC-style
web services may perform better than document-style web services. But document-style
web services provide more flexibility because you can use XML schemas to define the
messages. Similarly, avoid using message encoding because it makes your services less in-