• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Web Service Handler Architecture
 

Web Service Handler Architecture

on

  • 726 views

 

Statistics

Views

Total Views
726
Views on SlideShare
724
Embed Views
2

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Modular Message-based Handlers Leveraging Message Oriented Middleware
  • Introduce web service and handlers and talk briefly about what I am going to do ? A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols.
  • SAO defines criteria to build distributed systems .SAO is an abstraction. Previously it was tried to be realized with other technologies such as Distributed Objects. SOA started to evolve almost 30 years ago Web service is very promising technology to realize soa
  • Reusable logic is divided into services Logic that potentially be reused is represented by separate services. There is no theoretical limit to scope of logic a service can represent. Services share a formal contract In order to services to interact, they need not share anything but a formal contract that defines the terms of information exchange and any supplemental service description information Services are loosely coupled This means that the server requester has no knowledge of the technical details of the providers implementation, such as programming language, deployment platform and so forth. Services abstract underlying logic The only part of the service that visible to the outside world is what is exposed via the service description. The nature and form of underlying logic is invisible and irrelevant to other services Services are composable Services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers. Services are autonomous The logic governed by a service resides within an explicit boundary. The service has complete autonomy within this boundary and is not dependent on other services for it to execute this governance. Services are stateless Services should not be required manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere. Services are discoverable Services should allow their descriptions to be discovered by and understood by humans and service requestors that may be able to make use of their logic.
  • OASIS web service security Argonne : WS-Topic Publish Subscribe Notification, WS-Base Notification Combining these two technology will provide very good environment to integrate systems
  • It has different names in different environment. It is called as a “handler” in axis while the name of it is “filter” Web Service Enhancement. Incremental addition to functionalities. Handlers are incremental editions to the web services. They are very helpful because they add new functionalities to the web services without resulting in any modification in web services. For example, security, reliability, logging. Most of the web services specifications are a good candidate for being handler. Shared memory Current architecture either in axis or wse is a shared memory architecture. They communicate passing MessageContext object from one handler to another. The MessageContext consists of soap message and properties which is shared states between handlers. Invoked in sequence to process messages Handlers are invoked in sequence. The process of handler is in reverse order of client in service part. Static The handler sequence is predefined. It can not be changed on the fly. It is set by wsdd file during the deployment Request or response chain Several handlers can come together to build chains and it can be either request path or response path. A Chain also has similarities to the Chain of Responsibility design pattern in which a request flows along a sequence of Handlers until it is processed. Although an Axis Chain may process a request in stages over a succession of Handlers, it has the same advantages as Chain of Responsibility: flexibility and the ease with which new function can be added. Back to message processing -- a message is processed by passing through the appropriate Chains. A message context is used to pass the message and associated environment through the sequence of Handlers. The model is that Axis Chains are constructed offline by having Handlers added to them one at a time. Then they are turned online and message contexts start to flow through the Chains. Multiple message contexts may flow through a single Chain concurrently. Handlers are never added to a Chain once it goes online. If a Handler needs to be added or removed, the Chain must be 'cloned', the modifications made to the clone, and then the clone made online and the old Chain retired when it is no longer in use. Message contexts that were using the old Chain continue to use it until they are finished. This means that Chains do not need to cope with the addition and removal of Handlers while the Chains are processing message contexts -- an important simplification.
  • Mainly XSUL is build to solve performance and scalability problem caused by a bottleneck handler. Our approach is base on providing a flexible and simple handler framework which not only looks at performance and scalability. It provides architecture which takes handler from shared memory to distributed memory while shared memory approach is also utilized in some situations. Since we are going to use naradabrokering as a queuing mechanism, we do not have to have a contract. The handler can run as a intermediary which looks at the header does it jobs and returns the soap naradabrokering. Handlers can be updated without interrupting the other handlers and end point because they are decoupled by naradabrokering. In XSUL each handler has to have a contract with other handlers. I believe an itinerary routing need to be utilized for interaction among the handler. In dynamic handler invocation, the situation worsen. Lets say, we have H1,H2 and H3 distributed on the system. We will use H1 and H2 for one message and H1 and H3 for another message. H1 has to know both how to access H2 and H3. In our case, naradabrokering in the middle will cope with this problem either they deployed as a web service or an intermediary. Each handler does not need to know how to contact with the other handlers. Therefore, we can add or remove a handler on the fly and this provides dynamic handler invocation. In the middle naradabrokering provides a communication environment with its helpful fanctionalities. Since we distribute handlers, the interaction between them needs reliability in order to be sure that targeted handler get the message. Among distributed handlers, security may be needed and this can be provided by naradabrokering, MOM.
  • Messaging applications use a messaging client API to communicate with each other through a messaging system. When an application is communicating in this fashion, it is acting as either a producer or a consumer. Producers and consumers are loosely coupled in that they are not directly tied to each other; instead, they are abstractly connected to each other through virtual channels called publish and subscribe channels or point to point channels. Producer does not need to know which applications are receiving a message, or in some cases even how many are receiving it. Likewise the consumer does not need to know which applications are sending the data. It only knows that it receives a message and act upon it In the publish/subscriber model, multiple consumers may register an interest with, or subscribe to, a topic. A producer sends a message on that channel by publishing on that topic. Each subscriber receives a copy of that message. In the point-to-point model, only one consumer may receive a message that is sent to a queue. P2p may queue may have multiple consumers listening for the purpose of load balancing or “hot backup” however only one receiver may consume each individual message. Industry efforts are underway to standardize hierarchical topic trees using XML syntax in the WS-Notification family of specifications. Communication : communication is achieved by using network protocols, which are classified by ISO/OSI reference model. Coordination : The advantage of MOM supports asynchronous communication naturally. another strength is to support group communication by distributing same message to multiple receive. Reliability : implements message queues that stores messages on persistent storage. Scalability : Does not support access transparency very well, This disables migration and replication transparency. Thus, it complicates scalability Access transparency demands the way a component access the services of another component is independent of whether it is local or remote. Heterogeneity However, XML base messaging and SOAP are big improvements in the data heterogeneity. Does not support data heterogeneity very well, requires marshalling. Strongly coupled complexity is n^2
  • WSBPEL:Web Services Business Process Execution Language a composition is created by describing how to use the functionality provided by the collection of composed Web Services. Work Flow models these compositions as specifications of the execution sequence of the functionality provided by the composed Web Services. Execution orders are specified by defining the flow of control and data between In our code example, the activities cannot be performed in any order, but there is a sequencing constraint between them: the processing of the purchase order by the supplier must precede the acceptance of the shipping request by the shipper; the money can be received at any time. Parallel processing.Two or more tasks are performed concurrently Automatic matching is to manage whether work flow will wait suspended or delayed results. Work manager is a centralized task giver.
  • Handlers are very critical in a flexible web service architecture How to flexibly and simply implement handler. First leverage queuing system.
  • What is the scalability in distributed systems General concepts Simplicity: The reason of HTTP and email success. They are very simple and user friendly. Scalability: scalability is another important requirements of distributed systems. A simplistic view of distributed systems could identify two types of entities; clients and service. In this naïve universe, there is little need for distributed computing infrastructure. Alas, you can not use this model to build highly scalable distributed systems. Current handler architecture may not answer high load request. Performance always important issue in a computer program. It can be done either better hardware or improving architecture. Acceptable performance required. Need acceptable response time. Customer buy an item online. In order to pay, credit card approval required if this service can not be provided on time. Reusability : We would not want to create a new software for every simple task. Since handlers will be deployed as a web services. It will be easier to use them with many different services.
  • Client wants to use service readily.( Security, reliability) As I said earlier simplicity is the key requirement. We can not expect that every user knows how to implement specifications which is required to access web services. Such as; Reliability. The problem is getting worse if the client programming language is not supported one. Such as perl. Dynamic handler invocation. We may need dynamic handler invocation. A handler should be added or removed to the chain on the fly. For example, we may want to process a digitally signed message by selecting the handler from the handler pool. Scaling up to handle increased message volume. A service should answer a high message volume. Handlers should not be a bottleneck in the chain. Slowness of one handler can cause total system performance degradation. Necessity of More resources CPU and Memory. Some handler are very power hungry. Such as, XML Transformers. If you dealt with the XSLT transformation, you should realize that it requires very important CPU power and memory space. Reusability Handlers can and should be able to use several services and clients. In current architecture, this is not possible. Each service client pair has one handler which belongs to them. Client without implementing for example security or reliability handler. It can connect to the handler which is already deployed on the network Simpler Architecture : The system can work even multiple core systems which will be very popular. For being successful software architecture, it should have user friendly. If the architecture is made simpler, the deployment Dynamic handler invocation: Scale up More resources: XSLT transformation is very CPU and memory oriented process. By providing a separate CPU and memory to transformation process we can increase response time. Convoy effect: The delay may results from IO or CPU or some other resources. If the handlers are autonomous and do not effect each other, this delay can be solved by bypassing constraints.
  • Message base handler allows us to deploy a handler similar to intermediaries and web services. Handler can be deployed into different machine with a different container. A handler can be deployed within a same container either with another handler or service as it is seen in the figure. Handler can be either request path or response path Metadata needed. Mehmet research and mine.
  • Hybrid approach can be utilized in some specific situations. Hybrid approach is the approach of using old style handler structure with the message style handlers. The decision of whether a handler will be shared memory style or message style will be given according to the some criteria such as performance and nature of handler.
  • Are QoS requirements met for our system if we distribute handler? Is performance reasonable when we use messaging? Performance versus modularity and simplicity What happens if an error occurs during execution ? Should we start all over again ? Testing results fro performance, if message base performance is unacceptable we will use old style or within same machine of service Fault tolerance: Current handlers create a fault SOAP sends it all the way back to the client. Should we imitate this architecture ? Or can we continue processing from some handlers. If A handler fails in a process can we continue to the execution. In other words should we use mustunderstand tag for our handlers ? Distributing handlers needs authentication and other security related issues between handlers
  • Methods in MessageContext allow you to manage a set of message properties, which enable handlers in a handler chain to share processing-related state Both context objects extend MessageContext, which holds properties that the handlers can use to communicate with each other. A standard property MessageContext.MESSAGE_OUTBOUND_PROPERTY holds a Boolean that is used to determine the direction of a message. For example, during a request, the property would be Boolean.TRUE when seen by a client handler and Boolean.FALSE when seen by a server handler. Is the intermediaries able to process SOAP to route message from one handler to another. Does SOAP include this information ? Or is SOAP is just payload and. SOAP message trasported by another mechanism such as naradabrokering ? Naming is another issue in dynamic work flow mechanism.
  • Audit stores the messages. It may add extra information to the received xml document such as time stamp and contextual info. look at the list which I created

Web Service Handler Architecture Web Service Handler Architecture Presentation Transcript

  • Web Service Handler Architecture Beytullah Yildiz [email_address]
  • 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
    • http://www.naradabrokering.org/
    • http://www.informit.com
    • http:// ws.apache.org/axis/java/index.html