Presentation is loading. Please wait.

Presentation is loading. Please wait.

Programming Database Web Applications

Similar presentations


Presentation on theme: "Programming Database Web Applications"— 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 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 …
Clients One big application, possibly replicated on multiple servers All components located at a single hosting center Middleware Application Server DB DB

5 … to Web Service Workflows
Clients Components can be provided by external partners (fine-grained outsourcing, virtual corporations) Components can be distributed about multiple servers/locations WS WS WS WS 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 Web Service Architecture (Web based SOA)
Provider B UDDI-Registry SLA (QoS) WS- Security SAML WS-BPEL Search Services Web Service SOAP WSDL Provider A

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

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 https://www.google.com/api/adsense/v2/ReportService?wsdl

12 WSDL Components types messages portTypes bindings services
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 SOAP Simple Object Access Protocol
Provider B UDDI-Registry SLA (QoS) WS- Security SAML 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 ultimate nodes via zero or more intermediate nodes

15 Message Structure SOAP-Envelope consists of Header Body
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 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

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 Axis2 already supports REST style Web services
REST and Web Services Axis2 already supports REST style Web services URIs: Examples

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 Set of new SOAP header elements
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 WS-BPEL (=BPEL4WS) Provider B UDDI-Registry Search Services WS-BPEL
SAML WSDL SOAP UDDI-Registry Provider A Provider B WS-BPEL Web Service Search Services WS- Security SLA (QoS)

28 Business process model for Web services Allows modeling of:
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 Concurrent execution Error handling
<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 UDDI Universal Description Discovery & Integration
SAML WSDL SOAP UDDI-Registry Provider A Provider B WS-BPEL Web Service Search Services WS- Security SLA (QoS)

33 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 Yellow-Pages Green-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 Publisher API Browse registry
Search (with approximate results and wildcards) Publisher API Create, modify and delete entries Synchronize entries between multiple registries

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

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

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

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

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 XML-based specification for SLAs Developed by IBM Research
WSLA XML-based specification for SLAs Developed by IBM Research Not standardized yet But standard will be based on WSLA

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

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
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 …
Clients Centralized user management Authorization through middleware Middleware Application Server Access via „super-user“-account DB DB

51 … to Web Service Workflows
Clients No central point of administration Dependencies of access control policies Distributed authorization WS WS WS WS Multi-level authorization Access via „super-user“ poses severe risks DB DB Business Resources


Download ppt "Programming Database Web Applications"

Similar presentations


Ads by Google