INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation
description
Transcript of INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation
![Page 1: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/1.jpg)
INFOSYS 290, Section 3, Fall 2005
, Web Services: Concepts, Design and Implementation
Adam [email protected]
Lecture 2: Describe and Invoke -
SOAP and WSDL
![Page 2: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/2.jpg)
Today’s Content
• SOAP• Comparison with other distributed
technologies– Corba– DCOM– Java RMI
• WSDL• Web services survey
– SalesForce sforce– Siebel– Xmethods examples
![Page 3: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/3.jpg)
Service Broker
Basic SOAP Message Exchange
ServiceConsumer
Service Provider
http transport
SOAPmessage
WSDLdescribing
service
SOAPmessage
httptransport
client service
registryfind
publish
DESCRIBE
INVOKE
SOAP Sender SOAP Receiver
SOAP SenderSOAP Receiver
![Page 4: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/4.jpg)
SOAP Body
SOAP Message
SOAP header
SOAP envelope
Header block
Header data
Header data
Header data
Body child element
Body child element
![Page 5: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/5.jpg)
Sample SOAP Message<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header>
<env:Body> <m:alert xmlns:m="http://example.org/alert"><m:msg>Pick up Mary at school at 2pm</m:msg></m:alert>
</env:Body>
</env:Envelope>
![Page 6: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/6.jpg)
Conversational Message Exchange
buyer
seller
seller
seller
messagebroker
RFQ
QuoteResponse
Award
![Page 7: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/7.jpg)
Conversational SOAP Message Exchange: A Request
• <?xml version='1.0' ?> • <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope"> – <env:Header>
• <r:RFQNum xmlns:r=“http://bigco.example.org/RFQ” env:mustUnderstand=“true”>101</r:RFQNum>
• <r:custNum env:mustUnderstand=“true”>17</r:custNum>– </env:Header>– <env:Body>
• <r:RFQ xmlns:r=“http://bigco.example.org/RFQ”>– <r:manufacturer>SanDisk</r:<Manufacturer>– <r:productname>SecureDigital memory</r:productname>– <r:size>1GB</r:size>– <r:substitutable/>– <r:quantity>100</r:quantity></r:RFQ>
– </env:Body>• </env:Envelope>
![Page 8: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/8.jpg)
Conversational Exchange: A Response
• <?xml version='1.0' ?> • <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
– <env:Header> • <r:RFQNum xmlns:r=“http://bigco.example.org/RFQ”>• env:mustUnderstand=“true”>101</m:RFQNum>• <r:vendorID env:mustUnderstand=“true”>2470</r:vendorID>• <r:bidNum env:mustUnderstand=“true”>1</r:RFQNum>• <r:custNum env:mustUnderstand=“true”>17<r:custNum>
– </env:Header>– <env:Body>
• <r:quoteRespons xmlns:r=“http://bigco.example.org/RFQ”>– <r:manufacturer>KingMax</r:<Manufacturer>– <r:productName>SecureDigital memory</r:productname>– <r:size>1GB</r:size>– <r:speed>9000KB/s</r:speed>– <r:VendorName URL=“http://memunlim.com”>Memories
Unlimited</r:VendorName>– <r:SKU>KM-SD1000</r:SKU>– <r:quantity>100</r:quantity>
• </r:quoteResponse>– </env:Body>
• </env:Envelope>
![Page 9: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/9.jpg)
Conversational Exchange:Completion
• <?xml version='1.0' ?> • <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope"> – <env:Header>
• <r:vendorID env:mustUnderstand=“true”>2470</r:vendorID>• <r:bidNum env:mustUnderstand=“true”>1</r:bidNum>• <r:custNum env:mustUnderstand=“true”>17<r:custNum>
– </env:Header>– <env:Body>
• <r:Award xmlns:r=“http://bigco.example.org/RFQ”>– <r:SKU>KM-SD1000</r:SKU>– <r:quantity>50</r:quantity>
• </r:Award>– </env:Body>
• </env:Envelope>
![Page 10: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/10.jpg)
Remote Procedure Calls
• To invoke RPC– Address of target SOAP node– Method name– Identities and values of arguments– Separation of arguments identifying target of
RPC versus data• Plus values of properties for binding (e.g. GET,
POST)
– Optional header data
![Page 11: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/11.jpg)
RPC Invocation<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header><t:transaction xmlns:t=“http://shippingservice.org/transaction” env:encodingStyle=“http://shippingservice.org/encoding” env:mustUnderstand=“true”>5</t:transaction></env:Header>
<env:Body><s:shipOrder xmlns:s=“http://shippingservice.org”><s:origin env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" >
<r:vendorID xmlns:r=“http://bigco.example.org/RFQ”>2470
</r:vendorID></s:origin><s:destination>
<r:custNum env:mustUnderstand=“true”>17<r:custNum></s:destination><s:weight>500g</s:weight></s:shipOrder>
</env:Body> </env:Envelope>
![Page 12: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/12.jpg)
RPC Result<?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
><env:Header><t:transaction xmlns:t=“http://shippingservice.org/transaction” env:encodingStyle=“http://paymentservice.org/encoding” env:mustUnderstand=“true”>5</t:transaction></env:Header>
<env:Body><s:shipOrderResponse env:encodingStyle=“http://www.w3.org/2003/05/soap-encoding”xmlns:rpc=“http://www.w3.org/2003/05/soap-rpc”xmlns:s=“http://shippingservice.org”>
<rpc:result>s:status</rpc:result><s:status>confirmed</s:status><s:amount>$20.00</s:amount>
</s:shipOrderResponse></env:Body> </env:Envelope>
![Page 13: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/13.jpg)
SOAP Faults
• Place faults inside env:Body elements• In single env:Fault• env:Node identifies node which generated fault
– Absence indicates “ultimate recipient”• env:Code
– env:Value– env:Subcode
• env:Reason– env:Text
• env:Detail– Application specific
![Page 14: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/14.jpg)
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: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:message>Unknown destination</e:message> <e:errorcode>999</e:errorcode>
– </e:myFaultDetails> • </env:Detail>
– </env:Fault> • </env:Body> • </env:Envelope>
![Page 15: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/15.jpg)
SOAP Faults on MustUnderstand
<?xml version='1.0' ?> <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:Reason>
</env:Fault> </env:Body> </env:Envelope>
![Page 16: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/16.jpg)
SOAP Processing Model• SOAP messages are sent from one sender node passing through
zero or more intermediaries• Three roles
– next: each SOAP intermediary or end destination must act in this role– none: SOAP nodes must not act in this role– ultimateReceiver: destination acts in this role
• Header blocks targeted to specific roles using Role attribute• If mustUnderstand=“true” SOAP receiver must understand or
generate SOAP fault• Header blocks processed by intermediaries are generally removed
before forwarding– Override with relay attribute– Allows targeting of headers to specific intermediaries (but
mustUnderstand would then generally be turned off)
![Page 17: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/17.jpg)
SOAP Extensibility in Practice<S:Envelope ...>• <S:Header>• <wsa:ReplyTo>
<!-- WS-Addressing header block -->• <wsa:Address>http://bigco.example.org/buyer</wsa:Address>• </wsa:ReplyTo>
• <wssec:Security> – <wssec:BinarySecurityToken ValueType=”wssec:X509v3”
encodingType=”wssec:Base64Binary”>• dhw6weiurU982ndya73jdVBGt2567...d79HID7ghd652ad2
– </wssec:BinarySecurityToken>– <wsrm:Sequence>
• <wsu:Identifier>http://f123.com/sq14<wsu:Identifier>• <wsrm:MessageNumber>10</wsrm:MessageNumber>
– </wsrm:Sequence>• </S:Header>• <S:Body>...</S:Body></S:Envelope>
![Page 18: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/18.jpg)
SOAP Processing: Header Blocks, MustUnderstand and Relay
<?xml version="1.0" ?> • <env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope"> – <env:Header>
• <p:oneBlock xmlns:p="http://example.com" env:role="http://example.com/Log" env:mustUnderstand="true"> ... </p:oneBlock>
• <q:anotherBlock xmlns:q="http://example.com" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:relay="true"> ... ...</q:anotherBlock>
• <r:aThirdBlock xmlns:r="http://example.com"> ... ... </r:aThirdBlock>
– </env:Header>
– <env:Body > ... ... </env:Body>• </env:Envelope>
![Page 19: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/19.jpg)
SOAP Bindings
• specify how SOAP messages may be passed from one SOAP node to another using an underlying protocol
• provides a serialized representation of the message
• provides a mechanism to support features needed by SOAP applications (security, reliability, etc...)
• describes the features it provides
![Page 20: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/20.jpg)
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>
![Page 21: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/21.jpg)
SOAP SMTP Binding Example
• From: [email protected]• To: [email protected]• Subject: RFQ: Memory purchase• Date: Thursday, September 9 2004• Message-Id: <[email protected]>• Content-Type: application/soap+xml• <?xml version='1.0' ?>• <env:Envelope xmlns:env=”...”>• <env:Body>
![Page 22: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/22.jpg)
SOAP Remoting ArchitectureSOAP Remoting Architecture
Server objectimplementation
application level
Client application code
Server skeleton
XML unmarshaller
Client stub
XML marshaller
TCP/IP socket
remoting architecture level
wire protocol levelhttp protocol http
serverhttp
server
body
envelopeheader header
![Page 23: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/23.jpg)
So What’s Different?• Open format usable from any platform• Easy to understand and debug• Stable supported interfaces• Standards enable “expose service once” and have multiple
consumers – versus typical point to point integration efforts
• Easy for intermediaries to process messages and add value– Routing and delivery– security– management and monitoring– schema and service design– acceleration
• Easy to extend with additional semantics
![Page 24: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/24.jpg)
CORBA
Server objectimplementation
application level
Client application code
Server skeleton
Corba runtime
Implementationrepository
Client stub
Corba runtime
Implementationrepository
ORBORB
TCP/IP socket
![Page 25: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/25.jpg)
CORBA Dynamic Invocation
Server objectimplementation
application level
Client application code
Server skeleton
Corba runtime
Implementationrepository
Client stub
Corba runtime
Implementationrepository
ORBORB
TCP/IP socket
binding method
Remoting architecture level
Wire protocol level
![Page 26: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/26.jpg)
CORBA• Scalability
– Stateful programming model -– Shared activation +
• Performance– CORBA is only intermediary until object obtained (allowing direct client-server
interaction) + – Binary transport +
• Activation– Sophisticated four policy activation methods +
• State Management– Provides state management with a connection-oriented protocol +
• Garbage Collection– Implemented on per ORB vendor basis– No concept of distributed memory management
• Security– Just uses SSL -
![Page 27: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/27.jpg)
DCOM and DCE RPC
Server objectimplementation
application level
Client application- code
Server stub
COM runtime
Client proxy
COM runtime
SCMSCM
RPC channel
binding method
Remoting architecture level
Wire protocol level
registry registry
OXID ResolverPing client/server
![Page 28: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/28.jpg)
DCOM Object Creation
Server objectimplementation
application level
Client application- code
Server stub
COM runtime
Client proxy
COM runtime
SCMSCM
RPC channel
binding method
Remoting architecture level
Wire protocol level
registry registry
OXID ResolverPing client/server
![Page 29: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/29.jpg)
DCOM Object Invocation
Server objectimplementation
application level
Client application- code
Server stub
COM runtime
Client proxy
COM runtime
SCMSCM
RPC channel
binding method
Remoting architecture level
Wire protocol level
registry registry
OXID ResolverPing client/server
![Page 30: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/30.jpg)
DCOM Comparison• Scalability
– Not scalable due to garbage collection and connection overhead– All clients involved in call required to send pings to servers at two minute intervals
• Performance– Many roundtrips to activate and use remote object
• Activation– Client obtains reference to remote object’s class object through local SCM from
remote SCM– Client creates instances of remote objects through its proxy
• State Management– DCOM goal: location transparency– Makes it very difficult to have a stateless model
• User interface IFaces• Iteration IFaces
• Garbage Collection– After three ping fails, server cleans up resources for objects owned by remote client
• Security– Provides authentication, authorization and identity– Many authentication methods
![Page 31: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/31.jpg)
Java RMI
Server objectimplementation
application level
Client application- code
Server skeleton
Remote ReferenceLayer
Client stub
Remote ReferenceLayer
Transport Layer
binding method
remoting architecture level
wire protocol level
Transport Layer
TCP/IP Socket
RMIRegistry
![Page 32: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/32.jpg)
JRMP
signature (JRMI)
version
protocol
SingleOpProtocolStreamProtocolMultiplexProtocol
Message(serialized arguments based On Java’s Object Serialization
Protocol)
![Page 33: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/33.jpg)
RMI Comparison• Scalabilitiy
– Good overall– Registry could be bottleneck
• Performance– Fairly high– Use from Java applets in browser cause conversion to http –expensive
• Activation– Stub can be download over the network – Lazy activation and selection of specific server instances– Allows automatic instantiation of objects based on methods faulting and the fault resolution
process instantiating the remote object• State Management
– Provides both connection-oriented and connectionless protocols (good!)• Garbage Collection
– Distributed reference counting (like CORBA, DCOM)– Reference to remote objects is considered lease on object, which must be periodically
renewed• Security
– Strong security– Must have security credentials to perform dynamic class loading
![Page 34: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/34.jpg)
SOAP Comparison• Scalability
– Very scaleable especially over http if request/response model is maintained• Performance
– Degraded by XML overhead– But if you’re interoping between architectures anyway that overhead isn’t unreasonable
• Activation– Beyond SOAP’s scope
• State Management– Stateless if over http
• Garbage Collection– Beyond scope
• Security– https/SSL - not ideal for routability of course– WS-Security
• Other Disadvantages– No true standard serialization method– Multiple copies of objects transported
• Other Advantages– Encouragement of loose coupling (both physical and interface)– Protection of apps from changes in standards– Truly vendor-agnostic
![Page 35: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/35.jpg)
Web Services Description Language
• Provides a model and an XML format for the “contract” of a web service
• Separates abstract service description from both concrete network protocol and message format
• Describes data types used in messages• Messages are defined as aggregation of typed
parts• Operations are message exchange patterns
supported by the web service• PortTypes are named collections of operations
![Page 36: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/36.jpg)
WSDL Components
• Types– a container for data type definitions using some type system (such as XSD).
• Message– an abstract, typed definition of the data being communicated.
• Operation– an abstract description of an action supported by the service.
• Port Type–an abstract set of operations supported by one or more endpoints.
• Binding– a concrete protocol and data format specification for a particular port type
• Port– a single endpoint defined as a combination of a binding and a network address.
• Service– a collection of related endpoints.
![Page 37: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/37.jpg)
WSDL Specification
types
message message message
operation
porttype
operation operation
binding
serviceport
![Page 38: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/38.jpg)
An Example - WSDL Types<?xml version="1.0"?> <definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schems.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest">
<complexType><all><element name="tickerSymbol" type="string"/> </all>
</complexType> </element> <element name="TradePrice">
<complexType><all><element name="price” type="float"/></all></complexType>
</element> </schema></types>
![Page 39: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/39.jpg)
WSDL Operations
<message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message>
<message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/></message>
<portType name="StockQuotePortType"><operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation>
</portType>
![Page 40: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/40.jpg)
WSDL Bindings, Services, Ports
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document“ transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input><soap:body use="literal"/></input> <output><soap:body use="literal"/></output> </operation>
</binding> <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/> </port> </service> </definitions>
![Page 41: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/41.jpg)
Import for Types<?xml version="1.0"?> <definitions name="StockQuote"
targetNamespace="http://example.com/stockquote/definitions" xmlns:tns="http://example.com/stockquote/definitions" xmlns:xsd1="http://example.com/stockquote/schemas" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<import namespace="http://example.com/stockquote/schemas" location="http://example.com/stockquote/stockquote.xsd"/>
<message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/></message>
![Page 42: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/42.jpg)
WSDL Binding
• maps the abstract service functionality to a specific network protocol and message format
• defines:– the communication protocol to use– how service interactions are accomplished using this
protocol– the address to communicate with
• Three bindings are defined in the WSDL spec:– SOAP binding– HTTP binding– SMTP binding
![Page 43: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/43.jpg)
WSDL Binding Example:One-way Over SMTP
• <message name="SubscribeToQuotes"> <part name="body" element="xsd1:SubscribeToQuotes"/>– <part name="subscribeheader" element="xsd1:SubscriptionHeader"/>
• </message> • <portType name="StockQuotePortType">
– <operation name="SubscribeToQuotes"> • <input message="tns:SubscribeToQuotes"/>• </operation>
– </portType>• <binding name="StockQuoteSoap" type="tns:StockQuotePortType">
– <soap:binding style="document" transport="http://example.com/smtp"/> – <operation name="SubscribeToQuotes"> – <input message="tns:SubscribeToQuotes"> – <soap:body parts="body" use="literal"/> – <soap:header message="tns:SubscribeToQuotes" part="subscribeheader"
use="literal"/>– </input> – </operation>
• </binding> • <service name="StockQuoteService">
– <port name="StockQuotePort" binding="tns:StockQuoteSoap"> • <soap:address location="mailto:[email protected]"/>
– </port> • </service>
![Page 44: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/44.jpg)
Request-Response RPC Over HTTP
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> • <soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/> • <operation name="GetTradePrice">
– <soap:operation soapAction="http://example.com/GetTradePrice"/> – <input>
<soap:body use="encoded" namespace="http://example.com/stockquote" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
– </input> – <output>
<soap:body use="encoded" namespace="http://example.com/stockquote" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
– </output> • </operation>> </binding>
<service name="StockQuoteService"> <documentation>My first service</documentation><port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/></port>
</service>
![Page 45: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/45.jpg)
Web Services Client Tools
– MindReef– AboveAll
![Page 46: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/46.jpg)
Web Services Survey
• XMethods examples– Focus on “informational web services”
• http://pocketodds.com
• Business APIs– SalesForce– Siebel CRM OnDemand– PayPal
![Page 47: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/47.jpg)
Course Project• Goal
– Build “web service consuming” client applications from desktops and mobile devices
• Requirements– Use an “informational” web service
• Has QCUD (Query, Create, Update and Delete operations)– Consume web service from AboveAll or Visual Studio for desktop– Consume WS from GoodAccess Web Services or Visual Studio from mobile
device– Optionally write or enhance a backend web service
• Possibly as a “proxy web service” layer on top of original web service• Only if previous steps are achieved
– Demo to class– Write up as three page paper including: architecture and UI design
• Team size– Two people per project
• Proposal– Due next week: September 8, 2005
![Page 48: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/48.jpg)
References
• Specs– SOAP Specification, http://www.w3.org/TR/soap/– WSDL Specification, http://www.w3.org/TR/wsdl– UDDI Specification,
http://www.uddi.org/specification.html
• Tools– Visual Studio, http://microsoft.com/vstudio– Microsoft Web Services Enhancements
• http://msdn.microsoft.com/webservices/building/wse/default.aspx
![Page 49: INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation](https://reader033.fdocuments.net/reader033/viewer/2022052603/56813f59550346895daa25e0/html5/thumbnails/49.jpg)
How To Reach Me
• 408-396-5490
• Office hours Thursday at 4pm