180 likes | 272 Views
Architectural Styles for Reliable and Manageable Web services. Piyush Maheshwari Abdelkarim Erradi March 2005. Agenda. Service Oriented Architecture (SOA) Web Services Interaction Patterns Motivation for wsBus wsBus Architecture and Design Conclusion and Future Work.
E N D
Architectural Styles for Reliable and Manageable Web services Piyush Maheshwari Abdelkarim Erradi March 2005
Agenda • Service Oriented Architecture (SOA) • Web Services Interaction Patterns • Motivation for wsBus • wsBus Architecture and Design • Conclusion and Future Work
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}
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?
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
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
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.
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
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
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
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
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
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
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
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.
Questions & Comments? This work is part of a project jointly funded by the Australian Research Council and Microsoft (ARC Linkage Project LP0453880)