X-Informatics: I-400 and I-590 Web Services: SOAP and WSDL

1. X-Informatics: I-400 and I-590Web Services: SOAP and WSDL Spring Semester 2002 MW 6:00 pm – 7:15 pm Indiana Time Geoffrey Fox and Bryan Carpenter PTLIU Laboratory for Community Grids Informatics, (Computer Science , Physics) Indiana University Bloomington IN 47404 gcf@indiana.edu svgspring02

2. What is a Web or Grid Service? • The Webis distributed system allowing communities to access resources from clients • Resources are web-pages, instruments, Object repositories, Simulation codes running on supercomputers …. • A Serviceis a generic application or capability, respecting standards allowing multiple providers to compete on a given service Middle TierBroker Portal is customizable User interface Back endCapability Resource svgspring02

3. Some Business Web Services PaymentCredit Card Security Catalog Warehouse shipping • Business is developing “web service” concept to support areas like e-commerce where one composes atomic services like • Security • Payment • Catalog • Goods supply Each of these services could allow Multiple choices of provider In a given session WSDLinterfaces WSDLinterfaces svgspring02

4. SOAP and WSDL • SOAP started off as a project to define an XML-based object model – see the introduction to SOAP effort at W3C • SOAP became “just” an XML based messaging scheme building on transport protocols – with HTTP currently the dominant one of interest • WSDL Web Services Description Languagehttp://www.w3.org/TR/wsdl, is built on top of SOAP (and potentially other messaging/transport technologies) and roughly does define an XML based distributed object framework • Note XML itself provides an object framework svgspring02

