1. Lecture 19: Web Services ? CMSC 23300/33300 Computer Networks http://dsl.cs.uchicago.edu/Courses/CMSC33300

2. 2 Today’s Web l Web designed for application to human interactions l Served very well its purpose: u Information sharing: a distributed content library u Enabled B2C e-commerce u Non-automated B2B interactions l How did it happen? u Built on very few standards: HTTP + HTML u Shallow interaction model: very few assumptions made about computing platforms u Result: ubiquity

3. 3 What’s next? l The Web is everywhere. There is a lot more we can do! u E-marketplaces. u Open, automated B2B e-commerce. u Business process integration on the Web. u Resource sharing, distributed computing. l Current approach is ad-hoc on top of existing standards. u E.g., application-to-application interactions with HTML forms. l Goal: enable systematic application-to-application interaction on the Web

4. 4 Web Services “Web services” is an effort to build a distributed computing platform for the Web Yet another one!

5. 5 Designing Web Services l Goals u Enable universal interoperability u Widespread adoption, ubiquity: fast! u Enable (Internet scale) dynamic binding l Support a service oriented architecture (SOA) u Efficiently support both open (Web) and more constrained environments l Requirements u Based on standards. Pervasive support is critical u Minimal amount of required infrastructure is assumed l Only a minimal set of standards must be implemented u Very low level of application integration is expected l But may be increased in a flexible way u Focuses on messages and documents, not on APIs

6. 6 Web Services Model Web service applications are encapsulated, loosely coupled Web “components” that can bind dynamically to each other

7. 7 Service Oriented Architecture & Web Services SOA l Flexible u Locate services on any server u Relocate as necessary u Prospective clients find services using registries l Scalable u Add & remove services as demand varies l Replaceable u Update implementations without disruption to users l Fault-tolerant u On failure, clients query registry for alternate services SOA l Flexible u Locate services on any server u Relocate as necessary u Prospective clients find services using registries l Scalable u Add & remove services as demand varies l Replaceable u Update implementations without disruption to users l Fault-tolerant u On failure, clients query registry for alternate services Web Services l Interoperable u Growing number of industry standards l Strong industry support l Reduce time-to-value u Harness robust development tools for Web services u Decrease learning & implementation time l Embrace and extend u Leverage effort in developing and driving consensus on standards u Focus limited resources on augmenting & adding standards as needed Web Services l Interoperable u Growing number of industry standards l Strong industry support l Reduce time-to-value u Harness robust development tools for Web services u Decrease learning & implementation time l Embrace and extend u Leverage effort in developing and driving consensus on standards u Focus limited resources on augmenting & adding standards as needed

8. 8 Web Services Framework l Framework can be described in terms of u What goes “on the wire”: Formats and protocols u What describes what goes on the wire: Description languages u What allows us to find these descriptions: Discovery of services

9. 9 XML Messaging: SOAP l SOAP 1.1 defined: u An XML envelope for XML messaging, l Headers + body u An HTTP binding for SOAP messaging l SOAP is “transport independent”. u A convention for doing RPC u An XML serialization format for structured data l SOAP Attachments adds u How to carry and reference data attachments using in a MIME envelope and a SOAP envelope

10. 10 The SOAP Envelope <SOAP-ENV:Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">.........

11. 11 What Goes on the Wire l Internet-scale integration needs a lingua-franca u XML messaging protocol over HTTP: SOAP l Intra-enterprise integration needs to allow alternates: u CORBA, RMI u Messaging u In-memory method calls SOAP Security Attachments Reliability Routing Transactions Context W3C

12. 12 Descriptions: Metadata l Integration requires interoperable machine- understandable descriptions l Enables dynamic, delayed binding of components. l Language extensibility provides support for different levels of application integration. Interface Service QoS Service Public Flows Flows and Composition Agreements WSDL WSFL XML Schema

13. 13 Web Services Description Language l Provides functional description of network services: u IDL description u Protocol and deployment details u Platform independent description u Extensible language. l A short history: u WSDL v1.0, 9/2000 u WSDL v1.1 submitted to W3C 3/2001 u WSDL v2.0 candidate recommendation 3/2006 u A de facto industry standard

