1. 1 Formal Modeling & Verification of Messaging Framework of Simple Object Access Protocol (SOAP) Manzur Ashraf Faculty,BRAC University

2. 2 Terms Modeling is the process of abstracting the functional specifications a minimal working specimen (to understand and analyze the system more closely.) Verification means process of examining this specification for the presence of various errors that could lead to improper system operation.

3. 3 W3C published SOAP 1.2 as a proposed recommendation [May 7, 2003] Part 0: Primer Part1: Messaging Framework The SOAP processing model defining the rules for processing a SOAP message. The SOAP Extensibility model The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes. The SOAP message construct part 2: Adjuncts part 3: Specification Assertions and Test collections.

4. 4 Five elements of specification Services SOAP is a lightweight protocol for exchange of structured and typed information between peers in a distributed environment using XML. This protocol is used for client-server architectural model.

5. 5 Assumptions about the Environment a) Message/Request is sent to an ultimate SOAP receiver via zero SOAP intermediaries.(normally 0 to many) b) Message corruption or disruption is handled in lower protocol-binding level. c) Transmission between adjacent nodes in the message path is handled by SOAP protocol binding framework. There is no such issues in Processing model. However, the transmission channel is assumed to message-losses.

6. 6 Protocol Vocabulary A required Envelope element that identifies the XML document as a SOAP message, an optional Header element that contains header information, a required Body element that contains call and response information and an optional Fault element that provides information about errors occurred while processing the message

7. 7 SOAP Fault Codes VersionMismatch ( Found an invalid namespace for the SOAP Envelope element ) MustUnderstand Client (The message was incorrectly formed or contained incorrect information ) Server ( There was a problem with the server so the message could not proceed )

8. 8 Message Format enum Boolean = {0,1}; enum Error { Version_mismatch, mustUnderstand, Client, Server}; struct soap_envelop { char *namespace=http://www.w3.org/2001/12/soap-envelope; char *encodingStyle=http://www.w3.org/2001/12/soap- encoding; struct soap_header{ /* Optional */ char *actor; enum Boolean mustUnderstand; char *encodingStyle=http://www.w3.org/2001/12/soap- encoding; }; struct body_element{ /* Optional */ struct Fault_element{ enum Error faultCode; char *faultString; char *faultAction; char *detail; }; unsigned char* data; char *name_spec_qualified;}; };

9. 9 A typical SOAP request-response example Request : DEF Response: 23

10. 10 Procedure Rules The SOAP processing model partly specifies how a SOAP receiver processes a SOAP message. It applies to a single message only, in isolation from any other SOAP message. It involves sending multiple SOAP messages in sequence, each subsequent message depending on the response to the previous message.

11. 11

12. 12 Related works Adam D. Bradley Azer Bestavros Assaf J. Kfoury (2002) Write Deadlock: C1.1 - S1.1 Resembles a DoS attack

13. 13 Proxy-2616-fixed handles this correctly

14. 14 but Problem: Imperfect knowledge beyond first hop

15. 15 Level of Abstraction used in our model We have partitioned SOAP processing model into two parts: Requester (e.g., Client) and Responder (e.g., Server). We have abstracted all the message types of SOAP- Envelope (request/response) into three major types of message types as request, response and SOAP processing error. The envelope from Requester is a message type request, the error-free response- envelope from responder is a message type response and faulty response-envelope from responder due to processing error in receiver side is a message type err.

16. 16 Correctness Checking of Safety comprises two things: (1) checking local process assertions and invariants (if any), and (2) checking proper termination points of progress (end state levels – if any). Validating liveness comprises (1) looking for acceptance cycles, (2) looking for non-progress cycles, (3) using never claims – which defines an observer process that executes synchronously with the system, and (4) trace assertions – to reason about valid or invalid sequences of send or receive statements.

17. 17 LTL claim It represents whenever a message is sent by the Responder, it will eventually accepted by the Requester. !([](p -> X(<>q))) Where p corresponds to to_rcvr?[request(1)] q corresponds to to_sndr?[response(1)] OR to_sndr?[err(1)].

18. 18 Simulation

19. 19 Verification in SuperTrace/ BitState mode

20. 20 observation From the verification results, hash factor is very large (>100). It means we are confident of sufficient coverage. All the validation runs confirms that the correctness requirement of the SOAP 1.2 Processing model is properly met. However, if all messages sent by the Responder are lost, an acceptance cycle will be detected, meaning that the never claim is matched.

21. 21 Conclusion & Future Work The verification of the complete web- service suite incorporating HTTP server, SOAP server, UDDI service and requester (client) is future objective. Comparative analysis of formal specification of SOAP using UML and constructed specification from model using SPIN is another direction for comprehensive assessment of SOAP.