Outline
•
Web Service handler concept
•
Motivations and research issues
•
Distributed Handler Architecture
(DHArch)
•
Measurements and Analysis
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
Web Service Handler II
• Conventional handler structures
– JAX-RPC
– Apache Axis
– Web Service Enhancement (WSE)
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 by
WS-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
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
Motivating Scenario
•
Many handlers with possible substantial cost
•
The cost of the sequential handler execution
where T
kis the k
thhandler execution time
•
A bottleneck handler
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
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
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
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
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.
Description and Execution of Orchestration
•
Separation of the flow
directives and corresponding
execution
•
The directives comprise four
basic constructs:
•
sequential
•
parallel
•
looping
•
conditional
•
Engine manages two
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
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.
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.
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
Benchmark I-
Performance
I
3.
4.
5.
Handler A CPU Bound
Handler
Configurations
Apache Axis sequential 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 •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
Handler Configurations Axis Only Using by DHArch
Benchmark I- Performance II
Benchmark II- Scalability I
•
The goal is to measure the execution time while the
message rate increases.
Benchmark II- Scalability II
25
qApache Axis utilizes single machine
Benchmark II- Scalability III
•
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.
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.
Benchmark III-Overhead II
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.
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
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
