9.1 Introduction to Web Services

Web services technology represents an important step toward fulfilling the vision of the Internet as an open, interoperable environment in which customers and businesses can interact in ways that were not possible before. The technology is based on fundamental Internet technologies developed during the last few years by a variety of standards bodies, including the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). These Internet technologies allow software applications developed by various vendors or individuals to interoperate, regardless of the software or hardware systems used to implement the applications.

9.1.1 Web Services Technologies

The building blocks of Web services technology are Extensible Markup Language (XML) and HyperText Transfer Protocol (HTTP), which together provide a way to flexibly represent structured information and exchange it over networks. Other standards contribute to making Web services possible, including standards for describing, accessing, and publishing the service:

• Service description A software application that provides Web services must have a standard way of describing its services so that other applications can use them. The Web Services Description Language (WSDL) is the standard for describing a service.

  WSDL consists of a specific set of XML elements. Developed by the W3C, this standard allows a service to be described as a collection of port types that in turn consist of a set of operations. Operations can be either synchronous a request followed by a response or asynchronous the sender sends the message and continues processing without expecting a response. Each operation contains a description of the input and output messages describing the information that is expected and returned by an operation. Messages can be procedural in nature describing parameters to the operation or document oriented containing an XML document, such as a purchase order. Port types are bound to ports. Ports can be accessed over a specific protocol and data format at a network endpoint consisting of a host name and TCP/IP port number, all of which are specified through a binding. Thus, a WSDL document has all the elements necessary to provide a complete description of a Web service in a platform-independent manner.

• Service access It is essential for interoperable Web services to have a standard network protocol and data format for exchanging information. The Simple Object Access Protocol (SOAP), along with the data formats and type system described by the XML Schema standard, provide the technology for a standard network protocol and data format. (Both SOAP and XML are defined by the W3C.)

  SOAP messages are XML documents containing the necessary header information to allow a message to be properly transmitted from sender to receiver, as well as a body containing the service request or response message. The SOAP standard includes a standard binding to HTTP, which allows SOAP messages to be exchanged over the ubiquitous HTTP.

• Service publishing and discovery For Web services to initiate interactions with other Web services, there must be a standard way for a service to advertise its existence in a domain and for other services to search for and discover its contact information, such as network endpoint, protocol, and so forth, and the operations it supports. The Universal Description, Discovery, and Integration (UDDI) standard makes service publishing and discovery possible.

  The UDDI standard, developed by the UDDI Project, defines how to publish and discover Web services through a public registry, or directory. Information in an UDDI registry divides into three categories: "white pages," which include information such as contact addresses; "yellow pages," which organize businesses into categories; and "green pages," which provide technical information on how to access a service. Using this information, services can begin interacting with one another in a standard manner.

The WSDL, SOAP, and UDDI standards form the backbone of Web services technology. Enterprise applications use these technologies to interact with other applications at customer, supplier, and partner locations. Such interactions allow these applications to exchange business information and to conduct transactions rapidly. Enterprises in a variety of industries are becoming aware of the cost savings, along with productivity and efficiency gains, achieved by using Web services. As a result, businesses in diverse industries are making significant investments to enable their enterprises to use Web services.

9.1.2 J2EE and Web Services

Although Web services provide a new way for applications to interoperate over the Internet, an enterprise still must develop and implement a Web services application, or it must expose existing applications as Web services. To expeditiously implement or expose a Web service requires an application development and deployment platform that is powerful and full featured yet at the same time easy for developers and deployers to use. The J2EE platform leverages the strengths of the Java programming language and enterprise APIs, including the EJB technology, to provide an industry-leading Web services platform.

The strengths of the J2EE platform include a set of component models that allow developers to focus on writing the business logic in their applications and to delegate system-level details to infrastructure layers. In addition, the platform's range of business integration features for accessing relational databases, messaging systems, and enterprise information systems makes it easy to leverage existing enterprise information assets. These features are coupled with a powerful set of Web technologies, revolving around XML and HTTP, that simplify access to J2EE applications from customers and other business applications.

The J2EE 1.4 platform release includes an entire set of Web services technologies:

