Distributed Handler Architecture (DHArch) Beytullah Yildiz Advisor: Prof. Geoffrey C. Fox

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 2

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 3

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 4

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 5

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 6

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 7

Motivating Scenario I-A A typical handler execution scenario sequential execution The cost of the sequential handler execution : T logger + T monitor + T converter milliseconds 8

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

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

Distributed Handler Architecture (DHArch) 11

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. 12

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 13

14 Communication Manager

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 d6dc-0b0e-4aaa-95ff-2e758722a959 true ………

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. 16

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 17

Two-level Orchestration 18 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

20

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. 21

Benchmark I- Performance I Handler ACPU Bound Handler BCPU Bound Handler CIO Bound Handler DIO Bound Handler ECPU/IO 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 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 Stage 1A,B,C,D, E

Benchmark I- Performance II 23

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 24

Benchmark II-Overhead II 25 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

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 26

Benchmark III- Scalability II 27

Benchmark IV-WSRF and WS-Eventing I 28 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

Benchmark IV- II 29

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 30

Questions and Comments ? 31