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
Web Service Handler II
• Utilized in request and response path
• Leveraged by client and service
• Handler examples
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
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
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
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
Motivating Scenario I-A
•A typical handler execution scenario
•sequential execution
•The cost of the sequential handler
execution : T
logger+ T
monitor+ T
converterMotivating Scenario I-B
•
The cost of the concurrent
handler execution :
Motivating Scenario II
•
Having
convoy effect
•
Processing
Handler A
in a faster machine
Gateway
• An Interface between DHArch and A Web Service Container
• Provides flexibility and extensibility
• Facilitates interoperation with other SOAP processing engines
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
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
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.
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
Two-level Orchestration
•
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
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.
Benchmark I-
Performance
I
3.
4.
5.
6.
Handler A CPU Bound
Handler B CPU Bound
Handler C IO Bound
Handler D IO Bound
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
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
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
Benchmark II-Overhead II
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
Benchmark
IV-WSRF and WS-Eventing I
• 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
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
