Forums
In my career as a developer, I've worked in a few organizations (and survived through my fair share of re-organizations) but the general pecking order stays the same with regards to IT. Developers work together and take direction from a Project Lead who is directed by a Team Lead, who answers to a Department Lead who in turn receives orders from a person at the Executive level. There's the same thing at Hobson's work, however, their org chart has a additional...twist.
You see, within its walls, there is a very special team that is above all others, and they are known as the Server Guys. Whatever they say goes, and nothing goes above what they say. They are the ones responsible for the maintenance and support of all of the company's servers, and they know what's best. Like the Men in Black, they are not only above the system, they are the system.
Hobson always had a high level of respect for the folks who keep the machines running around-the-clock, but never quite realized the power they wielded at this company. That is, until he wrote his first application: a simple, web-based, client-side Java applet.
Server Guys vs. Java Applet
For some time, customers had been asking for a way to query their order statuses from the web instead of having to phone customer service, wait on hold, get out their last invoice with their customer id on it, and so on. When Hobson developed a short and sweet Java applet to do just that, everybody — including the customer service team who manned the phones — was very, very pleased.
But suddenly, after a week of working just fine on the live site, page requests were returning errors, customers were complaining, and management was getting upset. The root cause: the applet was gone. Why? The Server Guys had removed the applet from the Production web server as it posed a "serious" security threat.
"Your Java applet generated quite a lot of traffic even when customers weren't querying information," a department-wide email from them read. "External users could use this to launch a Denial of Service attack on our website."
Hobson was stunned. Users could actually DoS their website with the little applet he made?
Armed with connection monitors and network sniffers, he set about looking for anything strange, and he discovered one thing that could maybe, possibly be to blame. After the applet was downloaded, whenever it was be opened, it would send one empty HTTP request of about 200 bytes back to the server when the applet VM called getResourceAsStream. The browser's Java plug-in tried to retrieve it from the server first instead of looking at the downloaded applet itself.
Was this the DoS attack? Most definitely! According to the Server Guys, his applet was a "no-go" in Production.
Fortunately — and quite coincidentally — a couple days later, Sun issued a Java that allowed the resource requests to be turned off via a parameter. After it was proven that the 200 byte extra request was no longer being sent, the Server Guys begrudgingly allowed the applet back into Production with the warning "let's just hope the users have the newest Java update installed."
It wasn't too long after that that Hobson had his second run-in with the Server Guys.
Server Guys vs. System Architecture
The corporate Production servers have a web service that allows customers to electronically submit order forms using a dedicated order entry application. Once the order is successfully received, the customer receives an email confirmation their order.
Customers liked this because they knew the instant an order was confirmed and they could store the email for reference later. Of course, some customers preferred a little paper in their paperless process and requested a printed order acknowledgment be sent via snail mail, just in case they network problems, or the email was accidentally deleted, or their computer was struck by a meteorite.
Wanting to implement the change with as little impact as possible, Hobson's team decided to redirect the XML that would normally be used to a web service running on a dedicated server running Tomcat that would apply the data to a template and spit back a nice, pretty PDF. It was a pretty simple architecture, and the development team was confident the Server Guys would approve.
Too much time, too little payout, the Server Guys explained. Installing things like Tomcat, JBoss, or any other fancy-schmancy Java stuff on a server requires too many resources like processing power, memory, and disk space, and Hobsons's "pie in the sky" Java pseudo-solution was far too complicated. This was all despite the fact that the "pseudo-solution" was going to be installed on a server dedicated exclusively to this task.
The Server Guys could, however, allow PHP and maybe a stand-alone Java application to do the XML transformation. To make things easier for Hobson's team, they outlined the architecture that they might allow, once they see how it works in production:
Before Hobson could even ask why FTP was necessary, the Server Guys explained: directly writing to the disk of a machine which hosts such an important process (converting XML to PDF) is far too dangerous.
Despite the FTP storage backbone, Hobson and team were able to get the PDF transformer module up and running without an issue. Well, that is until the Server Guys shut it down for being a resource hog: it was consuming over fifty megabytes of memory. But once that was resolved, everyone was happy: the customers got their new features and the Server Guys continued to protect the company from potential IT diasters.
[Advertisement]
BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!