Distributed Handler Architecture (DHArch)

Beytullah Yildizbyildiz@indiana.edu

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 : Tlogger+ Tmonitor + Tconverter 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

messages15

<context> <id> 4099d6dc-0b0e-4aaa-95ff-2e758722a959

</id> <properties> <oneway>true</oneway> </properties> <payload>

……… </payload></context>

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

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

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