Preface
NServiceBus (NSB) is the most popular Enterprise Service Bus (ESB) in C#. It complements many of the other C# frameworks by providing an end-to-end ESB framework solution to work with services and messaging. The website, http://particular.net/, has many tools to assist in building endpoints, services, and messaging in Visual Studio. Visit http://particular.net/downloads for more details. There are also production tools to check on heartbeats of running endpoints and provide deep insights into running endpoints, services, and messages. NSB provides rapid development to allow integration into many different endpoints and services, for instance, e-mail, Secure File Transfer Protocol (SFTP), and the Windows Communication Foundation (WCF) protocol for web services.
Let's discuss using NHibernate, an object-oriented mapper (ORM) that maps objects to SQL databases, such as MySQL and SQL Server. As a developer, you will need to provide the mapping interface, usually an hbm.xml interface. While creating endpoints and sending messages NSB takes care of the mapping interface. This includes the creation of tables, logging, message durability, message retries, encryption, and many more components that help ensure high quality of software with the use of NSB. NSB provides many components, unique to NSB, needed for automation. NSB provides the following advantages:
- Separation of duties: There is separation of duties from the frontend to the backend, allowing the frontend to fire a message to a service and continue in its processing, not worrying about the results until it needs an update. Also, the separation of workflow responsibility exists through separating out NSB services. One service could be used to send payments to a bank, and another service could be used to provide feedback of the current status of the payment to the MVC-EF database, so that a user may see their payment status.
- Message durability: Messages are saved to queues between services so that if services are stopped, it can start from the messages in the queues when it restarts, and the messages will persist until told otherwise.
- Workflow retries: Messages, or endpoints, can be told to retry a number of times until they completely fail and send an error. The error is automated to return to an error queue. For instance, a web service message can be sent to a bank, and it can be set to retry the web service every 5 minutes for 20 minutes before giving up completely. This is useful during any network or server issues.
- Monitoring: NSB ServicePulse can keep a finger on the pulse of its services. Other monitoring can easily be done on the NSB queues to report on the number of messages.
- Encryption: Messages between services and endpoints can be easily encrypted.
- High availability: Multiple services or subscribers could be processing the same or similar messages from various services that are living on different servers. When one server, or service, goes down, others could be made available to take over those that are already running. Sagas are at the heart of the NServiceBus (NSB) workflow. Sagas save the message state in the form of saga data. They can retrieve the data as it is related to a message to update the message or data. This allows the NSB workflow to control the flow of data and messaging from end to end and correlate saved data to messages in the saga.
Messages are the means to transfer interaction and data between services in a service-oriented architecture (SOA). Sagas correlate, save, route, and manage processes that are started by these messages between services. Sagas even provide timeouts to ensure that messages do not live forever in a system.
Sagas provide decoupling between frontend websites and backend processes. It allows workflow to transfer so that a website can continue to do its work without having to wait for processes to return, such as the dreaded message "Please do not refresh this website as we bill your credit card".
NSB doesn't stop at development on Windows servers and desktops, but plays a big part in cloud development, for example with Microsoft Azure and the Microsoft cloud. NSB uses Service Bus as well as storage queues, SQL Server, and other storage containers. As the cloud is used more and more, NSB plays a key part in Software as a Service, as it is the premier framework for ESB in the C# clouds.
Even if your cloud solution doesn't end up being a C# compatible cloud, as many might hide the software running behind the cloud as being preparatory, NSB is a component for those that will do hybrid solutions, such as keeping data resident on-site. The connection to the cloud then will likely be via web services, and NSB sagas might likely provide the workflow to those web services.
From this book, you will discover the many features and characteristics of NSB, as follows:
- Sagas handle messages. A saga is started, or updated, by a message and passes it through its message handler. As messages are passed into the saga, the saga updates its sagas data from these messages through a message handler. The message logic doesn't normally end at the saga, but the saga creates a new one and passes it on to the next service. The saga may also respond back to the originating client. The saga routes messages while saving state and may be routing based on the previous state.
- Sagas contain long-lived transactions (LLTs) that contain database information for the messages for relatively long periods of time. An LLT is used when conditions such as short-lived transactions are not adequate. A short-lived transaction occurs when a call to a database, or MSMQ, performs a straightforward rollback or commit. For queues, NServiceBus performs second-level retries (SLRs) to try to commit a message a number of times before performing a rollback. In LLTs, there can be multiple conditions and multiple actions that need to take place for a message to be fully completed, or else operations execute the message from the beginning.
The message is changed from one type of message into another, as one is handled by the saga, and the saga may create a new one with the same ID to pass to another service. Even though the message is different, it is a continuation of the flow of the original message that is considered a single transaction. The transaction is the accumulation of messages as they flow from one end to another end with the same message ID so that it represents the same transaction. The messages may be a different message type as it passes through different services. For instance, it may be an order message for an order service. The transaction can take seconds, days, hours, or longer, as the services take responsibility for acting upon it.
- Sagas contain timeouts for timing out messages and states. Because messages can be long-lived, services are responsible for retrieving and moving them. Sagas can have timers set on messages and data so that it doesn't live forever or the timer could be part of the business logic; for example, a customer has 30 seconds to enter a pin for their debit card. Sagas contain state information. Sagas save saga data to the database based on the message's data. The saga data is initially started with a message, and it is also updated with messages that are passed in with the same identification information. When a message passes between different services, saving the state information before the next service is wise, as there might be a business requirement to revert to its original state.
NServiceBus is the C# platform of choice for those that require workflows. In sagas, high availability, high performance, monitoring, encryption, rapid deployment, and many more features can only be found in this framework when building
C# solutions.