Web Service Handler

bevyquixoticΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

74 εμφανίσεις

Web Service Handler
Architecture

Beytullah Yildiz

byildiz@indiana.edu

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

Service
S1
request and response
S2
S3
Client
C3
C2
C1
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
Handler
B
Handler
C
Handler
A
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
Handler
B
Handler
C
Handler
A
Client
Message
Message
Message
Handler
D
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
Handler
C
Handler
A
Client
Message
Message
Message
Handler
B
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

Message
Client
Message
Message
Handler
B
Service
Handler
D
Handler
C
Message
Message
Queuing
Handler
A
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