219451, Section 450, 2nd Semester, 2007219451, Section 450, 2nd Semester, 2007Web Services TechnologyWeb Services Technology

Lect re 4Lecture 4: Web Service Technology Stack gy

and SOAP

Monchai Sopitkamon Ph DMonchai Sopitkamon, Ph.D.

OutlineOutline

Web Services Technology StackgyebXMLSOAPSOAP

Web Services Technology StackWeb Services Technology StackgygyInternet and Web protocols (TCP/IP and HTTP) form the foundational layer for Web servicesfor Web services.Next layer contains the core XML-processing technologies, including XML and related technologies, e.g., XSL, DTDs, and XML Schema. Vertical Vertical Vertical Vertical Vertical DTDs, and XML Schema.Horizontal XML Vocabularies provide functionality that can be used across industries, e.g., ebXML.The technologies that enable Web

Language Language Language Language Language

W eb services Technologies : S OAP , W S DL, UDDI

Horizontal XML Vocabularies : ebXMLThe technologies that enable Web services lies above the XML horizontal vocabularies.The top layer contains vertical languages XML-based technologies that

Core XML P rocess ing: XML, S chema

W eb F ramework: Internet P rotocols , HTTP , TCP /IPlanguages, XML-based technologies that define specific processes for a single industry or group of industries.

XML Technologies that Enable XML Technologies that Enable B iB i P i S tP i S tBusinessBusiness--Processing SystemsProcessing Systems

Various XML-based technologies defining business processes can help solve real-world business issuesprocesses can help solve real world business issues.E.g., when shipping address is not correct, package may be delivered at wrong address or may not be delivered at all.at all.To prevent this, DTDs and schemas can be used to reduce the amount of errorneous info that enters an organization.o ga at o .However, only using XML documents does not guarantee that all business partners can understand the same documents.Business partners must establish sets of standards that every partner uses.

ebXMLebXML

Electronic Business XML is an open, XML-based infrastructure that enables l bal c m anies t c nd ct reliable inter erable e b sinessenables global companies to conduct reliable, interoperable e-businessEbXML provides a set of specifications that defines an alternative to Electronic Data Interchange (EDI) systems.EbXML allows businesses to partner and conduct global B2B transactions EbXML allows businesses to partner and conduct global B2B transactions using XML and the Internet.Many of these capabilities, although offered by EDI, can be achieved by XML at less costs than through EDI.W h bXML h b d With ebXML, organizations exchange business messages, maintain trading relationships, define and register business processes and transfer data using a set of specifications that describe the implementation of such systems.For larger organizations with substantial investments into EDI infrastructure, they can incorporate ebXML into their existing EDI implementation to let them conduct businesses with smaller organizations adopting ebXML technology.p g gy

ebXMLebXML ArchitectureArchitectureebXMLebXML ArchitectureArchitecture

Source: http://www.ibm.com/developerworks/xml/library/x-ebxml/

Business Transaction Protocol (BTP)Business Transaction Protocol (BTP)( )( )

Is an XML-based protocol developed to work with existing business-messaging standards, including ebXML to coordinate and manage complex transactions between business using including ebXML, to coordinate and manage complex transactions between business using Web services or other B2B technology.Members of this technology include BEA Systems, Sun Microsystems, HP, Oracle, Entrust, and etc.Due to the complexity of processes defined by BTP, the adoption of the technology has been p y p y , p gyslow. Only a few companies (e.g., BEA and HP) have implemented the protocol in their products and systems.The goal of the protocol is to define how organizations can coordinate their systems to achieve automated business transactions.BTP d b h hBTP describes a transaction as either an atom or a cohesion.An atom take part in a two-phase commit transaction – i.e., a process either fully commits to a transaction or rolls back (cancels) the transaction.An example of an atom includes a single Web services operation and the internal processes that support the operationthat support the operation.Cohesion is a group of atoms that work as a unit to complete a transaction.With cohesion, certain portions of transactions can be failed without cancelling the transaction.E i li d h di d h i i i h f il b h d ill b E.g., in an on-line order, the credit-card authorization might fail, but the order still can be sent to the warehouse to prepare the inventory to ship, and the authorization can be re-tried, instead of forcing the customer to begin the ordering process again.

Business Process Modeling Language (BPML) and Business Process Modeling Language (BPML) and B i P Q L (BPQL)B i P Q L (BPQL)Business Process Query Language (BPQL)Business Process Query Language (BPQL)

