1 / 25

Web Service Handler Architecture

Web Service Handler Architecture. Beytullah Yildiz byildiz@indiana.edu. Outline. Introduction Background Research Statement Motivation Architecture Issues Milestones References. Introduction.

tadc
Télécharger la présentation

Web Service Handler Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Service Handler Architecture Beytullah Yildiz byildiz@indiana.edu

  2. Outline • Introduction • Background • Research • Statement • Motivation • Architecture • Issues • Milestones • References

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. Local Deployment • Same CPU and Memory space • Supports synchronous Request/response paradigm • Communicate via messaging • Configuration file versus work-flow mechanism

  17. 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

  18. 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

  19. 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

  20. Overall Architecture

  21. 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?

  22. 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

  23. 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

  24. 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

  25. 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

More Related