Web Service Handler
Architecture
Outline
l
Introduction
l
Background
l
Research
l Statement
l Motivation
l Architecture
l Issues
l
Milestones
Introduction
l
Web service is define by W3C as: “
A Web
service is a software application identified by
a URI, whose interfaces and bindings are
capable of being defined, described, and
discovered as XML artifacts.”
l
Handler is an incremental addition to Web
Service functionalities
l
A new approach to Web Service Handler
Distributed Systems
l
Creation of distributed systems has been
studied for a long time
l
Derived from the need for integrating
geographically distributed components
l
Service Oriented Architecture was proposed
for seamless and loosely coupled interactions
l
Previous Distributed System Technologies
l CORBA, DCOM
l
Web Services started after mid-2000
Web Services
l Client-Server Architecture l SOAP Messaging
l Transportation
l Mainly HTTP
l Others such as SMTP and FTP
l Service Oriented Architecture
l Reusable
l Services share a formal contract l Loosely coupled
l Services abstract underlying
capability
Web Service
Standardization
l Very important for integrationl China cart wheel distance and language standardization
l Around 60 specifications
l UDDI,SOAP,WSDL
l Addressing, ReliableMessaging, Reliability,
Security,Eventing,Notification,Context, WS-Resource Framework
l Many groups are involved
l Commercial Companies; Microsoft, IBM, Sun, SAP, BAE, TIBCO,
Systinet and etc
l Organizations; OASIS, GGF
l Some specifications are competing
Web Service Handler I
l Also known as “filter”
l Incremental addition of capabilities l Request or response chain
l Apache Axis, Web Service Enhancement
l An example for current handler framework: Apache Axis
l Sequential invocation
l Shared memory usage, not concurrent processing l Static deployment
l Communication via MessageContext object l Weak asynchronous messaging support
Web Service Handler II
l XSUL deploys a handler as a web service
l Distributed for getting better performance and scalability l Have a contract (WSDL) for each handler deployment l Need to address dynamic handler deployment
l addHandler(new handler());
l May need to have a mechanism such as message queuing
to cope with
l High volume input and output for each handler
l Synchronization of concurrent processing ; automatic
matching may be needed
l Reliability and security for every interaction between
Message Oriented Middleware
l Supports communication between distributed
system components by facilitating message exchange.
l Producer and consumer roles
l Supports loosely coupled communication
l Supports Publish/Subscribe and/or point to point
communication
l Supports asynchronous messaging l Supports reliable messaging
l Glues together stand-alone applications and
components
l Each application may evolve independently from the
Work flow
l Known as flow composition, orchestration and
choreography
l Very simple configuration file
l Several specification for Web Service work flow : WSFL,
WSBPEL, WS-Choreography
l Provides execution sequence of the functionalities l Automates integration
l Supports parallel processing l Supports optimization
Proposal Statement
l
Handler is very critical in a flexible and simple
Web Service architecture
l
A message-based handler approach
significantly
l improves
l modularity l Simplicity
l Quality of Services l by leveraging
Motivation I
l Simplicity
l Very important criteria in distributed systems l Having only one notion; messaging
l Making life easier for clients
l Interoperability
l “Integration has replaced security as the highest priority
in IT planning for 2004” Integration Standard Trends (IDC) report
l Improving interoperability by messaging
l Scalability
l Handling high volume of input and output messages l Coping with convoy effect of insufficient handler within
Motivation II
l Performance
l Reasonable response time
l Necessity of more resources
l CPU and Memory
l Availability
l Handlers are replicable
l Reusability
l Distributed handler can also be used l By many services
l By many clients
Message-based Handler I
l
More natural for Web Service Architecture
l
Modular
l
Can work as a local and distributed
component
l
A handler can be deployable in both Request
and Response path
l
Supports dynamic handler
Message-based Handler II
l
Supports four deployment types
l One virtual machine (process)
l Several virtual machines in one physical machine l Distributed over LAN
l Distributed over WAN
l
Hybrid approach may be utilized
l
Easy to use
l
Able to leverage proven systems
l Message Queue
Local Deployment
l Same CPU and Memory
space
l Supports synchronous
Request/response paradigm
l Communicate via messaging l Configuration file versus
Distribution of Handlers
l Either one or many physical machines l Utilize one-way asynchronous messaging
l Utilizes different resources, CPU and Memory
l Can be deployed either alone or together with other components l May result in additional cost because of
l Network latency l Flow Management
l The nature of the distributed deployment needs to be investigated:
Hybrid Approach
l Leverages both
l Handlers staying in same memory space with services l Message-based Handlers
l Decision is required about handler deployment
approach
Queue and Work Flow
l Message queue addition
l Supports high volume message and prevents message drops l Provides reliable communication between handlers
l Supports asynchronous communication between handlers l Copes with memory utilization problems
l Copes with synchronization related issues especially in case of
voluminous inputs and outputs
l Supports for different queuing type; priority, time and produce
ordering
l May support batching l May support flow control
l Work Flow
Research Issues I
l Quality of Services
l Performance
l Is performance reasonable when
§ we use messaging?
§ we distribute the handler? l Fault Tolerance
l Can message-base deployment tolerate the faults?
l Can mustUnderstand be utilized ? l Security
l Is overall system secure if we distribute handlers over
Research Issues II
l
Nature of Message
l How can a state be passed between handlers? l Metadata may be needed, WS-Context
l Is SOAP Data Model ?
l Is SOAP explicit communication media ?
l
Work Flow
Research issues III
l
Is handler appropriate for distribution?
l Nature of handler; Reliability, Security
l
Decision about possible handlers
lThree type of specifications
l Affecting only header: WS-Context l Affecting only body: WS-Trust
l Affecting both : ReliableMessaging,
WS-Reliability, WS-Eventing WS-Notification
l
Transformers
l Federation, Mediation
Milestones
l Selection of targeted handlers l Deployment for
l implemented
l WS-ReliableMesaging l WS-Reliability
l WS-Eventing l WS-Notification l Loggers
l others
l Testing
l Getting local deployment results l Getting distributed results.
References
l Service Oriented Architecture, Thomas Erl l Enterprise Service Bus, David A. Chappell
l Developing Java Web Services, Ramesh Nagappan,
Robert Skoczylas, Rima Patel Sriganesh
l Java Web Service Architecture, James McGovern,
Sameer Tyagi, Michael E. Stevens, Sunil Mathew
l http://www.naradabrokering.org/ l http://www.informit.com
