Hello,
We have developed a webservice (WDSL) that creates and manages mailboxes. This webservice (WDSL) works fine from our current ASP.NET website. We now want to avoid that users have to wait on the response of the webservice while managing mailboxes
and also have more logging on who creates what, when,.... In a post that I made about a year ago on the ASP.NET forum I found out that I have three options: ASP.NET threading, CLR stored procedure with Service Broker, external
activation with Service Broker.
To be honest, the CLR stored procedure with service broker, looks the coolest to me, but I read regularly that this is not the way to go. The most common responses are security concerns and the fact that SQL need to be used as DB server and not an application server. The solution with the external activation is a workaround because you can offload to outside SQL (security). My problem with this solution is that you need to write an application the connects to the SQL server broker queue, get the data and then forward it to the WSDL service. There looks to be no direct solution available to consume the webservice directly with external activation. This is a bit a disappointment to me to be honest. It requires alot of coding for actually doing something very simple. I didn't really look into the ASP.NET threading. The reason is that I don't want the ASP.NET front end application to connect to the webservice. The main reasons are security (I want to run it in the back end without any link to the front end), I want to offload the front end webserver for the best performance and I don't like the idea of threading in ASP.NET.
What is your opinion/suggestions on this?
Thanks