5. An XML “Protocol Stack” UDDI or WSIL WSFL WSDL SOAP HTTP or SMTP or IIOP or RMTP TCP/IP Physical Network • UDDI finds where programs are • remote( (distributed) programs are just Web Services • WSFL links programs together • WSDL defines interface (methods, parameters, data formats) • SOAP defines structure of message including serialization of information • HTTP is negotiation/transport protocol • TCP/IP is layers 3-4 of OSI • Physical Network is layer 1 of OSI svgspring02

6. Note on UDDI • Won’t be discussed in detail here, but UDDI (Universal Description, Discovery and Integration) plays a role like Google on the web or yellow pages in the real world • Suppose we were a shopping cart service and told by a customer that we need to contact the SuchandSuch online credit card system • We would not only need to find www.suchandsuch.com but also identify the exact URL’s for “approval” and “payment” – and we would need to get the conventions correct for exchanging data • For instance, we would need to know if system used US Canadian or HK dollars • So UDDI knows about WSDL Interfaces and this knowledge enables programs with such interfaces to link together • UDDI and WSDL together enable dynamic Web applications svgspring02

7. Architecture of Future Web: CommodityScience Next Generation Consumer Web Twenty-First Century University and laboratory P e r f o r m a n c e Conv e n i e n c e Science Portals & Workbenches Community Portals Commerce Grid Education Grid Research Grid Computational Grid Education Services Computational Services Research Services & Technology Business Services Grid Services (resource independent) Grid Fabric (resource dependent) Networking, Devices and Systems • Commerce, Entertainment, Healthcare, Science, Computing, Education …. will be Grid or Web Services svgspring02

8. SOAP svgspring02

9. Basic Principles • SOAP stands for Simple Object Access Protocol. • Actually it is “just” an XML format for messages exchanged between Web services and their clients. • It defines in a general way how clients send requests to services, and how services respond. • See version 1.1 http://www.w3.org/TR/SOAP/ May 8 2000 • This effort has been generalized to XML Protocol activityhttp://www.w3.org/2000/xp/ svgspring02

10. Background • SOAP was originally conceived (circa 1997) as a mechanism for Remote Procedure Call using Web protocols (HTTP and later XML). • In programming languages, a procedure is a self-contained block of code, for performing some well-defined task. • A remote procedure call is an invocation of a procedure on one computer (e.g. the server) by a program running on another, remote computer (e.g. the client). • Calling a procedure remotely generally requires the caller send a request to the callee, then wait for a response. • Microsoft made the original proposals, but for political reasons the earliest release of XML-RPC (the precursor of SOAP) came from Userland (1998). • When SOAP itself emerged a couple of years later, it had been generalized to allow more general message-passing. svgspring02

11. SOAP Structure HTTP Delivery with address • SOAP defines a message with envelope, header and body • The SOAP standard also defines a binding to HTTP which is equivalent to methodology for delivering message • The SOAP body can specify data as well as fault processing information • SOAP can be transported over standard mail by just putting XML in body of mail – see http://xml.apache.org/soap/faq/faq_chawke_smtp.html http://www.w3c.org/2000/xp/Group/1/11/16/soap12-primer.html#SMTP svgspring02

12. SOAP Example 1 • We take November 16 tutorial:http://www.w3c.org/2000/xp/Group/1/11/16/soap12-primer.html • This is a SOAP Message – defining a reservation request • Header has key meta-data of application (namelist m: and instructions to SOAP (intermediate—actor) processors svgspring02

13. SOAP Example 1 (Concluded) • This has the SOAP Body with actual request svgspring02

14. SOAP Structure I • There are two basic namespaces for • Envelope and • Encoding which is same as “serialization” in other approaches to remote objects such as RMI – • it converts general formats – numbers, pictures etc. into a format that can be sent over a network and reconstructed on other computers which might store information in a different way • SOAP allows to specify other encoding methods • The Envelope defines a Header (compulsory) and a Body (optional) • It is users choice what information is placed in header and what in body • In general “metadata” in header and data in body – one assumes processing of “metadata” will happen first and often will allow one to skip body processing if header indicates message not needed svgspring02

15. SOAP Structure II This is structure of example we looked at Note “real” information uses separate namespaces from SOAP like reservation or passenger The Header has various SOAP attributes that can added to elements in application elements The Body can contain SOAP Fault messages svgspring02

16. SOAP Header • This allows header elements to have SOAP attributes to specify nature of header processing • envelope:actor specifies if header is instructions for routing nodes or just for final node • envelope:mustUnderstand specifies if it is essential or not that meaning of this element must be understood by recipient of message • actor if omitted implies that header is to be processed by final recipient of message • If actor=“http://schemas.xmlsoap.org/soap/actor/next” then the next (routing) processor should interpret header • mustUnderstand omitted or mustUnderstand=0 implies that it is not necessary to understand this element • mustUnderstand=1 implies recipient (controlled by actor) must understand element svgspring02

17. SOAP Example 2 • This is response to this request • UUID: is example of unique automatically generated URI svgspring02

18. SOAP Example 2 (Concluded) • This defines reservation in application dependent Schema svgspring02

19. RPC Like Example • Here we send payment data using UUID from previous message to link Credit Card to transaction • Invoke reserveAndCharge method with sundry parameters svgspring02

20. Faults in SOAP • This illustrates how SOAP wants faults in header or body to be handled • Fault is always returned in body not header+ svgspring02

21. Faults in SOAP • This are defined as child elements to envelope:Body and there can 0 or 1 envelope:Fault elements • Fault can contain • faultcode must be chosen from an enumerated list which includes versionMismatch mustUnderstand Client Server • For instance the mustUnderstand faultcode indicates error in processing an element in header with mustUnderstand attribute set • faultstring is a user specified representation of fault • faultactor indicates which “actor” (processor) generated fault • detail allows one to specify greater detail on fault svgspring02

22. SOAP Binding to HTTP • This is very simple • There is an optional SOAPaction: attribute added to HTTP but its utility does not seem well established For sending creditCard example Response creditCard example svgspring02

23. SOAP Binding to SMTP • This is very straightforward! svgspring02

24. Remarks on SOAP Structure • If you look at networking protocols, at each layer one specifies a header and a body • HTTP has a header telling system where to send information and some high level specification of what to get • In example, we see that body of HTTP message is full SOAP envelope and this envelope has SOAP Header and Body interpreted by “application” • At a lower level in protocol stack, TCP/IP and ATM etc. have their own headers and bodies • It is the standard Russian Dollsituation – each doll has a body (contained inside it) which is the full doll of higher level protocol HTTP SOAP SOAP Body svgspring02

25. SOAP Attachments • This uses same approach as email or HTTP and is a general way of including binary data in XML – but not understood by most parsers! XML links to MIMEAttachment using absolute or relative URI’s svgspring02

26. Encoding Arrays in SOAP • SOAP defines a set of rules for sending data of different types – in particular it defines arrays which are not in basic XML There is an Array type and also a built in element of this type svgspring02

27. Another Encoding Example • Here is an example where application schema defines type structure svgspring02

28. Links I • OSI Layers http://webopedia.internet.com/quick_ref/OSI_Layers.html • SOAPhttp://www.w3c.org/TR/soap • WSDL Web Service Definition Language http://www.w3c.org/TR/wsdl • WSFL Web Service Flow language http://www.ibm.com/software/webservices • WSIL Web Service Inspection Language http://www-106.ibm.com/developerworks/webservices/library/ws-wsilover/ • UDDI Universal Description, Discovery, and Integration http://www.uddi.org svgspring02

29. Links II • SOAP/WebServices Resource Center – http://www.soap-wrc.com/webservices/ • http://www.webservices.org/ • http://www.soaprpc.com/ • Public SOAP Services listing - http://www.xmethods.com/ • IBM Developers Tutorialhttp://www-105.ibm.com/developerworks/education.nsf/components-onlinecourse-bytitle/52CEEC8554DB0C1586256A0D005A6E41?OpenDocument • Class at Stanfordhttp://www.mnot.net/papers/ws-stan.html • Examples of WSDL/SOAP files for computational science http://aspen.ucs.indiana.edu/ptliu/gatewaywsdl/ svgspring02

30. WSDL svgspring02

31. WSDL Abstractions • WSDL abstracts a program as an entity that does something given one or more inputs with its results defined by streams on one or more outputs. • Functions are defined by method name and parametersmethodname(parm1,parm2, … parmN) • Where parameters are “Input” “Output” or both • In WSDL, we will have a Web Service which like a (Java or CORBA Program) can be thought of as a (distributed) object with many methods • Instead of a function call, the “calling routine” sends an XML message to the Web Service specifying methodname and values of the parameters • Note name of function is just another parameter svgspring02

32. Communicating Processes WebApplication1 WebApplication2 Single Address space stack WebServer WebServer Method2 Method1 WSDL Messages Shared Memory Distributed System svgspring02

33. Simple Minded View of Services • So we are building a “component” model of software systems • Components are “just web applications” or more precisely support the web standards • You can access them from portals for Graphical User Interface • You can link to them and discover them like web applications • So Grid Services concept is a sustainable “framework” for developing parallel and distributed systems • Parallel version implies low latency / high bandwidth communications in both hardware and software • So Grid services must be implementable with high functionality (SOAP) or high performance protocols (RMI, threads) • They are subroutine library model for the Grid svgspring02

34. Capabilities of the Education Web Service • Now we look at Applications that can be thought of as Web Services as we form either • e-Learning or • e-Science • Curriculum or“Learning Objects” • Web Pages becoming more sophisticated(Flash) • Audio-VideoConferencing,Chat rooms,white boardsto support student, teacher, mentorinteractions • Shared Documents for synchronous collaboration • Learning Management Systems • Student registration, Quizzes, Grading, Security • Database Storage (persistent Learning Objects) • IMS and ADL standards for interoperability • Asynchronous self paced access svgspring02

35. Some Education Web Services • Registration • Performance (grading) • Authoring of Curriculum • Online laboratories for real and virtual instruments • Homework submission • Quizzesof various types (multiple choice, random parameters) • Assessment data access and analysis • Synchronous Delivery of Curricula • Scheduling of courses and mentoring sessions • Asynchronous access, data-mining and knowledge discovery svgspring02

36. Some General Grid Web Services Portals customization Registration (security) People Collaboration (Access Grid -- Desktop Audio Video) Resource Collaboration (P2P, Document Sharing) News groups Channels Instant Messenger White board Anonymity Payment -- Digital Cash Catalog Support Comments as in Amazon Surveys Decision Making Authoritarian Consensus Group Mediation Advertising Search/Knowledge Discovery (Digital Library Service) MyGoogle Need for structured (Directory in Google, Indexed Databases etc.) Unstructured Data (basic Google) Computing Interface Workflow Support flow of information (approval) through some process secure authentication of this flow Authoring Multi-fragment pages Charts Multimedia Video on Demand Tenure evaluation support Generate CV Refereeing Universal Access from PDA/Phone to disabilities Caching Akamai Scaling Performance trouble shooting grid svgspring02

37. Science as a Grid Web Service I Science Generic Services building on previous Grid services Storage Rendering and Authoring of Mathematics Other specialized authoring and rendering Scientific Whiteboard nD (n=2 3) Support GIS Virtual worlds Integration of different sciences optimization image processing Matrix libraries Mathematical calculation and manipulation as a Grid Service Education as a Grid service Authoring Curriculum specification and associated services specification: prerequisites completion requirements Grading Homework Submission Quiz Setting including individualized questions Quiz Taking Office Hours Mentoring Delivery Assessment including evaluation of material evaluation of student interaction with material Self paced learning Particular learning models from K-12 to Lifelong svgspring02

38. Science as a Grid Web Service II General Science Research Computing Interface Job Control/Submission Scheduling Visualization Programming Parameter Specification Legacy Code support (wrapping) Application Integration Software version control Monitoring ..... Scientific Data services High Performance Special Formats Virtual data as in Gryphyn Fastlane/ Report submission Science Library Publication Comparison of Theory/Expt evaluation Research -- Theory/Discussion Scientific Notebook/Whiteboard Brainstorming Seminars Theorem proving Research -- Experimental Virtual Control Room from accelerator to satellite Data Analysis Virtual Instrument Sensors Satellites to Field work to wireless in the Amazon to Video cameras recording earthquake damage to LED in rack of accelerator control module medical instruments (Telemedicine Grid Service) Outreach Multi-cultural customization Multi-level presentations svgspring02

39. 7 Primitives in WSDL • types: which provides data type definitions used to describe the messages exchanged. • message: which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system. • operation– an abstract description of an action supported by the service. • portType: which is a set of abstract operations. Each operation refers to an input message and output messages. • binding: which specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType. • port: which specifies an address for a binding, thus defining a single communication endpoint. • service: which is used to aggregate a set of related ports svgspring02

40. Discussion of 7 Primitives • types specify data-structures which are equivalent to arguments of methods • message specifies collections of types and is equivalent to set of arguments in a method call. Note that it is an “abstract method” in Java terminology • operation is a a collection of input output and fault messages; there are 4 types of operation one-way(service just receives a message), request-response(RPC), solicit-response, notification (services pushes out a message) • portType represents a single channel that can support multiple operations. It is “abstract” as specified as a set of operations. It is equivalent to a “interface or abstract class” in Java • binding tells you transport and message format for a porttype (which can have multiple bindings to reflect say performance-portability trades) • port combines a binding and an endpoint network address (URL) and is like a “class instance” • service consists of multiple ports and is equivalent to a “program” in Java svgspring02

41. WSDL Stock Quote Example I: Header • We use an Example from W3C document http://www.w3.org/TR/wsdl which defines a stock quote service. The service supports a single operation called GetLastTradePrice, which is deployed using the SOAP 1.1 protocol over HTTP. It implements a request-response operation. The request takes a ticker symbol of type string, and the response returns the price as a float. WSDL File Stock QuoteData StructureSchema SOAP binding of WSDL WSDL Schema svgspring02

42. WSDL Stock Quote Example II: types • This defines an input (Stock Ticker Symbol like IBM or MSFT) and output floating price (such as 101.0) • Note name attributes can be referenced as “QName” WSDLElement Namespacefor thesedefinitions One or zerooccurrences ... Parts of standard XML Schema namespace svgspring02

43. WSDL Stock Quote Example III:messages • This is input argument list and references TradePriceRequest defined in <types> specification on previous foil. Note namespace is a local URI xsd1 • This is output argument list and references TradePrice defined in <types> specification on previous foil. • In this example input (request) and output (response) just have one entry svgspring02

44. WSDL Stock Quote Example IV:portType • This defines that this service involves • Send a message to service as defined by WSDL message with name GetLastTradePriceInput • Service returns a messageas defined by WSDL message with name GetLastTradePriceOutput • WSDL would allow one to specify <fault message=“tns:GetlastTradeFault” /> with something like • <message name="GetLastTradePriceFault"><part name="body" element="xsd1:TradePriceFault"/> </message> • And TradePriceFault defined in types section earlier svgspring02

45. WSDL Stock Quote Example V:binding, service End WSDL File • binding is linked to portType just defined StockQuotePortType • It uses a separate Schema to take the one defined operation GetLastTradePrice and tell you to send messages as body of SOAP message (as opposed to SOAP RPC) • It also defines soapAction as a URL • Finally we define the Service StockQuoteService with one port with previous binding (StockQuoteBinding) and a URL for Service svgspring02

46. Additional WSDL Features: Qname/import • WSDL allows you crossreference certain items • <portType name="StockQuotePortType"> …. • Is referenced by: • <binding name="StockQuoteBinding" type="tns:StockQuotePortType"> • This requires such referenced names in service, port,message, binding, portType to be unique • Note that this is an extension of normal XML and gives WSDL documents a syntax and role like xsd (Schema) files • WSDL is in fact something a “distributed object schema” • WSDL allows an import statement that is similar in function to that for Schema • It allows WSDL documents to be split into parts separating say types, abstract (message/portType) and implementation (binding, service, port) NCName QName svgspring02

47. Additional WSDL Features: import II • This defines a straightforward XML Schema file (without WSDL <types> element) with • Location(URL) http://example.com/stockquote/stockquote.xsd • And Namespace (URI) http://example.com/stockquote/schemas • It defines same elements as before with essentially identical interface before as <types> <schema> elements in WSDL use XML Schema syntax Schema is part of XML Schema specification and its use under types in WSDL is an example of extending WSDL svgspring02

48. Additional WSDL Features: import III Message portType • Now we reference these data structures and define the abstract message and portType structure – this is equivalent to IDL (without IIOP) in CORBA or Java Interface specification • This is file http://example.com/stockquote/stockquote.wsdl and namespace http://example.com/stockquote/definitions Importvariabletypespecification svgspring02

49. Additional WSDL Features: import IV • Finally we access abstract definition and define the service with file http://example.com/stockquote/stockquoteservice.wsdl svgspring02

50. wsdl:documentation wsdl:required • <wsdl:documentation> introduces general comments (documentation) and is of “mixed” XML type i.e. can contain any other elements or text • It can appear inside any WSDL element • WSDL allows extensions – especially to define new bindings – and any element in an extension can have attribute wsdl:required which is defaulted to false svgspring02