BPML is a meta-language for modeling business processesprocessesBPQL deploys processes.Companies can use BPML to model, deploy and p , p ymanage order, customer-care, demand-planning and product-development processes.BPML offers a model for businesses to BPML offers a model for businesses to communicate by exchanging messages.BPQL employs UDDI to register and discover b d l d business processes deployed on a process repository.

Web Services Flow Language (WSFL)Web Services Flow Language (WSFL)g g ( )g g ( )

Is an XML-based language created by IBM to incorporate Web services as part of a business’s workflowbusiness s workflowA business workflow is defined as the operations required to accomplish a process or transaction.In WSFL, Web services providers and Web services consumers can define the work t f d th fl th k d t f ll t i l t b i to perform and the flow the work needs to follow to implement business processes.WSFL functions as a layer on top of WSDL.WSFL uses WSDL to describe not only Web services characteristics, but also yQuality of Service (QoS), a characteristic of service not covered by WSDL.WSFL describes Web services compositions – collections of Web services that work together.Two types of composition models: flow model and global model.Two types of composition models: flow model and global model.The flow model describes the sequence of steps required by a collection of Web services to accomplish a transaction.The global model describes an interaction pattern composition, which specifies how the Web services relate to each other not the sequence of interactionshow the Web services relate to each other, not the sequence of interactions.

Universal Business Language (UBL)Universal Business Language (UBL)g g ( )g g ( )

UBL uses ebXML parameters and systems to develop a set of XML business documentsdevelop a set of XML business documents.Goal: to create a set of international, freely available, unlicensed e-commerce standard documents.To achieve this goal, UBL is based on an existing XML technology called the XML Common XML technology called the XML Common Business Language (xCBL) 3.0.xCBL 3.0 is a freely available widely implemented standard that defines several sets implemented standard that defines several sets of document formats.

History of SOAPHistory of SOAPyySOAP was created before the advent of Web services, as a communications protocol that could be used over the Internet.pWhen the XML 1.0 was released in 1998, not only did it describe data, but XML could also describe programmatic actions or behaviors.As a result IBM Lotus Microsoft DevelopMentor and Userland As a result, IBM, Lotus, Microsoft, DevelopMentor and Userland Software began collaborating to develop an XML-messaging protocol to define a non-platform specific way to invoke remote operations.This work later turned into the development of SOAP.The first SOAP specification, SOAP 0.9, was published in 1999.Several subsequent versions of SOAP were followed before the protocol was submitted to the W3Cprotocol was submitted to the W3C.The W3C released SOAP 1.2 as a Working Draft in July 2001.On June 24, 2003, SOAP 1.2 was finalized and accepted as part of the W3C Recommendations.

SOAP ArchitectureSOAP Architecture

Web services are often part of larger, object-based harchitectures

Good systems architectures promote loosely-coupled systems –i.e., systems in which each software component’s i l i i i d d f h di iimplementation is independent of those surrounding it.When an application resides in a loosely-coupled system, changes to one component or application do not affect other

li ti i th tapplications in the system.E.g., if the Web service implementation is modified to enhance performance, the developer does not have to modify other applications in the systemapplications in the system.Advantage: a developer can change a particular component without going through the error-prone process of modifying other system componentsใother system componentsใ

SOAP ArchitectureSOAP ArchitectureSOAP protocol allows XML messages to communicate programmatic instructions communicate programmatic instructions between applications.The SOAP specification consists of four main parts:

1. SOAP envelope: describes the format of a SOAP message.

2 SOAP di h 2. SOAP encoding: represents the structures or representations of data that are sent in a message.

3. SOAP RPCs: defines how a SOAP message can execute remote procedure calls (RPCs).p ( )

4. SOAP binding framework: defines the protocol through which SOAP messages are transmitted to applications.

SOAP ArchitectureSOAP ArchitectureSOAP is by itself not an executable application.SOAP specification does not include programming instructions or SOAP specification does not include programming instructions or restrict developers to a certain programming language, e.g., Visual Basic, Java, or C#.SOAP specification was designed to include only the functions and capabilities necessary to achieve platform and languagecapabilities necessary to achieve platform- and language-independent communications.By applying the SOAP protocol, developers can create SOAP applications that achieve interoperable messaging across platforms.Any programming language that can understand SOAP messages and XML can implement the protocol.SOAP Version 1.2 is a lightweight protocol intended for exchanging structured information in a decentralized distributed environmentstructured information in a decentralized, distributed environment.

