1. Distributed Handler Architecture Beytullah Yildiz byildiz@indiana.edu

2. Web Service Handler Additive functionality to Web Services. Incrementally adds new capability to Web Service endpoint. Supports more modular architecture; separation of tasks. Processes SOAP header and body. Called as either handler or filter. Many handlers can get together to build a chain. 2

3. Motivations I Web Services become fat because of utilizing many handlers. A handler may cause a convoy effect. Requirements for distributing handlers. Requirements for efficient handler orchestration. 3

4. Motivations II Reusability – A handler may be utilized by many Web Services. Modularity – Clean separation of the tasks improves modularity. Loosely coupling – Messaging decouples the computing nodes, handlers and endpoints. 4

5. Research Issues I Scalability. – Adding new handlers should not degrade the system performance. Performance. – What are the benefits and costs of the distributed handler structure? Flexibility – A new handler should be easily deployed and removed. Orchestration of the Distributed Handlers. – Efficient and effective handler workflow structure 5

6. Research Issues II Messaging for the distributed handlers. – What are advantages and disadvantages ? Parallel execution of the handlers. – What are advantages and disadvantages ? Architectural principles for the distributed handlers. – Conditions for the distribution of a handler. 6

7. Motivating Scenario I-A A typical handler execution scenario is sequential execution. The cost of the sequential handler execution : T logger + T monitor + T converter millisecond 7

8. Motivating Scenario I-B 8 The cost of the concurrent handler execution : MAX(T logger, T monitor, T converter )+ T overhead millisecond

9. Motivating Scenario II A CPU bound handler, having convoy effect on the execution, is deployed to a faster machine. Handler A 9 gf103638 millisecond everest696 millisecond Difference2942 millisecond

10. Distributed Handler Architecture (DHArch) 10

11. Gateway An Interface between DHArch and A Web Service Container. Provides flexibility to deploy DHArch for different SOAP processing engines. Necessary to be written for each native system. 11

12. The advantages of using NB in DHArch Queuing regulates message flow. Provides guaranteed message delivery. Efficient. Scale vey well; tree structure. – Many handlers can be addressable. Asynchronous messaging. 12

13. Messaging Format XML document. Consists of three main parts: – ID UUID generated key. – Properties Carries the necessary properties to the handler. – Payload Carries the message. SOAP message. 13 123456789 true The message

14. Communication Manager 14

15. Highlights of the Execution DHArch utilizes two context objects: – Native container context – Distributed Handler Message Context Two level orchestration prevents the orchestration engine to become too complex. Queues are leveraged to regulate the message flow. Caching idea is utilized to expedite the message processing by decreasing the access time. The execution queue can be prioritized. 15

16. Distributed Handler Message Context Keeps necessary information about a message to carry out the execution. Every message has its own context. Flow structure is kept inside of the context. Basically, stores The message Orchestration structures Handler related parameters Stage related parameters. 16

17. Two level Orchestration 17 Separation of the flow description and the execution Four constructs in description level: Sequential Parallel Looping Conditional Engine utilizes only two execution types: – Sequential – Parallel

18. 18 Orchestration Schema

19. 19 Execution

20. Message Journey between two stages A message travels from stage to stage Stages has the ability to execute handlers in parallel manner. A message can not exit from a stage without completing the execution of its handlers Every stage contains at least one handler. Every flow execution contains at least one stage. 20

21. Test I- Performance I 4. 5. 6. 21 Handler ACPU Bound Handler BCPU Bound Handler CIO Bound Handler DCPU/IO Handler EIO Bound 1.Axis in-memory 2.Handlers are sequential in DHArch 3.Handler are parallel in DHArch Stage 1A, C Stage 2E Stage 3B,D Stage 1A, B Stage 2E Stage 3C,D Stage 1A,B,C,D Stage 2E Results are gathered in four environments: Multicore Multiprocessor Local Area Network Single processor Five handlers are utilized. Six configurations are created.

22. Test I- Performance II 22

23. Test I- Performance III 23

24. Test II- Scalability I Results are collected in four environments: Multicore Multiprocessor Local Area Network Single processor The elapsed time of the service is measured while the number of the handlers is increasing. The same handler is utilized. The handlers are running sequentially. Single broker is leveraged. 24

25. Test II- Scalability II 25

26. Test II- Scalability III 26

27. Test III-Cost I Results are collected in four environments: Multicore Multiprocessor Local Area Network Single processor We measured the overhead of adding a single handler. We executed the same number of handlers both in typical Axis handler mechanism and in DHArch. The formula is : – Difference = elapsed time in DHArch – elapsed time in regular Axis deployment – Overhead = Difference/ the number of handlers 27

28. Test III-Cost II 28

29. Test III-Cost III 29

30. Principles for distributing a handler Performance wise, a handler should provide enough contribution to be distributed. – T gain ≥ T overhead Some handlers cannot be separated from the Service Endpoint because of their nature. – i.e. Reliability Some handlers may not be efficiently distributed for every environment. – i.e. Security in WAN requires additional security. 30

31. Contributions A generic architecture for the efficient distributed handler execution. Leveraging queuing system for the handler distribution. Ability to utilize distributed resources for handler execution. Ability to update the handler chain during execution. Two level handler orchestration. Parallel handler execution. Detailed performance evaluation of Distributed Handler Architecture. 31

32. Questions and Comments ? 32