1 / 49

INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation

INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation. Lecture 2: Describe and Invoke - SOAP and WSDL. Adam Blum ablum@good.com. Today’s Content. SOAP Comparison with other distributed technologies Corba DCOM Java RMI WSDL Web services survey

kiona
Download Presentation

INFOSYS 290, Section 3, Fall 2005 , Web Services: Concepts, Design and Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. INFOSYS 290, Section 3, Fall 2005, Web Services: Concepts, Design and Implementation Lecture 2: Describe and Invoke - SOAP and WSDL Adam Blum ablum@good.com

  2. Today’s Content • SOAP • Comparison with other distributed technologies • Corba • DCOM • Java RMI • WSDL • Web services survey • SalesForce sforce • Siebel • Xmethods examples

  3. Basic SOAP Message Exchange WSDL describing service Service Provider Service Consumer DESCRIBE http transport SOAP message client service SOAP Sender SOAP Receiver INVOKE http transport SOAP message SOAP Receiver SOAP Sender registry find Service Broker publish

  4. SOAP Message SOAP envelope SOAP header Header block Header data Header data Header data SOAP Body Body child element Body child element

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

  6. Conversational Message Exchange seller buyer message broker RFQ seller QuoteResponse Award seller

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

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

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

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

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

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

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

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

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

  16. 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)

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

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

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

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

  21. SOAP SMTP Binding Example • From: buyer@bigco.example.org • To: rfqs@marketplace.example.org • Subject: RFQ: Memory purchase • Date: Thursday, September 9 2004 • Message-Id: <17-101@bigco.example.org> • Content-Type: application/soap+xml • <?xml version='1.0' ?> • <env:Envelope xmlns:env=”...”> • <env:Body>

  22. SOAP Remoting Architecture SOAP Remoting Architecture application level Client application code Server object implementation Server skeleton Client stub XML marshaller XML unmarshaller remoting architecture level envelope header header body http protocol http server http server wire protocol level TCP/IP socket

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

  24. CORBA application level Client application code Server object implementation Implementation repository Client stub Server skeleton Implementation repository Corba runtime Corba runtime ORB ORB TCP/IP socket

  25. CORBA Dynamic Invocation application level Client application code Server object implementation binding method Client stub Implementation repository Server skeleton Implementation repository Corba runtime Corba runtime Remoting architecture level ORB ORB TCP/IP socket Wire protocol level

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

  27. DCOM and DCE RPC application level Client application- code Server object implementation binding method Client proxy Server stub COM runtime COM runtime Remoting architecture level SCM SCM registry registry RPC channel Wire protocol level OXID Resolver Ping client/server

  28. DCOM Object Creation application level Client application- code Server object implementation binding method Client proxy Server stub COM runtime COM runtime Remoting architecture level SCM SCM registry registry RPC channel Wire protocol level OXID Resolver Ping client/server

  29. DCOM Object Invocation application level Client application- code Server object implementation binding method Client proxy Server stub COM runtime COM runtime Remoting architecture level SCM SCM registry registry RPC channel Wire protocol level OXID Resolver Ping client/server

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

  31. Java RMI application level Client application- code Server object implementation binding method Client stub Server skeleton RMI Registry Remote Reference Layer Remote Reference Layer remoting architecture level Transport Layer Transport Layer TCP/IP Socket wire protocol level

  32. JRMP signature (JRMI) version SingleOpProtocol StreamProtocol MultiplexProtocol protocol Message (serialized arguments based On Java’s Object Serialization Protocol)

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

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

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

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

  37. WSDL Specification types message message message porttype operation operation operation binding service port

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

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

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

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

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

  43. 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:subscribe@example.com"/> • </port> • </service>

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

  45. Web Services Client Tools • MindReef • AboveAll

  46. Web Services Survey • XMethods examples • Focus on “informational web services” • http://pocketodds.com • Business APIs • SalesForce • Siebel CRM OnDemand • PayPal

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

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

  49. How To Reach Me • ablum@good.com • 408-396-5490 • Office hours Thursday at 4pm • web-services@sims.berkeley.edu

More Related