1. 17 th FFV Workshop Fahad Aijaz - Research Engineer - Communication Networks RWTH Aachen University March 12, 2010 Protecting Multi-Interfaced Mobile Web Services using Agreements

3. Research Scope (Introduction) Web Server GENERAL CONCEPT OF TODAY’S WEB - Specialized functions - Internal process - Access interface RESOURCES WEB SERVICES - Private Data - Multimedia - Websites TRANSPARENT ACCESS  High-tech Web Servers.  Hosts Web Service and Resources.  Transparent Access to the Clients.  Neutral towards diverse clients. IP Access to Mobile Nodes P2P Mobile Web Services Mobile Web Server Mobile Web Services Mobile Web Server Mobile Web Services Web Service Broker Publish + Search Consume CONSUMER + PROVIDER CONSUMER + PROVIDER Publish + Search MOBILE WEB SERVER

4. Research Scope (Evolution of the Mobile Web Server Architecture) Service Deployment Architecture Asynchronous Services Synchronous Services SEVERAL PROTOCOL BINDINGS 2007 Asynchronous Communication Architecture Service Management Architecture 2006 2008 REST Messaging Framework SOAP Messaging Framework MOBILE APPLICATIONS Mobile Web Server Architecture 2009 MOBILE NODE NOT ONLY MOBILE PHONES!  Mobile Web Server Mobile Web Services  ASYNCHRONOUS SERVICE ACCESS PROTOCOL

6. Identify the network resources using URLs! FUNDAMENTAL PRINCIPLE Map the request action to HTTP Methods! RE presentational S tate T ransfer Static network resources Example: HTML, XML, JPG, GIF… Network resources Example: HTML, XML, JPG, GIF… Every resource changes the client’s state Resources are transferred using HTTP World Wide Web is RESTful ! Not a Standard… … but it uses standards! Architecture style… …analogous to Client-Server Multi-Interfaced Mobile Web Services (Service as a Resource  SaaR) http://comnets.rwth-aachen.de/fah.html Transfer Representation State

7. SYNCHRONOUS ACCESS ASYNCHRONOUS ACCESS Services as a Resource (SaaR) (Defining Synchronous & Asynchronous Access) SERVICE IDENTIFIES THE REQUESTED ACTION… … BY USING HTTP METHODS THE SERVICE DEVELOPER DEFINES… … WHICH METHOD MEANS WHAT ACTION HTTP : // : / / IP PORT SERVICE RESOURCE rest.comnets.de LocationService 9091 Coordinates HTTP : // : / / / / IP PORT SERVICE TYPE RESOURCE OPERATION rest.comnets.de aLocationService 9091 Asynchronous Factory CreateInstanceRq GET | POST | PUT | DELETE  FETCH  UPDATE  INSERT  REMOVE

8. Research Scope  Quick Recap (Evolution of the Mobile Web Server Architecture) Service Deployment Architecture Asynchronous Services Synchronous Services SEVERAL PROTOCOL BINDINGS 2007 Asynchronous Communication Architecture Service Management Architecture AGREEMENT PROTECTED SERVICES 2006 2008 REST Messaging Framework Service Level Agreements Framework SOAP Messaging Framework MOBILE APPLICATIONS Mobile Web Server Architecture 2009 MOBILE NODE NOT ONLY MOBILE PHONES!    WEB SERVICE AGREEMENTS Mobile Web Server Mobile Web Services  ASYNCHRONOUS SERVICE ACCESS PROTOCOL

9. Service Level Agreements (SLA) Framework (Phases and Life Cycles) Agreement Creation Agreement Evaluation QoS Monitoring Disposal Monitoring  The functions of the SLA architecture are classified into 4 distinct phases  The SLA phases executes 4 distinct life cycles based on the incoming mobile Web Service requests  The SLA negotiation is based on the Web Service Agreement standard of the Open Grid Forum  The standard is Optimized to define the SLA messaging for mobile nodes  The SLA framework is compatible with the REST and SOAP access interfaces INTERNAL PHASE LIFE CYCLES INTER-PHASE LIFE CYCLES  Based on the synchronous and asynchronous server architecture DIRECT PHASE ACCESS 4 PHASES OF THE SLA FRAMEWORK Service Level Agreements Framework Agreement Offer Life Cycle Template Acquisition Life Cycle Service Invocation Life Cycle Agreement Disposal Life Cycle

