Service bus to build Bridges
•Download as PPTX, PDF•
1 like•754 views
To scale applications and follow SOA, Service Bus is a great option supporting multiple types of message passing.
More Related Content
More from Abhishek Sur
More from Abhishek Sur (20)
Recently uploaded
Recently uploaded (20)
Service bus to build Bridges
- 1. • Abhishek Sur • MVP, Microsoft @abhi2434 contact@abhisheksur.com
- 2. A comprehensive book on .NET Expert guide book with expert advices on development. Part 1 includes Visual Studio, Memory Management, Windows 8, ASP.NET, WPF, Architecture etc. A comprehensive book on .NET Expert guide book with expert advices on development. Part 2 includes Debugging, WCF, Windows Phone, Testing TFS, Extensibility, Windows Azure etc.
- 6. E AD C B
- 12. Store Front End
- 19. ?
Editor's Notes
- This is a 200 level technical deck on the capabilities of Service Bus
- To set some context, first broaden the scope outside of service bus and look at the domain that it is part of – which is all about system integration, service bus provides the messaging infrastructure for these solutions to be created and it is one of a number of capabilities of the platform that would be used (note: a number of other key capabilities are in development but not in preview at this time – EAI/EDI and Workflow)
- Easily Connect Applications Service Bus Messaging provides out-of-the-box support for various messaging patterns that enable to easily connect applications Queues offer a reliable, durable, and highly scalable way to store messages as they travel between systems without losing messages in case connectivity fails, one of the systems is down or is a mobile device with limited connectivity. Queues support multiple senders as well as multiple receivers with automatic load balancing. Topics and Subscriptions implement a publish/subscribe pattern that delivers a highly scalable, flexible, and cost-effective way to publish messages from an application and deliver them to multiple subscribers. Broadcast a message to hundreds or thousands of subscribers on a given Topic. Distribute messages to individual subscribers or groups of Topic subscribers using message property based filtering rules. Advanced messaging features provide a variety of options for delivery assurance and performance tuning: Local Transactions De-duplication Scheduled delivery Delivery confirmation (peek-lock) Delivery deferral Client-side pre-fetch Batched Send/Receive Connect Applications From Anywhere Service Bus enables connecting applications that are distributed across public cloud as well as hybrid environments, and various platforms, in a loosely coupled manner Enables connecting application across public cloud, public cloud and private cloud, and private cloud to private cloud through public cloud. Client applications can be running on PCs, mobile devices or in the browser. Service Bus Relay enables applications to securely call into private cloud applications hosted in your own datacenter behind firewalls and NATs Enterprises can use a SOA-based architecture and expose just the services they want to deliver from their private cloud environment which creates a more secure architecture than opening up a VPN. Supports various programing languages and platforms: .NET, WCF, REST, Java (Coming soon: Node.js, PHP) Supports a variety of different transport protocols and Web services standards, including REST, SOAP, and WS-*. One-way messaging between sender and listener supports unicast and multicast. Full-duplex connection-oriented sessions between sender and listener support bi-directional communication. Services discoverable through a stable, internet-accessible URL, regardless of location. Enterprise Grade Cloud Service Managed service operated by Microsoft with 99.9% monthly SLA. Service Bus takes care of delivery assurance, reliable messaging, scale and load balancing. Claim based security using the Azure Access Control service supports identity federation with Active Directory as well as common web identity providers like Google, Yahoo and Facebook. Cloud hosted service relay and brokered messaging capabilities can be leveraged directly from anywhere without the need for IT to change network configuration or install gateway agents/devices.
- An overview slide that covers the THREE main capabilities of SB and an example scenario of where this might be used. Sometimes you might only need this slide to explain, or just use it as a simple t-up slide before you go into the details of how each of these capabilities works at a high level.
- Although integrating systems is a key reason you would use service bus, it is also used within applications to decouple parts of the applications so that you can provide built in resilience and mechanism to scale your applications easily. These slides illustrate both these principles starting with resilience. In normal systems, components are tightly coupled which means that if any one of them fails, the whole thing fails and creates bad user experiences.
- By loosely coupling back and front ends of an application and shifting the application architecture to process transactions differently, the front end can send shipping requests first to a queue. Once on the queue, the store front end can send an acknowledgement to the user confirming the order. The assumption is that the order will get shipped. If there is some downstream problem, the system will have to communicate back to the user outside of the order transaction (for example – maybe the requested shipping date was not available). The Shipping service get’s orders from the queue in this architecture, it is not being SENT orders from the store front end. When the shipping service is working correctly – it just continues to get orders from the queue. If for some reason the Store Front end fails and there is a backlog of orders on the queue, the shippping service can still work. Likewise, if the shipping service is down, the store front end can still take orders.
- In this example we show that the shipping service can itself consist of multiple instances of worker processes that are pulling orders from the order queue. Each process will just pull one order, the queue guarantees order as well as ensuring that only 1 message is delivered to one instance of the tracking service. In this way, if you have many orders coming in, it is easy to add more worker instances to process these orders.
- This is a simple animation that shows the basic mechanics of a queue. We have publishers and consumers. Using a simple API, a publisher creates a message that contains message properties and data. These messages are created by the publisher and there does need to be some agreement between publishers and consumers on what the message properties and content are so that each understands how to handle the data in the messages. The Queue itself does not PULL and it DOES NOT push data – it is simply a store for the messages and ensures the right ordered delivery of the messages for consumers who ASK for a message. The typical pattern for consumers is to run in a loop, polling for messages from the queue.
- Topics are in essence, just more complex queues. We have the same publisher and consumer model. The difference is that with topics, you create one or more subscriptions which themselves can have rules that will only select certain messages sent to the topic. Publishers send to the Topic, but Consumers receive from one or more subscriptions. The Rules are applied (using the Service Bus API – there is no tooling/UI for this (Yet)) to subscriptions which affect which messages get to that subscription. The animation shows that you can actually set rules up after messages are already waiting at the subscription causing the subscription to have different messages that the subscription rule would indicate.
- Queues and Topics are all about messaging. The other main capability SB provides is the Relay that provides a mechanism to enable Cloud Applications to communicate with on-premise web services and applications. Traditionally, you would have to open up security firewalls to allow web service calls into on-premise systems. Using the SB relay, essentially an abstraction layer, enables the SB Relay to broker the communication between the calling client and the on-premise systems.
- This slide is just a little bit more detail about how this actually works. What happens is that the on-premise web service (that itself will call into other on-premise systems), needs to be registered with the SB relay and to use the specific SB Relay channel/protocol (all WCF magic). When this happens, the internal web service will now listen for requests to it on the SB Relay endpoint, not on the internal network (it can actually do both if you bind multiple protocols to the service). When a client calls the SB Relay endpoint, SB relays this call down to the actually service which then executes the request and returns the result up back through the Relay and back to the calling client.