Is it possible to use NServiceBus to publish and consume messages in the same application, specifically a web application?
In the future we will almost certainly need to maintain a separate long running service to process messages generated by this application, and this is why we are hoping to use NServiceBus from the start, but right now it would be nice to just start up the consumer and the publisher when the web application starts. This will make testing and deployment far easier for us.
I presume I will need to reference the NServiceBus.Host.exe and start up the process in the global.asax, but need help on what exactly I need to call to do this.
This is not a mode of deployment that is supported out of the box. While you could make this work by manually creating an additional appdomain for the second NServiceBus endpoint, you'd also likely need to give it a custom configuration source, and of course its own queue.
All in all, I'd recommend keeping it as a separate process, even if it is on the same box. That being said, you can create a second web app to host it rather than using the generic host if you don't want to manage windows services in addition to web apps.
Hope that helps.
Related
I'm building an app folowing DDD paterns with each AR having their events outbox saved to a permanent store.
That store gets polled by other parts interested in events.
Whole application is user oriented so the basic infrastructure is asp.net web api.
Now, i'd like to avoid having my domain artifacts spread across different processes/infrastructure options. For example, Azure Function that listens for event store & does logic upon events received.
It seems convenient to have web api & events consumer together in same container. Reason is that domain artifacts are deployed together with api & events consumer infrastructure.
I read that IHostedService might be one option for it as it can run as long running background process.
Question is, is IHostedService meant for this particular scenario of reacting to event outboxes? or are there some important drawbacks i'm missing and better infrastructural choices?
In general, I don't think there is anything wrong with using hosted service for running background workers.
I'm more sceptical about the "polling from other bounded contexts" part. I'd be at least concerned if that breaks the encapsulation of my contexts (similar to having "foreign" components read from a contexts persistence). But this might not be the case in your situation.
Anyways, in case you just want to guarantee that your events are reliably transmitted I would rather make sure that each component realizing a specific bounded context (e.g. microservice or component of a monolith) pushes these events somewhere interested consumer are able to pick them up.
So if it is about the reliable transmission of outgoing events I would suggest the transactional outbox pattern, maybe in combination with a publish-subscribe approach.
As you're on the .net stack the outbox feature of NServiceBus might be interesting for you.
Here's a link.) about implementing an IHostedService.
Indeed, IHostedService is a good way for long running process for your scenario by two methods.
It is important to note that the way you deploy your ASP.NET Core WebHost or .NET Host might impact the final solution. For instance, if you deploy your WebHost on IIS or a regular Azure App Service, your host can be shut down because of app pool recycles. But if you are deploying your host as a container into an orchestrator like Kubernetes, you can control the assured number of live instances of your host. In addition, you could consider other approaches in the cloud especially made for these scenarios, like Azure Functions. Finally, if you need the service to be running all the time and are deploying on a Windows Server you could use a Windows Service.
But even for a WebHost deployed into an app pool, there are scenarios like repopulating or flushing application's in-memory cache that would be still applicable.
The IHostedService interface provides a convenient way to start background tasks in an ASP.NET Core web application (in .NET Core 2.0 and later versions) or in any process/host (starting in .NET Core 2.1 with IHost). Its main benefit is the opportunity you get with the graceful cancellation to clean-up the code of your background tasks when the host itself is shutting down.
I am working on a project in which I want to use a Windows Workflow 4 State Machine. The Visual Studio solution templates and most guidance seem to steer everything towards hosting as a service in IIS that is created dynamically from send and receive activities within the workflow.
However, I would prefer to not use the send and receive activities and then host in my own WCF service which would allow me to use a Windows Service instead of IIS and use other bindings like TCP instead of HTTP and create my own interface instead of exposing MEX. In addition, it would be portable to any other hosting arrangement like in a WPF app or a console or whatever.
This feels a lot more flexible to me. Somehow, having service operations as part of the workflow seems like pretty tight coupling of two things that aren't that related. Is there any downside to my approach? I'm new to WF so I might be missing something.
Depending on the kind of workflows you are running you might need to write quite a bit of pluming code that workflow services provide for you.
Things to consider:
Are your workflows long lived?
Are you sending multiple messages to the same workflow?
Do your workflows need to survive a host restart?
Are you using Delay activities to respond to timeouts?
Do you need to be a able to retry action after error situations?
Lots of these things are automatically taken care of with a WF service and need your attention otherwise. It is certainly doable, I have done it in the past, but be aware of of what you are losing.
I need to create a Windows Service to watch a folder on our network and action files that are placed within it. The process is quite slow and I need the ability to check the progress from a client application (which will be running in about 10 places on the same network as the machine running the Windows service).
Is hosting some WCF service in the windows service the right way to go about this and if so, are there any resources on how I would do this?
Thanks!
it seems a reasonable approach to me.
you can get details of how to host a WCF service inside a windows service in the MSDN how to
This code project page also has an example.
you might need to debug start up issues with the service, and I find adding a
Debugger.Launch();
to the beginning of the OnStart method is the easiest way of doing that. it enables you to debug through the start up process of your service and see any exceptions that occur.
What is the best way to combine a single instance WCF service that uses ActiveMQ and runs within IIS/AppFabric?
Our Services need to support both HTTP transports and ActiveMQ (listening and sending messages). We've elected not to use MSMQ, and will use Spring.Net.NMS. The fundamental issue I have now is that ActiveMQ needs to connect to the queue(s) at startup and remain connected, but WAS is getting in the way with it's message-activation feature. If the service is not activated until a message arrives (HTTP/MSMQ, etc) then there is no trigger to have the connection to AMQ occur.
I know I can disable the recycling behavior, and I know I can do self-hosting with a Windows Service. But I want to take advantage of the monitoring and other features in AppFabric. I've already been down the route with IServiceBehavior and will use that for other nice things. But that interface is not called until a (non-AMQ) message arrives. So it won't work for this. What I was hoping for was something along the line of how ServletContextListeners work in Java, where you get both the start up and shutdown events. But it seems no such thing exists in WAS... it is driven only by messages arriving.
I've scoured every inch of web info for 3 days and the only thing I came across was to use a static class construction (C#) trick as the trigger. That's a hack, but i can live with it. It still leaves the issue of cleanly shutting down, which I can figure out later.
Anyone have a solid solution to this?
The direct WCF support for ActiveMQ that Ladislav mentions is still being supported. There just hasn't been an official release for the module in a while. However, you can still get the latest version of it from the 1.5.x branch or trunk and compile it yourself.
1.5.x branch for use with Apache.NMS 1.5.0:
https://svn.apache.org/repos/asf/activemq/activemq-dotnet/Apache.NMS.WCF/branches/1.5.x/
Check out instructions:
http://activemq.apache.org/nms/source.html
There was direct WCF support for ActiveMQ but I guess it is not developed anymore. Your problem actually is the IIS / WAS (provides hosting for non-http protocols) hosting architecture. Services in WAS are always activated when message arrives - there is no global startup. The reason for this is that WAS hosting expects that there is separate process (windows service) running the listener all the time and this process has adapter which calls WAS and uses message level activation. I guess you don't have such process for ActiveMQ and because of that you will have trouble to use ActiveMQ endpoint hosted in WAS. Developing such listener can be challenging task (example for UDP).
Creating custom listener can be probably avoided by using IIS 7.5 / AppFabric auto start feature. There is also not very well documented way to run the code when the application starts.
I have a server that needs to keep a small number of clients in sync. Whenever there is a change of state at the server, all the connected clients must be informed.
I am planning to use a “callback
contract”,
I can get hold of the
callback reference for each client on
the server by using
GetCallbackChanel().
I then need
to manage all these client channel
reference and call all of them when
needed.
So far so good however:
I don’t wish to block the server, so calls to the clients must be none blocking
Errors calling the client must be logged and coped with
Is there a standard WCF component to do this?
No, there is not a standard WCF component for this, at least through .NET 3.5. I can't speak to what may be available in .NET 4.0.
That said, there is a pretty straightforward way to do this. Juval Lowy, author of Programming WCF Services, describes how to do this using his WCF-based Publish-Subscribe Framework.
Basically, the idea is to create a separate WCF event service that resides in the same hosting application as your server (e.g., Windows service, IIS). When the state of your server changes, you publish the state change to the event service. The clients that need to be kept in sync subscribe to this same event via the event service. In effect, the event service becomes a broker for your server to notify clients of whatever events your server publishes.
The article I listed above has a code download, but you can also get the Publish-Subscribe Framework and a working example for free from his website, IDesign.net. Here is the link to the download. You may need to scroll your browser up just a little bit to see it as I believe their internal hyperlink is wrong.