If this is the wrong place to post this please let me know where I should ask this.
I was hoping to get a view from the other side of the .NET/J2EE fence. I am in the process of moving from Microsoft programming MTS,COM+ to the J2EE environment.
I am working with J2EE and have just touched the surface of EJB Programming within J2EE Environment. My concerns have come about over the past few weeks as poeple I know have been sending me these (Microsoft Supported) Papers which state that the EJB Specification is Flawed and that there are major problems? I am too new to the environment to have seen any of this. I was looking for some insight from an experienced programmer as to some of the pitfalls of the EJB Spec. On the otherhand what are some of the benefits aside from that it's not microsoft? I am not looking to start a thread on J2EE vs .NET. I am looking for Specific EJB Spec related problems which might be a problem in implementation and design of enterprise applications.
I understand some of the problems described to me such as in an eairlier version of the spec each call to an EJB is treated was a remote call. I understand this has been address as the specification is evolving.
Wise of you not to start yet another debate on .net & J2EE.
I am a sun certified architect and I hope my advice does not sound biased.
As far as I have heard J2EE is not as developer friendly as .net. It certainly has all the features (if not more) that .net has, but it certainly requires digging for information.
I have not really worked on .net but from what I have heard J2EE is generally more scalable. (A lot depends on your design though.)
J2EE is a proven technology. Not that .net is not, just a matter of time. I will certainly like to see how it scales.
J2EE could be an over kill for a small firm. There are a lot of hidden costs. Sun only defines the Specs (Kind of like OMG) so the rest of the implementation is up to the vendors (of course they have to be certified by Sun)
I can not say about .net but J2EE is certainly good as long as you stick to the Sun Specs (not use any vendor specific features...which may be cool but may not be portable across app-servers.)
The only other point, there are not many large-scale implementation that use Entity beans. Sun has done a lot of work redefining the entity bean specs, there are improvements but I believe it is still un-proven.
That’s all I could think of.
Hope it helps.
Thanks for your feedback.
Are the papers not stating what is flawed in the spec and what are the major problems? I'm confused. Microsoft usually attacks competition ferociusly but not with rumors. They purport some issues grossly out of proportion and lead to uncanny conclusions, but they always base their attacks on some foundation (great lies are always so near the truth). Perhaps, you should summarize what you read.
In a general way, you are on better grounds on the J2EE side; flawed or not, there *are* specs and a global community and a defined process to improve them. That is not valid for .NET. I really can't see the Microsoft's motive to (arguably) base its framework on standards while remaining proprietary.
Sorry I did not list specifics. I can see where I was being too broad. I was just looking for feedback from maybe someone else who has made the transition from MTS/COM+ over to EJB/J2EE.
Most of the papers claims are unfounded. They are mostly rants from Microsoft zealots who are bashing something they have never even programmed with.
As I come across specific instances I will paraphrase them and post to get more feedback.
All I have been able to find is J2EE to .NET junk like the Petstore comparison which I thought was a joke.