SOAP MessageSOAP MessageggSOAP encapsulates data in messages that are transferred to and from Web services.E h SOAP i i i i l

• An intermediary processes the info specific to that node, then

d th t it tEach SOAP message contains an initial envelope element, Envelope, composed of an optional Header element and a required Body element.The Envelope element specifies the

d h i f f h

sends the message to its next destination.

• If a node receives a SOAP message and the header contains no instructions for it it passes thep p

namespace and schema info for the message.The SOAP Header contains info about the message, parsing instructions for nodes that receive the message and

f

no instructions for it, it passes the message to the next node.

gsecurity info. Since a SOAP message does not always travel directly from its sender to the intended recipient, the header of the message might include routing info that

d f h g g g

instructs an intermediary to verify the identity of source of the message before it is processed at the final node.

SOAP MessageSOAP Messagegg

The body of a SOAP message describes the purpose of the SOAP describes the purpose of the SOAP message and contains the SOAP payload.A payload is the data or instructions intended for the receiving applicationintended for the receiving application.E.g., the body can include instructions for tasks that the receiver must perform, e.g., calling a method, or can include info that must be processed include info that must be processed by an application.If the header format is incorrect, and the node is unable to read the instructions contained in the header, ,a SOAP Fault element containing the error info is returned to the sending node.

The SOAP Header ElementThe SOAP Header ElementThe SOAP Header ElementThe SOAP Header Element

The optional SOAP Header element pcontains application specific information (like authentication, payment, etc) about ( p y )the SOAP message. If the Header element is present, it must p ,be the first child element of the Envelope element.

The SOAP Header ElementThe SOAP Header ElementThe SOAP Header ElementThe SOAP Header Element<?xml version="1.0"?> <soap:Envelope<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap

di ">-encoding"><soap:Header> <m:Trans

l "htt // 3 h l /t ti /" xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234

</m:Trans> </soap Header></soap:Header>... ...

/ E l</soap:Envelope>

EncodingEncodinggg

SOAP specification provides rules that describe how specific kinds of data can be represented in a SOAP messagerepresented in a SOAP message.These rules, known as SOAP encoding, enable applications that receive SOAP messages to recognize the format of, and therefore process, data in the messages.SOAP messages using this particular serialization SHOULD indicate that fact by

i th SOAP di St l tt ib t i f ti itusing the SOAP encodingStyle attribute information item.

SOAP encodingStyle attribute is used to define the data types used in the document.

Thi tt ib t SOAP l t d it ill l t th t l t' This attribute may appear on any SOAP element, and it will apply to that element's contents and all child elements.

A SOAP message has no default encoding.The SOAP header or body element can have the SOAP encodingStyle attribute The SOAP header or body element can have the SOAP encodingStyle attribute, which is the attribute that contains a URI (“http://www.w3.org/2003/05/soap-encoding”) that maps to the encoding rules.

The The encodingStyleencodingStyle AttributeAttributeThe The encodingStyleencodingStyle AttributeAttributeSyntaxsoap:encodingStyle="URI“soap:encodingStyle= URI

Example<? l i ="1 0"?> <?xml version="1.0"?> <soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www w3 org/2001/12/soap-soap:encodingStyle http://www.w3.org/2001/12/soapencoding"> ... Message information goes here Message information goes here ... </soap:Envelope>

The SOAP Body ElementThe SOAP Body ElementThe SOAP Body ElementThe SOAP Body Element

The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the messageSOAP defines one element inside the B d l t i th d f lt Body element in the default namespace ("http://www.w3.org/2001/12/soap-envelope") envelope ). This is the SOAP Fault element, which is used to indicate error messagesused to indicate error messages

The SOAP Body Element: An The SOAP Body Element: An Example SOAP RequestExample SOAP Request<?xml version="1.0"?> < E l<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www w3 org/2001/12/soapsoap:encodingStyle= http://www.w3.org/2001/12/soap-encoding">

<soap:Body> < G tP i <m:GetPrice xmlns:m="http://www.w3schools.com/prices">

<m:Item>Apples</m:Item> </m:GetPrice>

</soap:Body></soap:Envelope></soap:Envelope>

