1. Distributed Handler Architecture (DHArch) Beytullah Yildiz byildiz@indiana.edu Advisor: Prof. Geoffrey C. Fox

2. Outline Web Service handler concept Motivations and research issues Distributed Handler Architecture (DHArch) Measurements Contributions and Future works 2

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

4. Web Service Handler II Conventional handler structures – JAX-RPC – Apache Axis – Web Service Enhancement (WSE) Utilized in request and response path Leveraged by client and service From user point of view, one of two main computing components of Web Services 4

5. Handler Examples Security, reliability, logging, monitoring, compression and so on Mediators; especially between WS-specs i.e WS-Reliability and WS-Reliable Messaging WS- specifications 5 SpecificationStandard byImplemented by WS-ReliabilityOASISCGL WS-Reliable MessagingMicrosoft, IBM,…CGL, Apache WS-AddressingMicrosoft, IBM,…Apache WS-SecurityOASISApache WS-EventingMicrosoft, IBM,…CGL WS-NotificationOASISApache WS-Resource FrameworkOASISApache

6. Motivations Web Services utilizing too many handlers – Fat services A handler causing Bottleneck – convoy effect Benefits for reusability – a handler utilized by many Web Services – a handler exploited by both client and service 6

7. Motivating Scenario Too many handlers The cost of the sequential handler execution : A bottleneck handler 7

8. Research Issues I Performance – the benefits and costs of distributing handlers Scalability – throughput – the number of handlers for deployment Parallelism – Handler parallelism – Pipelining for the messages Flexibility and Extensibility – interoperable with other SOAP processing engine – easily deployable and removable handler mechanism 8

9. Research Issues II Orchestration – Efficient and effective handler orchestration Messaging for the distributed handlers – the way of distribution – task distribution – advantages and disadvantages Principles for distributing a handler – conditions and requirements – handler profile 9

10. Distributed Handler Architecture (DHArch) 10

11. Communication Manager Manages internal messaging Utilizes a MOM, NaradaBrokering – Publish/Subscribe paradigm – Queuing regulates message flow – Asynchronous messaging – Guaranteed message delivery – Fast and efficient – Scales very well Utilizes XML based messaging for the handlers 11

12. 12 Communication Manager

13. Messaging Format Serialization of message context on the wire Extensible and flexible Consists of three main parts: – ID 128 bit UUID generated key – Properties Conveys the necessary properties to the handler – Payload Carries relevant SOAP messages 13 4099d6dc-0b0e-4aaa-95ff-2e758722a959 false true ………

14. Distributed Handler Architecture (DHArch) 14

15. Highlights of the Execution Two-level orchestration prevents the orchestration engine from becoming too complex. DHArch utilizes two context objects: – Interacting Web Service container context – Distributed Handler Message Context (DHMContext) Queues are leveraged to regulate the message flow. Caching expedites the message processing by decreasing the access time. Pipelining for the message execution is used. The execution can be prioritized. 15

16. Gateway Interface between DHArch and A Web Service Container Provides extensibility Facilitates interoperation with other SOAP processing engines A gateway needs to be deployed for SOAP processing engine that need to be interoperate with. 16

17. Two-level Orchestration 17 Separation of the flow directives and corresponding execution The directives comprise four basic constructs: sequential parallel looping conditional Engine manages two execution styles: – sequential – parallel

18. Distributed Handler Message Context Keeps necessary information about a message to carry out the execution A unique context associated with each message. The orchestration structure is maintained within the context. Encapsulates the message orchestration structures handler related parameters parameters associated with the stages 18

19. 19

20. Message traversal in the stages A message travels from stage to stage. Every handler orchestration contains at least one stage. Every stage contains at least one handler. Within a stage, handlers executed parallel. A message cannot exit a stage without completion of the execution of its constituent handlers. 20

21. Benchmark I- Performance I 3. 4. 5. 6. 21 Handler ACPU Bound Handler BCPU Bound Handler CIO Bound Handler DIO Bound Handler ECPU/IO Configurations 1.Apache Axis sequential 2.DHArch Sequential Stage 1A, C Stage 2B,D Stage 3E Stage 1A, B Stage 2C,D Stage 3E Stage 1A,B,C,D Stage 2E The goal is to measure the performance for a single request. Every measurement is observed 100 times. Five handlers are utilized. Six configurations are created. Machines Fedora Core release 1 (Yarrow) Intel(R) Xeon(TM) CPU running on 2.40GHz 2GB memory Located on Local Area Network Stage 1A,B,C,D, E

22. Benchmark I- Performance II 22

23. Benchmark II- Overhead I The goal is to measure the overhead related to the distribution of a single handler. In every step, measurements are observed 100 times. Environment Sun Fire V880 operating Solaris 9 with 16 GB Memory, Equipped with 8 UltraSPARC III processors operating at 1200 MHz Located in Indianapolis 23

24. Benchmark II-Overhead II 24 The formula : Overhead = (T dharch – T axis ) / N Where T dharch is elapsed time in DHArch T axis is elapsed time in Axis N is the number of handlers

25. Benchmark III- Scalability I The goal is to measure throughput and the execution time while the message rate increases. The system: 2 Quad-core Intel Xeon processors running at 2.33 GHz Operating Red Hat Enterprise Linux ES release 4 (Nahant Update 4) 8GB physical memory 25

26. Benchmark III- Scalability II 26  Apache Axis utilizes single machine  DHArch utilizes multiple machines

27. Benchmark IV-WSRF and WS-Eventing I 27 The goal is to show the deployment of the well-known WS-specifications in DHArch. – WS-Eventing (CGL) – WS-Resource Framework (Apache) A sensor stateful resource and relevant events are created. Gridfarm cluster are utilized: Fedora Core release 1 (Yarrow) Intel(R) Xeon(TM) CPU running on 2.40GHz 2GB memory Located on Local Area Network

28. Benchmark IV- II 28

29. Contributions System research A distributed handler architecture Efficient, scalable, modular and transparent Concurrent handler execution Pipelining for the message execution Two-level orchestration for the distributed handlers Queuing to regulate flows Message based handler sequence Comprehensive benchmarks to evaluate the handler distribution for Web Services System software A prototype: DHArch WS-Eventing and WSRF deployment 29

30. Future Works Distributed Web Service Container An agent that finds the best orchestration configuration for the distributed handler execution Utilizing the tools and applications to analyze the orchestration 30