Re: Would it make sense to use Rhino ESB as communication infastructure between Windows Services

[Jason Meckley]

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:

Hi,

 

We're building a reporting system in C#. The data source will be file feeds that will be imported into a SQL Server 2008 DB via bcp ( SSIS is not an option as its use is unauthorised by our client).

 

Ideally we'd like to have some sort of FileWatcher, so as soon as the files arrive we trigger the bulk upload. We think that a possible option is to have a C# component hosted by a Windows Service that would be watching the "incoming" folder and would invoke the upload process as the file arrives.

 

We can either have a separate process to do the bulk upload or doing it in the same one but using background threads. What are your thoughts on this?

 

If we've got separate processes (windows services), we'd think of using Rhino ESB - Files arrive, then send a message to the other process so that it can import it into the DB.

 

When all the files have been imported, then another process would perform some calculations off that data and generate the report.

 

Does above make sense or is too overengineered? Another option would be using a single process and then leverage multithreading programming to process multiple files at the same time.

 

Regards.

[Daventry]

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.

[Jason Meckley]

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.

[Daventry]

Hi,

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.

Regards.

[Jason Meckley]

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.

[Daventry]

Fair enough, we'll think about it.

 

Many thanks for your replies!

[Nathan Palmer]

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.)

Nathan Palmer

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/z2Azm_5-67MJ.

To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.