introduction
In my prior post, I have listed some of the APIs that you can use for developing applications where PubSub pattern fits well. In this one, I will give talk little bit more in detail about one of which is Service bus for Windows server and then share some practical guidance.
Body
We are living an era of connected applications. And service bus for Windows server is one of the API/platform you can use to connect applications that may be dispersed and hosted on different platforms (Windows, Linux) in a one/way or bi-directional fashion. It is very like Windows Azure service bus, but differs as being hosted on your own data center.
Figure #1: The service bus for Windows server platform stack
Service bus services that runs on each ring node:
o Windows Fabric: Core clustering technology that manages a “ring” of nodes in the farm.
o Service Bus Message Broker: Manages the send and receive operations from Service Bus queues, topics and subscriptions.
o Service Bus Gateway: Serves as protocol head for supported Service Bus protocols. The gateway also performs security validation on incoming requests.
o Service Bus Resource Provider: Handles management requests from the Windows Azure Pack portal.
o Service Bus VSS Writer: Discovers and automates backup and restore operations using Microsoft Volume Shadow Copy Service (VSS) technology.
Recommendations:
- Make sure it is highly available (HA): HA can be fully satisfied only when both service and database layers are HA. Service layer HA can be accomplished by having at least 3 servers in the ring. In regards to database HA, there are different ways of doing that depending on your case (db version, disaster-recovery plan, etc.) You can check my blog posts about single site failover clustering here for SQL 2012 Server. Please note that Service bus v1.1 supports up-to 5 servers in the ring
- Make sure it is scalable: You need minimum 2n message containers where n is the number of servers of the service bus farm ring. So, HA and scalable service bus implementation requires 3 servers and 6 message containers (database instances) at least.
- Security considerations:
- Client applications can access service bus for Windows server resources only after a successful authentication which is through either a Shared Access Server (SAS) or Active Directory (AD) windows credentials. Certificate used for message security and if auto-generated certificate option selected during the installation, it must be imported to all the clients. Otherwise, it will raise STS related exceptions.
- Design considerations:
- Service bus for Windows server is used for message brokerage. If relaying functionality required, then you may consider Windows Azure service bus instead. Here are a brief overview of both messaging methods (for more details, please visit here):
- Relay: Both parties must be online, supports different approaches (one-way, bi-directional, etc.)
- Message Brokerage: No parties need to be online, asynchronous communication, best suites for http type communications. Service bus queues, topics, and subscriptions are central pieces of message brokerage.
- Evaluate topic with many subscribers vs. topic with less subscribers case and use of subscription filter rules.
- Attention to service bus quotas defined here
- Performance considerations:
- Please visit here listing best practices for performance improvements: Async calling and enabling client batching bring noticeable performance benefits.
- Consider adding rules for subscriptions that filters messages accordingly. Visit here for details
- Disable (or let it be default) the features of topic, subscription, queuing that are not required per your needs, such as Sort Ordering, Lock Duration, Require Session, Is Read Only, etc.
- Debugging considerations:
- Make sure all required service bus and database services are up running.
- Make sure the client has the imported certificate (for STS)
- Check firewall rules for ports used by the services
- Attention to object null reference exception and API exceptions (sending message to a topic which has not have any subscription cause exception, or creating a topic that its path already in use (another topic), etc.
Conclusion
Here, in this post, I have shared some of my learning from past experience. Hope it helps. As side note, as an alternative, you can play with Windows Azure service bus then plan & deploy the same functionality on your own environment if you will.
References:
- Service Bus for Windows Server (Service Bus 1.1)
- Best Practices for Performance Improvements Using Service Bus Brokered Messaging
- Windows Azure service bus