Posted By: Abhinav Taneja on March 7, 2001
I am working with my company's IT Division to decide the future direction of the Architecture for our company.
There is a debate between choosing between J2EE and .NET
Any thoughts on these lines would be helpful. Please answer keeping following issues in mind.
1) Which architecture is more robust for applications which require extensive search mechanisms and documents sharing and transfer and collaboration ?
2) Which options will reduce time to market and cost to market or develop and cost to maintain applications ?
3) Which architecture will useful for future flexibility of moving towards an ASP ?
4) Does size of IT shop and in house vs. out house development make a difference of what you choose ?
Thanks
Abhi
22 replies in this thread Reply
J2EE vs .NET
Posted By: William LaForest on March 8, 2001 in response to this message.
I have spent a lot of time working with both technologies and feel relatively unbiased.
I feel as though both technologies can satisfy your need for facilities which will provide robust support for document collaboration and searching.
The second consideration you raise is difficult to address without a fundamental understanding of your organization. If your company already has a slant one direction or another then re-education and staffing issues may become an important issue in determining time-to-market and development expense.
All things being equal there are a few factors to consider. If you choose to go J2EE then you must factor in time and cost in evaluating what implementation is going to be best for you; a small overhead but one that shouldn't be overlooked. I have found from the last three middleware projects I have been on that J2EE tends to incur more time costs from staff education due to the separation of specification and implementation. The developers must have understanding of both the J2EE API and the underlying implementation that you end up using. This is not entirely obviated in the Microsoft platform but information seems to be more concentrated. If you are able to come up with a full staff of seasoned developers in your chosen platform it won't matter... good luck!
I have found that, in general, speed to market has been faster in the Microsoft world due to the simplicity of some of the development tools and the use of VB. The more complex the system, however, the better J2EE becomes. VB and COM will become overburdened by their simplicity and C++ COM is more time consuming then J2EE to begin with. Cost of maintenance is almost always in the favour of J2EE for reasons I will touch on in response to your third question.
One thing I feel positive about: J2EE is much more successful in promoting code re-use. When I say code re-use I'm not referring to (in Microsoft parlance) component aggregation and extension. I'm talking about old fashion OO fundamentals. Microsoft is always touting binary (component) re-use and this is obviously good practice. I have read a myriad of articles and books where Microsoftonians say that traditional OO code re-use just never worked out that well; they obviously haven't implemented to many projects or architectures using a quality OO language such as SmallTalk or Java! I have found that J2EE projects almost always have a healthy share of both component reuse AND general OO reuse. Not every piece of code you write is going to end up as a component/EJB. My current project has a wonderful framework of Java classes that is constantly being extended through normal OO inheritance. Obviously this is possible in the Microsoft world if you choose the right language and are careful to enforce the right project policies but this happens far less frequently than in the Java world where it just seems to occur more naturally. For this reason alone I prefer J2EE for companies that are using an ASP model and require great flexibility.
