Friday, March 30, 2012

Replacing FTP with Service Broker

Hi there

Could you use service broker to replace FTP? We currently move hundreds of files around from source systems to destination systems. Some systems share the same files, some only recieve a subset of the data in the files.

This typically takes place early morning the next day.

Would it be possible, and I guess more importantly, has anyone done this;

Use service broker on all the source systems,sending to a central routing server that determines which destination servers require which piece of data and then forward it onto those servers. It would need to handle very high volumes of data.

The central server would also be required to transform some of the data as it passes through.

This would completely change the way in which we would exchange data around our network, allowing us to process more realtime than 1 day late.

Is there anyone who has done this, are their any case studies on this?

Thank you in advance.

Mark S

Service Broker could provide reliability for such a service (automatic fragmentation of files, automated resuming of intrerupts, guaranteed delivery of files) and secure trafic (encryption of files during tranfer).

However, FTP is a well known protocol and there are numerous tools and utilities to manage and monitor FTP, and you will miss this environment of familiar tools.

Frankly, altough I'm a big SSB fan, I wouldn't replace a ageneric FTP service with SSB lightly. The biggest advantage of FTP is that it does not require any write operation on the file location, only on the client. With SSB, to 'send' a file (the equivalent of a FTP GET) would require writing the file in sys.transmission_queue (database + log write) and then deleting this file from sys.transmsision_queue (again database+log write). All these writes add up to the needed disk space (altough both the database and the log space eventually get reused, everything 'in flight needs space) and as well to the necessary I/O bandwith. Also, the fragmentation logic, automatic retry and encryption all have a CPU cost, considerably higher than a FTP server would cosume.

So the SSB reliability guarantee comes at a price (primarily I/O + CPU cost), depending on the expected troughput this can range from an insignificant issue to a show stopper.

No comments:

Post a Comment