I am working on an ASP.NET MVC 5 application (based on nopCommerce). I want to use MassTransit to communicate with another application that is used for inventory management, billing, etc. It would be easier if I could add receive endpoints directly into the web application and not have to create a Windows service for that. But the MassTransit documentation says it is not recommended and there is no explanation as to why that is.
MassTransit in a web application
Configuring a bus in a web site is typically done to publish events,
send commands, as well as engage in request/response conversations.
Hosting receive endpoints and persistent consumers is not recommended
(use a service as shown above).
Does anyone know the reasoning behind it? Is it not safe to add receive endpoints in a web application? Will they not work properly?
Hosting endpoints in a web application is not recommended because web applications often restart for various reasons. These reasons are typically outside the control of the application itself.
While using a standalone Windows service is highly recommended, as long as the bus is properly started and stopped using the Application_Start and Application_End methods, it can be okay if you have no other options available.
We currently have an .NET 4 application that consists of Windows Service running in the background and local or remote clients (only 1-3 normally).
The clients have a WPF GUI and need some data from the windows service. Therefore, we use WCF with NamedPipe binding for a local client and NetTcp binding for remote clients. This works, but we often have problems with endpoints that are not reachable (channel faulted or not found etc.). We already try to rebuild faulted connections but it seems to be pretty fragile...
Now enter Web Api: It looks like a HTTP based stack might be more robust (no channels, no endpoints, can be self-hosted in windows service as well). There seems to be no problems with broken channels because each request is handled individually. So if something fails, you just repeat the request. (And we have experience with ASP.NET MVC from other apps, so this not new to us).
Now we are thinking what might be our best bet. Is it better to "harden" our existing WCF service (one service interface with about 15 operations) or to move the interface to Web Api and run it as HTTP requests (with JSON data)? Performance is not our main issue here...
Any ideas?
Hartmut
I recommend you stick with WCF (SOAP) services for your WPF application rather than moving to the Web API. There are a number of reasons for this. First I think we need to consider what the new Web API is trying to address - namely to provide a framework for supporting RESTful/HTTP/hypermedia services. This is likely to be a good fit for building applications that make heavy use of HTTP such as web, mobile and JavaScript applications, where you want to maximise the "reach" or interopability of your services (irrespective of platform). This is not to say that you can't use it for WPF clients but in your case, where all traffic is local to your domain, it makes more sense to stick with your current implementation.
The binding choices you have made for your services / clients sound ok to me. I would focus on why your channels are faulting and address these issues. You may also want to consider hosting your services via IIS and use WAS to expose your non-HTTP endpoints. I have had much success with this in the past and for the most part has been pretty stable. It also takes away a few of the headaches with managing your own host. If you are concerned about the TCP binding faults, then just create a new HTTP or wsHTTP endpoint and use that instead. This will provide you exactly the same transport the web api uses without having to change your programming model.
I have a web application running in a GlassFish 3.1 service on Windows 7 and Server 2008. I would like this application to be able to control a number of other services on the same machine. In particular I want it to be able to start and stop Tomcat services.
Essentially the application is acting as a controller for other applications I deploy on the machine so I can set any security necessary on the controlled applications.
I notice that .Net has a ServiceController class so I'm assuming that programmatic control is possible but I would very strongly prefer a pure Java solution if possible.
All the searches I've done turn up a lot of information about running Java as a service and not much on controlling services from Java. Is what I'm trying to do possible? What security hoops will I need to jump through?
You can do Runtime.exec("net stop tomcat6"). Of course tomcat6 can be replaced with any other service name.
Also check out this tutorial
http://www.java-samples.com/showtutorial.php?tutorialid=8
We run a number of ASP.NET MVC sites - one site per client instance with about 50 on a server. Each site has its own configuration/database/etc.
Each site might be running on a slightly different version of our application depending on where they are in our maintenance schedule.
At the moment for background processing we are using Quartz.net which runs in the app domain of the website. This works well mostly but obviously suffers issues like it isn't running when the appdomain shuts down such as after prolonged activity.
What are our options for creating a more robust solution?
Windows Services are being discussed but I don't know how we can achieve the same multi-site on different versions we get within IIS.
I really want each IIS site to have its own background processing which always runs like a service but is isolated in the same way an IIS site is.
You could install a windows service for each client. That seems like a maintenance headache though.
You could also write a single service that understands all versions of your app, then processes each client one after the other.
You could also create sql server jobs to do this, and setup one job for each customer.
I assume that you have multiple databases for each client as you mentioned.
Create a custom config file with db connection-strings for each client.
e.g.
<?xml version="1.0" encoding="utf-8" ?>
<MyClients>
<MyClient name="Cleint1">
<Connection key="Client1" value="data source=<database>;initial catalog=client1DB;persist security info=True;user id=xxxx;password=xxxx;MultipleActiveResultSets=True;App=EntityFramework" />
</MyClient>
<Myclient name="client2".....></MyClient>
</MyClients>
Write a windows service which loads the above config file (clients|connectiostring) into the memory and iterate through each client database config. I guess all clients have similar job queuing infrastructure, so that you can execute same logic against each database.
You can use a Mutex to initiate the windows service for a client so that it will make sure two instances of the service for the same client won't run at the same time.
I have some delphi code which, given a list of items, calculates the total price taking into account any special deals that might apply.
This code is non-trivial to rewrite in another language.
How should I set it up to communicate with a website running on the same server? The website will need to ask it for a price every time the user updates their shopping cart. It's possible that there will be multiple concurrent requests.
The delphi code needs to maintain an in-memory list of special deals, periodically refreshed from a database. So it cannot simply be executed every time or anything as simple as that.
I don't know what the website is written in, or even which http server it runs under, so I'm just looking for ideas or standard methods.
It sounds like the win32 app is already running as a Windows Service on the box. So, if you can't modify that service, you are going to have to deal with whatever way it wants to accept and respond to requests. This could be through sockets or some higher level communication protocol like web services.
You could do a couple of things. Write an assembly that knows how to communicate with the service and have your web site use that assembly. Or you could build a shim service that knows how to communicate with the legacy service, but exposes communication over higher level protocols such as web services. Either way will have the benefit of hiding the concurrency, threading and communications issue behind an easy to call interface, but the latter will make communicating with the service easier for everyone going forward.
If you can modify the delphi app to take an XML request and respond with an XML answer over a TCP socket (ideally using the HTTP protocol), you will be able to make it interoperate with most web server frameworks relatively easily. But the exact details of how to make that integration happen will depend on the language/framework it was written in.
If the web server is on windows you can compile your delphi app as a DLL that can return XML or HTML, taking parameters as part of the URL or a POST operation. Some details on making a Delphi DLL for web servers are here.
It doesn't matter what web server or OS the existing system is running under. What matters is what you want YOUR code to run under. If it is windows then the easiest solution would be to use WebBroker and write a custom ISAPI application, or use SOAP to expose web services. The first method could be used if you wanted to write a rest like API for instance, the second if your web application has the ability to consume web services.
Another option, if you are running both on the same box under IIS, is to create a COM/Automation object which you then invoke via server side scripting (ASP). If the application is an ASP.NET application, then I would use PRISM to port your code into an assembly.
I have done this with a quite complicated workers compensation calculator. I created a windows service using RemObjects Sdk. The calculations are exposed as a soap method so it can be accessed by nearly anything.
It's not necessary to use RemObjects in the service but it makes it much easier to do as it handles a lot of the underlying plumbing. The clients don't need RemObjects, they just need to be able to call soap methods. Nearly any programming langugae can do that.
You could also create an isapi dll for IIS that exposes a soap interface. This would be useful if other websites on different servers needed access to the methods. However I have handled this in my case by opening a port in the firewall to access my windows service.
There is a lot of examples on the web. A couple of places to start reading are About.Com and Dr Bob.
Torn this app into Windows Service. Write Web Service that will communicate with your windows service. You should spend some time designing your Web Service, because this Web Service is going to be your consistent interface, shielding old Delphi app. So in the future whenever you will want to write web app, mobile app, or whatever you will imagine, you will have one consistent interface – XML Web Service.
A popular way to integrate a web application with background services is a message broker.
The message flow would be:
the web application sends a "calculation request" message to a message destination on the message broker, which contains all needed parameters and also a correlation id to match the calculation request with the response from the Delphi service
one (or, in a high availability / load balanced environment more) Delphi services handle the messages: pull the next incoming message, process it by feeding the parameters to the calculation engine, and send a "calculation result message" back to the web server
the web server can either synchronously wait for the response (and discard responses which have no matching correlation ide) and build the result HTML document, or continue with other tasks and asynchronously receive the calculation result in a separate thread, for example in a Ajax based web application
See for an introduction this slideshow about the Dopplr image service:
http://de.slideshare.net/carsonified/dopplr-its-made-of-messages-matt-biddulph-presentation
If you can make it a service (but not a library), you have to do inter-process communication somehow - there are a few ways to do this on Windows:
Sockets directly which is hardest since you have to do marshalling/auth yourself
Shared Memory (yuck!)
RPC which works great but isn't trivial
DCOM which is easier but a pain to configure
WCF - but can you call it from your Windows Service written in Delphi?