I'm already using RabbitMQ as queue 'buffer' and as messaging bus but I'm considering moving to MassTransit to make it more easy to use.
We run in a multi-tenant environment, and to isolate our tenants we have created a dedicated vhost for each tenant plus a "common" vhost for non-tenant related messages.
I would like to know if there's a Best Practice for multi-tenancy with MassTransit and if it is possible to reproduce the same schema (1 vhost per tenant) with MassTransit.
Can I create multiple instance of IBusControl (one per tenant linked to a dedicated IRabbitMqHost) in the same process ?
Yes, MassTransit allows the creation of as many bus instances as you need, and you could create on per vhost without any issues. Just make sure your RabbitMQ server is configured to allow enough connections/sessions to support the total number of tenants, queues, and exchanges.
Related
We have microservices architecture that the services are publishing (and also subscribing) events (+ a gateway api). And we want to start using MassTransit, since the system consist of services which are feeding each other with events to achieve the flow to the end..
Every services in the flow, are generally making some api calls to complete its mission for the events they received.
Looks like we should use MassTransit Courier in order to keep all the services as they are (with only adding consumers) and create a saga state machine as an orchestrator in the gateway api.
Is this a good approach? Or should we try something different?
I need instances of a web-app to receive notifications via WebSocket.
These notifications derive from events in backend systems; these events need to be handled in multiple ways, not only pushed to clients.
Thus a pub/sub system is ideal: events are published and n consumers handle them if they are relevant for their operations (e.g. by topic).
Given my lack of knowledge on WebSocket I'm having a hard-time understanding the overall architecture I need to put in place.
In the pub/sub world consumers subscribe to queues of messages related to "topics" of interest to them.
Can the same be done in WebSockets? (i.e.: when connecting to a WebSocket from the browser, can I specify a set of topics that the client is interested in?).
If so, is it possible to directly connect to the pub/sub system or do I need a middle-layer that consumes from the pub/sub and pushes to websockets?
I guess that the answer to the last question depends on the pub/sub used and would need some library over WebSocket.
I am familiar with RabbitMQ, but I can choose another pub/sub system as at the moment nothing is in place so I have no migration costs.
Thanks
Upgrading skills from Azure Service bus to Rabbit MQ + Mass Transit. Please bear with me.
I have convoluted understanding in mind about Saga and State Machine (Automatonymous). Are they synonym of each other.
Does the name SAGA originates from integrated state machine functionalities
in service bus? Can we say Saga is superset of service bus?
As Azure does not have integrated state machine in their service bus.
In my opinion, Sagas are use for the transactions, for example among microservices, to maintain consistency between them.
You have applied the Database per Service pattern. Each service has
its own database. Some business transactions, however, span multiple
service so you need a mechanism to ensure data consistency across
services. For example, lets imagine that you are building an
e-commerce store where customers have a credit limit. The application
must ensure that a new order will not exceed the customer’s credit
limit. Since Orders and Customers are in different databases the
application cannot simply use a local ACID transaction.
Reference: http://microservices.io/patterns/data/saga.html
I have successfully updated a MassTransit app from 2.x to 3.x and switched to RabbitMQ for my transport. I did this to get one-to-many messaging to function properly, which the previous developer thought would work with MSMQ but I found it was not working and it became clear by reading the documentation that I would need to use 3.x and RabbitMQ.
My application has multiple instances of a website running on the server, with each instance for a specific customer base. I want each instance to publish to specific queues so that the data is only available to the back-end processes for the particular instance. I can easily configure each of these processes to only read from specific queues, but how do I get MassTransit to publish only to specific queues.
You should probably configure a separate RabbitMQ virtual host for each customer, and point that customer's web site instance to that specific virtual host. That way, each way site has its own virtual service for message traffic, keeping it isolated from the other.
Can anyone give me some suggestions of a business scenarios where I can implement Java Messaging Services (JMS). The message can be sent either by queue(point-to-point) or topic (regular/durable subscription).
I will be using JMS (enabled through TIBCO Enterprise Messaging Services).
The business scenarios must involve atleast 3 IT systems/applications.
The classic use case is that of an Enterprise Service Bus with JMS as one of the available transports. In this case any number of IT systems can request a service invocation by placing a message on a well-known queue. The service provider listening on that queue dynamically determines the reply based on the JMS message's Reply-To fields. An example of a typical service is to inquire on or update customer demographic information. For purposes of inquiry, this definitely meets your requirement of involving at least 3 IT systems since pretty much everything dealing with customers would need to request this service.
Another example with broad application is logging. I have several customers using JMS messages to capture log records from across the network and forward them to a hub of central servers. Because it is JMS, the central hub can be highly available by using redundant servers and can scale horizontally to absorb seasonal loads.
For pub/sub an example I really liked is from an insurance company. They publish events on topics that are subscribed in various call centers, internal news tickers and to business partners. During a hurricane a few years back, these events included updates on landfall predictions and then after the storm passed the updates included locations of mobile claims adjusters and other support services. Pub/Sub was a great way to coordinate this massive mobilization of personnel and communicate back to ground support back at headquarters.
A more mundane pub/sub use case with broad applicability is systems management. Instrumented applications can publish their status and interested parties can receive those notifications. If something is acting weird in Production, the administrator can dynamically enable a subscription to a stream of diagnostics. Ordinarily with no subscribers, the diagnostics are not produced. However, without any interruption in the running system, simply by subscribing, diagnostic messages from the app are produced on demand.
It's actually harder to find examples where JMS messaging should not be used. The most common contraindications are truly synchronous messaging and a requirement to process messages in strict sequence. All JMS providers I'm aware of make allowances for these requirements to varying degrees and I'm aware of many deployments of systems with these requirements. However the ideal use cases for JMS messaging are truly asynchronous or pseudo-synchronous communication and messages that are atomic (that is to say messages have no dependencies on each other or to specific broker instances).
Here are some of the scenarios where we (food retailer) use messaging:
-connection systems between remote locations, in our case POS and inventory management systems in stores, and central ERP and forecast systems: master data changes are sent as XML messages from the central ERP system to the store systems. the store systems send changes in inventory, orders and sales to the central systems. This is completely PTP based, as the master data is unique for each store.
-usage as a central messaging backbone, either directly for systems that are capable to do messaging, or via some adapter functionality for databases, files, SAP systems or HTTP. Here the messaging system builds the base for our ESB.