Web Services - Guide to Cloud Computing for Business and Technology Managers - page 175

rather than the desired simplicity, and in many applications, only a few
core standards are actually in use. There is also increasingly good tool and
library/framework support for these standards, so developers only have to
understand the capabilities offered rather than the detailed XML syntax; in
the following is a simple Web Service definition using the Java API for XML
Web Services (JAX-WS), part of the JEE platform. Creating a Web Service is
very simple:
package brokerservice.endpoint;
import javax.jws.WebService;
@WebService
public class Broker {
@WebMethod
public String viewStock(String name) {
//code omitted
}
}
So, with toolkits like JAX-WS, the service developer does not need to cre-
ate or understand XML messages formatted as SOAP. The JAX-WS runtime
system simply converts the API calls and responses to and from underlying
SOAP message formats.
One of the simplifying principles underlying Web Services is that the vari-
ous message fields and attributes used to support functions such as security
and reliability are totally independent of each other. Applications only need to
include just those few fields and attributes needed for their specific purposes
and can ignore all the other standards. For example, a SOAP request might
identify the requestor of a service by including a username and password
in the form specified in the WS-Security UsernameToken profile. This user/
password-related information is the only security-related header element
included in the message. WS-Security supports other forms of user authenti-
cation, as well as encryption and digital signatures, but as these are not used
by the service, they do not appear at all in the SOAP message request.
Another aim of the Web Service standards is to provide good support for
system architectures that make use of intermediaries . Rather than assuming
that clients always send requests directly to service providers, the interme-
diary model assumes that these messages can (transparently) pass along
a chain of other applications on their way to their final destination. These
intermediaries can do anything with the messages they receive, includ-
ing routing them, auditing, logging, checking security, or even adding or
subtracting bits of the message's content. Web services provide support for
intermediary-based architectures in a number of ways. These include tag-
ging header elements with the role of their intended recipient and support-
ing the end-to-end principle for functions such as security, so ensuring that
they continue to work even if messages pass through intermediaries rather
than traveling directly from client to service. For example, the client can