Polling Architecture Suggestion Required
-
Technical Details: .NET Framework 4.0 (C#) Windows Server 2008 Requirement: 1. Polling a local folder for files 2. Polling a Message Queue for messages 3. Polling a FTP folder for files 4. Polling a SMTP server for mails We need a single architecture that can be easily extended and also independently maintained for different requirements. For example if we need to add a new mail server to be monitored, we would just add an entry (with sufficient details) in a config-like file and the system should ideally pick the config entry and start polling for that. Another example to stop a single polling instance, it should be sufficient to just remove the entry from the config-like file. Whenever polling succeeds, i.e. if a new mail is received, a new file is found in a folder, etc. the system should be able to instantiate a new controled thread to process the item in question. It is a complex requirement for me to decide on an architecture solution to this. Would be thankful all who can provide possible solutions along with pros & cons of the same. Thanks in advance.
-
Technical Details: .NET Framework 4.0 (C#) Windows Server 2008 Requirement: 1. Polling a local folder for files 2. Polling a Message Queue for messages 3. Polling a FTP folder for files 4. Polling a SMTP server for mails We need a single architecture that can be easily extended and also independently maintained for different requirements. For example if we need to add a new mail server to be monitored, we would just add an entry (with sufficient details) in a config-like file and the system should ideally pick the config entry and start polling for that. Another example to stop a single polling instance, it should be sufficient to just remove the entry from the config-like file. Whenever polling succeeds, i.e. if a new mail is received, a new file is found in a folder, etc. the system should be able to instantiate a new controled thread to process the item in question. It is a complex requirement for me to decide on an architecture solution to this. Would be thankful all who can provide possible solutions along with pros & cons of the same. Thanks in advance.
Hi, I would use something like Strategy[^] to make different polling implementations. If a strategy finds something, I would let it create a Command[^] that can be executed by a thread. A Command can hold the data and have its own implementation. All Strategy and Command implementations regarding a technology e.g. mailing could go into its own package/assembly and get wired to a common execution platform at start-up. I hope it makes sense. Kind Regards, Keld Ølykke
-
Hi, I would use something like Strategy[^] to make different polling implementations. If a strategy finds something, I would let it create a Command[^] that can be executed by a thread. A Command can hold the data and have its own implementation. All Strategy and Command implementations regarding a technology e.g. mailing could go into its own package/assembly and get wired to a common execution platform at start-up. I hope it makes sense. Kind Regards, Keld Ølykke
-
Thanks Keld Ølykke! I got the overall idea, but I will need to read up on these two patterns and think of the solution (pros & cons). Also the "common execution platform" itself might need a little more thinking ( for amateur like me at least :) )
Most def. Hav fun!
-
Technical Details: .NET Framework 4.0 (C#) Windows Server 2008 Requirement: 1. Polling a local folder for files 2. Polling a Message Queue for messages 3. Polling a FTP folder for files 4. Polling a SMTP server for mails We need a single architecture that can be easily extended and also independently maintained for different requirements. For example if we need to add a new mail server to be monitored, we would just add an entry (with sufficient details) in a config-like file and the system should ideally pick the config entry and start polling for that. Another example to stop a single polling instance, it should be sufficient to just remove the entry from the config-like file. Whenever polling succeeds, i.e. if a new mail is received, a new file is found in a folder, etc. the system should be able to instantiate a new controled thread to process the item in question. It is a complex requirement for me to decide on an architecture solution to this. Would be thankful all who can provide possible solutions along with pros & cons of the same. Thanks in advance.
I would suggest building a plug-able framework where the main app's job is maintaining plug-in modules. Each module can be standalone and handle specific source but discoverable by the main app. The main app can scan a folder for DLL or EXE with class that implements some common interface and dynamically instantiate modules using factory. Modules can be add or remove from the folder at will.
-
Technical Details: .NET Framework 4.0 (C#) Windows Server 2008 Requirement: 1. Polling a local folder for files 2. Polling a Message Queue for messages 3. Polling a FTP folder for files 4. Polling a SMTP server for mails We need a single architecture that can be easily extended and also independently maintained for different requirements. For example if we need to add a new mail server to be monitored, we would just add an entry (with sufficient details) in a config-like file and the system should ideally pick the config entry and start polling for that. Another example to stop a single polling instance, it should be sufficient to just remove the entry from the config-like file. Whenever polling succeeds, i.e. if a new mail is received, a new file is found in a folder, etc. the system should be able to instantiate a new controled thread to process the item in question. It is a complex requirement for me to decide on an architecture solution to this. Would be thankful all who can provide possible solutions along with pros & cons of the same. Thanks in advance.
One way to make it generic and easy adaptable is: Extend the .Net FileWatcher class and create a component that listens to certain file changes in a directory. Next Create a windows Service application that will use this component. The settings and number of instances can be made configurable through the app config file of your windows service application. When a Instance notices a file change write a message to the application log file of the windows event Log. Using the Windows Event viewer You then can create custom views that filter for your messages generated by your Windows service application. On each custom view you can attach a task that will be triggered each time a message is written. To this task you can attach a batch file, powershell script or VBScript that will execute and perform your needed functionality each time the task is triggered.