Architectural Styles for Reliable and Manageable Web services

1. Architectural Styles for Reliable and Manageable Web services Piyush Maheshwari Abdelkarim Erradi March 2005

2. Agenda • Service Oriented Architecture (SOA) • Web Services Interaction Patterns • Motivation for wsBus • wsBus Architecture and Design • Conclusion and Future Work

3. So… what is Service Orientation? • Interoperability-centric approach to interconnect applications and facilitates complex interactions between heterogeneous and autonomous systems • Paradigm shift from RPC-based/object-based architecture to a loosely-coupled, message-focused and service-oriented architecture • SOA = {Services, Messages, QoS/Policy}

4. Service Orientation • Built around the concepts of service and message • A service is an entity that can send and receive messages • Service interaction is facilitated by exchanging messages • A service adheres to a contract • Describes the format of the messages exchanged • Defines the message exchange patterns in which a service is prepared to participate • Messages include • Application data • Control information: Addressing, Security, Reliability • Problem: How to provide QoS support and manageability?

5. Point-to-Point vs. Broker Pattern Broker Pattern Point to Point • Broker Pattern • Consistent handling of value-added QoS: centrally configured and enforced • Reduced coupling • Improved security & interoperability • Single point of failure and congestion: requires redundant/clustered configuration • Point-to-Point • Simple integration pattern and requires minimal infrastructure • Complicating manageability and maintainability as well as increasing operational cost as the number of connections grows • Duplication of QoS, transformation and routing logic between services

6. Mediation and Interoperation • Interoperation of Web services is hindered by many forms of mismatch • Data mismatch: the interacting parties do not agree on the data format that they are using • Protocols mismatch:the interacting parties use different protocols • Semantic Mismatch:The interacting parties interpret the same information in very different ways • These mismatches need to be reconciled for the interoperation to succeed. • Mediators (e.g., wsBus) are the components that reconcile these mismatches and add QoS support

7. Point-to-Point SOAP Messaging wsBus

8. What is wsBus? • wsBus = a lightweight service-oriented integration framework for dependable Web services interactions using broker pattern • Design Goals: • Maximize decoupling complemented by scalable mediation service to cope with the inherit heterogeneity of interacting services.

9. Why wsBus? • Inflexibility • Tightly-coupled(Location & implementation aware) • Synchronous (RPC, availability dependent) • Many connections and data formats • Not scalable • Extremely difficult to manage Overcome Point-to-Point integration problems

10. wsBus Features • Enhanced service registry that can be used as a private UDDI with richer metadata • Gatekeeper: Block unauthorized SOAP messages and control access to services • Multi-protocol support to bridge interfaces and protocol differences • Load balancing - redirecting high load jobs or messages for Gold clients to special servers • Improved reliability through configured re-routing or retry mechanisms

11. wsBus Features (cont.) • Protect applications from emerging and rapidly evolving Web services standards • Protect servers from overload by queuing or redirecting messages • Other added value services like Service Level Agreements (SLAs) monitoring, encryption, metering, and billing services

12. wsBus Architecture

13. wsBus Components • wsBus = mediating component • Provides various channels to access the registered Web services • Filters intercept and manipulate both request and response messages (e.g., transform old-format messages into new formats) • Reliability layer checks messages for expiration, duplication, and ordering • Then the Msg get queued for processing

14. Message Processing Pipeline • Messages travels along a pipeline • Pipeline is made from series of operations • Generic: • Validate message against schema • Filter / Select Route using XPath expression • Transform message with XSLT • Verify message integrity / sign message • Encrypt / decrypt message • Specific: • Evaluate a business rule • Perform some data operation • Path can be determined dynamically by routing rules • Pipeline can be easily adjusted by configuration

15. Reliability features • Expiration: expired messages are not delivered • Timeout: generate timeout if a response msg not returned within a specified time. • Store and forward mechanism • Clustering Web services Plus • Logging of all messages • Message tracking and correlation • Interoperability with various messaging protocols

16. Conclusion & Future Work • The Message is the key! • Asynchronous messaging & Loose coupling • wsBus leverages the principles of messaging systems as well as the emerging WS-* standards to support more reliable and manageable Web services interactions using a broker pattern • Future Work: • Complete wsBus development and fully evaluate its features in real settings • Investigate techniques to provide differentiated and guaranteed service levels

17. References • Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2003). Web Services: Concepts, Architectures, and Applications. Berlin: Springer Verlag. • Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice (2nd edition): Addison-Wesley. • Birman, K., Van Renesse, R., & Vogels, W. (2004). Adding high availability and autonomic behavior to Web services. Paper presented at the Proceedings of 26th International Conference on Software Engineering (ICSE 2004). • Pallickara, S., & Fox, G. (2003). NaradaBrokering: A Distributed Middleware Framework and Architecture for Enabling Durable Peer-to-Peer Grids. Paper presented at the Middleware 2003, Rio de Janeiro, Brazil. • Sadiq, S. W., Orlowska, M. E., Sadiq, W., & Schulz, K. (2004). Facilitating Business Process Management with Harmonized Messaging. Paper presented at the 6th International Conference on Enterprise Information Systems (ICEIS 2004), Porto, Portugal. • Vogels, W. (2003). Web Services Are Not Distributed Objects. IEEE Internet Computing, 7(6), 59- 66.

18. Questions & Comments? This work is part of a project jointly funded by the Australian Research Council and Microsoft (ARC Linkage Project LP0453880)