Outline Outline Web Services Technology Stack gy ebXML SOAP - - PDF document

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

Lect re 4 Lecture 4: Web Service Technology Stack gy and SOAP

Monchai Sopitkamon Ph D Monchai Sopitkamon, Ph.D.

Outline Outline

Web Services Technology Stack

gy

ebXML SOAP

SOAP

Web Services Technology Stack Web Services Technology Stack gy gy

Internet and Web protocols (TCP/IP

and HTTP) form the foundational layer for Web services for 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: SOAP, W SDL, UDDI Horizontal XML Vocabularies: ebXML

The technologies that enable Web

services lies above the XML horizontal vocabularies.

The top layer contains vertical

languages XML-based technologies that

Core XML Processing: XML, Schema W eb Framework: Internet Protocols, HTTP, TCP/IP

languages, XML-based technologies that define specific processes for a single industry or group of industries.

XML T echnologies that Enable XML T echnologies that Enable B i B i P i S t P i S t Business Business-

• Processing Systems

Processing Systems

Various XML-based technologies defining business

processes can help solve real-world business issues processes 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

• rganization.
• 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.

ebXML ebXML

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 siness enables global companies to conduct reliable, interoperable e-business

EbXML 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

ebXML ebXML Architecture Architecture ebXML ebXML Architecture Architecture

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 gy

• slow. 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 h

• BTP 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 operation that 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

processes processes

BPQL deploys processes. Companies can use BPML to model, deploy and

p , p y manage 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 workflow businesss workflow

A business workflow is defined as the operations required to accomplish a process

• r 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

y Quality of Service (QoS), a characteristic of service not covered by WSDL.

WSFL describes Web services compositions – collections of Web services that

work together.

T

wo types of composition models: flow model and global model. T wo 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 interactions how 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 documents develop a set of XML business documents.

Goal: to create a set of international, freely

available, unlicensed e-commerce standard documents.

T

• 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

• f document formats.

History of SOAP History of SOAP y

SOAP was created before the advent of Web services, as a

communications protocol that could be used over the Internet. p

When 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

• perations.

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 W3C protocol 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 Architecture SOAP Architecture

Web services are often part of larger, object-based

h architectures

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 i implementation 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 t applications 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 system applications in the system.

Advantage: a developer can change a particular component

without going through the error-prone process of modifying

• ther system componentsใ
• ther system componentsใ

SOAP Architecture SOAP Architecture

• SOAP 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 Architecture SOAP Architecture

SOAP 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 language capabilities 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 environment structured information in a decentralized, distributed environment.

SOAP Message SOAP Message g

• SOAP 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 t

• Each SOAP message contains an initial

envelope element, Envelope, composed

• f 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 the

p 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.

g security 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 Message SOAP Message g

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 application intended 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 Element The SOAP Header Element The SOAP Header Element The SOAP Header Element

The optional SOAP Header element

p contains 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 Element The SOAP Header Element The SOAP Header Element The 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>

Encoding Encoding

SOAP specification provides rules that describe how specific kinds of data can be

represented in a SOAP message represented 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 it using 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 encodingStyle encodingStyle Attribute Attribute The The encodingStyle encodingStyle Attribute Attribute

Syntax

soap:encodingStyle="URI“ soap:encodingStyle= URI

Example

<? l i ="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- soap:encodingStyle http://www.w3.org/2001/12/soap encoding"> ... Message information goes here Message information goes here ... </soap:Envelope>

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

The required SOAP Body element

contains the actual SOAP message intended for the ultimate endpoint of the message

SOAP 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 messages used to indicate error messages

The SOAP Body Element: An The SOAP Body Element: An Example SOAP Request Example 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/soap soap: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 Response Example 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 Faults SOAP Faults SOAP Faults SOAP Faults

An error message from a SOAP message is carried

inside a Fault element

Place faults inside env:Body elements If 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

message

The SOAP Fault element has the following child elements

• env:Node (identifies node which generated fault)

( g )

Absence indicates “ultimate recipient”

• env:Code

env:Value env:Subcode

• env:Reason (provide a human-readable explanation of the

fault)

env:T ext

• env:Detail (carrying application specific error information)

( y g pp p )

SOAP Fault Codes SOAP Fault Codes SOAP Fault Codes SOAP Fault Codes

Local 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 g

• itself. 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 item targeted at the faulting SOAP node is scoped with a data encoding that the faulting node does not support.

SOAP Fault Example SOAP Fault Example SOAP Fault Example SOAP 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 MustUnderstand SOAP Faults on MustUnderstand SOAP Faults on MustUnderstand SOAP 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:T ext xml:lang="en-US">Header not understood</env:T ext> <env:T ext xml:lang="fr">En tête non compris</env:T ext> <env:T ext xml:lang= fr >En-tête non compris</env:T ext> </env:Reason> </env:Fault> </env:Body> y </env:Envelope>

SOAP Message Exchange Model SOAP Message Exchange Model g g g 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 Model SOAP Message Exchange Model g g g 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 node SOAP 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 receiver process 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 Exchanges Conversational Message Exchanges g g g 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 Example Conversational 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/hotel s"> 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/trave l">

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

Conversational Message Exchanges Example Conversational 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> p env: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/e mployees" 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 Calls Remote Procedure Calls

One of the design goals of SOAP Version 1.2 is to encapsulate

remote procedure call functionality using the extensibility and p y g y flexibility of XML.

T

• 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 Example Remote Procedure Calls Example

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

Remote Procedure Calls Example Remote Procedure Calls Example p

Output parameters O p

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

Remote Procedure Calls Example Remote Procedure Calls Example p

urn" value "retu

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

SOAP Processing Model SOAP Processing Model SOAP Processing Model SOAP Processing Model

SOAP messages are sent from one sender node passing through zero or

more intermediaries

Three 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 role

Header blocks targeted to specific roles using Role attribute

g p g

If mustUnderstand=“true” SOAP receiver must understand or

generate SOAP fault

Header blocks processed by intermediaries are generally removed before

forwarding forwarding

• Override with relay attribute
• Allows targeting of headers to specific intermediaries (but mustUnderstand

would then generally be turned off)

The "role" Attribute The "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 Bindings SOAP Bindings SOAP Bindings SOAP 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 provides describes the features it provides

SOAP HTTP Binding SOAP HTTP Binding SOAP HTTP Binding SOAP HTTP Binding

A SOAP method is an HTTP

request/response that complies with the SOAP encoding rules. g

HTTP + XML = SOAP A SOAP request could be an HTTP POST A SOAP request could be an HTTP POST

• r an HTTP GET request.

The HTTP POST request specifies at The HTTP POST request specifies at

least two HTTP headers: Content-Type and Content Length and Content-Length.

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

POST /Reservations HTTP/1.1 Host: marketplace.example.org Content-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 Example SOAP SMTP Binding Example SOAP SMTP Binding Example SOAP SMTP Binding Example

From: buyer@bigco.example.org T

• : rfqs@marketplace.example.org

Subject: RFQ: Memory purchase D Th d S b 9 2004 Date: Thursday, September 9 2004 Message-Id: <17-101@bigco.example.org> C t t T li ti / + l Content-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 request request

POST /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 response response

HTTP/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