Managed File Transfer



  • Anyone else hate this? My organization has started using it and the massive increase in overhead and sheer incompetence of IT is mindboggling.



  •  Not a WTF unless you give a bit of background as to why. The idea of managed file transfers is to solve a real problem, and as you've given absolutely zero information about why your management did this, we might assume that it was to solve a real problem and that the WTF is you for hating change.


  • Trolleybus Mechanic

     I think there's a 3rd party plug-in you can use to give you back an "Unmanaged File Transfer" theme. It's still the same under the hood, but will look and feel like a classic file transfer.



  • So... what is it? Is "Managed File Transfer" the name of a product? Or does it mean you need a manager's approval to transfer a file? Or... what the fuck are we talking about?



  • @blakeyrat said:

    So... what is it? Is "Managed File Transfer" the name of a product? Or does it mean you need a manager's approval to transfer a file? Or... what the fuck are we talking about?

    System.IO.File.Copy, obviously.



  • Well, according to Wikipedia, MFT solves real problems (as has been mentionned in another comment) and, as such, is far from being a WTF. Organizations may implement it in a WTF-y way, though. I have personally implemented and maintained (as part of a team) Java middleware software that used Connect Direct to transfer files between various heterogeneous computers (among which were z/OS mainframes, Solaris, AIX, Novell, Windows boxes). Connect Direct, being a complex software and thus unavoidably having its own set of WTFs, did help solve the communication problems nicely.

    So, if you could give us more context, we might be in a better position to judge whether your particular environment is a WTF or not.



  • @TheRider said:

    Well, according to Wikipedia,

    So it's SFTP combined with single-sign-on combined with logging combined with some sort of observer process that can restart failed transfers. That took almost an entire sentence to explain, I can see why the OP left that critical information out.


  • ♿ (Parody)

    @blakeyrat said:

    @TheRider said:
    Well, according to Wikipedia,

    So it's SFTP combined with single-sign-on combined with logging combined with some sort of observer process that can restart failed transfers. That took almost an entire sentence to explain, I can see why the OP left that critical information out.

    Yeah, and it seems like something I'd want if I were doing that sort of thing. Without more detail, it makes the OP look like TRWTF. Like, are you using this on your intranet or across the internet? What were you doing before? What are you transferring? I wonder if the "MFG" tag was a cryptic clue or a typo for "MFT?"

    Enquiring minds probably don't care.



  • We are switching to MFT and I agree with the OP. The need is real, the solution is correct in concept, but (at least here) the implementation is TRWTF. We've just started and someone from corporate just started installing an MFT client on one of our servers on Monday. He came back to me and said "The server doesn't have enough disk space, you need to free up 2GB".



  • @Jaime said:

    We are switching to MFT and I agree with the OP. The need is real, the solution is correct in concept, but (at least here) the implementation is TRWTF. We've just started and someone from corporate just started installing an MFT client on one of our servers on Monday. He came back to me and said "The server doesn't have enough disk space, you need to free up 2GB".

    TRWTF there isn't MFT either; it's the system administrator allowing, or being forced to allow, any dumbass from corporate to do whatever they want to a server that obviously wasn't meant for MFT.



  •  For all of those who have no idea what I am talking about... don't worry you will .... MFT is comming to an IT department near you. Take a standard like FTP and replace it with something which..

    1. costs way more ( $500m last year in sales)

    2. provides 'security'

    3. provides some features that are hard to do with FTP (not really)

    4. provides for better auditing (think SOX).

    5. takes way more time to setup

    6. requires non-standard methods of accessing data

    So basically take an internet standard 40 years old, and replace it with something with enterprisy with security, SOX compliance, and all of those wonderful things that prevents people from actually getting work done.

     

    or from the wiki

     

    Above all, MFT allows users to centralize control over FTP, thereby avoiding the wrath of auditors for another day. "Auditors are really cracking down on companies that are just doing this casual use with FTP, where they're sending files all over the place from their desktops, or even from the iSeries," Luebbe says. "It's just really easy to crank up an FTP session and fire off files without having any security or auditing around what's getting sent."



  • @toon said:

    @Jaime said:

    We are switching to MFT and I agree with the OP. The need is real, the solution is correct in concept, but (at least here) the implementation is TRWTF. We've just started and someone from corporate just started installing an MFT client on one of our servers on Monday. He came back to me and said "The server doesn't have enough disk space, you need to free up 2GB".

    TRWTF there isn't MFT either; it's the system administrator allowing, or being forced to allow, any dumbass from corporate to do whatever they want to a server that obviously wasn't meant for MFT.

    The dumbassery is asking me what server to install it on without telling me that it has unexpectedly high system requirements. I understand what MFT does, yet I can't fathom why it needs more disk space than an entire operating system does. Our file volume is very low, that space is only for the tool, not the data in transit.


  • @mdritchie said:

     For all of those who have no idea what I am talking about... don't worry you will .... MFT is comming to an IT department near you. Take a standard like FTP and replace it with something which..

    1. costs way more ( $500m last year in sales)

    2. provides 'security'

    3. provides some features that are hard to do with FTP (not really)

    4. provides for better auditing (think SOX).

    5. takes way more time to setup

    6. requires non-standard methods of accessing data

    So basically take an internet standard 40 years old, and replace it with something with enterprisy with security, SOX compliance, and all of those wonderful things that prevents people from actually getting work done.

    Feh, who need's security? I'm sure our competitors have their own secret files, why would they need to steal ours? And, it's like anyone actually reads those audits.



  • @Jaime said:

    The dumbassery is asking me what server to install it on without telling me that it has unexpectedly high system requirements.[...] Our file volume is very low, that space is only for the tool, not the data in transit.

    ...and yet you didn't bother to really try to find out what was going to be installed, before telling your coworker what server to install it on? This sort of reeks of you not caring what that dude from corporate was putting on your server. Or to tell him to put the tool on your server, and the data in transit somewhere else. Because it sounds to me, like you found out what that stuff was, after you told him it was ok to install. Don't get me wrong here: I readily admit that I don't really know how to do your job, as I am a developer and not a sysadmin. But I'm starting to think that the WTF here isn't the MFT, but that I'm replying to its comment right now.



  •  Pity there is no such thing as 'SFTP'. When MFT vendors talk about security they mean something rather different.



  • @mdritchie said:

    So basically take an internet standard 40 years old, and replace it with something with enterprisy with security, SOX compliance, and all of those wonderful things that prevents people from actually getting work done.

    So you'd prefer everybody uses insecure plain-jane FTP? You are the WTF.

    Now if you're saying "the specific implementation of managed file transfer sucks", that's one thing. The concept, however, sounds more than reasonable.

    And nobody, nobody, in the year 2012 should be using plain FTP for anything, ever.



  • @blakeyrat said:

    @mdritchie said:
    So basically take an internet standard 40 years old, and replace it with something with enterprisy with security, SOX compliance, and all of those wonderful things that prevents people from actually getting work done.

    So you'd prefer everybody uses insecure plain-jane FTP? You are the WTF.

    Now if you're saying "the specific implementation of managed file transfer sucks", that's one thing. The concept, however, sounds more than reasonable.

    And nobody, nobody, in the year 2012 should be using plain FTP for anything, ever.

    Agreed.



  • @blakeyrat said:

    And nobody, nobody, in the year 2012 should be using plain FTP for anything, ever.
    Yeah! Instead of sending files, it now just deletes them!

     


  • ♿ (Parody)

    @mdritchie said:

    Pity there is no such thing as 'SFTP'. When MFT vendors talk about security they mean something rather different.

    Well, the wikipedia article talks about that as part of some MFT implementations. But it also says that MFT provides a place to encrypt stuff on the server. Plus auditing. SFTP doesn't do any of that for you.

    Of course, I'm very willing to believe (as others in this thread have indicated) that some vendors' implementations are TRWTF. So far, two people have said that the MFT implementations they've had to deal with are WTFs, but I haven't seen any vendor names. C'mon people, name and shame!



  • @toon said:

    @Jaime said:
    The dumbassery is asking me what server to install it on without telling me that it has unexpectedly high system requirements.[...] Our file volume is very low, that space is only for the tool, not the data in transit.

    ...and yet you didn't bother to really try to find out what was going to be installed, before telling your coworker what server to install it on? This sort of reeks of you not caring what that dude from corporate was putting on your server. Or to tell him to put the tool on your server, and the data in transit somewhere else. Because it sounds to me, like you found out what that stuff was, after you told him it was ok to install. Don't get me wrong here: I readily admit that I don't really know how to do your job, as I am a developer and not a sysadmin. But I'm starting to think that the WTF here isn't the MFT, but that I'm replying to its comment right now.

    I was told that the EDI team was upgrading their infrastructure and that FTP would not be enabled on the new system. So far, so good. We were told that we had to use MFT, so we had a meeting to assess what that means to us. They mentioned that a small client would be installed at our endpoint and our system would simply import delivered files from a local directory instead of fetching them over FTP. This was great news. Monday was the day to begin the implementation in test, a guy from corporate pops on the radar and asks only one question, "What's the name of your test EDI server?". I tell him. He then goes through his channels to get administrative access, and I don't here from him until he has a disk space issue.

    BTW, I'm a developer. They never asked anyone if they could install it, they simply reported the installation problem to me. We were aware that at some point the client would be installed, but we were given no agenda of what he was doing while he was there. For all I knew, it could have been a pre-install assessment.

    Back to the WTF, the freakin' file transfer client was 2GB.



  • @boomzilla said:

    @mdritchie said:
    Pity there is no such thing as 'SFTP'. When MFT vendors talk about security they mean something rather different.

    Well, the wikipedia article talks about that as part of some MFT implementations. But it also says that MFT provides a place to encrypt stuff on the server. Plus auditing. SFTP doesn't do any of that for you.

    Of course, I'm very willing to believe (as others in this thread have indicated) that some vendors' implementations are TRWTF. So far, two people have said that the MFT implementations they've had to deal with are WTFs, but I haven't seen any vendor names. C'mon people, name and shame!

    Axway


  • @Jaime said:

    I was told that the EDI team was upgrading their infrastructure and that FTP would not be enabled on the new system. So far, so good. We were told that we had to use MFT

    Enterprise EDI implementations usually require a VAN which is expensive and high-maintenance. For the last 5-7 years or so, there has been a slow mainstream migration towards HTTP-based secure transmission (AS2) which is at least as secure and way cheaper. Now most big shops (like Wal-Mart) accept both EDI over VAN and AS2 over internet solutions (as long as it is certified) and many products offer plug-in for ERPs to allow AS2 transmission (which implies non-repudiation, a must). Major AS2/AS3 solutions support files as large as 2GB and because there is no exotic network protocol it is easy to support.

    Some products allow compatibility between MFT and AS2, it's all nice in whitepapers but so far I haven't seen a huge adoption IRL.



  • @Speakerphone Dude said:

    Enterprise EDI implementations usually require a VAN which is expensive and high-maintenance. For the last 5-7 years or so, there has been a slow mainstream migration towards HTTP-based secure transmission (AS2) which is at least as secure and way cheaper. Now most big shops (like Wal-Mart) accept both EDI over VAN and AS2 over internet solutions (as long as it is certified) and many products offer plug-in for ERPs to allow AS2 transmission (which implies non-repudiation, a must). Major AS2/AS3 solutions support files as large as 2GB and because there is no exotic network protocol it is easy to support.

    Some products allow compatibility between MFT and AS2, it's all nice in whitepapers but so far I haven't seen a huge adoption IRL.

    Sometimes I wonder if I'm even in the same industry as you people.



  • @Speakerphone Dude said:

    @Jaime said:

    I was told that the EDI team was upgrading their infrastructure and that FTP would not be enabled on the new system. So far, so good. We were told that we had to use MFT

    Enterprise EDI implementations usually require a VAN which is expensive and high-maintenance. For the last 5-7 years or so, there has been a slow mainstream migration towards HTTP-based secure transmission (AS2) which is at least as secure and way cheaper. Now most big shops (like Wal-Mart) accept both EDI over VAN and AS2 over internet solutions (as long as it is certified) and many products offer plug-in for ERPs to allow AS2 transmission (which implies non-repudiation, a must). Major AS2/AS3 solutions support files as large as 2GB and because there is no exotic network protocol it is easy to support.

    Some products allow compatibility between MFT and AS2, it's all nice in whitepapers but so far I haven't seen a huge adoption IRL.

    I'm on the other end. Our EDI team deals with external partners, I'm responsible for one of the back end ordering systems. Our communications with the EDI team go over the corporate network.

    Anyways, I just peeked at the MFT client install. It has two JVMs, Tomcat, and a 400MB dBase-like file. It also seems to be exactly what you would expect under the hood. There is a license directory with all of the license text for libraries that require distributing such things. I see OpenSSL, the Bouncy Castle crypto library, Apache Xerces and a bunch of other XML libraries. Three services were installed, all running as LocalSystem and starting automatically. It opens two listening sockets on 127.0.0.1 and each listening process is connected to the other all of the time. In other words, highly enterprisey software.

    As for the big file comment, we receive about 100 EDI documents per day, each less than 2KB. If they'd bothered to ask any question or look at our history, they'd know that we don't need to reserve very much space for content.



  • @Jaime said:

    @Speakerphone Dude said:
    @Jaime said:

    I was told that the EDI team was upgrading their infrastructure and that FTP would not be enabled on the new system. So far, so good. We were told that we had to use MFT

    Enterprise EDI implementations usually require a VAN which is expensive and high-maintenance. For the last 5-7 years or so, there has been a slow mainstream migration towards HTTP-based secure transmission (AS2) which is at least as secure and way cheaper. Now most big shops (like Wal-Mart) accept both EDI over VAN and AS2 over internet solutions (as long as it is certified) and many products offer plug-in for ERPs to allow AS2 transmission (which implies non-repudiation, a must). Major AS2/AS3 solutions support files as large as 2GB and because there is no exotic network protocol it is easy to support.

    Some products allow compatibility between MFT and AS2, it's all nice in whitepapers but so far I haven't seen a huge adoption IRL.

    I'm on the other end. Our EDI team deals with external partners, I'm responsible for one of the back end ordering systems. Our communications with the EDI team go over the corporate network.

    Anyways, I just peeked at the MFT client install. It has two JVMs, Tomcat, and a 400MB dBase-like file. It also seems to be exactly what you would expect under the hood. There is a license directory with all of the license text for libraries that require distributing such things. I see OpenSSL, the Bouncy Castle crypto library, Apache Xerces and a bunch of other XML libraries. Three services were installed, all running as LocalSystem and starting automatically. It opens two listening sockets on 127.0.0.1 and each listening process is connected to the other all of the time. In other words, highly enterprisey software.

    As for the big file comment, we receive about 100 EDI documents per day, each less than 2KB. If they'd bothered to ask any question or look at our history, they'd know that we don't need to reserve very much space for content.

    Two things:

    • your situation is typical; I've seen clients with a very high load of transactions (EDI and AS2) leading to at most a few hundreds of MBs each month. The only situation where I've seen large files is in the aerospace industry because following regulations each transaction regarding an airplane requires the communication of the entire "book" which gets bigger and bigger over time.
    • Tomcat is *not* enterprise-grade software. It has been designed as a quick J2EE compliance validation tool and IMHO never got to a point where it can actually deliver the kind of performance or stability that real enterprise software requires. It is not in the same league as Websphere or Weblogic.



  • @Speakerphone Dude said:

    Tomcat is not enterprise-grade software. It has been designed as a quick J2EE compliance validation tool and IMHO never got to a point where it can actually deliver the kind of performance or stability that real enterprise software requires. It is not in the same league as Websphere or Weblogic.

    I hope you aren't reading "enterprisey" as "enterprise grade". Enterprisey is a derogatory term that is used to describe software that is unnecessarily complicated, the type that shows up in corporate projects all the time.

    ... and if they installed WebSphere just to host a file transfer end point, someone would have to die. Also, who cares about "the performance that enterprise software requires" when I move less than a meg per day? I'll take simple and correct over fast any day.



  • @Jaime said:

    @Speakerphone Dude said:

    Tomcat is not enterprise-grade software. It has been designed as a quick J2EE compliance validation tool and IMHO never got to a point where it can actually deliver the kind of performance or stability that real enterprise software requires. It is not in the same league as Websphere or Weblogic.

    I hope you aren't reading "enterprisey" as "enterprise grade". Enterprisey is a derogatory term that is used to describe software that is unnecessarily complicated, the type that shows up in corporate projects all the time.

    ... and if they installed WebSphere just to host a file transfer end point, someone would have to die. Also, who cares about "the performance that enterprise software requires" when I move less than a meg per day? I'll take simple and correct over fast any day.

    Well it depends what goes into that meg. If it's a 500M$ deal on commodities that is sent to a clearinghouse, it is worth spending 200k$ on software that will work around the clock and support transparent long-distance failover if needed; just the penalty on one late trade can be worth more than that. If that meg contains the PO for a batch of Fruit of the Loom t-shirts, then sending a floppy disk with bad sectors by the cheapest bike messenger in town may be good enough. I suspect that your situation is somewhere in the middle.

    In my experience the right solution usually involves business requirements, not file size or number of users. Look at Renaissance Technologies: less than 300 employees managing over 20G$ in assets - however based on their size it is a small business; does not mean they don't need reliable software.



  • @Speakerphone Dude said:

    @Jaime said:
    @Speakerphone Dude said:

    Tomcat is not enterprise-grade software. It has been designed as a quick J2EE compliance validation tool and IMHO never got to a point where it can actually deliver the kind of performance or stability that real enterprise software requires. It is not in the same league as Websphere or Weblogic.

    I hope you aren't reading "enterprisey" as "enterprise grade". Enterprisey is a derogatory term that is used to describe software that is unnecessarily complicated, the type that shows up in corporate projects all the time.

    ... and if they installed WebSphere just to host a file transfer end point, someone would have to die. Also, who cares about "the performance that enterprise software requires" when I move less than a meg per day? I'll take simple and correct over fast any day.

    Well it depends what goes into that meg. If it's a 500M$ deal on commodities that is sent to a clearinghouse, it is worth spending 200k$ on software that will work around the clock and support transparent long-distance failover if needed; just the penalty on one late trade can be worth more than that. If that meg contains the PO for a batch of Fruit of the Loom t-shirts, then sending a floppy disk with bad sectors by the cheapest bike messenger in town may be good enough. I suspect that your situation is somewhere in the middle.

    In my experience the right solution usually involves business requirements, not file size or number of users. Look at Renaissance Technologies: less than 300 employees managing over 20G$ in assets - however based on their size it is a small business; does not mean they don't need reliable software.

    I love how you avoided the fact that I addressed the performance aspect of your comment and instead picked insane edge cases and focused on stability. If you are going to play the crazy edge case game, you can play it alone.


  • @Jaime said:

    I hope you aren't reading "enterprisey" as "enterprise grade".  Enterprisey is a derogatory term that is used to describe people who use the term "Enterprise Grade"..
    FTFY.



  • @Jaime said:

    @Speakerphone Dude said:
    @Jaime said:
    @Speakerphone Dude said:

    Tomcat is not enterprise-grade software. It has been designed as a quick J2EE compliance validation tool and IMHO never got to a point where it can actually deliver the kind of performance or stability that real enterprise software requires. It is not in the same league as Websphere or Weblogic.

    I hope you aren't reading "enterprisey" as "enterprise grade". Enterprisey is a derogatory term that is used to describe software that is unnecessarily complicated, the type that shows up in corporate projects all the time.

    ... and if they installed WebSphere just to host a file transfer end point, someone would have to die. Also, who cares about "the performance that enterprise software requires" when I move less than a meg per day? I'll take simple and correct over fast any day.

    Well it depends what goes into that meg. If it's a 500M$ deal on commodities that is sent to a clearinghouse, it is worth spending 200k$ on software that will work around the clock and support transparent long-distance failover if needed; just the penalty on one late trade can be worth more than that. If that meg contains the PO for a batch of Fruit of the Loom t-shirts, then sending a floppy disk with bad sectors by the cheapest bike messenger in town may be good enough. I suspect that your situation is somewhere in the middle.

    In my experience the right solution usually involves business requirements, not file size or number of users. Look at Renaissance Technologies: less than 300 employees managing over 20G$ in assets - however based on their size it is a small business; does not mean they don't need reliable software.

    I love how you avoided the fact that I addressed the performance aspect of your comment and instead picked insane edge cases and focused on stability. If you are going to play the crazy edge case game, you can play it alone.

    On sunny days there may be no difference between a Tomcat solution and a Websphere solution; both can process the 1MB file in the same amount of time. However when something goes wrong, if there is an unexpected increase in load, or if there is a hardware or network problem, the fact that Websphere has features like load balancing or transparent failover will ensure that the same performance is experienced from a user point of view - something less likely with a Tomcat setup (unless it is complemented by additional stuff). This is what service level means, and this is where performance and stability meet. It does not mean that a Tomcat setup is bad per se; it depends on the business requirements.

    If the edge fund vs. t-shirt factory is too much of a "crazy edge case", here is a less dramatic example: Dell vs. HP. On one side you have a company that has a 7-day inventory turnover and therefore relies heavily on just-in-time manufacturing; on the other there is the standard high inventory vendor that has very large warehouses. Market share aside, let's suppose that they are in the same kind of business, have the same volume of orders and can deliver a PC in about the same time; still, one company will invest heavily in its "mass customization" solution and will require a lot of fault-tolerance in its ordering system while the other will make sure that the ERP is running smoothly and that inventory is well managed. Same size, different priorities - it's all about business requirements.



  • @Speakerphone Dude said:

    500M$
    @Speakerphone Dude said:
    200k$
    @Speakerphone Dude said:
    20G$

    Is this your first experience writing currency? The dollar sign goes first. Nobody uses "G" to mean billion. Stop being stupid.



  • @morbiuswilters said:

    @Speakerphone Dude said:
    500M$
    @Speakerphone Dude said:
    200k$
    @Speakerphone Dude said:
    20G$

    Is this your first experience writing currency? The dollar sign goes first. Nobody uses "G" to mean billion. Stop being stupid.

    According to the Universal Truth both are correct depending on the currency: "Many currencies, especially in Latin America and the English-speaking world, place it before the amount (e.g., R$50.00); many others place it after the amount (e.g., 50.00 S₣); and the Cape Verdean escudo, like the former Portuguese escudo and French franc, placed its sign in the decimal position (i.e., 20$00)."

    For now on, mostly for your benefit, I will use the amazing third form (which I discovered as I was researching this). Just my 0$02.


  • ♿ (Parody)

    @Speakerphone Dude said:

    On sunny days there may be no difference between a Tomcat solution and a Websphere solution; both can process the 1MB file in the same amount of time. However when something goes wrong, if there is an unexpected increase in load, or if there is a hardware or network problem, the fact that Websphere has features like load balancing or transparent failover will ensure that the same performance is experienced from a user point of view - something less likely with a Tomcat setup (unless it is complemented by additional stuff).

    I've highlighted the part that indicates you're making a weird comparison. Tomcat is just the webserver, no? If you wanted the equivalent of Websphere, you'd use something like JBoss with Tomcat. Not that I'm an expert on the topic, nor do I care to be one, but your point seems...weird.



  •  This thread is getting funnier and funnier. On one side you have developer types who are saying 'I want to get something done so I don't get fired, keep the easy part of the solution (moving files) simple'. On the other hand you have the IT support types saying 'but what about a whole bunch of ridiculous edge cases, lets spend lots of money on something centralized so I can keep my job managing it'.



  • @boomzilla said:

    @Speakerphone Dude said:
    On sunny days there may be no difference between a Tomcat solution and a Websphere solution; both can process the 1MB file in the same amount of time. However when something goes wrong, if there is an unexpected increase in load, or if there is a hardware or network problem, the fact that Websphere has features like load balancing or transparent failover will ensure that the same performance is experienced from a user point of view - something less likely with a Tomcat setup (unless it is complemented by additional stuff).
    I've highlighted the part that indicates you're making a weird comparison. Tomcat is just the webserver, no? If you wanted the equivalent of Websphere, you'd use something like JBoss with Tomcat. Not that I'm an expert on the topic, nor do I care to be one, but your point seems...weird.
    I'll add to this that the entire concept of the Internet was to build a reliable communication system on top of an unreliable foundation. It's not that hard.


  • ♿ (Parody)

    @mdritchie said:

    This thread is getting funnier and funnier. On one side you have developer types who are saying 'I want to get something done so I don't get fired, keep the easy part of the solution (moving files) simple'. On the other hand you have the IT support types saying 'but what about a whole bunch of ridiculous edge cases, lets spend lots of money on something centralized so I can keep my job managing it'.

    If only we could live in a world where the likes of SOX compliance was a "ridiculous edge case."



  • @Jaime said:

    @boomzilla said:

    @Speakerphone Dude said:
    On sunny days there may be no difference between a Tomcat solution and a Websphere solution; both can process the 1MB file in the same amount of time. However when something goes wrong, if there is an unexpected increase in load, or if there is a hardware or network problem, the fact that Websphere has features like load balancing or transparent failover will ensure that the same performance is experienced from a user point of view - something less likely with a Tomcat setup (unless it is complemented by additional stuff).
    I've highlighted the part that indicates you're making a weird comparison. Tomcat is just the webserver, no? If you wanted the equivalent of Websphere, you'd use something like JBoss with Tomcat. Not that I'm an expert on the topic, nor do I care to be one, but your point seems...weird.
    I'll add to this that the entire concept of the Internet was to build a reliable communication system on top of an unreliable foundation. It's not that hard.

    I'll let you know when this actually happens.



  • @boomzilla said:

    @mdritchie said:
    This thread is getting funnier and funnier. On one side you have developer types who are saying 'I want to get something done so I don't get fired, keep the easy part of the solution (moving files) simple'. On the other hand you have the IT support types saying 'but what about a whole bunch of ridiculous edge cases, lets spend lots of money on something centralized so I can keep my job managing it'.

    If only we could live in a world where the likes of SOX compliance was a "ridiculous edge case."

     

    Kind-of sad when the largest WTF in the history of IT, SOX compliance, has grown so large that anything related to it no longer qualifies as a WTF.



  • @mdritchie said:

    Kind-of sad when the largest WTF in the history of IT, SOX compliance, has grown so large that anything related to it no longer qualifies as a WTF.

    Feh. I was doing ridiculous, pointless, securing and auditing with HIPAA before SOX compliance made it cool.

    All permanent connections to external data sources require 128-bit encryption? Well since our vender's a dumbshit and only supports crappy encryption, let's just replace our existing Internet-based solution with a 56k modem-- since it's not "permanently connected", hey it fits the requirements with no encryption at all. GOOD LAW WRITING HIPAA DUMBSHITS!


  • ♿ (Parody)

    @mdritchie said:

    Kind-of sad when the largest WTF in the history of IT, SOX compliance, has grown so large that anything related to it no longer qualifies as a WTF.

    You're making stuff up now. Because no one in this thread has said anything of the sort.


  • ♿ (Parody)

    @blakeyrat said:

    GOOD LAW WRITING HIPAA DUMBSHITS!

    I came across the following today:
    @Don Boudraux said:

    Legal central planning is no more likely to work well than is economic central planning.

    And if you think HIPAA or SOX are bad, wait until Dodd-Frank really gets going.



  • @mdritchie said:

     This thread is getting funnier and funnier. On one side you have developer types who are saying 'I want to get something done so I don't get fired, keep the easy part of the solution (moving files) simple'. On the other hand you have the IT support types saying 'but what about a whole bunch of ridiculous edge cases, lets spend lots of money on something centralized so I can keep my job managing it'.

    The real funny thing in this thread is that some people completely misunderstand the point and make it obvious with an irrelevant summary.



  • @Speakerphone Dude said:

    @mdritchie said:

     This thread is getting funnier and funnier. On one side you have developer types who are saying 'I want to get something done so I don't get fired, keep the easy part of the solution (moving files) simple'. On the other hand you have the IT support types saying 'but what about a whole bunch of ridiculous edge cases, lets spend lots of money on something centralized so I can keep my job managing it'.

    The real funny thing in this thread is that some people completely misunderstand the point and make it obvious with an irrelevant summary.
    Even funnier is that the person who read "HaHa, I found this large collection of libraries, including Tomcat in a 2GB mess of a file transfer program" and responded "Tomcat isn't enterprise grade" thinks that people missing the point is funny.


  • @boomzilla said:

    @Speakerphone Dude said:
    On sunny days there may be no difference between a Tomcat solution and a Websphere solution; both can process the 1MB file in the same amount of time. However when something goes wrong, if there is an unexpected increase in load, or if there is a hardware or network problem, the fact that Websphere has features like load balancing or transparent failover will ensure that the same performance is experienced from a user point of view - something less likely with a Tomcat setup (unless it is complemented by additional stuff).

    I've highlighted the part that indicates you're making a weird comparison. Tomcat is just the webserver, no? If you wanted the equivalent of Websphere, you'd use something like JBoss with Tomcat. Not that I'm an expert on the topic, nor do I care to be one, but your point seems...weird.

    A typical setup is to have Apache (httpd) in the front-end to do web server stuff (serve static content, perform url rewriting, etc.) and Tomcat (or Jetty) in the back-end to run web applications (mostly JSP or plain servlets). When there is additional business logic, distributed transactions or more extensive data manipulation JBoss can sit behind Tomcat but this is not required in most situations. Websphere and Weblogic have the same kind of layers, however it's all proprietary from end-to-end. If you want to see all the "moving parts", have a look at what the Apache Geronimo project includes, it's a good example.

    If you take a simple comparison where you have a web application running on one side on Tomcat and on the other side on the web application server part of Websphere, there is a bunch of features available in Websphere and not in Tomcat, especially around stuff like failover and load balancing. Most web application servers (like Tomcat or IIS) can be part of a third-party load balancing cluster, however they don't share sessions or requests so if a node dies, people currently using it are disconnected. Not on Websphere or Weblogic, where the application server is cluster-aware. To get the same behavior with Tomcat you need more software, such as some components of JBoss (hence the section you highlighted).


  • ♿ (Parody)

    @Speakerphone Dude said:

    Not on Websphere or Weblogic, where the application server is cluster-aware. To get the same behavior with Tomcat you need more software, such as some components of JBoss (hence the section you highlighted).

    Yes. Also, if you just have a JRE, you won't have any of that, and you'll have to add stuff (though you might have a chance if you can supercool the JDK). Of course, you have no clue what else was in there or what it was doing. But I guess I don't really want to stop the enjoyment you get from listening to yourself type.



  • @boomzilla said:

    @Speakerphone Dude said:
    Not on Websphere or Weblogic, where the application server is cluster-aware. To get the same behavior with Tomcat you need more software, such as some components of JBoss (hence the section you highlighted).

    Yes. Also, if you just have a JRE, you won't have any of that, and you'll have to add stuff (though you might have a chance if you can supercool the JDK). Of course, you have no clue what else was in there or what it was doing. But I guess I don't really want to stop the enjoyment you get from listening to yourself type.

    This is uncalled for. In a previous message, you said:

    @boomzilla said:

    I've highlighted the part that indicates you're making a weird comparison. Tomcat is just the webserver, no? If you wanted the equivalent of Websphere, you'd use something like JBoss with Tomcat.

    What I am telling you is that Websphere is a suite, not a single product, and when you compare the equivalent of Tomcat in the Websphere suite, there are less features. I am not sure how this translates into me liking to listen myself type, but I guess you wanted an opportunity to use that quasi-funny expression so you are welcome.


  • ♿ (Parody)

    @Speakerphone Dude said:

    What I am telling you is that Websphere is a suite, not a single product, and when you compare the equivalent of Tomcat in the Websphere suite, there are less features.

    Yes, because Tomcat isn't a suite like Websphere is (remember, you're the one who brought up Websphere). So why are you comparing them and stating the obvious? It's like we were talking about Microsoft Word, and then you saying that LibreOffice has more features than MS Word.

    Why do you keep doing that? The only answer I could come up with is that you like to type.



  • @boomzilla said:

    @Speakerphone Dude said:
    What I am telling you is that Websphere is a suite, not a single product, and when you compare the equivalent of Tomcat in the Websphere suite, there are less features.

    Yes, because Tomcat isn't a suite like Websphere is (remember, you're the one who brought up Websphere). So why are you comparing them and stating the obvious? It's like we were talking about Microsoft Word, and then you saying that LibreOffice has more features than MS Word.

    Why do you keep doing that? The only answer I could come up with is that you like to type.

    Using your example, what I was saying was more something like: the word processing component of LibreOffice has more features than Word, without taking into consideration the whole suite on neither side.

    "Websphere application server" is a product, not a suite. It is part of "Websphere suite" because just about everything that IBM is now selling has the "Websphere" tag (see the catalog).

    This being said, I feel like my actual point did not go through and you are probably right that it comes out like repetition so I will not insist.



  • Goddamn this discussion is boring.



  • @Speakerphone Dude said:

    For now on, mostly for your benefit, I will use the amazing third form (which I discovered as I was researching this). Just my 0$02.

    You aren't living in one of those cultures. Stop being stupid.


Log in to reply