SOA Pattern-Asynchronous Queuing
Download as PPTX, PDF8 likes3,244 views
In today’s data-driven world, messages play a vital role as they are heavily used to transfer data and communicate among various IT ecosystems. As these ecosystems become more business critical, people expect messages to process and respond in less than a second, regardless of the complexity and distance between ecosystems. The concept of “Asynchronous Messaging” can be applied to fulfill this industry essential as it helps in different ways and means to communicate efficiently and efficaciously. This webinar will discuss
Ad
More Related Content
What's hot (20)
Similar to SOA Pattern-Asynchronous Queuing (20)
Ad
More from WSO2 (20)
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (20)
SOA Pattern-Asynchronous Queuing
- 1. SOA Pattern: Asynchronous Queuing Senaka Fernando Dinesh Lakmal Kodithuwakku
- 2. About the Presenter(s) Senaka Fernando Architect- Solutions Architecture, WSO2 Senaka is a Solutions Architect at WSO2. Before moving to the Solutions Architecture team, Senaka focused on the WSO2 Governance Registry and WSO2 Cloud Services Gateway. In addition to his product R&D efforts, he has provided technology consulting on customer engagements, helping to successfully implement governance, enterprise application integration, SAP integration, and on-premise portal solutions. He also founded the WSO2 Web Services Framework/C++ during his internship with WSO2 in 2008. Dinesh Lakmal Kodithuwakku Solutions Engineer - Solutions Architecture, WSO2 Lakmal is a Solutions Engineer at WSO2. He has five years of hands-on experience with mobile computing technologies. His expertise spans analyzing, implementing and testing software solutions for mobile computing platforms as well as carrying out research and identifying technologies and methodologies to determine the optimum solutions for project tasks when required. *
- 3. * About WSO2 ๏ Global enterprise, founded in 2005 by acknowledged leaders in XML, web services technologies, standards and open source ๏ Provides only open source platform-as-a-service for private, public and hybrid cloud deployments ๏ All WSO2 products are 100% open source and released under the Apache License Version 2.0. ๏ Is an Active Member of OASIS, Cloud Security Alliance, OSGi Alliance, AMQP Working Group, OpenID Foundation and W3C. ๏ Driven by Innovation ๏ Launched first open source API Management solution in 2012 ๏ Launched App Factory in 2Q 2013 ๏ Launched Enterprise Store and first open source Mobile solution in 4Q 2013
- 6. One of the biggest pains ● Services might require consumers to interact with them asynchronously ● This can inhibit performance and compromise reliability by locking it’s resources ● Services and their consumers run into isolated failures in this very disconnected setting *
- 7. How to overcome this? ● Services can exchange messages with consumers via intermediary buffers (or brokers) ● Buffers allow services and consumers to process messages independently ● Both service and consumer gets the freedom to process messages and report failures without depending on each other *
- 8. Why Messaging? ● Enhanced reliability ○ e.g: via Persistence, Transactions ● Decoupling ○ Space ○ Time ○ Synchronization *
- 9. Basic Messaging Model ● Messaging is implemented with a broker ● Participants send messages and broker delivers them to recipients ● Two main models ○ Point-to-Point - Messages are delivered only once and held on a queue from which a consumer picks one at a time ○ Publish/Subscribe - Messages are broadcasted to many consumers at once *
- 10. Queues ● Ability to store a message in a temporary storage is a fundamental requirement in enterprise integration (but some may require more durable models) ● Point to Point model: Queue is a destination that contains messages sent from a producer that awaits delivery to a designated consumer ● Messages are delivered in-order ● Guarantees that each message is processed only once *
- 11. Queues...cont ● A message is removed from the queue once it has been received by the consumer ● May provide additional features ○ Persistence ○ Monitoring * Sender Queue Receiver Receiver Receiver Receiver
- 12. Topics ● Pub/Sub model ● Multiple consumers subscribe for messages ○ Topics are used to send messages to one or more consumers ● No guarantee that, messages are delivered in sent order ● No guarantee that, each message is processed only once *
- 13. Topics...cont ● Producers publish messages to topics and each consumer subscribed to the topic receives a copy of the message * Sender Receiver Receiver Receiver Receiver Topic
- 14. Durable Topics ● Broker collects messages while subscriber is offline ● Broker distributes messages to all interested parties ● Each subscriber has its own internal queue until it unsubscribe *
- 15. Durable Topics ● Best of both worlds? ● Or additional complexities? *
- 16. What WSO2 Product(s) to use? ● WSO2 Message Broker (MB) ○ Implements and supports JMS API using AMQP ○ JMS (Java Message Service) ■ A Standard Java API for programmers to handle messaging by interacting with a message broker ○ AMQP (Advanced Message Queuing Protocol) ■ Open Standard for passing business messages between applications or organizations *
- 17. What WSO2 Product(s) to use? ● WSO2 Message Broker (MB) ○ Will support MQTT from end of 2014 (ETA) ■ Implementation is already completed and has been demonstrated at some conferences ○ MQTT (Message Queuing Telemetry Transport) ■ A lightweight pub/sub protocol implemented on top of TCP/IP to facilitate machine-to-machine (M2M) and Internet-of-Things (IoT) integrations *
- 18. What WSO2 Product(s) to use? *
- 19. How WSO2 MB is different? ● Scalability - WSO2 MB can be clustered to handle complex business requirements ● Uses Apache Cassandra as the storage for persistent messages ● Supports distributed queuing *
- 20. How WSO2 MB is different? ● Can easily handle large message transfers ● Highly available and fault tolerant ● High interoperability via AMQP clients: ■ Java ■ C ■ C++ ■ .Net ■ many more*
- 21. UC 1: Rate Limiting ● Some services only process messages at a specific rate ● Clients may send messages at an arbitrary rate ● Provides a virtualized service interface that stores all messages in a queue ○ Services can consume messages from the queue at their own pace ○ Or the broker can forward the stored messages to the actual service at a controlled rate *
- 22. Pattern: Store & Forward * Proxy Service Message Store Message Sender Service Client request (Variable rate) Store Fetch Forward (Fixed rate)
- 23. UC 2: Guaranteed Delivery ● Sometimes we need to ensure that all requests are received and processed by the back-end systems ● All requests can be stored in a persistent message queue ○ Back-end systems consume these messages whenever they are able to ● Or use a persistent queue as the dead letter channel *
- 24. Pattern: Dead Letter Channel * Proxy Service Message Store Service Client request 2. Store on Error ERROR 1. Send 3. Retry
- 25. UC 3: Separation of Concerns ● Sometimes messages should be processed through expensive audit/logging routines ● To avoid high response times, messages can be cloned and stored in a queue ● Audit/logging systems consume the messages off the queues *
- 26. Pattern: Separation of Concerns * Proxy Service Message Store Service Client request Store copy of message Audit System
- 27. UC 4: Translation ● Sometimes the client and service speak different protocols ● Input and Outputs don’t tally with each other in terms of format or one of several aspects such as rate ● A Message Bus controls and reshapes the communication between the client and service *
- 29. Contact us !