Web Services and Grid Services - PowerPoint PPT Presentation

web services and grid services n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Web Services and Grid Services PowerPoint Presentation
Download Presentation
Web Services and Grid Services

play fullscreen
1 / 47
Web Services and Grid Services
152 Views
Download Presentation
alika-tyler
Download Presentation

Web Services and Grid Services

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Web Services and Grid Services Mike Jackson – EPCC Some slides in this presentation are graciously provided by the OGSA-DAI Project

  2. Purpose • XML and Web Services • Grids • OGSA • OGSI

  3. XML and Web Services

  4. Web Services (1/2) • Network-enabled application • Exposes a well-defined interface • Often Stateless: • Born • Services Request • Dies • State maintenance dependant on service hosting environment • Accessible using common Internet protocols: • HTTP • XML-oriented technology: • Describe services and their interfaces: • WSDL – Web Services Description Language • Support messaging: • SOAP – Simple Object Access Protocol

  5. Web Services (2/2) SOAP Response SOAP Request WSDL Database Web Service Client Application Code Application Code

  6. XML • eXtensible Markup Language • Standard format for structured documents and data: • Supports exchange over heterogeneous platforms • Human-readable: • Less efficient than proprietary formats • Address the limitations of HTML: • Application-specific syntax and semantics

  7. An Example of XML <?xml version="1.0" encoding="ISO-8859-1"?> <!-- A list of attendees on some course --> <attendees> <attendee id=“123”> <name first-name=“Mike” last-name=“Jackson”/> <institution>EPCC</institution> </attendee> <attendee id=“456”> <name first-name=“Daragh” last-name=“Byrne”/> <institution>EPCC</institution> </attendee> </attendees>

  8. XML Namespaces (1/3) <film-types> <film-type>RomCom</film-type> <film-type>Spaghetti Western</film-type> </film-types> <film-types> <film-type>amphipathic</film-type> <film-type>hydrophobic</film-type> </film-types>

  9. XML Namespaces (2/3) • Telephone numbers: • Within Edinburgh University: 50-5141 • Within Edinburgh: 650-5141 • Within the UK: 0131-650-5141 • XML namespaces: <xmlns:bio=“http://bio.stuff/membrane” bio:film-types> • Namespace prefix: • Declaration: xmlns: • Maps to URI reference: bio • URI reference: • Global URI: “http://bio.stuff/membrane” • Local part: film-types • Qualified name: bio:film-types

  10. XML Namespaces (3/3) <xmlns:cinema=“http://world.cinema/flix” cinema:film-types> <cinema:film-type>RomCom</cinema:film-type> <cinema:film-type>Spaghetti Western</cinema:film-type> </cinema:film-types> <xmlns:bio=“http://bio.stuff/membrane” bio:film-types> <bio:film-type>amphipathic</bio:film-type> <bio:film-type>hydrophobic</bio:film-type> </bio:film-types>

  11. XML Schema • Specify the structure of XML documents: • Names of elements and attributes • Content of elements • Values of attributes • Namespaces of elements • XML Schema are XML documents • Facilitates validation of XML documents: • Check conformance of document to XML Schema: • Are elements nested legally? • Do elements have legal attributes? • Do attributes have legal values? • More information from: • http://www.w3.org/XML/Schema

  12. SOAP (1/2) • Simple Object Access Protocol: • a stateless, • one-way, • message exchange paradigm • Framework to convey application-specific information in an extensible manner • Specifies rules for: • SOAP envelopes – container for: • Header: originator and destination and application-specific information e.g. payment or authentication details about the SOAP message • Body: message data • Data encoding format • Conventions for message encoding: • Document-style • RPC-style

  13. SOAP Example (1/2) <soapenv:Envelope> <soapenv:Header> <wsse:Security soapenv:actor=“http://some.security.intermediary" soapenv:mustUnderstand=“1"> . . . </wsse:Security> </soapenv:Header> <soapenv:Body> <!–- An RPC call to a sayHelloWorld() operation --> <sayHelloWorld/> </soapenv:Body> </soapenv:Envelope>

  14. SOAP Example (2/2) <soapenv:Envelope> <soapenv:Header> <wsse:Security soapenv:actor=“http://some.security.intermediary" soapenv:mustUnderstand=“1"> . . . </wsse:Security> </soapenv:Header> <soapenv:Body> <sayHelloWorldResponse> <!–- The result of the sayHelloWorld() operation --> <helloMessage>Hello World!</helloMessage> </sayHelloWorldResponse> </soapenv:Body> </soapenv:Envelope>

  15. SOAP (2/2) • Silent on: • Semantics of any application-specific data it conveys • Routing of SOAP messages • Reliable data transfer • Firewall traversal • Can operate over various transports: • HTTP • FTP • SMTP • Fully describes the required actions to be taken by a SOAP node on receiving a SOAP message • More information from • http://www.w3.org/2000/xp/Group/

  16. WSDL (1/2) • Web Services Description Language – 1.1 • XML description of Web Services: • Define input and outputmessages • Define operations in terms of input and output messages • Aggregate operations into portTypes: • Application-specific collections of related operations. • Combine portTypes with a concrete network protocol and message format to form a binding: • How to communicate to a service’s portType. • Combine a binding and a network address to define a concretenetwork endpoint or port: • Where to find a service’s portType. • Aggregate ports into an abstract network endpoint or service

  17. WSDL (2/2) • WSDL is extensible: • Allows description of endpoints and their messages • Regardless of what message formats or network protocols are used to communicate • Typically used in conjunction with following protocols and message formats: • SOAP 1.1 • HTTP GET/POST • MIME • More information from: • http://www.w3.org/TR/wsdl

  18. WSDL Example (1/3) <?xml version="1.0" encoding="UTF-8"?> <definitions name="HelloWorld"> <types> <xsd:schema> <!-- For example <helloMessage>HelloWorld!</helloMessage> --> <xsd:complexType name="HelloMessageType"> <xsd:sequence> <xsd:element name="helloMessage“ type="xsd:string"/> </xsd:sequence> </xsd:complexType> <!-- For example <sayHelloWorld/> --> <xsd:element name="sayHelloWorld"> <xsd:complexType/> </xsd:element> <!-- For example <sayHelloWorldResponse> <helloMessage>HelloWorld!</helloMessage> </sayHelloWorldResponse/> --> <xsd:element name="sayHelloWorldResponse" type="HelloMessageType"/> </xsd:schema> </types>

  19. WSDL Example (2/3) <message name="HelloInputMessage"> <part name="parameters“ element="sayHelloWorld"/> </message> <message name="HelloOutputMessage"> <part name="parameters" element="sayHelloWorldResponse"/> </message> <portType name="HelloWorldPortType"> <operation name="sayHelloWorld"> <input message="HelloInputMessage"/> <output message="HelloOutputMessage"/> </operation> </portType>

  20. WSDL Example (3/3) <binding name="HelloWorldSOAPBinding" type="helloworld:HelloWorldPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHelloWorld"> <soap:operation soapAction="http://www.tutorial.org/myservices/helloworld#sayHelloWorld"/> <input><soap:body namespace="http://www.tutorial.org/myservices/helloworld" use="literal"/></input> <output><soap:body namespace="http://www.tutorial.org/myservices/helloworld" use="literal"/></output> </operation> </binding> </definitions>

  21. Web Services – Summary • XML: • eXtensible Markup Language • Namespaces • XML Schema • SOAP: • Simple Object Access Protocol • Stateless, one-way message exchange paradigm • WSDL: • Web Services Description Language • Abstract interface description • Concrete service location and communication information. • Web Services: • Stateless • XML-oriented technology

  22. Grids

  23. Motivating Grids • Difficult problems – “Grand Challenges” – require: • Collaboration • Sharing: • Ideas • Efforts • Resources – computational, data, storage • Emerging Open Grid Infrastructures will: • Support global collaboration • Change the way that we work

  24. What are Grids? • Grids are about dynamic Virtual Organisations (VOs) sharing data and computing resources • Virtual Organisations: “Dynamic groups of individuals, institutions, and resources, which have a well-defined set of sharing and Quality-of-Service (QoS) rules associated with them” P. Z. Kunszt, The Open Grid Services Architecture: A Summary and Evaluation, CERN, April 2002.

  25. Virtual Organisations • VOs include: • Resource users • Resource providers: • Including application, data and storage service providers • Resources include: • Data resources • Servers • Other programs • Resource Usage Policies: • Grid end-users can utilise resources according to: • The policies (rules) of the VO of which they are a member of • The policies of the resource providers • Dynamic VOs: • VOs should be able to change in scope and extension, transparently from the end users, or clients

  26. Examples of VOs • Scientific Collaborations: • e.g. Astronomers, Geneticists, Physicists, Medics: • Need to share and integrate data • Need to share computing power for data analysis • Engineering Collaborations: • e.g. Aircraft design and construction consortia: • Need to share computing power for simulations for design • Need to share and integrate analysis data and results • Business: • e.g. Business-to-Business (B-to-B): • Need to share and integrate data • Need to share computing power for e.g. data mining, market simulations

  27. Open Grids • Open Grids enable: • Coordinated and coherent collaboration • Resource sharing • Service component-based Grids enable heterogeneous environments to be integrated and reconciled to accomplish complex tasks • Service components support heterogeneity: • Interface- and message-passing-based • Hide platform and implementation

  28. OGSA

  29. What is OGSA? • Open Grid Services Architecture: • Open Grid Architecture + Web Services = Grid Services • Grid Services: • Dynamic • Transient • Stateful – have a finite lifetime • Defined by a well-defined set of interfaces and behaviours • More information from: • http://forge.gridforge.org

  30. OGSA Characteristics • Supports: • Resource access • Resources sharing • Service integration • Uniform access to services • Specifies protocols and standards that: • Are: • Implementation-independent • Platform-independent • Support: • Communication • Data access, transfer, translation and transformation • Access and security • Auditing and logging

  31. Best of Both Worlds Open Grid Services Architecture Share resource Manage resource Access resource Continuous Availability Resources on demand Applications on demand Global Accessibility Secure and universal access Business integration Vast resource scalability Grid Protocols Web Services

  32. OGSA Structure System Management Services Grid Services Open Grid Services Infrastructure Web Services

  33. OGSI

  34. What is OGSI? • Open Grid Services Infrastructure • Minimum set of standards and behaviours with which Grid Services must comply • Exploits existing Web Services properties: • Interface abstraction via WSDL portTypes • Web Service protocols • Hosting platform-independent • Extends these to provide for: • State management • Event notification • Service location and access • Lifecycle management • Service data • More information from: • http://forge.gridforge.org

  35. OGSI PortTypes (1/2) • GridService: • findServiceData • setServiceData • requestTerminationBefore • requestTerminationAfter • destroy • Factory: • createService • HandleResolver: • findByHandle • ServiceGroup • ServiceGroupRegistration: • add • remove

  36. OGSI PortTypes (2/2) • ServiceGroupEntry • NotificationSource: • subscribe • NotificationSubscription • NotificationSink: • deliverNotification

  37. Grid Service Identification • Grid Services are identified by means of a • Grid Service Handle (GSH), which is used to find the • Grid Service Reference (GSR) that is unique to an instance of a Grid Service. • A HandleResolver service is used to provide a GSR given a GSH • GSH: • Type of URI (or URL) • Constant for the lifetime of the Grid Service. • GSR: • Representation of the service interfaces: • Can be a WSDL document • Can change if the service evolves

  38. Anatomy of a Grid Service (1/4) GridService portType (required) Other PortTypes (Optional) • Service Data Access • Lifetime Management • Service Creation • Service Grouping • Notification • Handle Resolution • Other functions e.g: • Workflow • Auditing • Resource Management Grid Service Handle Hosting Environment

  39. Anatomy of a Grid Service (2/4) GridService portType (required) Other PortTypes (Optional) • Service Data Access • Lifetime Management • Service Creation • Service Grouping • Notification • Handle Resolution • Other functions e.g: • Workflow • Auditing • Resource Management ServiceDataSet Handle Hosting Environment

  40. Anatomy of a Grid Service (3/4) GridService portType (required) Other PortTypes (Optional) • Service Data Access • Lifetime Management • Service Creation • Service Grouping • Notification • Handle Resolution • Other functions e.g: • Workflow • Auditing • Resource Management Handle Hosting Environment Service Data Service Data Service Data

  41. Anatomy of a Grid Service (4/4) PortTypeImpl.cs PortTypeImpl.cs PortTypeImpl.cs PortTypeImpl.cs PortType PortType PortType PortType SDE SDE SDE SDE SDE SDE SDE SDE SDE SDE SDE SDE Service Data Service Data Service Data Service Data Grid Service

  42. WSDL and GWSDL • WSDL 1.1: • Lack of portType inheritance: • A portType cannot be defined in terms of an aggregation or extension of one or more other portTypes • Lack of an open content model: • Needed for specifying service data • GWSDL: • portType inheritance • Open content model • GWSDL => WSDL 1.1: • Flattening the inheritance hierarchy • The “most-derived” portType • WSDL 2.0: • Currently a draft standard • Replace GWSDL

  43. GWSDL and Flattening GridService setServiceData() findServiceData() requestTerminationBefore() requestTerminationAfter() destroy() MyService setServiceData() findServiceData() requestTerminationBefore() requestTerminationAfter() destroy() add() remove() myOperation() ServiceGroup ServiceGroupRegistration add() remove() MyService myOperation()

  44. OGSI Implementations • Microsoft .NET: • EPCC: MS.NETGridOGSI Release 1.2 • University of Virginia: OGSI.NET Release 2.1 • Java: • Globus: Globus Toolkit 3 Release 1.0 • Unicore • Perl: • University of Manchester: OGSI::Lite • Python: • Lawrence Berkley National Labs: pyGlobus

  45. WSRF • Web Services Resource Framework • Access and manipulate state via Web Services: • WS-Resource – a stateful resource • Replaces OGSI: • WS-Addressing for resource identification • WS Resource Framework rendered in terms of six new specifications: • WS-ResourceProperties • WS-ResourceLifetime • WS-Notification • WS-RenewableReferences • WS-ServiceGroup • WS-BaseFault • More information from: • http://www.globus.org/wsrf • Especially: “From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring”

  46. OGSI => WSRF • GWSDL => WSDL1.1 + portType flattening pending WSDL 2.0 • GSH => WS-Addressing Endpoint Reference + WS-RenewableReferences • GSR => WS-Addressing Endpoint Reference • Service data => Resource properties • GridService portType => WS-ResourceProperties + WS-ResourceLifetime • Factory portType => Factory pattern • ServiceGroup portTypes => WS-ServiceGroups • Notification portTypes => WS-Notification • HandleResolver portType => WS-RenewableReferences • Operation Faults => WS-BaseFault

  47. Grid Services – Summary • Grids: • Virtual Organisations • Sharing, access and management of distributed, heterogeneous resources • Open Grid Services Architecture: • Grid Services = Web Services + Open Grid Architecture • State + lifetime • Open Grid Services Infrastructure: • Building blocks of OGSA service • Service lifetime management, state access, registration, notification, creation, access • Service identification – GSH + GSR • Service description – GWSDL • Web Services Resource Framework