1 / 51

Programming Database Web Applications

Programming Database Web Applications. Web Service Technologies Andreas Scholz. Course Logistics. The grade will be computed as follows: In-class presentation: 40% Programming project 40% Final exam: 20%

kamin
Download Presentation

Programming Database Web Applications

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. Programming Database Web Applications Web Service Technologies Andreas Scholz

  2. Course Logistics • The grade will be computed as follows: • In-class presentation: 40% • Programming project 40% • Final exam: 20% • Each team should make an appointment to meet with Dean and me during office hours and discuss • 1) the material for and outline of their presentation and • 2) the application they are planning to implement. (Look at http://www.programmableweb.com/mashups for inspiration) • The final exam will be a one hour meeting between for each team individually. The team will demonstrate their project and describe how it is implemented. We will ask each team to make certain small enhancements to their project and they will attempt to complete them within the hour.

  3. Service Oriented Architectures (SOA) • Architectural principle: loosely coupled services • Benefits for developers • High quality through specialization • High reusability • Low “artificial” dependencies (no legacy code) • High scalability • High extensibility • Short time-to-market through reuse

  4. Architectural Changes:From Monolithic Architectures … • One big application, possibly replicated on multiple servers • All components located at a single hosting center Clients Middleware Application Server DB DB

  5. WS WS WS WS … to Web Service Workflows • Components can be provided by external partners (fine-grained outsourcing, virtual corporations) • Components can be distributed about multiple servers/locations Clients DB DB Business Resources

  6. Service Oriented Architectures (SOA) • Benefits for companies (visions) • Companies do not need to host non core business services themselves, but buy these components from external companies (-> Salesforce, etc) • Eased integration with external partners through well-defined interfaces and workflows (e.g. automobile industry) • One single technology to connect all components • Higher competition for single components leads to better products (hopefully) • No lock-ins (nowadays migration is expensive)

  7. WS-* Technologies • Basic technologies (needed for simple, small-sized applications/mashups) • Description: WSDL • Transport: SOAP/REST • Addressing: WS-Addressing • Advanced technologies (needed for complex, business oriented applications) • Discovery: UDDI/WS-Discovery • Orchestration: BPEL • Security: WS-Security, WS-Policy, XACML, SAML • Quality of Service:

  8. Web services protocols

  9. SLA (QoS) WS- Security SAML Web Service Architecture (Web based SOA) Provider B UDDI-Registry WS-BPEL Search Services Web Service SOAP WSDL Provider A

  10. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A WSDLWeb Service Definition Language

  11. WSDL • Description language for Web service interfaces • XML-based notation • Machine and language independent • Can be automatically generated from existing code or used to produce code • http://bladekemper22.informatik.tu-muenchen.de:8080/axis2/services/Version?wsdl • http://soap.amazon.com/schemas2/AmazonWebServices.wsdl • https://www.google.com/api/adsense/v2/ReportService?wsdl

  12. WSDL Components • types • Data type definitions (machine and language independent) • messages • Define the data being transmitted (input- and output-parameter) • portTypes • Specify functionality (input-, output- and fault-messages) • bindings • Specify concrete (transmission-) protocols • services • Aggregate of ports (communication endpoints)

  13. SLA (QoS) WS- Security SAML SOAPSimple Object Access Protocol Provider B UDDI-Registry WS-BPEL Search Services Web Service SOAP WSDL Provider A

  14. SOAP • Generic transport protocol • XML-based (message = XML-document) • Stateless • Independent of Protocol • HTTP • Request via POST-Message (Content-Type: text/xml) • Response contained in Reply • SMTP • SOAP messages travel from initial to ultimatenodes via zero or more intermediate nodes

  15. Message Structure • SOAP-Envelope consists of • Header • Intermediate nodes can be addressed via roles • Intermediate nodes may alter header but not body • Allows high-level routing, logging, etc. • Body • (optional) fault-element with predefined structure • Application-specific content… • … with standardized syntax for RPC (various styles, see http://www-128.ibm.com/developerworks/webservices/ library/ws-whichwsdl/ for a brief overview)

  16. SOAP Body – RPC/Encoded • RPC/encoded: myMethod(int x, float y) <soap:body> <myMethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </myMethod></soap:body> • Benefits • Straightforward • Easy to dispatch • Drawbacks • Bloated because of types • Hard to validate because only x and y stem from a schema

  17. SOAP Body – RPC/Literal • RPC/literal: myMethod(int x, float y) <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod></soap:body> • Benefits • Straightforward • Easy to dispatch • Compact representation • Drawbacks • Still hard to validate

  18. SOAP Body – Document/Literal • WSDL now contains a types section with XML schema information <types><schema> <element name="xElement" type="xsd:int"/> <element name="yElement" type="xsd:float"/></schema></types> • SOAP message <soap:body> <xElement>5</xElement> <yElement>5.0</yElement></soap:body>

  19. SOAP Body – Document/Literal • Benefits • Compact • Can be validated (all components defined in XML Schema) • Drawbacks • No method name makes dispatching hard (possible solution: SOAP Action)

  20. Document/Literal Wrapped • WSDL <schema><element name="myMethod"> <complexType><sequence> <element name="x" type="xsd:int"/> <element name="y" type="xsd:float"/> </sequence></complexType></element></schema> • SOAP <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod></soap:body> Looks like RPC/Literal, but different semantics!

  21. Representational State Transfer (REST) • Architectural style for building web applications – not a standard • Philosophy (Roy Fielding): "Representation State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use." • Documentation • http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm • http://www.oio.de/public/xml/rest-webservices.htm

  22. REST • Properties • Stateless client/server communication • Uses HTTP operations GET,PUT,POST,DELETE • URIs used to address all resources • Navigation by selection of URIs (note: SOAP actions are defined by the content of the message, not the URI)

  23. REST Example <?xml version="1.0"?> <p:ShoppingCart xmlns:p= ...> <Item id="00345" xlink:href="http://www.sample.org/parts/00345"/> </p:ShoppingCart> <p:Item xmlns:p=... > <ID>00345</ID> <Name>Widget-A</Name> <Description>...</Description> <Specification xlink:href="http://www.sample.org/items/00345/specification"/> </p:Part>

  24. REST and Web Services • Axis2 already supports REST style Web services • URIs: http://server/axis2/rest/service/op?params • Examples • http://bladekemper22:8080/axis2/rest/Version/getVersion • http://bladekemper22:8080/axis2/services/helloworld?wsdl • http://bladekemper22:8080/axis2/rest/helloworld/concat?a=foo&b=bar

  25. WS-Addressing • Field of application • Dynamic generation and customization of service endpoint descriptions • Identification and description of specific service instances that are created as the result of stateful interactions • Correlation of SOAP messages (asynchronous call via different HTTP connections)

  26. Functionality Id of message, needed for ReplyTo or FaultTo • Set of new SOAP header elements <wsa:MessageID>...</wsa:MessageID><wsa:RelatesTo RelationshipType="..."?> ...</wsa:RelatesTo><wsa:To>...</wsa:To><wsa:Action>...</wsa:Action><wsa:From>endpoint-reference</wsa:From><wsa:ReplyTo>endpoint-reference</wsa:ReplyTo><wsa:FaultTo>endpoint-reference</wsa:FaultTo> • (Simplified) EndpointReference element <wsa:EndpointReference mlns:wsa="..."> <wsa:Address>http://...</wsa:Address> <wsa:PortType>...</wsa:PortType> </wsa:EndpointReference> Contains id of related message (used in reply) Target address and action Source EPR EPR for replies EPR for faults WSDL port

  27. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A WS-BPEL (=BPEL4WS)

  28. WS-BPEL • Business process model for Web services • Allows modeling of: • Sequences of peer-to-peer message exchanges (synchronous and asynchronous) • Long-running interactions involving two or more parties • Exceptional conditions and their consequences • Can be used • As a notation to describe processes and • To actually implement processes (BPEL4J)

  29. BPEL Challenges • Services are stateless, real world applications are not • Solution: correlationSets store service specific identifiers • No distributed transaction processing between services • Solution: compensation rules for committed (sub)transactions • Services can be deployed dynamically • Solution: Flexible binding methods • Static: design-time, deployment-time • Dynamic: with lookups, with passed-in endpoints

  30. BPEL Commands • Control flow • <receive>,<reply>: Communicate with other services • <invoke>: Call other Web service • <sequence>,<switch>,<while>: Internal control flow • Concurrent execution • <pick>: Wait for an event • <flow> (<link>): Concurrent execution (with synchronization) • Error handling • <throw>,<catch>: Internal error handling • <compensate>: Compensation rules

  31. BPEL Example

  32. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A UDDIUniversal Description Discovery & Integration

  33. UDDI Registry • An UDDI Registry provides • A meta-service for discovering Web services • Internationalized search (various encodings and languages) • Powerful search functionality for • Businesses, organizations and other providers, • The Web services they make available and • The technical interfaces of those services

  34. Registry Contents • White-Pages • Find services, businesses and providers • Get contact information • Yellow-Pages • Find services by taxonomy (location, business, etc) • Green-Pages • Find services by technical characteristics (used protocols, standards, data-formats, etc)

  35. UDDI - API • Inquiry API • Browse registry • Search (with approximate results and wildcards) • Publisher API • Create, modify and delete entries • Synchronize entries between multiple registries

  36. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A WS-Discovery

  37. WS-Discovery • XML based broadcast mechanism for services discovery • Support of proxies for better scaling • Search for services based on ldap, string comparison or URI

  38. (WS-Discovery http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf)

  39. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A QoS for Web Services

  40. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A QoS for Web Services

  41. Service Level Agreement (SLA) • Formal agreement between • Provider • Consumer • Defines: • Performance requirements • Availability • Metrics • Thresholds • Penalties

  42. Example SLA:Formal agreement Web Service Uptime • Web Service Uptime is the total time in a calendar month that a Web Service is available through the Internet, provided that the Client has established connectivity. Our guarantee is that our Web Services will be available to clients free of outages for 99.9% of each calendar month. SLA Network or Web Service Violation Credit • SLA Network or Web Service Violation Credit occurs when our network uptime guarantee or web service uptime guarantees are not met. We will refund the customer 5% of the monthly fee for each hour of downtime (up to 100% of your monthly fee) for network downtime. …

  43. WSLA • XML-based specification for SLAs • Developed by IBM Research • http://www.research.ibm.com/wsla/ • Not standardized yet • But standard will be based on WSLA

  44. Provider B UDDI-Registry SLA (QoS) WS- Security WS-BPEL SAML Search Services Web Service SOAP WSDL Provider A Web Services Security Standards

  45. Web Services Security Standards • WS-Security • Including security information in SOAP messages • SAML • Authentication and authorization • XACML • Authorization

  46. WS-Security • Web Services Security • Specifies, how security information has to be included in SOAP messages • Microsoft, IBM, Verisign  now OASIS • Succeeding specifications: • WS-Federation (federated identity management) • WS-Trust (trust negotiation, specifying security requirements of services …) • WS-SecureConversation (for establishing security context, thus, improving performance of long-running transactions) • …

  47. SAML • Security Assertion Markup Language • Liberty Alliance (SUN …) • XML-standard for exchanging security information • Basic concept: assertions (of credential possession, authorization etc.) • Useful for authentication and authorization

  48. XACML • eXtensible Access Control Markup Language • OASIS specification • Access control • Specification of policies • Formulating requests • Specifies policy enforcement and evaluation (of policies w.r.t. a request) • Supports • Positive/negative authorization • DAC = discretionary access control

  49. Standards … and further Research • Standards provide the basis for further research • Open issues: Security requirements that result from application integration processes demand for: • Analyzing/Verifying dependencies • Distributed authentication and authorization

  50. Architectural Changes:From Monolithic Architectures … • Centralized user management • Authorization through middleware Clients Middleware Application Server • Access via „super-user“-account DB DB

More Related