Java Web Development with NetBeans IDE

1. Java Web Development with NetBeans IDE －－Kai Qian Chapter 8 JAX-WS Web Services

2. Introduction to Web Services • A web service is a service meant for consumption by another application or component, much in the same way that session beans are meant to be used by other application components. • Web services work in much the same way, using the standard technologies already in place to allow applications to communicate and provide services to other applications. • What Web Services do is to allow communication between two applications using standard technologies like HTTP and XML.

3. Introduction to Web Services, contd. • Web services use existing Internet application protocols like HTTP as a carrier for messages between the web service and the client. • The HTTP protocol becomes a sort of box for shipping web services messages back and forth between applications. • In the case of web services this other layer is called SOAP (originally an acronym for Simple Object Access Protocol), a protocol that defines the messages that are sent between applications so that they can communicate useful messages to each other, like “run this method,” or “here is the result of your message request.”

4. Web Service Messages

5. WSDL • Java's web service API is called JAX-WS, for Java API for XML Web Services. • It uses the SOAP protocol (which in turn uses XML) to exchange messages between applications. • The services are defined by a WSDL (Web Services Description Language) document. • The WSDL document is yet another XML document that defines the capabilities of the web service and allows remote applications to see which methods the web service provides.

6. SOAP • SOAP is a protocol or standard for wrapping up these types of requests in XML to help facilitate communication. • The server receives the request, executes the method with the parameters sent by the client, and then sends the return value in a SOAP response back to the client.

7. Web Services, Session Beans, and State • Web services can be created as part of a web application or an enterprise application. • A session bean can hide its implementation details behind a Java interface and the web service hides its implementation details behind the WSDL file. • The session beans do so as part of the overall Java Enterprise platform and web services as a language-agnostic service that can be integrated into a stand-alone application.

8. RESTful Web Services • REST stands for Representation State Transfer. • Instead of using SOAP as a message format, the RESTful way of doing things uses the HTTP protocol directly to transmit information. • The four basic HTTP methods map neatly onto the four basic operations for a database system: GET – Read POST – Create PUT – Update DELETE – Delete

9. RESTful Web Services, contd. • Sample RESTful Web Service request: Request: GET http://localhost:8080/RESTTest/resources/flights/1/?timestamp=1224968091531

10. RESTful Web Services, contd. • Sample RESTful Web Service response: <?xml version="1.0" encoding="UTF-8"?> <flight uri="http://localhost:8080/RESTTest/resources/flights/1/"> <airlinename>United Airlines</airlinename> <arrairport>New York Newark Intl Arpt (EWR)</arrairport> <arrtime>2008-06-16T22:30:00-04:00</arrtime> <bookingstatus>Confirmed</bookingstatus> <depairport>Oakland (OAK)</depairport> <deptime>2008-06-16T13:00:00-04:00</deptime> <direction>68</direction>

11. RESTful Web Services, contd. <flightid>1</flightid> <flightnum>United Airlines 71</flightnum> <tripRef uri="http://localhost:8080/RESTTest/resources/flights/1/trip/"> <tripid>128</tripid> </tripRef> </flight>

12. RESTful Web Services, contd. • Because a REST system is session-less, RESTful web services do not maintain state between calls. • Each URL should uniquely identify a resource and should contain all information necessary to locate a specific resource, making the need for session tracking unnecessary. • One of the reasons that state is not emphasized in REST systems – the resources that are being represented are not business methods that need to keep track of the client's state.

13. Overview • The term Web services is used to categorize software applications that are exposed over a network via the use of XML standards and Internet protocols in such a manner that they are highly interoperable with other disparate distributed applications • Web services are based on an architectural style called service-oriented architecture (SOA) • The concept behind SOA is that different functional units of a business process are exposed via software as services to be consumed over a network • By the term service we mean a unit of work done by a service provider to achieve desired results for a service consumer (also commonly referred to as service requester)

14. Service Oriented Architecture • Examples of services in the banking industry might be a loan processing service, an account transaction service to handle withdrawals, deposits, and transfers, or a service that handles processing charges to credit cards • Some of the primary goals of SOA are interoperability and loose coupling among interacting software applications, a separation of concerns, and reusability of services • SOA focuses on integrating independent business services, regardless of the technology used to implement the services. This way of thinking allows businesses to better align their services with business needs rather than the technology in which their systems are implemented.