The SOAP Body Element: An The SOAP Body Element: An Example SOAP ResponseExample SOAP Response<?xml version="1.0"?> <soap:Envelope

xmlns:soap="http://www w3 org/2001/12/soap-xmlns:soap= http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">encoding

<soap:Body> <m:GetPriceResponse

xmlns:m="http://www w3schools com/prices"> xmlns:m= http://www.w3schools.com/prices > <m:Price>1.90</m:Price>

</m:GetPriceResponse> </soap:Body></soap:Envelope>

SOAP FaultsSOAP FaultsSOAP FaultsSOAP FaultsAn error message from a SOAP message is carried inside a Fault elementPlace faults inside env:Body elementsIf a Fault element is present, it must appear as a child element of the Body element. A F lt l t l i SOAP A Fault element can only appear once in a SOAP messageThe SOAP Fault element has the following child elements◦ env:Node (identifies node which generated fault)( g )

Absence indicates “ultimate recipient”◦ env:Code

env:Valueenv:Subcode

◦ env:Reason (provide a human-readable explanation of the fault)

env:Text◦ env:Detail (carrying application specific error information)( y g pp p )

SOAP Fault CodesSOAP Fault CodesSOAP Fault CodesSOAP Fault CodesLocal Name Meaning

VersionMismatch The faulting node found an invalid element information item instead of the VersionMismatch The faulting node found an invalid element information item instead of the expected Envelope element information item. The namespace, local name or both did not match the Envelope element information item required by this recommendation

MustUnderstand An immediate child element information item of the SOAP Header element MustUnderstand An immediate child element information item of the SOAP Header element information item targeted at the faulting node that was not understood by the faulting node contained a SOAP mustUnderstand attribute information item with a value of "true"

Sender The message was incorrectly formed or did not contain the appropriate Sender The message was incorrectly formed or did not contain the appropriate information in order to succeed. For example, the message could lack the proper authentication or payment information.

Receiver The message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message p g g gitself. For example, processing could include communicating with an upstream SOAP node, which did not respond.

DataEncodingUnknown A SOAP header block or SOAP body child element information itemtargeted at the faulting SOAP node is scoped with a data encoding that the faulting node does not support.

SOAP Fault ExampleSOAP Fault ExampleSOAP Fault ExampleSOAP Fault Example<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'>

<env:Body> <env:Fault>

<env:Code> <env:Value>env:Sender</env:Value> <env:Subcode><env:Subcode> <env:Value>rpc:BadArguments</env:Value>

</env:Subcode> </env:Code> <env:Reason>

<env:Text xml:lang="en-US">Processing error</env:Text> <env:Text xml:lang="cs">Chyba zpracování</env:Text>

</env:Reason> <env:Detail>

<e:myFaultDetails xmlns:e="http://shippingservice org/faults"><e:myFaultDetails xmlns:e= http://shippingservice.org/faults > <e:message>Unknown destination</e:message> <e:errorcode>999</e:errorcode>

</e:myFaultDetails> </env:Detail>

</env:Fault></env:Fault> </env:Body> </env:Envelope>

SOAP Faults on MustUnderstandSOAP Faults on MustUnderstandSOAP Faults on MustUnderstandSOAP Faults on MustUnderstand

<?xml version='1.0' ?> < E l l "h // / / / l ><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope><env:Header> <env:NotUnderstood qname="t:transaction"

xmlns:t="http://shippingservice.org/transaction"/></env:Header> <env:Body>

<env:Fault> <env:Code>

<env:Value>env:MustUnderstand</env:Value> </env:Code> <env:Reason> <env:Text xml:lang="en-US">Header not understood</env:Text> <env:Text xml:lang="fr">En tête non compris</env:Text> <env:Text xml:lang= fr >En-tête non compris</env:Text> </env:Reason>

</env:Fault> </env:Body> y</env:Envelope>

SOAP Message Exchange ModelSOAP Message Exchange Modelg gg g

Defines how components exchange messages as well as the basic

• A SOAP message uses the messages as well as the basic requirements for processing one-way transmissions from a SOAP sender to a SOAP receiver.SOAP nodes are essentially

SOAP actor name to identify intermediaries and SOAP receivers.

SOAP nodes are essentially applications or components that understand SOAP messages.A SOAP node that sends a SOAP message is called a SOAP sender; message is called a SOAP sender; whereas a node that receives a message is called a SOAP receiver.The SOAP receiver is also called a SOAP actor.SOAP actors are identified by an actor name, a Uniform Resource Identifier (URI).