14. 14 WSDL Structure l portType u Abstract definition of a service (set of operations) l Multiple bindings per portType: u How to access it u SOAP, JMS, direct call l Ports u Where to access it Service Port (e.g. http://host/svc) Binding (e.g. SOAP) Abstract interface portType operation(s) inMesageoutMessage Port Binding

15. 15 Using WSDL l As extended IDL: WSDL allows tools to generate compatible client and server stubs u Tool support for top-down, bottom-up and “meet in the middle” development l Allows industries to define standardized service interfaces l Allows advertisement of service descriptions, enables dynamic discovery and binding of compatible services u Used in conjunction with UDDI registry l Provides a normalized description of heterogeneous applications

16. 16 Client Proxy object RMI- IIOP JMS/ MQ SOAP/ HTTP Client invocation l Single stub can invoke services over different bindings u Depends only on abstract interface. l Are independent of binding (but pluggable). u Add new bindings without recompiling/redeploying stub l Allows optimisations based on the bindings of service l Will support extended services models if described in WSDL

17. 17 Discovery: Finding Metadata l Static binding requires service “libraries” l Dynamic binding requires runtime discovery of meta-data Inspection Directory ADS, DISCO UDDI

18. 18 Service Discovery: UDDI l UDDI defines the operation of a service registry: u Data structures for registering l Businesses l Technical specifications: tModel is a keyed reference to a technical specification. l Service and service endpoints: referencing the supported tModels u SOAP Access API u Rules for the operation of a global registry l “private” UDDI nodes are likely to appear, though.

19. 19 UDDI Relationships Web Service SIC CODE NAICS DUNS Numbers Thomas Registry ID Rosetta-Net BASDA Simple.Buy Schemas, Interchange specification businessEntity businessService bindingTemplate InstanceDetails categoryBag keyedReference identifierBag keyedReference tModels

20. 20 Web Services Security Standards are slowly evolving (Jan ‘04) proposed SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-Authorization In progress promised WS-Federation

21. 21 Web Services Security Stands are slowly evolving (today) proposed SOAP Foundation WS-Security WS-Policy WS-TrustWS-PrivacyWS-SecureConversation WS-Authorization In progress promised WS-Federation SAML XACML Evolving

22. 22 GT4’s Use of Security Standards Supported, Supported, Fastest, but slow but insecure so default

23. 23 GT-XACML Integration l eXtensible Access Control Markup Language u OASIS standard, open source implementations l XACML: sophisticated policy language l Globus Toolkit ships with XACML runtime u Included in every client and server built on GT u Turned-on through configuration l … that can be called transparently from runtime and/or explicitly from application … l … and we use the XACML-”model” for our Authz Processing Framework

24. 24 GT Authorization Framework

25. 25 GT Authorization Framework VOMSShibbolethLDAP PERMIS … GT4 Client GT4 Server PDP Attributes Authorization Decision PIP

26. 26 Resource Management Infrastructure Web Services (WSDL, SOAP, WS-Security, WS-ReliableMessaging, …) WS-Resource Framework & WS-Notification* (Resource identity, lifetime, inspection, subscription, …) Data Access & Management Services (DAIS, RFT, DRS) Compute Access & Management Services (GRAM), etc. Applications of the framework (Compute, network, storage provisioning, job reservation & submission, data management, application service QoS, …) *WS-Transfer, WS-Enumeration, WS-Eventing, WS-Management define similar functions

27. 27 “Stateless” vs. “Stateful” Services l Without state, how does client: u Determine what happened (success/failure)? u Find out how many files completed? u Receive updates when interesting events arise? u Terminate a request? l Few useful services are truly “stateless”, but Web Services interfaces alone do not provide built-in support for state Client FileTransfer Service move (A to B) move

28. 28 File Transfer Service (without WS Resource Framework) l Developer reinvents wheel for each new service u Custom management and identification of state: transferID u Custom operations to inspect state synchronously (whatHappen) and asynchronously (tellMeWhen) u Custom lifetime operation (cancel) Client FileTransfer Service move (A to B) : transferID move state whatHappen tellMeWhen cancel

29. 29 WSRF in a Nutshell l Service l State representation u Resource u Resource Property l State identification u Endpoint Reference l State Interfaces u GetRP, QueryRPs, GetMultipleRPs, SetRP l Lifetime Interfaces u SetTerminationTime u ImmediateDestruction l Notification Interfaces u Subscribe u Notify l ServiceGroups RPs Resource Service GetRP GetMultRPs SetRP QueryRPs Subscribe SetTermTime Destroy EPR Modeling & Managing State in Distributed Sysems, Proceedings IEEE, 93(3), 2005

30. 30 FileTransferService (w/ WSRF) l Developer specifies custom method to createResource and leaves the rest to WSRF standards: u State exposed as Resource + Resource Properties and identified by Endpoint Reference (EPR) u State inspected by standard interfaces (GetRP, QueryRPs) u Lifetime management by standard interfaces (Destroy) Client FileTransferService createResource (A to B) : EPR createResource RPs Transfer getRP queryRPs destroy

31. 31 Data Transfer Comparison Control Data Control Data Control Data Control Data globus-url-copyRFT Service RFT Client SOAP Messages Notifications (Optional)

32. 32 GRAM services GT4 Java Container GRAM services Delegation RFT File Transfer request GridFTP Remote storage element(s) Local scheduler User job Compute element GridFTP sudo GRAM adapter FTP control Local job control Delegate FTP data Client Job functions Delegate Service host(s) and compute element(s) GT4 WS GRAM Architecture SEG Job events

33. 33 Business Process Execution Language Data Service @ uchicago.edu Workflow script: Fetch data from data service in Chicago Perform step 1 using service at Duke Perform step 2 using service at OSU Analytic service @ osu.edu Analytic service @ duke.edu Workflow Results

34. 34 Business Process Execution Language Data Service @ uchicago.edu <BPEL Workflow Doc> BPEL Engine Analytic service @ osu.edu Analytic service @ duke.edu <Workflow Results> <Workflow Inputs> l Each workflow is also a service u Enacted by BPEL Engine u Typically runs like a script (synchronous) u Other powerful models are possible link

35. 35 Basic BPEL Workflow Model Receive Inputs Assign args Send results Assign results Invoke Service Analytic Service

36. 36 BPEL Workflow Model – Parallelism (flows) Receive Inputs Assign results Assign args Invoke Service Assign args Invoke Service Assign args Invoke Service Send results Assign results Assign args Invoke Service Assign args Invoke Service Assign args Invoke Service Assign results Assign args Invoke Service Assign args Invoke Service Assign args Invoke Service

37. 37 Example from caBIG Cancer Institute Grid Data Service 10x interpolateremoveBGdenoisealignnormalize Duke interpolateremoveBGdenoisealignnormalize OSU plot Argonne iterate 5x 10x

38. 38 Workflow Document

39. 39 CQL Query Passed to Workflow <ns1:query xmlns:abpel-deser1="http://rproteomics.cagrid.nci.nih.gov/RPData" xmlns:ns1="http://rproteomics.cagrid.nci.nih.gov/RPData"> <query xmlns:ns5="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="scanFeatures_query2.xml"> <ns5:Target xmlns:ns6="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="edu.duke.cabig.scanFeatures.ScanFeatures"> <ns6:Objects xmlns:ns7="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="edu.duke.cabig.scanFeatures.Attributes"> <ns7:Property xmlns:ns9="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL“ name="project" predicate="equal" value="WorkflowDemo"/> <ns7:Property xmlns:ns8="http://CQL.caBIG/1/gov.nih.nci.cagrid.CQL" name="processingStep" predicate="equal" value="load"/>

40. 40 BPEL Workfow Document Excerpt <receive createInstance="yes" operation="startWorkFlow“ partnerLink="WorkFlowClientPartnerLinkType“ portType="ns2:startWorkFlowPortType“ variable="workFlowInputMessage" /> <from part="parameters" query="/ns1:WorkFlowInputType/query" variable="workFlowInputMessage" /> <invoke inputVariable="queryInputMessage" operation="query“ outputVariable="queryOutputMessage" partnerLink="RproteomicsDataLinkType" portType="ns1:RPDataPortType" /> <from expression="count(bpws:getVariableData('queryOutputMessage', 'parameters', '/ns1:queryResponse')/response/ns4:CQLQueryResult) div 2" />

41. 41 BPEL Document – Iterate over a service call <while condition="bpws:getVariableData('indexCounterDuke')... <invoke inputVariable= "denoise_waveletUDWTWByValueInputMessageDuke" operation="denoise_waveletUDWTWByValue" outputVariable= "denoise_waveletUDWTWByValueOutputMessageDuke" partnerLink="DukeRproteomicsPartnerLinkType“ portType="ns3:RProteomicsPortType" />...

42. 42 Specifications Landscape: April 2006 SYSTEMS MANAGEMENT UTILITY COMPUTING GRID COMPUTING Core Services Web Services Foundation WS-Addressing Privacy WS-BaseNotification CIM/JSIM WSRF-RAP WSDM WS-Security Naming OGSA-EMSOGSA Self Mgmt GFD-C.16 GGF-UR Data Model HTTP(S)/SOAP Discovery SAML/XACML WSDL WSRF-RL Trust WS-DAI VO Management Information Distributed query processing ASP Data Centre Use Cases & Applications CollaborationMulti MediaPersistent Archive Data Transport WSRF-RP X.509 StandardEvolvingGapHole

43. 43 Web Services Summary l Web Services are logically simple u Standard mechanisms for describing, discovering, and accessing services u Encourage loose coupling; service-oriented architecture l Web Services are complex in practice u Due to the wide variety of interactions that can occur l Broad adoption is encouraging. l For more information u Web Services Architecture: http://www.w3.org/TR/ws- arch/