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

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

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

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

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, Extreme Lab WS-NotificationOASISApache, Extreme Lab WS-Resource FrameworkOASISApache WS-TrustOASISExtreme Lab WS-SecureConversationOASISExtreme Lab

Motivations Web Services utilizing 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

Motivating Scenario Many handlers with possible substantial cost The cost of the sequential handler execution where T k is the k th handler execution time A bottleneck handler 7

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

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 9

Distributed Handler Architecture (DHArch) 10

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

12 Communication Manager

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

Distributed Handler Architecture (DHArch) 14

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

Description and Execution of Orchestration 16 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

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 17

18

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

Summary of the Execution Separation of the description from the execution 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 is leveraged as well as handler parallism. The message execution can be prioritized. 20

Benchmarks The set of benchmarks Performance Scalability Overhead The deployment of well known WS- Specifications Utilized Handlers in these benchmarks Created for the benchmarking purposes Actual handlers 21

Benchmark I- Performance I Handler ACPU Bound Handler BCPU Bound Handler CIO Bound Handler DIO Bound Handler ECPU/IO Handler 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 handler (software) configurations are selected. Hardware configurations Single processor Multiprocessor Multicore Cluster utilizing LAN Stage 1A,B,C,D, E

Handler Configurations Axis Only Using by DHArch Benchmark I- Performance II 23

Benchmark II- Scalability I The goal is to measure the execution time while the message rate increases. A cluster utilizing multicore machines is leveraged 24

Benchmark II- Scalability II 25  Apache Axis utilizes single machine  DHArch utilizes multiple machines

Benchmark II- Scalability III 26 Without handler parallelism – DHArch increases the execution time because of the distribution overhead. – DHArch running on a cluster increases the throughput. With handler parallelism – We can achieve both increased message throughput and reduced execution time for per message. – Sequential and Parallel executions result in the same maximum message throughput.

Benchmark III- 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. Four hardware configurations are utilized. Multiprocessor results will be illustrated. 27

Benchmark III-Overhead II 28 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 IV-WSRF and WS-Eventing I 29 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. The sensor is motivated by CGL work on GPS sensors. A cluster using Local Area Network is utilized.

Benchmark IV- II 30

Contributions System research A distributed handler architecture Efficient, scalable, modular and transparent Concurrent handler execution Pipelining for the message execution Separation of the description and the execution for the handler orchestration Queuing to regulate flows Message based handler sequence Identifying the circumstances where this architecture has advantages Parallelism within the handlers Easy use multiple-machine clusters Comprehensive benchmarks to evaluate the handler distribution for Web Services System software A prototype: DHArch WS-Eventing and WSRF deployment 31

Future Works Using DHArch for the internal functions of Web Service Container: implicit handlers An agent that finds the best orchestration configuration for the distributed handler – dynamic load balancing Improving fault tolerance Security – NaradaBrokering Security Framework Comparison with the XSUL+DEN, another approach from Extreme Lab 32