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