I have a workflow service (xamlx) which implements some complex business process (with persistence and correlation). This service is hosted in IIS and I use AppFabric to control workflow instanses (Terminate them or Cancel).
Now I need to allow users, who don't have administrative rights and, hence, access to AppFabric to stop workflows (Terminate) if they make mistakes while invoking it and restart the workflow.
Is it possible to implement the same logic as it is used in AppFabric with C# code (I plan to create a web service with the help of which it would be possible to terminate workflows)
Thanks in advance!
The AppFabric use a Workflow Control Endpoint to handle all commands you issue using the UI. You can use the WorkflowControlClient in your code to do the same thing. Note that by default the AppFabric used the NetNamedPipeBinding which only allows for local connections so you might need to add another binding like the BasicHttpBinding.
Related
I would like to create a service whose job is to monitor other services that are running within the same process, and then report basic information like health or service dependencies. I'm having trouble figuring out the best way for my monitoring service to access detailed information about the other services without having to have each service publish its metadata or expose some custom endpoint the monitoring service can communicate with. If I load the configuration and read through it I can get most of the way there but this approach has a few weaknesses:
Getting the absolute URI for each endpoint can be difficult,
especially when using IIS hosting or fileless activation.
Any configuration that was done programmatically would not be able to be read by the monitoring service
What I'd like to be able to do is to somehow access the ServiceDescription to get all the information I need about each ServiceHost, without requiring any work on the part of the service designer to give it to me. Is something like this possible?
If you've checked Channs links and are convinced you need to roll your own health monitoring infrastructure, you'll probably need to either derive from ServiceHost or go all out and derive from ServiceHostFactoryBase or possibly do both depending on what you need to implement. They'll give you access to the ServiceDescription instance for each service as it is spun up.
One alternative would be to use WCF's built-in health monitoring and performance monitoring capabilities. This works at the individual service level though.
I know that it is not a good idea to have timers inside a WCF service class that is hosted inside IIS since these are meant to have short lifetimes. And from the advice here it also sounds like having a service is the best way to go for that situation.
But has anyone tried using timers inside a self-hosted service in production? We have a windows service that acts as a client and uses timers to do periodic operations at the moment.
This is fine for most cases, but I am concerned about the robustness of the design: some of the operations are critical (financial system calculation triggers). Since the WCF service and the windows service are two components, ensuring both are running is difficult.
If I moved the critical operations to a timer inside the WCF Service I remove that problem, but what else should I be concerned about then?
If I understand correctly, your question is actually about IIS-hosted WCF services, is that right?
IIS controls the application pool that your WCF service runs in. That means that IIS may decide to recycle your application pool and all the apps/services in it. Then your service only gets activated again once it is called by a client. So, scheduling in WCF services or ASP.NET applications cannot be relied on.
The picture of course changes if you can self-host your WCF service. Then there is no IIS application pooling to take into account, and you can schedule at will. Therefore, if you need the combination of WCF + scheduling, it's best to create a Windows service that will include both.
Hey all, I have one WCF project which creates an instance of a workflow, the workflow after created is persisted and unloaded (then I can resume it using bookmarks). I am using WorkflowApplication.
In the database I can see the record but AppFabric doesn't show me the persisted instance.
Does AppFabric only works for WF xalmx services???
Any help will be appreciated :)
Thanks
Paúl.
Yes AppFabric only shows you information about workflow services it manages. By using the WorkflowApplication you are basically doing all workflow management yourself and keeping AppFabric completely out of the loop. If you want your workflows to show up in AppFabric you should use a workflow service, ie XAMLX file, and use the Receive activity and WCF to work with it.
For my projects I need quite often to create windows services.
I need them for scheduling operations, file system watching, asynchronous or long running side tasks (backup files, sending messages, check incoming mail to process, notifications etc).
I also use them to expose WCF services that are cross applications in the enterprise.
The self hosted scenario seems to me more appropriate as we are still on II6 that is quite limited (only http) for exposing WCF.
Most of) the services need also to expose some kind of administration interface (web or desktop) for reporting, starting and stopping the various services etc.
Seems strange to me that a "host container" that leverages most of these features (host, install new services, remote ui for admin, exposing wcf, scheduling etc) with some kind of mef plugins doesn't already exists.
What are the options if I do not want to start from scratch?
I am a developer for an open source windows service hosting framework called Daemoniq. I understand how installers can be an inconvenience so creating installers on the fly is one of its features. You can download it from http://daemoniq.org
Current features include:
container agnostic service location via the CommonServiceLocator
set common service properties like serviceName, displayName, description and serviceStartMode via app.config
run multiple windows services on the same process
set recovery options via app.config
set services depended on via app.config
set service process credentials via command-line
install, uninstall, debug services via command-line
Please feel free to have a look at it. Code contributions are also welcome =D
Thanks!
There is one host server in development (Microsoft) - codename Dublin.
The possible option would be to create one Windows Service - host application, which will load all of your WCF services and create ServiceHost for each of them (for instance, through reflection).
Having only one windows service would make it easy to administer all service hosts (you wouldn't have to administer windows service, but only in-process hosts).
We have an existing WCF service that makes use of wsDualHttpBinding to enable callbacks to the client. I am considering moving it to netTcpBinding for better performance, but I'm quite wary of moving away from the IIS-hosted service (a "comfort zone" we currently enjoy) into having our own Windows service to host it. I was hoping we could still host this on IIS 7 but Win2K8 won't be reality for us for some time.
What things should I watch out for when creating our own Windows service to host our WCF service? Things like lifetime management and request throttling are features that come free with IIS hosting so I'd also like to know how we can effectively host our service on our own without the convenience of having IIS do the hard work for us. Thanks! :)
So as you cannot host using WAS there are a couple of things to realise.
If the service crashes it doesn't restart by default (although you can change this in service properties)
IIS will recycle the application pool if it hangs or grows too big; you must do this yourself if you want the same sort of reliability.
You must create an account for the service to run under, or use one of the default services. Resit the temptation to run the service as SYSTEM or under an administrator account; if you want to use a built in account use NETWORK SERVICE.
It becomes harder to debug in situ.
Consider using a error logger such as log4net
Having said that I deployed a WCF/Windows service combination for a customer 9 months ago; it's heavily used and hasn't died once.
You can request throttle in a Windows service, it's part of the WCF configuration. Note the defaults are very low, it is likely you will have to increase these.
Hosting in a Windows Service Application (http://msdn.microsoft.com/en-us/library/ms734781.aspx) is a good start.
If you can host your service on Vista, you can also benefit from Windows Process Activation Service (WAS). WAS is a generalization of the IIS process activation, which can be used to activate processes over non-HTTP endpoints (TCP, Named Pipe, MSMQ). To learn more about WCF hosted in WAS, read http://msdn.microsoft.com/en-us/library/ms733109.aspx. To learn how to install and configure WAS, read http://msdn.microsoft.com/en-us/library/ms731053.aspx.