1 / 34

T HE US N ATIONAL V IRTUAL O BSERVATORY

T HE US N ATIONAL V IRTUAL O BSERVATORY. Building Web Services. Matthew J. Graham CACR/Caltech. Overview. WSDL Attachments Security State Asynchrony Message orientation. Design styles. Contract-last development Implement service java org.apache.axis.wsdl.Java2WSDL <interface>

farrah
Download Presentation

T HE US N ATIONAL V IRTUAL O BSERVATORY

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. THE US NATIONAL VIRTUAL OBSERVATORY Building Web Services Matthew J. Graham CACR/Caltech NVO Summer School 2006

  2. Overview • WSDL • Attachments • Security • State • Asynchrony • Message orientation NVO Summer School 2006

  3. Design styles • Contract-last development • Implement service • java org.apache.axis.wsdl.Java2WSDL <interface>  contract coupled to service implemenation’s interface • Contract-first development • Write XSD and WSDL • java org.apache.axis.wsdl.WSDL2Java -s <wsdl> • Fill in business logic NVO Summer School 2006

  4. 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) • Use WSDL 1.1 • http://www.xmethods.net NVO Summer School 2006

  5. Anatomy of a WSDL file <definitions> </definitions> <import>* - include other WSDLs <types> - define datatypes used in <message> <schema></schema>* </types> <message>* - model data exchanged <part></part>* </message> <porttype>* - describe interfaces supported for <operation>* an endpoint <input></input> - define input and output parameters <output></output> <fault></fault>* </operation> </porttype> <binding>* - formatting and representation of SOAP <operation>* message on the wire <input></input> <output></output> </operation> </binding> <service>* - identifies actual endpoint for WS <port></port>* </service> NVO Summer School 2006

  6. WSDL example • <definitions xmlns:http=http://schemas.xmlsoap.org/wsdl/http/ xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s=http://www.w3.org/2001/XMLSchema xmlns:s0=http://skyservice.pha.jhu.edu xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/ targetNamespace="http://skyservice.pha.jhu.edu" xmlns="http://schemas.xmlsoap.org/wsdl/"> • <types><s:schema elementFormDefault="qualified" targetNamespace="http://skyservice.pha.jhu.edu"> • <s:element name="ComovingLineOfSight">… • <s:element minOccurs="1" maxOccurs="1" name="z" type="s:float" /> • <s:element minOccurs="1" maxOccurs="1" name="hubble" type="s:float" /> • <s:element minOccurs="1" maxOccurs="1" name="omega" type="s:float" /> • <s:element minOccurs="1" maxOccurs="1" name="lambda" type="s:float" /> • …</s:element> • <s:element name="ComovingLineOfSightResponse”>… • <s:element minOccurs="1" maxOccurs="1" name="ComovingLineOfSightResult" type="s:float" /> • …</s:element> • </s:schema></types> • <message name="ComovingLineOfSightSoapIn"> • <part name="parameters" element="s0:ComovingLineOfSight" /> • </message> • <message name="ComovingLineOfSightSoapOut"> • <part name="parameters" element="s0:ComovingLineOfSightResponse" /> • </message> • <portType name="DistanceSoap"> • <operation name="ComovingLineOfSight"> • <documentation>Return the comoving line of sight distance...</documentation> • <input message="s0:ComovingLineOfSightSoapIn" /> • <output message="s0:ComovingLineOfSightSoapOut" /> • </operation> • </portType> • <service name="Distance"> • <port name="DistanceSoap" binding="s0:DistanceSoap"> • <soap:address location="http://voservices.net/Cosmology/ws_v1_0/Distance.asmx" /> • </port> • </service> • </definitions> NVO Summer School 2006

  7. What about the binding? <binding name="DistanceSoap" type="s0:DistanceSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="ComovingLineOfSight”> <soap:operation soapAction="http://skyservice.pha.jhu.edu/ComovingLineOfSight" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> NVO Summer School 2006

  8. 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 NVO Summer School 2006

  9. WSDL binding flavours (I) RPC Document • <message name=“Request”> • <part name=“x” type=“xs:int”/> • </message> • <message name=“empty”/> • <portType name=“foo”> • <operation name=“method”> • <input message=“Request”/> • <output message=“empty”/> • </operation> • </portType> • <types> • <schema> • <element name=“xElement” type=“xs:int”/> • </schema> • </types> • <message name=“Request”> • <part name=“x” element=“xElement”/> • </message> • <message name=“empty”/> • <portType name=“foo”> • <operation name=“method”> • <input message=“Request”/> • <output message=“empty”/> • </operation> • </portType> Literal • <message name=“Request”> • <part name=“x” type=“xs:int”/> • </message> • <message name=“empty”/> • <portType name=“foo”> • <operation name=“method”> • <input message=“Request”/> • <output message=“empty”/> • </operation> • </portType> Encoding NVO Summer School 2006

  10. WSDL binding flavours (II) RPC Document • <soap:envelope> • <soap:body> • <method> • <x>5</x> • </method> • </soap:body> • </soap:envelope> • <soap:envelope> • <soap:body> • <xElement>5</xElement> • </soap:body> • </soap:envelope> Literal • <soap:envelope> • <soap:body> • <method> • <x xsi:type=“xs:int”>5</x> • </method> • </soap:body> • </soap:envelope> Encoding NVO Summer School 2006

  11. WSDL binding flavours (III) Document/literal wrapped • <types> • <schema> • <element name=“method”> • <complexType> • <sequence> • <element name=“x” type=“xs:int”/> • </sequence> • </complexType> • </element> • </schema> • </types> • <message name=“Request”> • <part name=“parameters” element=“method”/> • </message> • <message name=“empty”/> • <portType name=“foo”> • <operation name=“method”> • <input message=“Request”/> • <output message=“empty”/> • </operation> • </portType • <soap:envelope> • <soap:body> • <method> • <x>5</x> • </method>> • </soap:body> • </soap:envelope> NVO Summer School 2006

  12. 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 • RPC’s natural tendency to expose programming language object structures  doc/literal wrapped (95%) NVO Summer School 2006

  13. Why not doc/literal wrapped? - I rpc/literal doc/literal doc/literal wrapped • <message name=“Request”> • <part name=“x” type=“xs:int”/> • </message> • <types> • <schema> • <element name=“xElement” • type=“xs:int”/> • </schema> • </types> • <message name=“Request”> • <part name=“x” element=“xElement”/> • </message> • <types> • <schema> • <element name=“method”> • <complexType> • <sequence> • <element name=“x” type=“xs:int”/> • </sequence> • </complexType> • </element> • </schema> • </types> • <message name=“Request”> • <part name=“parameters” • element=“method”/> • </message> • <portType name=“foo”> • <operation name=“method”> • <input message=“Request”/> • </operation> • </portType> • <soap:envelope> • <soap:body> • <method> • <x>5</x> • </method> • </soap:body> • </soap:envelope> • <soap:envelope> • <soap:body> • <xElement>5</xElement> • </soap:body> • </soap:envelope> • <soap:envelope> • <soap:body> • <method> • <x>5</x> • </method>> • </soap:body> • </soap:envelope> NVO Summer School 2006

  14. Why not doc/literal wrapped? - II • 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: <complexType name=“Node”> <sequence> <element name=“name” type=“string”/> <element name=“left” type=“Node”/> <element name=“right” type=“Node”/> </sequence> </complexType> RPC/encoding: <A> Literal: <A> <name>A</name> <name>A</name> <left href=“9999”/> <left> <right href=“9999”/> <name>B</name> </A> </left> <B id=“9999”> <right> <name>B</name> <name>B</name> </B> </right> </A> A Left Right B Left Right NVO Summer School 2006

  15. 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) • WS-I Testing Tools NVO Summer School 2006

  16. WS-* • WS-Semantics • WS-Topic • WS-Transaction • WS-Transaction Management • WS-Transfer • WS-Trust • ASAP • ebXML • MTOM • SAML • SOAP • SwA • UBL • UDDI • WSDL • XACML • XML Encryption • XML Signature • XKMS • WS-I Basic Profile • WS-I Basic Security Profile • WS-Manageability • WS-Management • WS-MetadataExchange • WS-Notification • WS-Policy • WS-PolicyAssertions • WS-PolicyAttachment • WS-PolicyFramework • WS-Polling • WS-Provisioning • WS-Reliability • WS-ReliableMessaging • WS-RemotePortals • WS-ResourceFramework • WS-ResourceLifetime • WS-ResourceProperties • WS-Routing • WS-SecureConversation • WS-Security • WS-SecurityPolicy • WS-Addressing • WS-AtomicTransaction • WS-Attachments • WS-BaseNotification • WS-BPEL • WS-BrokeredNotification • WS-BusinessActivity • WS-CAF • WS-Choreography • WS-CDL • WS-Context • WS-Coordination • WS-CoordinationFramework • WS-Discovery • WS-DistributedManagement • WS-Enumeration • WS-Eventing • WS-ExperienceLanguage • WS-Federation • WS-GAF • WS-Inspection • WSIL NVO Summer School 2006

  17. 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 NVO Summer School 2006

  18. 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-* NVO Summer School 2006

  19. 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) • Xfire (http://xfire.codehaus.org) • WSE 3.0 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwse/html/newwse3.asp) NVO Summer School 2006

  20. 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 NVO Summer School 2006

  21. WS-Security • OASIS standard (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 NVO Summer School 2006

  22. WSS Implementations • Java: • WSS4J (http://ws.apache.org/wss4j) used by Axis2/XFire • C#: • WSE 2.0 (http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx) • WSRF.Net (http://www.cs.virginia.edu/~gsw2c/wsrf.net.html) • Perl : • WSRF::Lite (http://www.sve.man.ac.uk/Research/AtoZ/ILCT) • Python: • pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/) NVO Summer School 2006

  23. 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) NVO Summer School 2006

  24. 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) NVO Summer School 2006

  25. WS-RF: the nuts and bolts • WSDL for a stateful service: <definitions> <import>* <types> <xs:schema> <xs:element name=“StatefulResourceProperties”>…</xs:element> <xs:schema> <types> <porttype wsdlpp:extends=“…” wsrp:ResourceProperties=“tns:StatefulResourceProperties”> • Implementations: • Java: GT4 (htttp://www.globus.org); Apache WSRF (http://ws.apache.org/wsrf) • .NET: WSRF.Net (http://www.cs.virginia.edu/~gsw2c/wsrf.net.html) • Python: pyGridWare (http://dsd.lbl.gov/gtg/projects/pyGridWare/) • Perl: WSRF::Lite (http://www.sve.man.ac.uk/Research/AtoZ/ILCT) NVO Summer School 2006

  26. 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) • Toolkits exist which facilitate asynchronous activities: • WS-RF (see above) • Axis2 (http://ws.apache.org/axis2) • JMS (http://java.sun.com/products/jms) / Caffeine (http://caffeine.berlios.de/site/) • WSIF (http://www.apache.org/wsif) NVO Summer School 2006

  27. Messaging operations • WSDL 1.1 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 NVO Summer School 2006

  28. Patterns for asynchrony (I) • Fire and Forget: • Request/response (Transport timeout) C S C S C S NVO Summer School 2006

  29. Patterns for asynchrony (II) • Polling: • Callback: C S C S NVO Summer School 2006

  30. 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 NVO Summer School 2006

  31. What’s wrong with WSDL (for SOAP)? • Focuses on interface abstraction to describe services (‘RPC mindset’) • Limited modelling of interaction patterns (no more than 2 message exchanges) • No choreographical information (x  y  z) • Difficult to describe infrastructure protocols that use SOAP headers • Technologies that use WSDL as a basis tend to be more verbose and complex than necessary NVO Summer School 2006

  32. 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) • Indigo: dual contracts are beyond WSDL NVO Summer School 2006

  33. SSDL • SOAP is the messaging vector over arbitrary transport (and transfer) protocols • WS-Addressing used for embedding addressing information within SOAP envelopes and binding those addresses onto underlying transport protocols • XML Infoset is the underlying component model • Use Xinclude for contract modularization • Promotes protocol framework extensibility NVO Summer School 2006

  34. SSDL structure • Schemas • XML Schemas • Messages • SOAP documents • Protocols (how messages relate to each other) • MEP (WSDL 2.0) • Communicating Sequential Processes • Rules (uses preconditions on send and receive events) • Sequential Constraints • Endpoints • WS-Addressing Endpoint Reference NVO Summer School 2006

More Related