|Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Jason Meckley||7/12/12 9:18 AM|
I don't see why an ESB is needed for this type of operation. I might use Rhino.ETL to manage the ETL operations from file to DB, but other than that I would stick with a simple windows service and file system watcher object. when a file is created. kick of a Rhino ETL process to consume in the file. when the ETL completes generate the report.
On Thursday, July 12, 2012 9:14:09 AM UTC-4, Daventry wrote:
|Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Daventry||7/12/12 10:07 AM|
Speaking of Rhino ETL - Is it faster than the bcp command line tool?
On the other hand - Rhino ETL relies on FileHelpers to parse text files, doesn't it? Don't you have to pass in a type as a parameter? i.e - You'd have to generate a C# class where each property represents a column in the file.
The reason for having a separate windows service is that the users will have a silverlight frontend to view the reports, override some values and repeat some calculations. If we just have the ASP.NET web site running everything and it goes down, the files wouldn't be loaded overnight, right? So we were thinking of using RSB for the communication between the windows service and the web host - send a message to reload files, regenerate reports, notify progress update from the report generation, etc.
|Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Jason Meckley||7/12/12 10:21 AM|
Faster? I don't know. I use it because it preforms well, is easy to implement and dead simple to unit test operations.
You lost me with asp.net, silverlight and needing to "re-download" files if the server is down. An ESB is designed to coordinate log running asynchronous work flows. What you describe doesn't fit that model. you are initiating requests and waiting for a response.
|Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Daventry||7/12/12 2:20 PM|
Sorry about the confusion, let me try to rephrase
We've got a web app to visualize reports for a given date. In the meantime the feeds for a new date are available, so we have to import them but this process takes over an hour. In the meantime the users might still be viewing reports for an older date. Would you have the import logic running in the same application server on a backgroud thread?
Hope it's a little more clear now.
|Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Jason Meckley||7/13/12 5:58 AM|
I would keep the UI and background service as separate components. I'm just not sure I would jump to an ESB to handle communication between the two.
|Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Daventry||7/13/12 7:07 AM|
Fair enough, we'll think about it.
Many thanks for your replies!
|Re: [rhino-tools-dev] Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services||Nathan Palmer||7/22/12 2:54 PM|
Just as a note. I've built this scenario and it's worked out great. We had a website where the user could trigger back-end long running processes. The user would hit a button which would send a message to the bus and ultimately be picked up by a windows service that would run it. Once it was complete the user interface would get updated (the service actually updated the database however and didn't communicate back through the bus.)