15. Service Oriented Architecture, cont. • Most of the design effort in SOA is focused on creating service interfaces that serve as contracts for how the services are to be invoked and respond. A well-defined service interface provides a clear separation from any hardware, operating systems, programming languages, or protocols that may compose the service implementation. • Applications are integrated via the service interface, not the service implementation. As a result, the applications are loosely coupled. The benefit lies in their ability to survive evolutionary changes in their structure and implementation. • Tightly coupled systems are based on interfaces that are tightly interrelated in function and form, thus making them brittle to any form of change that may be required.

16. Service Oriented Architecture, cont. • In SOA, large business processes are broken down into generic, loosely coupled, functional units (called services) in which each unit performs a different task. These services can then be orchestrated together to form any number of different business processes. • Since integration is tied to interfaces and not the implementation, changing a service provider is not hindered by incompatibilities in underlying platforms. If later on the company finds that another service provider has better prices, then the system can easily be repositioned to use that provider. In SOA, the services become the building blocks to develop complete applications.

17. Service Oriented Architecture, cont. • Service-oriented architectures can be conceptualized as containing three roles (service provider, service broker, and service requester) and three operations (publish, find, and bind). The three operations define the relationships between the three roles. The three roles communicate by sending request messages and processing any response messages.

18. Service Oriented Architecture, cont. • Service Provider – The service provider develops the service interface and implementation and deploys the service so that it is available to be invoked over a network. The service provider also creates a service description and publishes that service description with one or more service brokers (this is the publish operation). • Service Broker – The service broker is also commonly called the service registry. The broker accepts requests from service providers to publish information about the services they want to make available. The information published includes the type of the service, a description of the service, and the location where the service can be invoked. The service requester can then query the service broker to find a particular service (this is the find operation).

19. Service Oriented Architecture, cont. • Service Requester – The service requester uses the service broker to find services that match some set of criteria. The service requester can then use the service description to connect to the service and invoke it (this is the bind operation). The act of finding a service is also called service discovery. • The key to making SOA work is the service description and the interface it describes. The service interface provides a mechanism for decoupling different software functional units (services). The service description provides a mechanism that can be used to dynamically compose the resulting services. The service description is published to the service registry by the service provider, then retrieved by the service requester via the find operation, and then used to dynamically bind to the service to form a business process.

20. Web Services • Web services is one approach to implementing a service-oriented architecture that uses XML-based data representations and communications protocols to achieve platform independence and thus interoperability. • Web services are considered the next evolutionary step in distributed computing beyond technologies like CORBA, DCOM, and J2EE. • Web services, despite the name, can and are deployed on all types of networks including local area networks (typically corporate intranets). • Web services ease the difficulty of enterprise application integration, particularly between organizations (B2B). • They allow business systems to be built quickly by combining Web services built internal to an organization with those of business partners.

21. Web Services, cont. • The four core Web service technologies – XML, SOAP, Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). • XML – (eXtensible Markup Language) is the basis for SOAP, WSDL, and UDDI. Depending on your definition of Web services, XML is really the foundation for all Web service technologies. Representing data in XML is one of the primary keys to Web service’s interoperability. • SOAP – Web services basically involve the exchange of XML documents or data that is organized into an XML format. SOAP provides a standard routing and packaging format for transmitting that XML data between applications on a network.

22. Web Services, cont. • WSDL – (commonly pronounced as “whiz-dul”) is the technology that is used to write the service description. WSDL allows an organization to describe the types of XML documents and SOAP messages that must be used to interact with their Web services. It is just an XML document that is conformant to the WSDL schema definition. • UDDI – A technology that enables service discovery. Before an organization can use a Web service, they must first discover the Web service description. UDDI defines a standard set of operations that can be invoked via SOAP messages, which are used to publish and find Web service descriptions. In other words, UDDI is one approach to creating a service registry.

23. Web Services, cont. Web Services Interaction

24. WSDL Invoking a Web service requires you to know several pieces of information: 1) What message exchange protocol the Web service is using (like SOAP) 2) How the messages to be exchanged are structured (the required data) 3) What transport protocol is employed by the Web service (like HTTP or SMTP) 4) The network address of the Web service • In SOA all of this information is provided by a service description. A service description is simply a concept, so it can be implemented in a number of ways. • WSDL is a language for creating service descriptions that are precise, machine readable, and platform independent

