Distributed Handler Architecture ( DHArch )

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

2. Web Service Handler I • 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

3. Web Service Handler II • Utilized in request and response path • Leveraged by client and service • Handler examples • Logging, monitoring, compression and so on • WS- specs i.e. WS-Security, WS-Reliable Messaging • From user point of view, one of two main computing components of Web Services

4. Motivations I • Web Services utilizing too many handlers • Fat services • A handler causing convoy effect • Bottleneck handler • Requirements for distributing handlers • Requirements for efficient and effective handler orchestration

5. Motivations II • Reusability • a handler utilized by many Web Services • a handler leveraged by both client and service • Modularity • improving modularity by clean separation of the tasks • Loosely coupling • decoupling handlers from Web Service Container by messaging

6. Research Issues I • Performance • the benefits and costs of distributing handlers • Scalability • throughput • the number of handlers for deployment • Flexibility and Extensibility • easily deployable and removable handler mechanism • interoperable with other SOAP processing engine • Orchestration • Efficient and effective handler orchestration

7. Research Issues II • Messaging for the distributed handlers • the way of distribution – task distribution • advantages and disadvantages • Parallelism for the handlers • advantages and disadvantages • Principles for distributing a handler • conditions and requirements • handler profile

8. Motivating Scenario I-A • A typical handler execution scenario • sequential execution • The cost of the sequential handler execution : Tlogger+ Tmonitor + Tconverter milliseconds

9. Motivating Scenario I-B The cost of the concurrent handler execution : MAX(Tlogger, Tmonitor, Tconverter) +Toverhead milliseconds

10. Motivating Scenario II • Having convoy effect • Processing Handler A in a faster machine removes the bottleneck.

11. Distributed Handler Architecture (DHArch)

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

13. Communication Manager • Manages internal messaging • Utilizes a MOM, NaradaBrokering • Publish/Subscribe paradigm • Queuing regulates message flow • Asynchronous messaging • Guaranteed message delivery • Fast and efficient delivery • Scales very well • Tree structure broker network • So many handlers can be distributed • Utilizes XML based messaging for the handlers

14. Communication Manager

15. Messaging Format • An XML document • Serialization of message context on the wire • Extensible • Consists of three main parts: • ID • 128 bit UUID generated key • Properties • Conveys the necessary properties to the handler • Payload • Carries relevant SOAP messages <context> <id> 4099d6dc-0b0e-4aaa-95ff-2e758722a959 </id> <properties> <oneway>true</oneway> </properties> <payload> ……… </payload> </context>

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

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

18. Two-level Orchestration • Separation of the flow directives and corresponding execution • Flow directives comprise four basic constructs, defined by Workflow Management Coalition (WfMC) : • sequential • parallel • looping • conditional • Engine manages two execution styles: • sequential • parallel

19. Orchestration Schema

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

22. Benchmark I- Performance I • The goal is to measure the performance of a single request. • Every measurement is repeated 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 • Apache Axis sequential • DHArch Sequential 3. 4. 5. 6.

23. Benchmark I- Performance II

24. Benchmark II- Overhead I • The goal is to measure the overhead related to the distribution of a single handler. • The same handler is utilized for Apache Axis and DHArch execution environment. • Handler parallelism is not utilized in order to calculate the pure overhead. • Overhead contains message transfer cost , handler orchestration management and creating and utilizing data structures • In every step, tests are repeated 100 times. • Environment • Sun Fire V880 operating Solaris 9 with 16 GB Memory, located in Indianapolis • Equipped with 8 UltraSPARC III processors operating at 1200 MHz

25. Benchmark II-Overhead II The formula : Overhead = (Tdharch – Taxis) / N Where Tdharch is elapsed time in DHArch Taxis is elapsed time in Axis N is the number of handlers

26. Benchmark III- Scalability I • The goal is to measure throughput • Three handlers are utilized. • Logger • Monitor • Format Converter • Execution is parallel in DHArch. • Execution is sequential in Apache Axis. • The system: • UltraSPARC T1 processor running on 900 MHz • Contains 8 cores with 4 threads per core • Running Solaris Operating System • 8GB physical memory

27. Benchmark III- Scalability II

28. Benchmark IV-WSRF and WS-Eventing I • The goal is to show the deployment of the well-known WS-specifications in DHArch. • WS-Specifications • WS-Eventing (CGL) • WS-Resource Framework (Apache) • A sensor stateful resource and relevant events are created. • 5 machines of 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

29. Benchmark IV- II

30. Contributions • A generic architecture for efficient , scalable, modular, transparent and interoperable distributed handler mechanism. • Introducing data structures and algorithms to the distributed handlers • Queuing to optimize the execution and to improve responsiveness • Unique context structure to provide dynamic handler execution • Caching to reduce the access time • Introducing unique orchestration structure to the handlers in order to have descriptive power as well as very efficient orchestration engine • Preliminary research for Distributed Web Service Container • Introducing concurrency to the handlers on container level as well as pipelining for the message execution • Providing an environment to utilize additional resources for handler execution

31. Questions and Comments ?