Web Services & the Grid

1. Web Services & the Grid Ian Atkinson Ian.Atkinson@jcu.edu.au HPRC Manager, ITR School of Maths, Physics and IT James Cook University, Townsville, Australia

2. Outline of Presentation • What are Web Services? • Programming models • Grid vs. Web Services • Technologies • SOAP • WSDL • UDDI • Comparison with alternatives Essential Source: The Globus Toolkit 4 Programmer’s Tutorial. Borja Sotomayor

3. Programming Evolution • Low level assembly coding • High level languages (e.g fortran, cobol) • libraries & subroutines • Object Oriented Programming • reusability not as great as expected • Component Based development • Web services is an example

4. How do achieve distribution? • Many technologies exist • CORBA, RMI, RPC etc. • Interoperability drawbacks gave birth to W3C Web Service definition

5. What are Web Services? • Open standards (XML, SOAP, etc.) based Web applications that interact with other web applications for the purpose of exchanging data. • Initially used for the exchange of data on private (enterprise) networks • Have evolved to include transactions over the public Internet.

6. Humans & Machines • Web browsers and HTML deal with application to human communication • General model for human-to-application interaction • SOAP and XML-based web services are for program-to-program communication • Resolves program, machine, operating system and organizational boundaries • General model for application-to-application interaction & access

7. Weather Service

8. Yet More Definitions… • Web Services define a platform-independent standard based on XML to communicate within distributed systems. • They are loosely coupled and allow short-term cooperation between services. • The main protocol defining the kind of communication to a web service is SOAP (Simple Object Access Protocol).

9. More Definitions: CIMA • A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). • Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. http://www.w3.org/TR/ws-arch/

10. Perspective • This basic problem that web services solve is no different to many other distributed computing projects (corba, rmi etc.). • Many previous efforts have aimed at smaller scales, or have been research projects. • Web Services tackles real world implementation problems associated with large-scale distributed systems, • hence much more widely adopted than many earlier efforts

11. Component Distribution • Component Based Development gives life to distributed computing • Components made accessible over computer networks via standard interfaces • Components are dubbed “services” • Allow us to create client/server applications

12. Distributed Web Services

13. Desirable Characteristics of a Web Service • Self describing • XML Schema for grammar of payload • Human readable instances • Discoverable • UDDI, WS-Inspection, (or other) method of advertising availability • Capable of many to many integrations that are enabled by a web service • Coarse grained • Large documents representing entire business events or business objects • Asynchronous • When appropriate (often for large scale work) After Adam Good, 2005

14. Complete Stack

15. Grid v’s Web Services • GRID • Grid computing: sharing heterogenous resources to solve massive computational problems (e.g. different platforms, hardware,software/languages) • Grid computing problems: clustering network, coordinated resource sharing, flexible access, security, high performance • Stateful • WEB • Another solution of middleware • Enabling technology (Internet protocols, xml) • Increase the interoperability • Toward business process management • Stateless

16. Web Services and Grid Services • Web Services advantages: • Best for complex stateless services • Business process management by BPEL • Standard workflow language • Extendable architecture (security, massaging, transport protocol)

17. GT1 GT2 OGSI Have been converging ? WSDL 2, WSDM WSDL, WS-* HTTP Grid and Web Services:convergence… Grid WSRF Web Source: http://www.globus.org/wsrf

18. W3C Web Services

19. Unraveling some acronyms… • SOAP • WSDL • UDDI

20. SOAP (simple object application protocol) • or Service Oriented Architecture Protocol • Exchange XML-based messages over a network • Foundation layer of the web services stack • INTEROPERABILITY!! • XML can be interpreted independent of the platform, OS, programming language • Legacy codes can be distributed through a common interface • Always automatically generated and interpreted by web service containers

21. WSDL describing service SOAP Message Exchange Consuming program Exposing program http transport SOAP messages Requesting service Service provider http transport Service discovery UDDI Service Registry

22. Anatomy of SOAP • Envelope - The root element in an XML encoded SOAP message. May contain: • recipient of the message, • content of the message and • the processing instructions • Encoding Rules - Specify the way the application defined data-type instances will be exchanged • Remote Procedure Call - representations that define a convention for representing the RPC calls and the responses to them

23. SOAP Package SOAP envelope SOAP header Header block Header data Header data Header data SOAP Body Body child element Body child element

24. Sample SOAP Envelope <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Åke Jógvan Øyvind</n:name> </n:passenger> </env:Header>

25. SOAP Transport Methods • Uses Internet application layer as a transport protocol • HTTP is the most widely adopted. • Others - SMTP, HTTPS etc.

26. SOAP Weaknesses • XML can be slow to parse/interpret • Using “application protocols” as transport protocols • Most uses of HTTP as a transport protocol are done in ignorance of how the operation would be modeled in HTTP. • e.g HTTP - GET and POST are inefficiently used • GET used when a post should be uses - vise versa

27. Web Service Deployment

28. WSDL • Web Service Definition Language • XML based language for describing Web Services • Answers the question: How do I communicate with a web service? • Used to generate code stubs. YAY! (Mat)

29. WSDL

30. Web Service Invocation

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

32. WSDL Specification Types message message message porttype operation operation operation binding service port

33. 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://schemas.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>

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

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

36. UDDI • Universal Description Discovery and Integration • Platform-independent, XML-based registry • A protocol for publishing and discovering metadata about Web Services over the internet • Enables applications to find web services, at design, or runtime

37. Additional Specifications • WS-Security • Defines how to use XML Encryption and XML Signature in SOAP to secure message exchanges, as an alternative or extension to using HTTPS to secure the channel. • WS-Reliability • Astandard protocol for reliable messaging between two Web services. • WS-ReliableMessaging • A protocol for reliable messaging between two Web services, issued by Microsoft, BEA and IBM • WS-Addressing • A way of describing the address of the recipient (and sender) of a message, inside the SOAP message itself.

38. WS-Security • Web Services Security • Communications protocol providing a means for applying security to web services • How integrity and confidentiality can be enforced • Kerberos, SAML, X.509 • Attaching signature and encryption headers to SOAP messages • HTTPS - Transport Layer Security

39. WS-Reliability • SOAP over HTTP does not guarantee any level of reliability and security. • Describes reliable delivery of messages between distributed applications • often connected by software /system / networks that are not fail-safe.

40. WS-ReliableMessaging

41. Alternative Approaches to Web Services • Noting that these are homogeneous systems: • CORBA • RMI

42. CORBA Comparison • 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 

43. 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  • 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

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

45. Thank you…

47. Sample SOAP Message (cont’d) <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> <p:departureDate>2001-12-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> <p:return> <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/> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body> </env:Envelope>

48. A Soap Response <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> • <env:Header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" 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> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true"> <n:name>Åke Jógvan Øyvind</n:name> </n:passenger> </env:Header> • <env:Body> • <p:itineraryClarification xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:departing> </p:departure> <p:return> <p:arriving> <p:airportChoices> JFK LGA EWR </p:airportChoices> </p:arriving> </p:return> </p:itineraryClarification> </env:Body> </env:Envelope>

49. Why are Web Services Useful for On Line Instruments

50. WS Architecture • The basic architecture includes Web services technologies capable of: • Exchanging messages • Describing Web services • Publishing and discovering Web service descriptions