25. WSDL, cont. • WSDL is based on XML. WSDL documents are simply XML documents with their own XML schema, XML namespaces, and processing rules. • WSDL was designed as an IDL (interface definition language) for Web services that is independent of any specific protocol, programming language, or operating system. • WSDL is typically used to describe SOAP-based Web services, but it is not specific to SOAP.

26. WSDL Document Structure • A WSDL service description has two major definition sections – service interface and service implementation • The service interface definition defines the service at an abstract level by describing the messages it sends and receives. It answers the question about what the Web service does in terms of the operations it provides and the data it requires as well as the data (if any) it responds with. • The service implementation definition defines the concrete implementation of the Web service interface by describing the wire and transport protocols in use (e.g., SOAP and HTTP) and the network address (i.e., a URL). It answers the questions about how a service is accessed and where a service is located.

27. WSDL Document Structure, cont. • The separation of interface and implementation within a WSDL document allows multiple Web service implementations to be described that reuse the same interface. This can reduce the size of WSDL documents and consequently the time required to process them and the effort required to maintain them. • A WSDL document is composed of the following key XML elements (continued on the next few slides), listed in their recommended order of appearance. The WSDL specification does not mandate this order. • definitions (mandatory): The root element of the XML document that defines a WSDL service description. There can be only one definitions element in a WSDL document and it contains all of the other WSDL elements.

28. WSDL Document Structure, cont. • documentation (optional): Can be used to describe aspects of the WSDL document to human readers. • import (optional): Can be used to make available in the current WSDL document the definitions from other WSDL documents. Allows WSDL documents to be modularized. • types (optional): Used to define all of the data types used by other elements throughout the WSDL document. WSDL does not mandate the use of any specific typing system, but the default typing system is XML Schema. • message (optional): Used to describe the data transmitted between the service provider and the service requester, which represents a set of operation parameters and return values. Represents the payload of a one-way message, either a request message or a response message.

29. WSDL Document Structure, cont. • portType (opt): Defines a Web service’s abstract interface definition (like a Java interface). Contains various operation elements that abstractly define the operations (methods) supported by a Web service. (i.e., what the Web service does). • operation (opt): Analogous to a Java method declaration. It defines an operation that may be invoked on a Web service, including the name of the operation and the list of input parameters and output values. The operation element references one or more message elements to describe the parameter list. • binding (opt): Used to associate operation elements of a portType with a data format (like XML Schema) and a protocol (like SOAP over HTTP). Conceptually, the binding element is a concrete implementation of the abstract service interface (the portType). how the Web service is accessed

30. WSDL Document Structure, cont. • service (opt): Aggregates one or more bindings and assigns a network address to each binding. In other words it defines the network address for the Web service. where the Web service is located. • port(opt):Used as the immediate child of the service element to accomplish the actual association between a binding element and a network address. • WSDL 1.1 namespace: http://schemas.xmlsoap.org/wsdl/

31. WSDL Document Structure, cont. <definitions name=”…” targetNamespace=”…” xmlns:soapbind=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns=”http://schemas.xmlsoap.org/wsdl/”> <types><xsd:schema targetNamespace=”…”>…</xsd:schema></types> <message name=”…”><part name=”…” element=”…”/></message> <portType name=”…”> <operation name=”…”> <input message=”…”/><output message=”…”/><fault name=”…” message=”…”/> </operation> </portType> <binding name=”…” type=”…”> <soapbind:binding style=”…” transport=”…”/> <operation name=”…”> <soapbind:operation soapAction=”…”/> <input><soapbind:body use=”…”/></input> <output><soapbind:body use=”…”/></output> </operation> </binding> <service name=”…”> <port name=”…” binding=”…”><soapbind:address location=”…”/></port> </service> </definitions>

32. Example WSDL Document <definitions name=”MonitorPricingWS” targetNamespace=”http://monitors.co/ws/Pricing” xmlns:mon=”http://monitors.co/ws/Pricing” xmlns:montypes=”http://monitors.co/ns/pricing/types” xmlns:soapbind=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns=”http://schemas.xmlsoap.org/wsdl/”> <types> <xsd:schema targetNamespace=”http://monitors.co/ns/pricing/types”> <xsd:element name=”MonitorPriceRequest”>…</xsd:element>   <xsd:element name=”price” type=”xsd:float”/>   <xsd:element name=”InvalidArgumentFaultDetail”>…</xsd:element> </xsd:schema> </types> <message name=”GetMonitorPriceRequest”> <part name=”priceRequest” element=”montypes:MonitorPriceRequest”/> </message> <message name=”GetMonitorPriceResponse”> <part name=”price” element=”montypes:price”/> </message> <message name=”InvalidArgumentFault”> <part name=”errorMessage” element=”montypes:InvalidArgumentFaultDetail”/> </message>

