Fallacy 7: Development over Monitoring, management and profiling

 In real world we have still the phenomenon, that project leaders and management is still more interested in lowering the development costs and really do not care about the maintenance and production, or the overall costs. Because developers are primarily interested in development :-), custom grown frameworks are prefered over Java EE. Because development takes usually only 25% of the overall costs - this strategy is seldom a cheap solution. In my last project review, developers tried to built an own messaging and batch-solution as a  lean server with Java SE - only to avoid the usage of J2EE (not Java EE 5). It was a HA project - but they had no monitoring solution. I'm sure they were already about to also reinvent JMX :-). The stakeholder "administrator" could only monitor the application using the standard UNIX tools like top or ps...
J2EE 1.4 comes already with JSR-77 implementation which allows monitoring of every deployed component (EJB, Servlet connector etc.). I described the deployment aspect in Glassfish in my last entry. The monitoring feature come with every application server for free and no additional development overhead. Glassfish provides also a proprietary extension called "Call Stack", which allows the visualization and profiling of the call hierarchy. This feature is very useful in the development phase.

Another crucial aspect is the capability of controling the throughput. It is not a big deal to scale infinitely, in real world it is more appropriate to set constraints. This can be easily achieved defining thread pool with limited number of threads. In the next step you could assign a thread pool to a session bean or servlet - and limit the scaleability.

For enterprise architectures, another aspect is the connectivity. With JCA connectors it is relatively easy to talk to backend systems. It is also possible to initiate transactions from outside using proprietary protocols or connectors (comes with JCA 1.5).
During the estimation of the projects costs we should consider the whole lifecycle - the development phase is only one small part. From the overall perspective Java EE could be cheaper, than using a proprietary framework or reinventing the wheel. Considering only the development phase - Java EE seems often to be an overengineered solution :-)

For more fallacies see:  Common J2EE/Java EE Fallacies.