Presentation is loading. Please wait.

Presentation is loading. Please wait.

7/8 Sep 2005NVO Summer School 20051 Part I: Quick and Dirty T HE US N ATIONAL V IRTUAL O BSERVATORY Web Service Technologies Or How the Magic Happens.

Similar presentations


Presentation on theme: "7/8 Sep 2005NVO Summer School 20051 Part I: Quick and Dirty T HE US N ATIONAL V IRTUAL O BSERVATORY Web Service Technologies Or How the Magic Happens."— Presentation transcript:

1

2 7/8 Sep 2005NVO Summer School 20051 Part I: Quick and Dirty T HE US N ATIONAL V IRTUAL O BSERVATORY Web Service Technologies Or How the Magic Happens Matthew J. Graham CACR/Caltech

3 7/8 Sep 2005NVO Summer School 20052 Overview Web services and SOA RESTful services Rich clients SOAP and WSDL Attachments Security State Asynchrony

4 7/8 Sep 2005NVO Summer School 20053 Web services (oc)cult Invocations Strange languages Action at a distance High priesthood

5 7/8 Sep 2005NVO Summer School 20054 What is a web service? A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine- processable format. - W3C Not a new idea: RPC, RMI

6 7/8 Sep 2005NVO Summer School 20055 Service Oriented Architecture An application architecture within which all functions are defined as independent services with well-defined invocable interfaces which can be called in defined sequences to form scientific processes. Not a new idea: CORBA, ICE Principles: –Service reusability –Service contract –Service loose coupling –Service abstraction Virtual Observatory = Service Oriented Astronomy – Service composability – Service autonomy – Service statelessness – Service discoverability

7 7/8 Sep 2005NVO Summer School 20056 Hows it done in the real world? Things should be made as simple as possible, but no simpler - Albert Einstein A web service is just a machine-readable web app and a web app is just a dynamic web site WWW is the largest, most distributed and scalable application on the planet HTTP and HTML (XML)

8 7/8 Sep 2005NVO Summer School 20057 REST: The formal approach Architectural style not an implementation (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_s tyle.htm) Each resource has a URI Exchange resource representations (XML) Uniform CRUD API: HTTP protocolCRUD actionDescription POSTCREATECreate a new resource GETRETRIEVERetrieve a resource representation PUTUPDATEUpdate a resource DELETEDELETEDelete a resource

