The third approach is to write both the WSDL and the corresponding Java code. This offers
the best of both worlds: a well-written WSDL file and clean Java code. This gets around
the issue of having the tools generate either a nonportable WSDL file or messy Java code.
This is the most technically challenging approach, because both the WSDL and the Java
code must match. For services targeted at other languages and platforms with a long-term
life expectancy, this is definitely the best choice.
All three of these solutions require the use of a data-binding framework. In most environ-
ments, JAXB (JSR 222) is the default data-binding framework. The data-binding frame-
work is responsible for converting the XML into Java objects that are then passed into your
service. For example, consider the bid service that has a placeBid method. This method
takes a Bid object as a parameter.
We'll touch on these approaches later when we examine best practices. Let's first answer
the question of when SOAP should be used.
8.2.2. When to use SOAP web services
The question this section attempts to answer is, When should you use SOAP web services?
This is a loaded question and can be interpreted one of several different ways. It could be
interpreted as “Should I expose application services via SOAP versus another technology
like Java's RMI or RESTful web services?” Or it could be interpreted as the question of
whether application services should be exposed to external systems via a technology like
SOAP. The second question isn't within the scope of this chapter. It can be best addressed
by topics that focus on the design of service-oriented architectures (SOA) and SOAP in
more detail, such as SOA Governance in Action by Jos Dirksen (Manning, 2012). We'll fo-
cus on the first question.
When looking at exposing business functionality to other systems, the Java EE 7 stack
provides several different technologies to choose from, including SOAP. You can also
choose to expose business services via Java RMI, JMS, and RESTful web services. Each
one of these technologies has benefits and trade-offs depending on your requirements.
Java Remote Method Invocation (RMI) is the original Java technology for exposing busi-
ness services. Java RMI makes EJB possible, and beans are available by default via RMI.
Java RMI is optimal in situations where the client is a Java application. RMI has much