Architecture of Windows service and reliability
-
I'm creating a Windows service that will be responsible for hosting and general management of additional modules with a common interface. Typically, these modules will be responsible for invoking a Workflow Foundation workflow, but that will not be a design requirement -- the only requirement is that the module adheres to the interface. I will not necessarily have control of what goes on in each module. Therefore, reliability of the remaining modules is a concern. Currently, I'm considering a scenario where the Windows service manages the creation and lifetime of one or more separate host processes (EXE) where each host process is simply a shell to run a host module. Remoting would be used for interprocess communication such as start, stop, health, common services (provided from the service), et al. The good thing about this design is that I can easily manage the state of the processes and spawn new ones as needed -- OOM situations, poorly behaving workflows, etc. My first concern with this design is security. Specifically, I would want the host processes to run within the same security context as the service that created it. I will test this at some point soon, but I figured someone would probably know this offhand. My second concern with the design is the Workflow Foundation resources. Each host process would get its own instance of the Workflow Runtime and there could possibly be several host processes running. Would this create as unnecessary burden on the computer as I think it would -- especially considering I would take advantage of some of the WF services such as the tracking and persistence services. And finally if this architecture sounds overally burdensome, do you have any other recommendations?
-
I'm creating a Windows service that will be responsible for hosting and general management of additional modules with a common interface. Typically, these modules will be responsible for invoking a Workflow Foundation workflow, but that will not be a design requirement -- the only requirement is that the module adheres to the interface. I will not necessarily have control of what goes on in each module. Therefore, reliability of the remaining modules is a concern. Currently, I'm considering a scenario where the Windows service manages the creation and lifetime of one or more separate host processes (EXE) where each host process is simply a shell to run a host module. Remoting would be used for interprocess communication such as start, stop, health, common services (provided from the service), et al. The good thing about this design is that I can easily manage the state of the processes and spawn new ones as needed -- OOM situations, poorly behaving workflows, etc. My first concern with this design is security. Specifically, I would want the host processes to run within the same security context as the service that created it. I will test this at some point soon, but I figured someone would probably know this offhand. My second concern with the design is the Workflow Foundation resources. Each host process would get its own instance of the Workflow Runtime and there could possibly be several host processes running. Would this create as unnecessary burden on the computer as I think it would -- especially considering I would take advantage of some of the WF services such as the tracking and persistence services. And finally if this architecture sounds overally burdensome, do you have any other recommendations?
-
tgrt wrote:
that will be responsible for hosting and general management of additional modules with a common interface.
That sound a lot like what the Com+ Appilcation Server does. Is there some reason you are not using it?
-
This will be a 100% managed application using C#. I'm not familiar with the capabilities of the COM+ application server. But, I can say that the service will be providing more than trivial capabilities to each of the modules.
-
tgrt wrote:
This will be a 100% managed application using C#
Even more reason to look at COM+, the BCL has classes for create Com+ Serviced components. Check it out[^].
Thank you for the article. It seems to be focused more on the transaction side. However, I will look into the COM+ serviced components further to make sure they'll meet all my requirements. The modules that will be managed by the service will work independently of one another and additionally the workflows they run will work independently of one another. The ultimate question of reliability will come when I determine what happens when an OOM exception occurs in the COM+ serviced component. The last thing that can happen is that the service is corrupted in any way shape or form.
-
tgrt wrote:
This will be a 100% managed application using C#
Even more reason to look at COM+, the BCL has classes for create Com+ Serviced components. Check it out[^].
I looked at the MSDN documentation for the COM+ components. I may be missing something with what is probably just a superficial look, but it doesn't look like it's going to do what I want. My modules will be controlled by the service in so much as a start/stop basis. The service will also centralize tracing, monitor the health of the modules, and provide some common services such as configuration settings. However, each module will be responsible for running any number of workflows (whether through WF or another mechanism) based on different physical events -- the specific type of the module will determine what and how.
-
I looked at the MSDN documentation for the COM+ components. I may be missing something with what is probably just a superficial look, but it doesn't look like it's going to do what I want. My modules will be controlled by the service in so much as a start/stop basis. The service will also centralize tracing, monitor the health of the modules, and provide some common services such as configuration settings. However, each module will be responsible for running any number of workflows (whether through WF or another mechanism) based on different physical events -- the specific type of the module will determine what and how.
Having been only introduced to it last night, I will tentatively suggest looking at WCF as a more focused, more current, alternative to COM+. Don't be misled by the Communications term, which tends to conceal its role as a services infrastructure.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
Having been only introduced to it last night, I will tentatively suggest looking at WCF as a more focused, more current, alternative to COM+. Don't be misled by the Communications term, which tends to conceal its role as a services infrastructure.
My head asplode!
Calling all South African developers! Your participation in this local dev community will be mutually beneficial, to you and us.
-
I looked at the MSDN documentation for the COM+ components. I may be missing something with what is probably just a superficial look, but it doesn't look like it's going to do what I want. My modules will be controlled by the service in so much as a start/stop basis. The service will also centralize tracing, monitor the health of the modules, and provide some common services such as configuration settings. However, each module will be responsible for running any number of workflows (whether through WF or another mechanism) based on different physical events -- the specific type of the module will determine what and how.
Well I'm not at all surprised that without complete requirements, which is not actually possible in text messaging, you can slightly miss the target, if indeed I have. More generally my point is that there is very little need to build your own Service these days. I see you are now looking at WCF, I haven't looked into that yet so I have no idea how it relates to my point of not needing to author your own hosting process. In terms of reliability and scalability I would require a proven concrete reason to author my own service rather than use an existing hosting platform from the current Windows Server products. Keep in mind it's not because I am apprehensive about writing a service, I have authored so many services since NT4 that I can't even remember them all. Back in 2000 I lead a project that developed a proprietary application server ( long Dilbert story ) in Java so I have no fear of doing it but still, not now, not without a proof.
-
Thank you for the article. It seems to be focused more on the transaction side. However, I will look into the COM+ serviced components further to make sure they'll meet all my requirements. The modules that will be managed by the service will work independently of one another and additionally the workflows they run will work independently of one another. The ultimate question of reliability will come when I determine what happens when an OOM exception occurs in the COM+ serviced component. The last thing that can happen is that the service is corrupted in any way shape or form.
tgrt wrote:
when an OOM exception occurs
an Out Of Memory exception?
tgrt wrote:
The last thing that can happen is that the service is corrupted in any way shape or form.
Again without knowing more about your requirements I'm just guessing. This is because you need to execute modules you don't trust? If the supplied modules don't handle their own errors what are you going to do to ensure against corruption? So you handle the exception and then what?
-
tgrt wrote:
when an OOM exception occurs
an Out Of Memory exception?
tgrt wrote:
The last thing that can happen is that the service is corrupted in any way shape or form.
Again without knowing more about your requirements I'm just guessing. This is because you need to execute modules you don't trust? If the supplied modules don't handle their own errors what are you going to do to ensure against corruption? So you handle the exception and then what?
You're correct, when I say OOM, I mean out of memory condition which might be an out of memory exception or stack overflow exception, etc. Anything that fits within a broad category of non-application based exceptions. I'm trying to provide enough information without laying out all of the requirements which is obviously not possible within this medium. The executed modules will trusted in the context of security, but not within the context of stability. For example, I'll provide the controlling service (through whatever that turns out to be) and several executing module. The user, being a system administrator or developer type, will choose which ones they need and create workflows that execute based on criteria dependent on each executing module. The user can also extend the solution in such a way as creating their own executing modules based on a common interface. What I don't want is for a executing module to fail and bring down other executing module or even worse the service itself. The service will monitor the health of the executing modules and if there is a failure it will cleanup anything that is necessary and start a brand new shiny executing module to pick up where the old one left off.
-
Well I'm not at all surprised that without complete requirements, which is not actually possible in text messaging, you can slightly miss the target, if indeed I have. More generally my point is that there is very little need to build your own Service these days. I see you are now looking at WCF, I haven't looked into that yet so I have no idea how it relates to my point of not needing to author your own hosting process. In terms of reliability and scalability I would require a proven concrete reason to author my own service rather than use an existing hosting platform from the current Windows Server products. Keep in mind it's not because I am apprehensive about writing a service, I have authored so many services since NT4 that I can't even remember them all. Back in 2000 I lead a project that developed a proprietary application server ( long Dilbert story ) in Java so I have no fear of doing it but still, not now, not without a proof.
-
You're correct, when I say OOM, I mean out of memory condition which might be an out of memory exception or stack overflow exception, etc. Anything that fits within a broad category of non-application based exceptions. I'm trying to provide enough information without laying out all of the requirements which is obviously not possible within this medium. The executed modules will trusted in the context of security, but not within the context of stability. For example, I'll provide the controlling service (through whatever that turns out to be) and several executing module. The user, being a system administrator or developer type, will choose which ones they need and create workflows that execute based on criteria dependent on each executing module. The user can also extend the solution in such a way as creating their own executing modules based on a common interface. What I don't want is for a executing module to fail and bring down other executing module or even worse the service itself. The service will monitor the health of the executing modules and if there is a failure it will cleanup anything that is necessary and start a brand new shiny executing module to pick up where the old one left off.
tgrt wrote:
What I don't want is for a executing module to fail and bring down other executing module or even worse the service itself. The service will monitor the health of the executing modules and if there is a failure it will cleanup anything that is necessary and start a brand new shiny executing module to pick up where the old one left off.
Yes the Com+ Application Server does all of that
-
tgrt wrote:
What I don't want is for a executing module to fail and bring down other executing module or even worse the service itself. The service will monitor the health of the executing modules and if there is a failure it will cleanup anything that is necessary and start a brand new shiny executing module to pick up where the old one left off.
Yes the Com+ Application Server does all of that
led mike wrote:
Yes the Com+ Application Server does all of that
Can it also provide services such as centralized configuration settings (including database connection strings), centralized tracing, et al. to each individual module? It occurred to me that one of the aspects of this application may not be clear. Logically this is a single application that will run by itself with no user interaction. It will essentially be responding to some external event -- the definition of the event will vary from module to module. My premise for separating the modules in a physical manner is for the purpose of reliability, but a physical separation is not a requirement in of itself. The simplist architecture is that the service would create the individual classes without the host and manage them; however, in that scenario an OOM condition would bring everything down.
-
led mike wrote:
Yes the Com+ Application Server does all of that
Can it also provide services such as centralized configuration settings (including database connection strings), centralized tracing, et al. to each individual module? It occurred to me that one of the aspects of this application may not be clear. Logically this is a single application that will run by itself with no user interaction. It will essentially be responding to some external event -- the definition of the event will vary from module to module. My premise for separating the modules in a physical manner is for the purpose of reliability, but a physical separation is not a requirement in of itself. The simplist architecture is that the service would create the individual classes without the host and manage them; however, in that scenario an OOM condition would bring everything down.
Happy New Year tgrt! I see the Design and Architecture forum has returned. I did not ignore your last post, the forum was not available after they launched the new version of the site. How is your project going? Do you need any further assistance?
tgrt wrote:
Logically this is a single application that will run by itself with no user interaction.
That is what the COM+ Application Server is.
tgrt wrote:
the definition of the event will vary from module to module.
Yes, each COM+ component defines what it does and how it does it.
tgrt wrote:
however, in that scenario an OOM condition would bring everything down.
The COM+ server is fairly mature as it first surfaced back in like 1996 or something like that. I imagine you will find it quite robust in the latest versions of the Microsoft Server Operating Systems.