Build Your Platform Around Technology Needs
Early in project design, a Java-based solution is well served by considering the weaknesses (outlined above) of Java for server-side development, specifically server management and security. These are non-trivial attributes of your server that, if neglected, can seriously impact the quality of the resultant solution; Java does not provide concrete or even well-defined solutions for these issues.
I'm not recommending doing a full up-front design in these two areas; rather, I suggest that you consider what technologies are going to get what you need, and what facilities your candidate platform supports in those two areas.
For example, if you are considering J2EE, then you'll eventually need a plan for dealing with security. Is the project likely to require complex security rules? If so, how will those be implemented? Will you use a specific container's proprietary security APIs, roll your own security infrastructure, or simply rely on the coarse-grained (but portable) security facilities included in all J2EE containers?
As for J2EE management: Will you hook in to the container's management infrastructure, design your own, or go with an open standard, such as JMX (betting that JMX will eventually be rolled in to J2EE and you'll reap portability rewards in the future)?
The up-front time spent considering these issueswhere Java provides the weakest supportmay add days or weeks to your timeline. However, neglecting these issues could well add many more weeks or months to the process.
One disadvantage of Java in the project-management sphere is the paradoxical high cost of some application servers. One would think that with open, portable standards, individual implementations would be in much stronger competition because migration is relatively easy. When a vendor tries to gouge a development company, the company just switches over to another implementation. The competition should be even more pronounced where very low-cost or even free alternative container implementations exist.
|I can't explain the reluctance to use a cheaper J2EE container, but I'm gratified to know my code will still run in the $18,000 container if called upon to do so.
On the day of this writing, I hear that BEA raised the listing price of its flagship software to $18,000 per processor. On my personal desktop machine I'm running the free, open-source jBoss application server and Tomcat. I can't explain the reluctance to use a cheaper J2EE container, but I'm gratified to know my code will still run in the $18,000 container if called upon to do so.
So, Give Me the Breakdown
A high-quality server has coding requirements to guarantee some level of scalability, extensibility, throughput, manageability, security, and code-base/deployment maintainability. The J2SE and J2EE platforms provide good support for some areas but are weak in others. A viable candidate platform is one that has facilities to support a project's requirements. Where the platform is weak, then affordable third-party solutions must exist, or you must realistically be able to build what you need and add it to the platform.
Where the Java platforms are weak, there are third-party solutionsoften implementations based on open standardswhich guarantee a high degree of portability. Open standards also provide a framework for you to "roll your own" subsystem solutions, which will also retain compatibility with third-party solutions you might choose to use in the future. Java's wealth of open-abstraction APIs is, in my humble opinion, one of Java's greatest advantages.