33. Example WSDL Document, cont. <portType name=”MonitorPricingPortType”> <operation name=”getMonitorPrice”> <input message=”mon:GetMonitorPriceRequest”/> <output message=”mon:GetMonitorPriceResponse”/> <fault name=”InvalidArgumentFault” message=”mon:InvalidArgumentFault”/> </operation> </portType> <binding name=”MonitorPricingSOAPBinding” type=”mon:MonitorPricingPortType”> <soapbind:binding style=”document” transport=”http://schemas.xmlsoap.org/soap/http”/> <operation name=”getMonitorPrice”> <soapbind:operation soapAction=”http://monitors.co/ws/Pricing/GetMonitorPrice”/> <input><soapbind:body use=”literal”/></input> <output><soapbind:body use=”literal”/></output> <fault name=”InvalidArgumentFault”> <soapbind:fault name=”InvalidArgumentFault” use=”literal”/> </fault> </operation> </binding>

34. Example WSDL Document, cont. <service name=”MonitorPricingService”> <port name=”MonitorPricingPort” binding=”mon:MonitorPricingSOAPBinding”> <soapbind:address location=”http://monitors.co/ws/Pricing”/> </port> </service> </definitions> The elements with a prefix of soapbind: are extensibility elements. They are used to define SOAP-specific details of the Web service. The soapbind:binding element defines the messaging style of the Web service operations as “document” and the network protocol used to transport SOAP messages as “HTTP”. The soapbind:body element defines the encoding for the input and output messages as “literal” and the soapbind:fault element defines the encoding for the fault message as “literal”.

35. WSDL definitions Element • The root of the WSDL document. All other WSDL XML elements are contained within definitions. • Called “definitions” because the WSDL document is a container for a set of service definitions. In practice only a single service is defined in a WSDL document. • May contain zero or more documentation elements, zero or more import elements, one optional types element, zero or more message elements, zero or more portType elements, zero or more binding elements, and zero or more service elements. <definitions name=”MonitorPricingWS” targetNamespace=”http://monitors.co/ws/Pricing” xmlns:soapbind=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns=”http://schemas.xmlsoap.org/wsdl/”> … </definitions>

36. WSDL importElement • Used to import WSDL definitions from other WSDL documents. • Works the same as the import element of XML Schema by binding a network location to an XML namespace, but don’t confuse the use of the two. WS-I BP mandates that the WSDL import only import WSDL documents, and the XML Schema import only import schema definitions. • A typical use of the WSDL import element is to split a WSDL document into service interface definition and service implementation definition. <definitions name=”PricingService” targetNamespace=”…” xmlns:mon=”http://Pricing” xmlns:soapbind=”…” xmlns=”…”> <import namespace=”http://Pricing” location=”http://Pricing/pricing.wsdl”/> <service name=”MonitorPricingService”> <port name=”PricingPort” binding=”mon:MonitorPricingSOAPBinding”> <soapbind:address location=”http://monitors.co/PricingService”/> </port> </service> </definitions>

37. WSDL typesElement • Defines data types used in the WSDL document. These data types are used within the message elements to define the payloads of the messages transmitted to and from the Web service. • Since the default type system of WSDL is XML Schema, all XML Schema built-in types (like xsd:string, xsd:float, etc.) are immediately available, but you often need to define your own types. <definitions name=”MonitorPricingWS” targetNamespace=”…” xmlns:mon=”…” xmlns:montypes=”http://monitors.co/ns/pricing/types” xmlns:soapbind=”…” xmlns:xsd=”…” xmlns=”…”> <types> <xsd:schema targetNamespace=”http://monitors.co/ns/pricing/types”> <xsd:element name=”MonitorPriceRequest”>…</xsd:element>   <xsd:element name=”price” type=”xsd:float”/>   <xsd:element name=”InvalidArgumentFaultDetail”>…</xsd:element> </xsd:schema> </types>   <message name=”GetMonitorPriceRequest”> <part name=”priceRequest” element=”montypes:MonitorPriceRequest”/> </message> </definitions>