SOAP Message Exchange ModelSOAP Message Exchange Modelg gg g

From the previous baseline m del de el ers can model, developers can incorporate intermediate nodes, called intermediaries, or can create a request/response model as shown in the right figure SOAP receiver

SOAP nodeSOAP node

as shown in the right figure.An example of a request/response model is one where a client sends a message

SOAP sender

SOAP receiverprocess the

XML message

SOAP request

SOAP response

to a Web service and the Web service returns information to the client.According to SOAP 1.2 According to SOAP 1.2 specification, two exchange models exist: Conversational Message Exchanges and Remote Procedure Calls

Conversational Message ExchangesConversational Message Exchangesg gg g

A much larger set of usage scenarios than that covered by the request response pattern can be covered by the request-response pattern can be modeled simply as XML-based content exchanged in SOAP messages to form a back-

d f th " ti " h th ti and-forth "conversation", where the semantics are at the level of the sending and receiving applications. An example for Conversational Message Exchanges model is the case of XML-based content exchanged in SOAP messages between content exchanged in SOAP messages between the travel reservation application and the travel service application in a conversational pattern.

Conversational Message Exchanges ExampleConversational Message Exchanges Example<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-

envelope">

<env:Header>

i

<p:departure>

<p:departing>New York</p:departing>

<p:arriving>Los Angeles</p:arriving>

<p:departureDate>2001-12-14</p:departureDate><m:reservation

xmlns:m="http://travelcompany.example.org/reservation"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

env:mustUnderstand="true">

p p p p

<p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference>

</p:departure>

<p:return>

<p:departing>Los Angeles</p:departing> <m:reference>uuid:093a2da1-q345-739r-ba5d-

pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>

<p:departing>Los Angeles</p:departing>

<p:arriving>New York</p:arriving>

<p:departureDate>2001-12-20</p:departureDate>

<p:departureTime>mid-morning</p:departureTime>

<p:seatPreference/> </m:reservation>

<n:passenger xmlns:n="http://mycompany.example.com/employees"

env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

<p:seatPreference/>

</p:return>

</p:itinerary>

<q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> envelope/role/next

env:mustUnderstand="true">

<n:name>Monchai Sopitkamon</n:name>

</n:passenger>

</env:Header>

s >

<q:preference>none</q:preference>

</q:lodging>

</env:Body>

</env:Envelope> <env:Body>

<p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel">

Sample SOAP message for a travel reservation containing header blocks and a body

Conversational Message Exchanges ExampleConversational Message Exchanges Example

<?xml version='1.0' ?> <env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>

<env:Body> <p:itineraryClarification

xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <env:Header>

<m:reservation xmlns:m="http://travelcompany.example.or

g/reservation" env:role="http://www.w3.org/2003/05/soap-

envelope/role/next"

<p:departure> <p:departing>

<p:airportChoices> JFK LGA EWR </p:airportChoices>

</p:departing> penv:mustUnderstand="true">

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>

p p g</p:departure> <p:return>

<p:arriving> <p:airportChoices> JFK LGA EWR

05:00</m:dateAndTime> </m:reservation> <n:passenger

xmlns:n="http://mycompany.example.com/employees"

env:role="http://www w3 org/2003/05/soap

</p:airportChoices> </p:arriving>

</p:return> </p:itineraryClarification>

</env:Body>env:role= http://www.w3.org/2003/05/soap-envelope/role/next"

env:mustUnderstand="true"> <n:name>Monchai Sopitkamon</n:name>

</n:passenger>

</env:Body></env:Envelope>

</env:Header>

SOAP message sent in response to the message

Remote Procedure CallsRemote Procedure CallsOne of the design goals of SOAP Version 1.2 is to encapsulate remote procedure call functionality using the extensibility and p y g yflexibility of XML.To invoke a SOAP RPC, the following information is needed:◦ The address of the target SOAP node.

Th d h d ◦ The procedure or method name. ◦ The identities and values of any arguments to be passed to the

procedure or method together with any output parameters and return value.

◦ A clear separation of the arguments used to identify the Web resource which is the actual target for the RPC, as contrasted with those that convey data or control information used for processing the call by the target resource.

◦ The message exchange pattern which will be employed to convey the RPC, together with an identification of the so-called "Web Method" to be used.

