Distributed Handler Architecture (DHArch)

Beytullah Yildizbyildiz@indiana.edu

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

Specification Standard by Implemented byWS-Reliability OASIS CGL

WS-Reliable Messaging Microsoft, IBM,… CGL, Apache

WS-Addressing Microsoft, IBM,… Apache

WS-Security OASIS Apache

WS-Eventing Microsoft, IBM,… CGL , Extreme Lab

WS-Notification OASIS Apache, Extreme Lab

WS-Resource Framework OASIS Apache

WS-Trust OASIS Extreme Lab

WS-SecureConversation OASIS Extreme 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

service6

Motivating Scenario

• Many handlers with possible substantial cost• The cost of the sequential handler execution where Tk is the kth 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 handlers11

12

Communication Manager

Handler Execution

Manager

NB

Client

Handler

Handler Execution

Manager

NB

Client

HandlerNB Broker

Handler Execution

Manager

NB

Client

Handler XML

Message

Handler

NBClient

Distributed Handler Manager

Handler XML

Message

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

<context> <id> 4099d6dc-0b0e-4aaa-95ff-2e758722a959 </id> <properties> <oneway>false</oneway> <mustPerform>true</mustPerform> </properties> <payload>

……… </payload></context>

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

3.

4.

5.

6.

22

Handler A CPU Bound

Handler B CPU Bound

Handler C IO Bound

Handler D IO Bound

Handler E CPU/IO

Handler Configurations 1. Apache Axis sequential2. DHArch Sequential

Stage 1 A, C

Stage 2 B,D

Stage 3 E

Stage 1 A, B

Stage 2 C,D

Stage 3 E

Stage 1 A,B,C,D

Stage 2 E

• 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 1 A,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 machineDHArch 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 = (Tdharch – Taxis) / N Where Tdharch is elapsed time in DHArch Taxis 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