38. WSDL messageElement • Used to describe the logical abstract payload of a message transmitted to or from a Web service: incoming messages, outgoing messages, SOAP header blocks, and SOAP fault Detail elements. • A WSDL document may contain zero or more message elements, all of which must have unique names within the WSDL document • Each message element may contain zero or more part elements that describe each part of the message. • Can be modeled to represent either a document-style message or an RPC-style message. • In a document-style message the part elements represent XML document fragments. • In an RPC-style message the part elements represent input or output parameters of a procedure call.

39. WSDL messageElement, cont. • The part element may contain a type attribute that is used to refer to an XML Schema type (xsd:simpleType or xsd:complexType) or an element attribute that is used to refer to an XML Schema element (xsd:element), both of which are declared (or imported) by the types definition. • A part element may use either type or element but not both. use the element attribute to specify the payload of the message be exactly the XML element that you referenced; use the type attribute, to specify what the data type of the element must be. The element that is actually used is determined by the binding element. • part elements use the type attribute for RPC-style messaging and the element attribute for document-style messaging. Because document-style messages are meant to carry XML document fragments (XML elements) and RPC-style messages are meant to carry parameters for a procedure (defined as specific data types).

40. WSDL messageElement, cont. <definitions name=”MonitorPricingWS”…> <types> <xsd:schema targetNamespace=”http://monitors.co/ns/pricing/types”> <xsd:element name=”InvalidArgumentFaultDetail”> <xsd:complexType>…</xsd:complexType> </xsd:element> </xsd:schema> </types> <message name=”GetMonitorPriceRequest”> <part name=”productId” type=”xsd:string”/> <part name=”currency” type=”xsd:string”/> </message> <message name=”GetMonitorPriceResponse”> <part name=”price” type=”xsd:float”/> </message> <message name=”InvalidArgumentFault”> <part name=”errorMessage” element=”montypes:InvalidArgumentFaultDetail”/> </message> … </definitions> Partial RPC-Style Web Service Definition

41. WSDL portTypeElement • Used to define the abstract interface of a Web service. A portType is similar in concept to a Java interface. • Defines a collection of operation elements under a unique name (the name attribute of the portType). • The interface that the portType defines is implemented by the binding and service elements. The binding element specifies the protocols and encoding of the Web service implementation. The service element defines the network address where the Web service implementation can be invoked. <portType name=”MonitorPricingPortType”> <operation name=”getMonitorPrice”> <input message=”mon:GetMonitorPriceRequest”/> <output message=”mon:GetMonitorPriceResponse”/> <fault name=”InvalidArgumentFault” message=”mon:InvalidArgumentFault”/> </operation> </portType>

42. WSDL operationElement • Analogous to a Java method signature. • Can contain zero or one input element, zero or one output element, and zero or more fault elements. • The input element declares the message payload that is transmitted from the client to the Web service, and the output element declares the message payload that is transmitted from the Web service to the client. • The fault elements declare the payloads of fault messages that may be transmitted from the Web service to the client in the event of an error. • Each input, output, and fault element must contain a message attribute defined earlier in the WSDL document.

43. WSDL operationElement, cont. <definitions name=”MonitorPricingWS” targetNamespace=”http://monitors.co/ws/Pricing” xmlns:mon=”http://monitors.co/ws/Pricing” xmlns:montypes=”…” xmlns:soapbind=”…” xmlns:xsd=”…” xmlns=”…”> <types>…</types>   <message name=”GetMonitorPriceRequest”><part name=”…” element=”…”/> </message> <message name=”GetMonitorPriceResponse”><part name=”…” element=”…”/> </message> <message name=”InvalidArgumentFault”><part name=”…” element=”…”/> </message>   <portType name=”MonitorPricingPortType”> <operation name=”getMonitorPrice”> <input message=”mon:GetMonitorPriceRequest”/> <output message=”mon:GetMonitorPriceResponse”/> <fault name=”InvalidArgumentFault” message=”mon:InvalidArgumentFault”/> </operation> </portType> </definitions>

