Web Service Handler Architecture Beytullah Yildiz

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

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

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

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

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

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