◦ Optionally, data which may be carried as a part of SOAP header blocks.

Remote Procedure Calls ExampleRemote Procedure Calls Example

eter

sIn

pu

t p

aram

e

SOAP RPC request with a mandatory header and two input (or "in") parameters

Remote Procedure Calls ExampleRemote Procedure Calls ExampleppO

utp

ut

par

amet

ers

O p

RPC response with two output (or "out") parameters

Remote Procedure Calls ExampleRemote Procedure Calls Examplepp

u

rn"

valu

e "r

etu

RPC response with a "return" value and two "out" parameters

SOAP Processing ModelSOAP Processing ModelSOAP Processing ModelSOAP Processing ModelSOAP messages are sent from one sender node passing through zero or more intermediariesThree roles◦ http://www.w3.org/2003/05/soap-envelope/role/next (next): each SOAP

intermediary or end destination must act in this role◦ http://www.w3.org/2003/05/soap-envelope/role/none (none): SOAP nodes p g p p ( )

must not act in this role◦ http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver

(ultimateReceiver): destination acts in this roleHeader blocks targeted to specific roles using Role attributeg p gIf mustUnderstand=“true” SOAP receiver must understand or generate SOAP faultHeader blocks processed by intermediaries are generally removed before forwardingforwarding◦ Override with relay attribute◦ Allows targeting of headers to specific intermediaries (but mustUnderstand

would then generally be turned off)

The "role" AttributeThe "role" Attribute

Table below summarizes the applicable standardized roles that may be " " " "assumed at various SOAP nodes. ("Yes" and "No" means that the

corresponding node does or does not, respectively, play the named role.)

SOAP BindingsSOAP BindingsSOAP BindingsSOAP Bindings

specify how SOAP messages may be passed from one SOAP node to another using an underlying protocol (e.g., HTTP, SMTP)SMTP)provides a serialized representation of the

message provides a mechanism to support features needed by SOAP applications (security needed by SOAP applications (security, reliability, etc...)describes the features it providesdescribes the features it provides

SOAP HTTP BindingSOAP HTTP BindingSOAP HTTP BindingSOAP HTTP Binding

A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.gHTTP + XML = SOAPA SOAP request could be an HTTP POST A SOAP request could be an HTTP POST or an HTTP GET request.The HTTP POST request specifies at The HTTP POST request specifies at least two HTTP headers: Content-Type and Content Lengthand Content-Length.

SOAP HTTP Binding ExampleSOAP HTTP Binding ExampleSOAP HTTP Binding ExampleSOAP HTTP Binding Example

POST /Reservations HTTP/1.1Host: marketplace.example.orgContent-Type: application/soap+xml;

charset="utf-8"Content-Length: nnnn<?xml version='1.0' ?><env:Envelope xmlns:env=”...”><env:Body>◦ <r:RFQ>

SOAP SMTP Binding ExampleSOAP SMTP Binding ExampleSOAP SMTP Binding ExampleSOAP SMTP Binding ExampleFrom: buyer@bigco.example.orgTo: rfqs@marketplace.example.orgSubject: RFQ: Memory purchaseD Th d S b 9 2004Date: Thursday, September 9 2004Message-Id: <17-101@bigco.example.org>C t t T li ti / + lContent-Type: application/soap+xml<?xml version='1.0' ?><env:Envelope xmlns:env=” ”><env:Envelope xmlns:env= ... ><env:Body>

A SOAP Example: The SOAP A SOAP Example: The SOAP requestrequestPOST /InStock HTTP/1.1 Host: www example org Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn<?xml version="1.0"?> ?xml version 1.0 ? <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-

envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

B d l "h // l / k" <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice>

<m:StockName>IBM</m:StockName> </ G S kP i > </m:GetStockPrice>

</soap:Body></soap:Envelope>

A SOAP Example: The SOAP A SOAP Example: The SOAP responseresponseHTTP/1.1 200 OK Content Type: application/soap+xml; charset=utf 8 Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn<?xml version="1.0"?> < E l l ="htt // 3 /2001/12/<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-

envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> g<soap:Body xmlns:m="http://www.example.org/stock">

<m:GetStockPriceResponse> <m:Price>34.5</m:Price> m:Price 34.5 /m:Price

</m:GetStockPriceResponse> </soap:Body>

</soap:Envelope>p p