Your SlideShare is downloading. ×
  • Like
  • Save
Implementation and Performance Analysis of a UDP Binding for SOAP
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Implementation and Performance Analysis of a UDP Binding for SOAP



Published in Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Master Thesis Presentation Implementation and Performance Analysis of a UDP Binding for SOAP Fahad Aijaz [email_address] Supervised by: Prof. Dr. -Ing. B. Walke Dipl.-Ing. Guido Gehlen Chair of Communication Networks RWTH Aachen, Germany Wednesday, February 8, 2006
  • 2. Presentation Agenda
    • Motivation (“Why?“)
    • Proposed Solution (“What?“)
    • Simple Object Access Protocol (SOAP) & Middleware Architecture
    • Mapping to OSI Reference Model
    • Unreliable and Reliable UDP Binding
    • Mobile Web Service Server Architecture
    • Performance Analysis
    • Analytical Model
    • Theses
    • Summary & Outlook
    • End of Presentation
  • 3. 1: Motivation REASON: Since HTTP and TCP are not designed for a mobile environment
    • The congestion control, connection establishment (3-way handshake)
    • and slow-start phase of TCP effect high latencies in mobile
    • communication networks.
     In a mobile network, the latency of a SOAP RPC call is high. REASON: If SOAP is used by the application, the remote procedure calls (RPCs) will be transmitted in the majority of cases within the slow start phase of the TCP connection.
    • UDP is a mandatory requirement for the multicast/broadcast communication for applications related to Web Service Discovery.
    • One example is UPnP home networking and mobile services.
    • To provide a supliment for default HTTP binding in mobile network but
    • with better performance.
    • The use of XML Web Services over standard Internet protocols and mobile communication systems is veryinefficient.
    Reliable Unreliable
  • 4. 2: Proposed Solution  UDP Binding for SOAP should be developed which avoids the problems of TCP.
    • Since UDP is an unreliable protocol an additional
    • reliability protocol shall be implemented in the UDP SOAP
    • Binding.
    • Session management has to be specified and developed using the
    • SOAP specification and Web Service Addressing.
    • HTTP Server shall be extended with the additional functionality of UDP Server.
    • UDP client and server binding shall be developed.
    • Enable the invocation of mobile SOAP services via UDP.
  • 5. 3: Simple Object Access Protocol (SOAP)
    • The framework has been designed to be independent of any particular
    • programming model and other implementation specific semantics.
    • SOAP is intended for exchanging structured information in a decentralized, distributed environment.
    • SOAP uses XML technologies to define an extensible messaging
    • framework, which provides a message construct that can be exchanged
    • over a variety of underlying protocols.
    Default: HTTP Our Focus: UDP
  • 6. 4: Web Services Based Middleware Architecture Middleware Glue (IT World) Computing (Telco World) Communication WS-Discovery, WS-Addressing, WS-Security etc. Middleware to support developers Can be bound to either session or transport layer protocols (Transport Neutral)
  • 7. 5: Mapping to OSI Reference Model Transport Support for Mobile and Desktop Clients Algorithm Recommendation by SOAP-over-UDP Specification Based on the unique MessageId in SOAP Messages and WS-Addressing Selective Repeat (Explicit Request) ARQ is realized by introducing additional header in UDP datagram. 3 (N) 4 (T) 5 (S) 6 (P) 7 (A) HTTP TCP IP UDP SOAP HTTP-Binding Unreliable UDP-Binding Reliable UDP-Binding SOAP Session Management SOAP Session Management ARQ
  • 8. 6: SOAP Message Exchange Patterns (MEP) and Service Access Points (SAP) UDP SOAP UDP-SAP Reliable Binding Unreliable Binding WS-Sec. WS-Addr. SOAP Parser Rel. One-Way SAP Rel. Req-Resp SAP Unrel. One-Way SAP Unrel. Req-Resp SAP One-Way Req-Res SOAP MEPs  Core SOAP Parser providing 4 SAPs to upper layers, by using WS-Addressing properties
  • 9. 6.1: Unreliable UDP (One-Way Message Exchange Pattern) SOAP receiver SOAP sender UDP-DATA request UDP-DATA indication SOAP-MESSAGE request SOAP-MESSAGE indication SOAP UDP UDP SOAP UDP datagram
    • Possible Use Cases
    • Sending multicast “probe“ messages for discovery to a control point.
    • Service Announcement
  • 10. 6.2: Unreliable UDP (Request-Respose Message Exchange Pattern) SOAP receiver (server) SOAP sender (client) UDP-DATA request UDP-DATA indication SOAP-MESSAGE request SOAP-MESSAGE indication SOAP UDP UDP SOAP UDP datagram SOAP-MESSAGE response UDP-DATA request UDP-DATA indication SOAP-MESSAGE confirm UDP datagram Message correlation
    • Possible Use Cases
    • Event Transmission (e.g. State changes)
    • Context Information Exchange (eg. Status, mood, location)
    • Realtime Information Retrieval (e.g. Positioning data)
  • 11. 6.3: Reliable UDP (One-Way Message Exchange Pattern) Roles are swapped for request-response MEP 1 k N j i X 1 2 2 i j k N j Segment Buffer
    • Possible Use Cases
    • P2P Instant Messaging Services
    • Transportation Sector (e.g. Airlines, trains, buses)
    • Courier Services (e.g. Address changes)
    • As an alternative to HTTP
    Only one ACK/NACK is transmitted
  • 12. 7: Selective Repeat ARQ (Explicit Request)  Selective Repeat attempts to retransmit only those packets that are actually lost. Required due to packet size constraint.  Explicit NACK is sent for only lost packets.  Packet assembly is done at the receiver when all packets are received and buffered in correct sequence.  Segmentation is done by the sender in adjustable sized chunks of bytes. Seq. No. Flag S, C, E UUID UDP Headers SOAP Data Current Time [msec], IP-Addr. In HEX , Object hash code , Random Number
  • 13. 8: Mobile Web Service Server Architecture Server UI decoupled from the business logic. Common for both listeners.
  • 14. 9: Performance Analysis (Measurements) 9.1: RTT: Reliable UDP Vs HTTP Including HTTP/TCP Processing Overhead Major Selective Repeat latencies are discarded, since not comparable to low-level TCP ARQ Java performance, memory and bytecode loading time overhead exists Mean RTT of the Reliable UDP ≈ 20-25% of RTT of the HTTP (On laptop)
  • 15. 9.2: RTT: Unreliable UDP Vs Reliable UDP Extra time for NACK processing, additional headers ... No re-transmission in this case
  • 16. 9.3: Processing: Reliable UDP Vs HTTP
    • Request Handling
    • Duplicate Detection
    • XML Parsing
    • Response SOAP Headers
    • UUID Generation
  • 17. 10: Analytical Model of Selective Repeat ARQ over UDP P lost : Probability for loss of datagram n D : Number of datagrams to be send T D : Transmission time of a datagram T timeout : Timeout T NACK : Transmission time for NACK n lost : Number of lost datagrams n x : Number of datagrams except last one excluding the last one CASE: No datagram loss CASE: Last datagram lost CASE: n lost datagrams lost Mean Transmission Latency of sending SOAP over reliable UDP using selective-repeat ARQ
  • 18. 10.1: Comparison With HTTP Model Used Model Used Without Loss Probability With Loss Probability Model Used Model Used HTTP UDP Analytically the UDP performance ≈ 25% of the TCP Analytically the UDP performance ≈ 17% of the TCP
  • 19. 11: Theses  Web Service invocation over reliable UDP can be used as a substitute to the default SOAP/HTTP binding in mobile communication environment for better performance.  The reliable UDP with selective-repeat ARQ (explicit request) as a reliability mechanism is approximately 20-25% faster than the HTTP on average.  Unreliable UDP binding enables the sending of multicast probe messages in ad-hoc environments to consume and announce Mobile Web Services hosted by and to its peers respectively.  The analytical model can be used to calculate the mean transmission latency of the SOAP messages over UDP in mobile communication environment.  The analytical model has been validated against the measurements.
  • 20. 12: Summary & Outlook
    • Flow control shall be realized to avoid receiver overloading and network congestion.
    • Analytical model can be extended further for handling the cases of multiple retransmissions.
    • SOAP message compression at the Server can be integrated for smaller message sizes. J2ME compression libraries can be used.
    • In general, message encryption using WS-Security specification can be integrated within the middleware architecture to ensure secure message transmission. This has already been realized at ComNets.
    • Realization of reliable and unreliable UDP SOAP-Binding that conforms to the SOAP-over- UDP specification and in addition, enhances the recommendation.
    • Designing and implementation of two reliability mechanisms for SOAP message transmission, the back-Off algorithm and selective-repeat ARQ.
    • Realization of the duplicate detection mechanism.
    •  Implementation of the session management at the SOAP level, conforming the Web Service Addressing specification to support message correlation.
    •  Designing of two versions of transport module for sending and receiving SOAP messages using reliable or unreliable transmission mechanisms.
    • Performance evaluation of the UDP SOAP-Binding in comparison to the default HTTP binding.
    • Analytical model to calculate mean transmission latency of sendinf SOAP messages over UDP.
    Outlook Summary
  • 21. 13: End of Presentation
    • Thank you for your attention !
    • Questions?
    • Fahad Aijaz
    • [email_address]
  • 22. Selective Repeat ARQ State Machine