distributed handler architecture (dharch) beytullah yildiz [email protected] advisor: prof....
TRANSCRIPT
Distributed Handler Architecture (DHArch)
Beytullah [email protected]
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