9 7/8 Sep 2005NVO Summer School 20058 Accidentally RESTful HTTP GET/POST + XML (POX/HTTP) Verbs allowed in URIs Requires little new infrastructure - just HTTP and XML processing technologies Simple clients, e.g. wget or xsltproc Commercially popular (85% of traffic, 6x faster): –Amazon (http://www.amazon.com/gp/aws/landing.html) –Yahoo (http://developer.yahoo.net)http://developer.yahoo.net –eBay (http://developer.ebay.com/rest) –Flickr (http://www.flickr.com/services/) –Del.icio.us (http://del.icio.us/doc/api)http://del.icio.us/doc/api

10 7/8 Sep 2005NVO Summer School 20059 What do RESTful services lack? Reliable messaging Digital signatures Message routing Resource life cycle management Asynchronous event notification

11 7/8 Sep 2005NVO Summer School 200510 Is this a problem? Security –transport level (HTTPS): point-to-point –fast and well supported State –sessions Asynchrony –easy to implement

12 7/8 Sep 2005NVO Summer School 200511 Client technologies: fat web pages XForms (http://www.w3.org/Markup)http://www.w3.org/Markup –MVC approach to web forms separates content (XML model/instance) from presentation (XSLT/XHTML) –Server-side implementation: Orbeon (http://www.orbeon.org) Chiba (http://chiba.sourceforge.net) –Client-side implementation: FormsPlayer (http://www.formsplayer.com) FormFaces (http://www.formfaces.com) Browsers (e.g. http://www.mozilla.org/projects/xforms)

13 7/8 Sep 2005NVO Summer School 200512 AJAX (Asynchronous Javascript + XML) Uses browsers XML support: DOM, XSLT XMLHttpRequest Google Maps, Google Suggest

14 7/8 Sep 2005NVO Summer School 200513 The bleeding edge AFLAX (Asynchronous Flash + XML): –http://www.xamlon.com/software/xamlonpr o/flash/aflax.aspxhttp://www.xamlon.com/software/xamlonpr o/flash/aflax.aspx –OpenLaszlo (http://openlaszlo.org)http://openlaszlo.org Mashups –On July 19, Google registered: googlesolarsystem.*, googlegalaxy.*, and googleuniverse.*,

15 7/8 Sep 2005NVO Summer School 200514 AJAX SOA

16 7/8 Sep 2005NVO Summer School 200515 Part II: Standards T HE US N ATIONAL V IRTUAL O BSERVATORY Web Service Technologies Or How the Magic Happens Matthew J. Graham CACR/Caltech

17 7/8 Sep 2005NVO Summer School 200516 Recap Client technologies: XForms, AJAX RESTful approach: –Distributed hypermedia model (WWW) is key architecture for loosely coupled distributed systems –Each URL is a representation of some object, e.g. http://us- vo.org/conesearch?POS=123,34&SR=0.5 –Manipulate representation with CRUD interface –Application understands that resource access method is semantically significant –Low REST vs. high REST

18 7/8 Sep 2005NVO Summer School 200517 What is SOAP? Originally meant Simple Object Access Protocol An XML-based communication protocol and encoding format for exchanging structured information in a decentralized, distributed environment W3C specification (http://www.w3.org/TR/soap)

19 7/8 Sep 2005NVO Summer School 200518 Anatomy of a SOAP message An envelope to encapsulate data which defines formatting conventions for describing the message contents and routing directions: header and body A message exchange pattern: request/response (RPC mechanism), fire-and-forget A transport or binding protocol Data encoding rules for describing the mapping of application-defined datatypes into an XML tag-based representation

20 7/8 Sep 2005NVO Summer School 200519 SOAP example Request: http://www.w3.org/2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema float float float float Response: float

21 7/8 Sep 2005NVO Summer School 200520 Why is SOAP better? Asynchrony Routing Reliable messaging (e.g. once-and-only delivery, guaranteed or exact execution) Send and receive complex datatypes to invoke a particular method not just key-value pairs Security Binds to other protocols Service description

22 7/8 Sep 2005NVO Summer School 200521 What is WSDL? Web Services Description Language An XML grammar for describing a web service as a collection of endpoints capable of exchanging messages in a particular fashion W3C specification (http://www.w3.org/TR/wsdl) http://www.xmethods.net

23 7/8 Sep 2005NVO Summer School 200522 Anatomy of a WSDL file *- model data exchanged * *- formatting and representation of SOAP *message on the wire *- identifies actual endpoint for WS * *- include other WSDLs - define datatypes used in * *- a subset of operation supported for *an endpoint - define input and output parameters *

24 7/8 Sep 2005NVO Summer School 200523 WSDL example http://schemas.xmlsoap.org/wsdl/http/http://www.w3.org/2001/XMLSchemahttp://skyservice.pha.jhu.eduhttp://schemas.xmlsoap.org/soap/encoding/ … … … Return the comoving line of sight distance...

25 7/8 Sep 2005NVO Summer School 200524 What about the binding?

26 7/8 Sep 2005NVO Summer School 200525 Binding attributes Style (representation on the wire) –rpc: the endpoint treats child elements in the body as XML representation of method call (SOAP 1.1, sec. 7) –document: the body can contain arbitrary XML Use (how data is serialized across the wire) –encoded: rules in a URL specified by encodingStyle attribute –literal: rules specified by XML schema

27 7/8 Sep 2005NVO Summer School 200526 WSDL binding flavours (I) RPC Document Literal Encoding

28 7/8 Sep 2005NVO Summer School 200527 WSDL binding flavours (II) 5 5 5 RPC Document Literal Encoding

29 7/8 Sep 2005NVO Summer School 200528 Document/literal wrapped

30 7/8 Sep 2005NVO Summer School 200529 Which flavour to use? Doc style can pass entire transaction as an XML document (state) Doc style not constrained by RPC-oriented encoding Doc style can be validated at call time Processing overhead in encoding payloads with RPC Doc style can use low memory parsers such as SAX and StAX RPCs natural tendency to expose programming language object structures doc/literal wrapped (95%)

31 7/8 Sep 2005NVO Summer School 200530 Why not doc/literal wrapped? Overloaded operations: public void myMethod (int x, float y); public void myMethod (int x); Number of parameters: public void someOtherMethod(int x, float y); Data graphs: RPC/encoding: Literal: A A B B B A Left Right B Left Right

32 7/8 Sep 2005NVO Summer School 200531 Client Invocation Models Static: use generated stubs (wsdl2*) Dynamic: –no generated code –a proxy dynamically generates a class at runtime that conforms to a particular interface, proxying all invocations to a single generic method –Examples: Java : use javax.xml.rpc.Service.getPort() and createCall().NET : use RealProxy class (must extend ContextBound) or Reflection.Emit Generic SOAP client: http://soapclient.com/soaptest.html

33 7/8 Sep 2005NVO Summer School 200532 Interoperability Suitable for and capable of being implemented in a neutral manner on multiple operating systems and in multiple programming languages Not all web services are interoperable! Web Services Interoperability Organisation (http://www.ws-i.org)http://www.ws-i.org WS-I Testing Tools

34 7/8 Sep 2005NVO Summer School 200533 Attachments: opaque data By value –XML representation or –use xs:hexBinary or xs:base64Binary within the body –data expansion by a factor of ~1.33 - 4 –anything within SOAP body gets parsed –processing costs of encoding/decoding By reference –attach pure binary data as external unparsed entity outside SOAP message –use reference URI within the body

35 7/8 Sep 2005NVO Summer School 200534 Reference solutions SwA (SOAP with Attachments) –Multipart MIME message: SOAP (0), data (1-n) –Use Content-Id as reference in body –Lack of length header on message sections –No recommendation just W3C Note DIME (Direct Internet Message Encapsulation) –Uses faster and more efficient binary encoding –No standard, disowned by Microsoft Both introduce a data structure outside realm of XML data model: no rules to specify how attachment content related to SOAP envelope so incompatible with WS-*

36 7/8 Sep 2005NVO Summer School 200535 MTOM Message Transmission Optimization Mechanism Uses MIME - backwards compatible with SwA Uses XOP:Include as reference mechanism (XOP = XML Binary Optimized Packaging) Conceptually binary data is base64-encoded in SOAP XML document compatible with WS-* Implementations: –Axis2 (http://ws.apache.org/axis2)http://ws.apache.org/axis2 –WSE 3.0 (http://msdn.microsoft.com/library/default.asp?url=/li brary/en-us/dnwse/html/newwse3.asp)

37 7/8 Sep 2005NVO Summer School 200536 Security Transport level (https) Message level: –End-to-end: allows for unlimited intermediaries –Data origin authentication –Different types of security tokens/credentials: unsigned (username/password) binary (X.509 certificate) XML (SAML token) –Multiple credentials

38 7/8 Sep 2005NVO Summer School 200537 WS-Security OASIS standard (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss)(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss)) Security token validation (authentication): –validate authentication assertions made by principals Message integrity (signing): –verify message origin –validate encryption keys –confirm security token claims Message confidentiality (encryption ) Introduces extra XML into SOAP header

39 7/8 Sep 2005NVO Summer School 200538 WSS Implementations Java: –WSS4J (http://ws.apache.org/wss4j) C#: –WSE 2.0 (http://msdn.microsoft.com/webservices/webservices/build ing/wse/default.aspx) –WSRF.Net ( http://www.cs.virginia.edu/~gsw2c/wsrf.net.html ) http://www.cs.virginia.edu/~gsw2c/wsrf.net.html Perl : –WS-Security will be supported by WSRF::Lite (but not yet) (http://www.sve.man.ac.uk/Research/AtoZ/ILCT) Python: –pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/ )http://dsd.lbl.gov/gtg/projects/pyGridWare/

40 7/8 Sep 2005NVO Summer School 200539 State Stateless is good: –In case of failure, just restart without concern of previous interactions (reliability) –New service instances can be created/destroyed in response to system load (scalability) How to handle state? –Separate web service and state information (resource) –Identify resource with a unique key –Use message exchanges with the service to interact with the resource (manipulate state)

41 7/8 Sep 2005NVO Summer School 200540 WS-Resource An entity composed of a web service and a stateful resource The address is called an endpoint reference (WS-Addressing) ACID: –Updates made in all-or-nothing fashion (atomicity) –Consistent state even after failure (consistency) –Updates isolated within a given work unit (isolation) –Permanence of updates (durability)

42 7/8 Sep 2005NVO Summer School 200541 WS-RF: the nuts and bolts WSDL for a stateful service: * … Implementations: –Java: GT4 (htttp://www.globus.org); Apache WSRF (http://ws.apache.org/wsrf)http://ws.apache.org/wsrf –.NET: WSRF.Net (http://www.cs.virginia.edu/~gsw2c/wsrf.net.html)http://www.cs.virginia.edu/~gsw2c/wsrf.net.html –Python: pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/)http://dsd.lbl.gov/gtg/projects/pyGridWare/ –Perl: WSRF::Lite (http://www.sve.man.ac.uk/Research/AtoZ/ILCT)

43 7/8 Sep 2005NVO Summer School 200542 Asynchrony Real world is asynchronous No current standards for asynchronous services but most promising is OASIS ASAP (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap)http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap Toolkits exist which facilitate asynchronous activities: –WS-RF (see above) –Axis2 (http://ws.apache.org/axis2)http://ws.apache.org/axis2 –JMS (http://java.sun.com/products/jms) /http://java.sun.com/products/jms Caffeine (http://caffeine.berlios.de/site/)http://caffeine.berlios.de/site/ –WSIF (http://www.apache.org/wsif)

44 7/8 Sep 2005NVO Summer School 200543 Messaging operations WSDL defines four types of messaging operation that an endpoint can support: –One-way: endpoint receives a message –Request/response: endpoint receives a message and sends a correlated message –Solicit/response: endpoint sends a message and receives a correlated message –Notification: endpoint sends a message One-way/two-way transport behaviour

45 7/8 Sep 2005NVO Summer School 200544 Patterns for asynchrony (I) Fire and Forget: Request/response (Transport timeout) CSCS CS

46 7/8 Sep 2005NVO Summer School 200545 Patterns for asynchrony (II) Polling: Callback: CS CS

47 7/8 Sep 2005NVO Summer School 200546 WS-Addressing No standard SOAP way to specify: –where a message is going –how to return a response –where to report an error WS-Addressing provides: –To –ReplyTo –FaultsTo –Anonymous –MessageId / RelatesTo –Standard for including service-specific attributes

48 7/8 Sep 2005NVO Summer School 200547 MEST (MESsage Transfer) Messaging: –No notion of client/server: just peers –Largely time independent: messages delivered when peer is available –Messages can be duplicated and delivered to multiple peers Messages and services are first class abstractions (no interfaces, data and operations) SSDL (http://www.ssdl.org)http://www.ssdl.org Indigo: dual contracts are beyond WSDL

49 7/8 Sep 2005NVO Summer School 200548 Conclusions Pick the right approach: do you need SOAP? Location of functionality: fat web pages Think about interactions: WSDL Use your favourite language and platform Interoperability is a great idea Be aware of emerging and converging technologies and new paradigms


Download ppt "7/8 Sep 2005NVO Summer School 20051 Part I: Quick and Dirty T HE US N ATIONAL V IRTUAL O BSERVATORY Web Service Technologies Or How the Magic Happens."

Similar presentations


Ads by Google