Choosing a Platformby drago99 (Sexton)
|on Jul 22, 2004 at 01:22 UTC||Need Help??|
We at my firm have been debating for several weeks over which platform the next generation of our product should be developed on.
Among the contenders were ASP.NET, JSP and Perl (mod_perl + Apache::ASP).
All of them have their "pros" and "cons", so it was no easy choice for anyone.
->> The bosses wanted an established technology with substantial mindshare, security and scalability. Price was also a factor.
->> The developers wanted a well-documented, extensible toolkit that could do anything with minimal effort, and adapt to unforeseen changes down the road, as well as a rich collection of add-on components for enhanced functionality.
->> The network engineers wanted something that wouldn't tax the servers or the network more than necessary, and took into account serious issues like security, load-balancing, clustering, failover scenarios, deployment and upgrades.
So we looked at the big application servers for Java: WebSphere ($15,000/processor) and BEA WebLogic ($4,200). These products do not have a reputation for being cheap or easy. Those of us who had worked with them before only had nightmare stories to tell.
Java: Close, but no cigar.Then we looked at Microsoft's ASP.NET and the .NET Framework.
The features we need, while seemingly advanced, are not new concepts. Java has some of them, but at too great a price in terms of performance and overhead. .NET will have a hackneyed implementation of them with its next release.
The features in question are:
We knew what the application should look like, it was a matter of what tools would help us get the job done on-time and under-budget.
These features are definitely outside the scope of most web applications, but they are the minimum requirements for what we are building.
Fortunately we were able to find a tool with all of these features, as well as the pros .NET had to offer, just to name a few. Perl.
Through an XML API, we are able to support clients running on any platform, but the core itself and the initial client package will be written in Perl.
Maybe a future release of .NET will support all the features the design depends on, but for now it looks like we would end up doing too much extending to make things work the way we need them to.
To be sure, ASP.NET is an excellent way to build websites and web applications, and its event-driven model helps simplify some things that would be difficult to produce otherwise. IIS6 has several great new features, but we're still stuck without direct access to the server API (unless you consider ISAPI DLLs direct access), runtime generation of new classes and/or methods, and abstracted discovery of remote methods/etc.
<UPDATE: Here are the Pros & Cons we were looking at.>
I'm just glad we didn't have to compromise our design to fit inside our toolset's box.