44. WSDL operationElement, cont. • When the operation element only contains an input element, then the MEP is one-way. No output or fault elements can be declared in a one-way MEP. Ex: <portType name=”MonitorPurchaseOrderPortType”> <operation name=”submitPurchaseOrder”> <input name=”order” message=”mon:SubmitPurchaseOrderMessage”/> </operation> </portType> • To define a request-response MEP, the operation element must contain a single input and a single output element, and the input element must precede the output element. Ex: <portType name=”MonitorPricingPortType”> <operation name=”getMonitorPrice”> <input message=”mon:GetMonitorPriceRequest”/> <output message=”mon:GetMonitorPriceResponse”/> <fault name=”InvalidArgumentFault” message=”mon:InvalidArgumentFault”/> </operation> </portType>

45. WSDL parameterOrderAttribute • operation elements may also contain an optional parameterOrder attribute, which is used to enforce a proper order of parameters in an RPC-style message. • The parameterOrder attribute must include all of the operation’s inputparts and only outputparts that are not the return value of the procedure call. • If an output message only contains a single part, then that part is assumed to be the return value. • If an outputpart is listed in the parameterOrder attribute, then it is treated as an OUT parameter. • If both an input and output message contain a part with the same name, then that part is assumed to be the same parameter and is treated as an INOUT parameter.

46. WSDL parameterOrderAttribute, cont. <message name=”GetMonitorPriceRequest”> <part name=”productId” type=”xsd:string”/> <part name=”currency” type=”xsd:string”/> </message> <message name=”GetMonitorPriceResponse”> <part name=”price” type=”xsd:float”/> </message> <portType name=”MonitorPricingPortType”> <operation name=”getMonitorPrice” parameterOrder=”productId currency”> <input message=”mon:GetMonitorPriceRequest”/> <output message=”mon:GetMonitorPriceResponse”/> </operation> </portType>

47. WSDL bindingElement • The service implementation definition is described by the binding and service elements. • The binding element defines the format for the messages in a protocol-specific manner. It maps an abstract portType to a concrete implementation that uses specific messaging styles (RPC or document), protocols (like SOAP and HTTP), and encoding styles (like literal or SOAP Encoding). • A single WSDL document may contain multiple bindings for each portType. For example, you may want to bind a single portType to both a SOAP over HTTP implementation and a SOAP over SMTP implementation.

48. WSDL bindingElement, cont. <definitions name=”MonitorPricingWS” targetNamespace=”http://monitors.co/ws/Pricing” xmlns:mon=”http://monitors.co/ws/Pricing” xmlns:montypes=”…” xmlns:soapbind=”…” xmlns:xsd=”…” xmlns=”http://schemas.xmlsoap.org/wsdl/”> <portType name=”MonitorPricingPortType”> <operation name=”getMonitorPrice”> <input message=”mon:GetMonitorPriceRequest”/> <output message=”mon:GetMonitorPriceResponse”/> </operation> </portType> <binding name=”MonitorPricingSOAPBinding” type=”mon:MonitorPricingPortType”> <soapbind:binding style=”document” transport=”http://schemas.xmlsoap.org/soap/http”/> <operation name=”getMonitorPrice”> <soapbind:operation soapAction=”http://monitors.co/ws/Pricing/GetMonitorPrice”/> <input><soapbind:body use=”literal”/></input> <output><soapbind:body use=”literal”/></output> </operation> </binding> </definitions>

49. SOAP Binding • The SOAP-WSDL extensibility elements allow us to define the SOAP-specific details of the Web service: • soapbind:binding – Describes the default message style (RPC or document) of the operations in the WSDL binding and the underlying network protocol (like HTTP) that will be used to transport the messages. • soapbind:operation – Specifies a message style for the operation that overrides the default style in the soapbind:binding element and to specify a value for the SOAPAction HTTP header field. • soapbind:body – Describes how the messagepart elements will be formatted in the SOAP Body element. Defines the encoding style of the message payload, the namespace for the elements of the message payload, and which part elements are going to appear in the message.

50. SOAP Binding, cont. • soapbind:fault – Serves a similar purpose as the soapbind:body element except it applies to faults instead of input and output messages. • soapbind:header – Describes SOAP header blocks for input or output messages. Each input and output element can have one or more soapbind:header elements, which makes since because a single SOAP message can have multiple header blocks. • soapbind:headerfault – Describes a fault that is specific to a header block. SOAP requires faults that are associated with header blocks be placed in the SOAP Header, and consequently, WSDL requires soapbind:headerfault elements to be nested within their associated soapbind:header elements.