I have a wcf service and i want to call a method automatically , immediately after the publishing in IIS. Like an initialization of the WCF service without having to call the method manually or from somewhere else. Where should i place my Initialize method in WCF Service in order to run exactly after the start of the application?
If you're hosting in IIS you can use the application_start event within the Global.asax of the web app that hosting tHE WCF service to do any application initialization. If you are trying to call one of your services when it is first installed then this is likely the wrong approach.
What is the motivation for running some code on start up of the web service? If you are trying to get around a slow initial call to the WCF service I suggest you would want to do some work on the WCF client-side rather than in the service...but Im just guessing at your motivation here
Initialization of the WCF service? So do you have singleton service or do you want to initialize some global state? Otherwise initialization doesn't make sense because service instances will be created for actual clients.
By default IIS starts application when it is accessed first time. If you place initialization in Application_Start (HttpApplication or Global.asax) the code will run when the application is first accessed. But accessing the service is not something that your application can initiate.
IIS 7.5 (Windows 2008 R2) has warm-up module which can run some code when pool is recycled or worker is restarted. If you use other version of IIS you have to use some external solution like custom application pinging your service in regular intervals.
Related
This is ASP.NET ASMX Web Service / .NET Framework 4.0.
In web service, I want to execute one method on another thread something like “Fire and Forget” so that Web Service returns some value in response immediately to web site. That method on another thread could take 10 minutes after Web Service returns response immediately to Web site. Also, I do not need return value of that method.
I have tested this scenario using ThreadPool.QueueUserWorkItem and it seems that thread started using ThreadPool will still keep executing even after Web Service returns response back to Web site. Am I correct here? Also is there a better way to achieve this?
The problem is that every now and then, ASP.NET will recycle the app pool. Because it doesn't know about your background task, it will not be considered and will be aborted when the AppDomain is disposed.
Most of the time, the work will complete, but if you run for long enough, you will encounter this scenario.
There are two solutions:
1) The "proper" way is to write a Windows Service that runs outside ASP.NET. You can send instructions to the Service over WCF.
2) The "quick and dirty" way is to write a hidden web service in your ASP.NET site that is never called by users. Your app starts an asynchronous request to the hidden service and then returns its own result to the user, without waiting.
ASP.NET does not know that the request to the hidden service came from inside your app - it just treats it as another request. Because ASP.NET knows about this request, it will not abort it when it recycles.
I have an ASP.NET Webform which currently calls a Java WebService. The ASP.NET Webform is created/maintained inhouse, whereas the Java WS is a package solution where we only have a WS interface to the application.
The problem is, that the Java WS is sometimes slow to respond due to system load etc. and there is nothing I can do about this. So currently at the moment there is a long delay on the ASP.NET Webform sometimes if the Java-WS is slow to respond, sometimes causing ASP.NET to reach its timeout value and throw the connection.
I need to ensure data connectivity between these two applications, which I can do by increasing the timeout value, but I cannot have the ASP.NET form wait longer than a couple of seconds.
This is where the idea of a queuing system comes into place.
My idea is, to have the ASP.NET form build the soap request and then queue it in a local queue, where then a Daemon runs and fires off the requests at the Java-WS.
Before I start building something from scratch I need a couple of pointers.
Is my solution viable ?
Are there any libraries etc already out there that I can achieve this functionality with ?
Is there a better way of achieving what i am looking for ?
You can create a WindowsService hosting a WCF service.
Your web app can them call the WCF methods of your Windows Service.
Your windows service can call the java web service methods asynchronously, using the
begin/End pattern
Your windows service can even store the answers of the java web service, and expose them through another WCF methods. For example you could have this methods in your WCF service:
1) a method that allows to call inderectly a java web service and returnd an identifier for this call
2) another method that returns the java web service call result by presenting the identifier of the call
You can even use AJAX to call the WCF methods of your Windows Service.
You have two separate problems:
Your web form needs to learn to send a request to a service and later poll to get the results of that service. You can do this by writing a simple intermediate service (in WCF, please) which would have two operations: one to call the Java service asynchronously, and the other to find out whether the async call has completed, and return the results if it has.
You may need to persistently queue up requests to the Java service. The easiest way to do this, if performance isn't a top concern (and it seems not to be), is to break the intermediate service in #1 into two: one half calls the other half using a WCF MSMQ binding. This will transparently use MSMQ as a transport, causing queued requests to stay in the queue until they are pulled out by the second half. The second half would be written as a Windows service so that it comes up on system boot and starts emptying the queue.
you could use MSMQ for queuing up the requests from you client.
Bear in mind that MSMQ doesn't handle anything for you - it's just a transport.
All it does is take MSMQ messages and deliver them to MSMQ queues.
The creation of the original messages and the processing of the delivered messages is all handled in your own code on the sending and receiving machines: the destination machine would have to have MSMQ installed plus a custom service running to pick them up and process them
Anyway there is a librays for interop with MSQM using JAVA : http://msmqjava.codeplex.com/
Another way could be you can create a queue on one of your windows box and then create a service that pick up the messages form the Queue and foreward them to the Java service
I've been researching for days and I've gotten to the point where my WCF service creates an Access object via com/interop. I've ran the OpenCurrentDatabase call for the Access object without an error but Application.CurrentDB is still nothing/null. If the CurrentDB is nothing then I surely can't call Application.Run "myFunction" I realize WCF services aren't meant to be user interactive, but it's a long story why I'm trying to go this route. Basically I need to have a proof of concept ready sooner rather than later and the alternative (correct) route involves the complete re-writing of a large complex access VBA application. It's not a permissions issue, I have the IIS user names added to the security tab. What I really need is a way to set Environment.UserInteractive to true so my WCF service can create an instance of Access on my server machine, run the VBA functions, close out, return true. I'm using VS 2010 for the WCF, IIS 7 for my server, Access 2010 for the VBA application. Please help!
The answer is to have the WCF service write the access macro name to a database and have a desktop application on the server machine monitor the database. The desktop application loads access, performs the actions, and writes back to the database upon completion. The WCF service monitors the database waiting for an "operation complete" status and returns the result.
Given an application pool that runs on integrated mode, the apppool is able to provide service to "Managed Handler Requests" (GET an aspx page) as well as "non-Managed Handler Requests" (GET a jpg file).
When processing a MHR request the app pool should consider all modules but for nonMHRs should not consider the modules marked with the Managed Handler precondition.
Has the app pool two different HttpAplication pipelines (one for MHRs and the other for nonMHRs) ?
Or he only has one pipeline and is able to decide which httpAplication event handlers are raised depending of the request?
I guess the app pool decides if the request is managed or not, before httpApplication starts the BeginRequest. At least before the AuthenticateRequest. Is that right?
Response in the link:
All resources served by IIS are mapped to a handler in configuration. If the configuration mapping does not exist, requests for the resource will receive a 404 HTTP status. In addition to the configuration mapping, which takes place before the pipeline begins, the handler mapping can be changed during request execution ...
The Init function of the modules are only executed once (maybe in the application pool startup) independently of the Managed Handler precondition?
I guess the apppool doesn't create the whole pipeline (registering httpaplication events and so) for each request.
Thanks in advance,
UPDATE1: After reading the link I still "see" two diferent pipelines given a single apppool.
By diferent pipelines I mean two diferent sets of event handlers registered in the IIS pipeline:
BEGIN_REQUEST
AUTHENTICATE_REQUEST
AUTHORIZE_REQUEST
RESOLVE_REQUEST_CACHE
MAP_REQUEST_HANDLER
ACQUIRE_REQUEST_STATE
PRE_EXECUTE_REQUEST_HANDLER
EXECUTE_REQUEST_HANDLER
RELEASE_REQUEST_STATE
UPDATE_REQUEST_CACHE
LOG_REQUEST
END_REQUEST
When an application pool in integrated mode starts, it can look up the modules section and can execute the Init function of each module (indepentdently of the precondition setting). The Init function of each module registers itself in some IIS pipeline stages. But at runtime when processing non-managed requests it should skip the event handlers of modules with precondition managed handler. How can do that?
UPDATE2:
From my understanding, an app pool (the windows process) host an ASP.Net runtime (httpRuntime in System.Web?). This runtime contains a pool of httpApplication objects. When app pool starts (or maybe until first request arrive) several httpApplications are instantiated. At this time the Init method of the httpModules (under modules in web.config) are called.
Until IIS7 integration mode appearance I thought all httpApplication objects would be clones, but because depending of the type of handler's request (managed or non managed) some httpModules should be considered or not, I deduce that the httpRutime contains two httpApplication pools or maybe a given httpApplication object is only able to process managed handler requests or non-managed hadler requests, but never the two...
I think you can read this one
http://blogs.msdn.com/b/tmarq/archive/2007/08/30/iis-7-0-asp-net-pipelines-modules-handlers-and-preconditions.aspx
In there you see that the IIS has only one pipeline. The "classic" way of serving asp.net requests begins in the IIS pipeline’s EXECUTE_REQUEST_HANDLER event. Think of ASP.NET in classic mode as a pipeline within the IIS pipeline.
With the integrated mode you can basically plug in managed code in the whole IIS pipeline series of events, like adding asp.net forms authentication to static files like .jpg
I create a WCF Service Application that runs in IIS 7.0 . In its initialization I start an endless loop ( while(true) ) , but after a period of time ,where I didn't call a method from his svc file, the wcf pass in an idle mode, and it doesn't react in the process the loop has to do. It is like it stops working. And then if i call a method to his svc file then starts working again. Is there a solution to avoid the idle mode so it can continue to keep the procedure in the loop alive?
WCF services are designed to "wake up" when requests are made.
If what you want is something like continuous polling, you may want to consider creating a Windows Service instead.
If you're looking for a WCF service that maintains state, you'll have to implement that yourself. One way is to deploy a Workflow Service (using WF 4) with persistence, such as SqlWorkflowInstanceStore. It exposes its interface using WCF. The service will be idle between calls, but instances will remember state.
WCF is meant to be consumed and to fire events, not to host long-running processes. You really want WF (workflow foundation) or BizTalk to host some long-running events. WCF events are typically short lived. You can create a XAMLX which combines the two concepts.