• Java API for XML-based RPC (JAX-RPC) Major enterprise vendors, through the Java Community Process (JCP), worked together to develop the JAX-RPC standard. JAX-RPC defines Java APIs for accessing Web services from Java applications: how to map a WSDL description of a Web service to a Java interface, called the service endpoint interface. JAX-RPC also defines how to map existing Java application interfaces to WSDL descriptions. As a result, applications using JAX-RPC program to familiar Java interfaces and data types and do not need to deal with low-level details, such as parsing or composing XML documents and extracting XML documents from SOAP messages.

  Furthermore, JAX-RPC implementations provide the client- and server-side libraries to send and receive Web services requests over SOAP. JAX-RPC thus provides the necessary support for Java applications to access Web services, implement Web services, and be transformed into Web services.

• Java API for XML Registries (JAX-R) JAX-R provides APIs that Java developers use to access XML registries, including registries based on UDDI. Similar to JAX-RPC, JAX-R is being developed through the JCP by a large number of enterprise vendors.

• SOAP with Attachments API for Java (SAAJ) SAAJ defines APIs that allow Java applications to construct SOAP 1.1 messages and send them to peers on a network. It also defines APIs for consuming and manipulating SOAP messages that have been received by an application. SAAJ provides functionality to create SOAP messages and then add header, body, and fault elements to those messages.

• Java API for XML Processing (JAX-P) JAX-P defines APIs that Java applications use to parse, manipulate, and transform XML documents. It includes the W3C standard programming APIs: Simple API for XML (SAX), Document Object Model (DOM), and Transformation API for XML (TrAX). JAX-P provides a powerful set of APIs that applications use to produce and consume XML documents they have received from or intend to send to Web services.

• Java API for XML Binding (JAX-B) JAX-B provides APIs and standards for representing XML documents and fragments as Java data structures. JAX-B defines how to map a document type definition (DTD) or schema for an XML document into a set of Java classes. This mapping allows instance documents that conform to the DTD or schema to be represented in memory as a set of Java objects that are instances of the corresponding Java classes. Thus, the Java programmer can use a high-level object-oriented view of the underlying XML document; the developer does not have to deal with details of the document structure and XML-specific APIs.

In addition, the EJB 2.1 architecture defines how to use an enterprise bean to implement a Web services endpoint. The Web Services for J2EE specification also describes how to develop and deploy Web services clients and servers in a J2EE environment.

9.1.3 Security and J2EE-Based Web Services

Enterprises that build Web services to expose their enterprise applications to customers, suppliers, or partners must be sure that such Web services are secure. Enterprise applications must be able to access and update business-critical data. The availability of enterprise applications is critical to the functioning of business processes in the enterprise. It is imperative that Web services not impair the consistency or availability of enterprise applications and data.

The technologies that predated Web services did not implement security uniformly. As a result, most enterprise organizations used different security standards, which made it difficult for organizations to interoperate securely, creating a problematic situation.

Web services technology provides solutions to such security concerns by providing standardization. Some of these solutions are based on established standards, such as the Secure Sockets Layer (SSL). Other standards, such as for security information in SOAP messages, are forthcoming. Standards bodies are giving the security area intense attention, and security standards for resolving security issues across enterprises using Web services are still evolving.

The EJB architecture and the J2EE platform provide an "enterprise-strength" security infrastructure that enables administrators to control who is allowed to access what applications and data. This security is achieved through

• Message protection, for ensuring the integrity and confidentiality of data as it is transmitted over the Internet

• Authentication, for verifying the identity of clients of Web services

• Authorization, for restricting access to only an allowed set of operations

Chapter 11, Managing Security, discusses the security infrastructure in detail. The important point for developers of EJB-based Web services is that there are no new APIs for Web services security. Instead, the container takes care of the security needs of the application, based on information provided in the deployment descriptor.

The Web services features of the EJB architecture also allow for modular, componentized, and incremental development of Web services. For example, an enterprise may expose just a small component of its large enterprise application as a Web service, keeping the remaining parts of the application unaffected. This permits the enterprise to tightly control the set of allowed operations that can be performed by external users. Furthermore, security for such external access is enforced at the entry point, which in this case is the EJB-based Web service hosted and administered by the enterprise. The administrators of the Web service use the familiar security administration tools provided by the J2EE product to modify the Web service and control who can access what parts of the service. Thus, an enterprise can build and administer the Web service with minimal incremental work.

The next sections discuss how to leverage the strengths of the EJB architecture, Web services technologies, and these Java APIs JAX-RPC, JAX-R, JAX-P, and JAX-B to develop Web services using enterprise beans.