Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web Service Handler Architecture

706 views

Published on

  • Be the first to comment

  • Be the first to like this

Web Service Handler Architecture

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

×