Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > .NET > Other .NET > General .NET
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
General .NET For general discussion of MICROSOFT .NET topics that don't fall within any of the other .NET forum subcategories or .NET language forums.  If your question is specific to a language (C# or Visual Basic) or type of application (Windows Forms or ASP.Net) try an applicable forum category. ** PLEASE BE SPECIFIC WITH YOUR QUESTION ** When posting here, provide details regarding the Microsoft .NET language you are using and/or what type of application (Windows/Web Forms, etc) you are working in, if applicable to the question. This will help others answer the question without having to ask.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the General .NET section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old November 30th, 2011, 09:15 AM
Friend of Wrox
Points: 3,489, Level: 24
Points: 3,489, Level: 24 Points: 3,489, Level: 24 Points: 3,489, Level: 24
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Central, NJ, USA.
Posts: 1,102
Thanks: 0
Thanked 2 Times in 2 Posts
Question Command Line versus Component

Good Morning,

I have entered into a debate that I am having some struggles answering- and I know there are better answers than the ones I've come up with so far, or at least I think there are.

The Problem: I want to use a file transfer (FTP/SFTP/FTPS) component to handle file transfers (potentially more than one at a time). The pushback is "WS_FTP Pro is the only approved file transfer solution"

The "Facts":
1. All architecture decisions made by the development team has to be approved by a corporate "Senior Architect" that then presents the solution to the "Architecture Review Board" for approval.
2. There is a very rigid structure of "Approved" standard products and a complex procedure to get new items approved.
3. The only approved file transfer client solution approved is WS_FTP Professional.
4. We are integrating secure file transfer into a .NET application.


I am putting forth the stand that we should get the standards committee to approve a component for secure file transfer. The Architect on the project is arguing that we should use WS_FTP Pro as it’s approved.

Of course, WS_FTP Pro is a command line interface- rather than a native component. So far I have a few points I am making to try and make the case for a component- I need to know if the community has any other- or perhaps a pointer to a whitepaper on Components vs command line interfaces.

My points as of now:
1. Complexity of install with the component is greatly reduced.
2. Supportability with the component is enhanced.
3. Costs related to deployment licensing are reduced.
4. Error control can be managed better when there’s a direct integration to the component.
5. The developers and support staff don’t need to learn another product/scripting language/etc.
6. We can design it so it handles multiple threads without starting multiple copies of the WS_FTP product (using a lot of computer resources)
7. I can use streams to send data instead of files, enhancing security by not writing temporary files to the hard drive. (This is personal and confidential data).
8. Improving performance by eliminating startup time of the FTP client as well as reduced disk I/O.
9. Managed Code, Managed Code, Managed Code.
10. Can use a standard logging methodology shared by all of our related applications instead of breaking the logs up among different locations (I.E. only our logs or needing both our and WS_FTP logs)


As of yet, this has not been enough o convince him that we should use a component. Please keel in mind he comes from a *nix background, rather than .NET- he’s from a world where there were not components, there were tiny programs to perform single functions that passed data back and forth through command lines and return codes.

His answer is “I have worked on many projects using command line file transfer that were excellent architectures” - which I am sure is true. I feel, however, the component solution is better.

So, any other arguments/documents/Etc I can use to make my case?


Thanks!

__________________
Hal Levy
Reply With Quote
  #2 (permalink)  
Old December 12th, 2011, 06:07 PM
Registered User
Points: 3, Level: 1
Points: 3, Level: 1 Points: 3, Level: 1 Points: 3, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Dec 2011
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Managed File Transfer

Hal,

You definitely need a program that does managed file transfer. I was in the same boat with the company I work for last year. We had 8 different servers/glorified desktops running various scripts and data massaging to make csv and xml files. The actual FTP was manually done and was not secure either. It wasn't till after this process was pieced together that a new manager developed a software approval process. It seemed rigid at first, but we could still download and try things in development. Overall the approved software list has made life easier while our company was expanding, but yes it has made getting "good" applications harder to get in production.

I will try address your concerns while trying not to sound like a running ad for the solution we ended up selecting. We tried 4 different solutions and are so happy with the software we decided on.

1) Installation Complexity. Your application should install with an installer and regardless of platform, should have minimal pre-requisites. It will be good to figure out from the solution if upgrades are provided, how are they installed and can they be rolled back. We have AS400's, Linux, and Windows servers. The GoAnywhere Director application we went with installs the same way on each platform, upgrades the same, and since it's all administered through a secure web-browser, there is no client software! If you have applications that need to programatically call different projects or routines, GoAnywhere has Run Project API's that you can place in your applications.
2) Support. You can't pay enough for good support and for people that understand your business and what needs to get done. When we were looking for an application we went from companies who were off-shore and couldn't get things to work to Linoma Software, the makers of GoAnywhere, who are in the mid-west, and know how to use both the systems and the software. They've held our hands, showed us how to make projects work with variables and make some complex business process that can be designed with a GUI. If you understand the programming side of what you want to do, the sky is the limit and they even support that.
3) Managed File Transfer solutions are not cheap. But when we realized the cost of the application and annual support versus what we were paying in manhours and the risk of having so many points of failure along with the sensitivity of the information, we estimate our ROI was 3 months and now we are saving 20 hours a month and running on 3 servers that are all locked up in a data center.
4) Error handling. We used to know if something broke because the recipients would complain they did not receive the deliverable. A solution like GoAnywhere has error handling built in at multiple levels with easy to understand logs and it will even email you to tell you what is happening. So now we have if/then handling built in to projects that if something fails like a file is missing, then the project can either notify and stop or it can go with what it has or set variables that will trigger different processes.
5) Every application has a way of doing things, but trying to learn a variant of some language to perform the same task is not a good use of time. The Director program is browser-based, click links to build processes, and it just works. What has been great is the online help, video tutorials, and user guide for this application.
6) Managing server resources. No application is helpful if it lags a server. Again we had 8 machines doing things before b/c not one application did it all and some would bring a production machine to its knees. With GoAnywhere it can run multiple threads or processes simultaneously without making the server sweat.
7) Temporary files and bits and pieces all over the place is not a way to maintain data security. Unless your systems is locked tight with user roles too many people can get to those temp files and reconstruct way too much. With a good application like this GoAnywhere Director, we can read in huge files, perform all kinds of functions, and write out encrypted results on the fly with no temporary bits and pieces or slave files.
8) Operating time - different services or components take time to start and stop. GoAnywhere has everything up and available at all times, so there is not waiting
9) Yes
10) You could be lost in logs. We like that this solution spits out to SYSLOGS.

A few things you didn't cover:
1) Role based access - you need to have role-based access. No one person should have free reign. GoAnywhere is based on this and does it well. PCI and HIPAA require it.
2) Fail-over, expandability, future-proofing - we run our databases on a central DB server. not too many applications support running on an external database, but for maximum uptime we are happy that we are good in this area with GoAnywhere.

Here are some links that you might find helpful:
http://blog.goanywheremft.com/
http://blog.linomasoftware.com/2010/...onsiderations/
http://www.goanywheremft.com/resourc...r/white-papers
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
command line caller C# gemma85 C# 0 November 10th, 2011 04:57 AM
Command Line complier godspeedba BOOK: Professional C# 4.0 and .NET 4 1 April 15th, 2011 10:36 AM
Issue using "saxon:line-number()" in command line XSL with Saxon9.jar ROCXY XSLT 3 June 3rd, 2009 04:24 AM
Asp Command Line dizzy1 Classic ASP Basics 1 August 30th, 2007 06:32 PM



All times are GMT -4. The time now is 11:26 AM.


Powered by vBulletin® Version 3.7.0
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.