10. Agreement Creation Phase (Template Acquisition Life Cycle) A) TEMPLATE WITH VALIDITY B) MUST BE USED BEFORE EXPIRY C) AUTOMATED DELETION ( DISPOSAL MONITORING ) Mobile Web Server SERVICE FT FETCH TEMPLATE SYNCHRONOUS MOBILE WEB SERVICE DERIVED FROM THE WEB SERVICE AGREEMENT STANDARD MAY RESIDE IN THE CLOUD OR THE MOBILE NODE A) READS & MANIPULATES THE TEMPLATE B) GENERATES A UUID FOR THE CLIENT C) SAVES A COPY AGAINST THE UUID D) DISPATCHES THE TEMPLATE UUID + AGREEMENT TEMPLATE EXAMPLE REST REQUEST http://mobile.comnets.de/FetchTemplate SERVICE PROVIDER’S AGREEMENT TEMPLATE MOBILE WEB SERVICE CLIENTS FETCH TEMPLATE 1 AGREEMENT TEMPLATE 2

12. Agreement Evaluation and QoS Monitoring Phase (Service Invocation Life Cycle) Mobile Web Server A) EVALUATE REQUEST AGAINST THE ESTABLISHED AGREEMENT B) VERIFY INVOKE COUNT & INVOKE INTERVAL ( DEFAULT ) C) INVOKE/SCHEDULE SERVICE D) INITIATE QoS MONITORING ACTIVE PENDING Instantly effective Scheduled SERVICE AGREEMENT AGREEMENT STATES VERIFY UUID SERVICE A) SERVICE PROVIDER SPECIFIES THE QoS HANDLERS ( DEPLOYMENT ) B) READS THE SERVICE SETTINGS C) STARTS THE ASSOCIATED QoS HANDLERS D) HANDLERS MONITORS AND ACTS ON QoS VIOLATIONS THIRD-PARTY HANDLERS POSSIBLE MOBILE WEB SERVICE CLIENTS SERVICE INVOCATION + UUID 5 SERVICE RESPONSE 6 AGREEMENT ACCEPT/REJECT 4 Verification Evaluation IMMEDIATE INVOCATION SCHEDULED INVOCATION AGREEMENT EVALUATION PHASE COMPLETED  QoS MONITORING PHASE STARTED ! QoS Monitoring NOTIFICATION For asynchronous services only! QoS VIOLATIONS

13. Disposal Monitoring Phase (Agreement Disposal Life Cycle) Mobile Web Server VERIFY UUID SERVICE CLIENT – CONTROLLED AUTOMATIC DISPOSAL SPECIFIED BY THE SERVICE PROVIDER DURING THE SERVICE DEPLOYMENT Disposal Monitoring Client – controlled only! A) PERIODICAL CLEANUP CYCLES IN AUTOMATIC DISPOSAL B) LOOKS FOR EXPIRED AGREEMENTS & TEMPLATES C) END DATE OF AN AGREEMENT AND INVOKE COUNT IS MONITORED AS EXPIRATION CRITERIA D) DISPOSES TEMPLATES , AGREEMENTS & CLIENT RECORDS (UUID) E) ONE PROCESS FOR ALL AGREEMENTS FOR CLIENT – CONTROLLED ONLY SERVICE PROVIDER MAY SPECIFY THE CLEANUP INTERVAL FOR AUTOMATIC PROCESS TO AVOID QoS & AGREEMENT VIOLATION RISKS Client – controlled only! DEFAULT MOBILE WEB SERVICE CLIENTS AGREEMENT DISPOSAL + UUID 5 DISPOSAL RESPONSE 6 AGREEMENT TEMPLATE 2 Verification QoS Monitoring PRECONDITIONS CLIENT IS ALLOWED SERVICE NOT IN EXECUTION

14. Performance Evaluation - 1/3 ( SYNCHRONOUS  Mean Server Processing Latency) SOAP REQUEST REST REQUEST ~ 2 TIMES FASTER!

15. SOAP REQUEST REST REQUEST ~ 5 TIMES FASTER Performance Evaluation - 2/3 ( ASYNCHRONOUS  Mean Server Processing Latency)

16. 45 Performance Evaluation - 3/3 (Server Utilization Analysis) 200 ~90% < 45% REST Server SOAP Server > 400 Reqs./s possible! CAPACITY INCREASE  approx. > 8 TIMES <40 180 >90% < 90% REST Server SOAP Server > 180 Reqs./s possible! SYNCHRONOUS MOBILE WEB SERVER ASYNCHRONOUS MOBILE WEB SERVER CAPACITY INCREASE  ~ 5 TIMES REST SERVER

18. Thank you for your attention ! Questions are welcome! 5