Outline
•
Web Service handler concept
•
Motivations and research issues
•
Distributed Handler Architecture
(DHArch)
•
Measurements
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
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
Specification Standard by Implemented by
WS-Reliability OASIS CGL
WS-Reliable Messaging Microsoft, IBM,… CGL, Apache WS-Addressing Microsoft, IBM,… Apache
Motivations
•
Web Services utilizing too 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
•
Too many handlers
•
The cost of the sequential handler execution :
Research Issues I
•
Performance
– the benefits and costs of distributing handlers
•
Scalability
– throughput
– the number of handlers for deployment
•
Parallelism
– 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
Communication Manager
•
Manages internal messaging
•
Utilizes a MOM, NaradaBrokering
–
Publish/Subscribe paradigm
–
Queuing regulates message flow
–
Asynchronous messaging
–
Guaranteed message delivery
–
Fast and efficient
–
Scales very well
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
Highlights of the Execution
•
Two-level orchestration 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 for the message execution is used.
Gateway
•
Interface
between DHArch and A Web Service
Container
•
Provides
extensibility
•
Facilitates interoperation with other SOAP processing
engines
Two-level 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
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.
Benchmark I-
Performance
I
3.
4.
5.
Handler A CPU Bound
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 •The goal is to measure the performance
for a single request.
•Every measurement is observed 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
Benchmark II- 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.
• Environment
• Sun Fire V880 operating Solaris 9 with 16 GB Memory,
Benchmark II-Overhead II
Benchmark III- Scalability I
• The goal is to measure throughput and the execution time while the message rate increases.
• The system:
• 2 Quad-core Intel Xeon processors running at 2.33 GHz
• Operating Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Benchmark III- Scalability II
Benchmark
IV-WSRF and WS-Eventing I
• 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.
• Gridfarm cluster are utilized:
• Fedora Core release 1 (Yarrow)
• Intel(R) Xeon(TM) CPU running on 2.40GHz
• 2GB memory
Contributions
•
System research
• A distributed handler architecture
• Efficient, scalable, modular and transparent • Concurrent handler execution
• Pipelining for the message execution
• Two-level orchestration for the distributed handlers • Queuing to regulate flows
• Message based handler sequence
• Comprehensive benchmarks to evaluate the handler distribution for Web Services
