Discussions

News: Top Five Reasons to Choose J2EE as Your Application Server

Bookmark and Share Get thread feed

  1. Top Five Reasons to Choose J2EE as Your Application Server (50 messages)

    • Posted by: Dion Almaer
    • Posted on: October 31 2002 10:27 EST
    Sun has come out with a short document that talks about the top 5 reasons why J2EE should be chosen.

    The reasons are:

    1. Integration
    2. Compatibility
    3. The J2EE Programming Model
    4. Web Services Support
    5. Open Standards: Safety and Freedom

    It is interesting to see this document, as it represents the views of Sun themselves. Are these your top 5 reasons?

    A lot of people are bashing EJBs (as always), but they do have value. They shouldn't be used in EVERY application, and only certain types of them should be used in your application, but Stateless Session Beans, and Message Driven Beans are good. (Maybe AOP and JDO will take over).

    Read The Top Five Reasons to Choose J2EETM as Your Application Server Platform.
    Reply to this

    Threaded Messages (50)

  2. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    DAMAGE CONTROL
    Reply to this Reply to original

  3. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    The J2EE vs. .NET report has been debunked as bogus and not informative. Read http://dreambean.com/petstore.html

    I would hope that TSS and/or THe middleware company could respond to these claims, as they seem quite legitimate. The last thing the Java community needs is a report from a pro-Java company like MWC that shows .NET to be far superior in terms of performance, when the comparison didn't seem that fair.
    Reply to this Reply to original

  4. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Dave, TMC already responded with an FAQ and mention of doing a re-test.

    http://www.middleware-company.com/j2eedotnetbench.
    Reply to this Reply to original

  5. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    IMO TMC and TSS can never provide an unbiased report concerning this topic. Take a look at Precise's strategic partners and hidden agendas will be known.

    http://www.precise.com/Partners/Strategic/


    TSS and TMC should never be apart of any sort of benchmark regarding J2EE, since they are owned by Precise.

    moving forward, I suggest J2EE interests in regards to benchmarks be spearheaded by another group that takes pride in their work.
    Reply to this Reply to original

  6. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    n n: "IMO TMC and TSS can never provide an unbiased report concerning this topic. Take a look at Precise's strategic partners and hidden agendas will be known."

    So Precise has Microsoft as a strategic partner. So does IBM and Apple and they are certainly no big fans (for some parts of their business anyway.)

    We've worked with Precise since 2000 (A.D.) on some of the biggest J2EE apps we've seen (multiple e10000s, giant clusters, big integration projects with mainframes etc.) Precise provides performance-related analysis, tools and consulting. Their products are used and sold by companies like Oracle, EMC and Microsoft. They've supported several J2EE app servers with their "Indepth" product line since 2000. They and Wily were two early supporters of performance products for J2EE.

    While I appreciate your desire to find a conspiracy, it looks like TMC just got way over their heads on this one. They shouldn't have gone it alone, they should have required a third party to officiate (including for test design), and they should have disclosed all details up front.

    Instead, Microsoft ends up with one of the (if not THE) best known J2EE consultancies writing a document that appears to independently (i.e. sans Microsoft) show that, in general, .NET is far faster than J2EE, when in reality the test represents probably fewer than 1% of J2EE applications (requiring XA transactions across multiple data sources.) Notably, without that requirement (which Microsoft did not meet -- they did not use XA distributed transactions!) and a few tweaks, the TMC J2EE PetStore can beat the current .NET 1.0sp2. I'm also wondering if the XA logging (the one thing that really killed the J2EE performance and absolutely killed server "B") was on a small static RAM drive (fairly common to use a mirrored array of static RAM drives for TX manager logging for real apps) how it would have done.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  7. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Cameron,

    Trying to rationalize this today only feeds the parasite.
    The next time it festers might be too late.

    http://www.precise.com/Partners/Strategic/

    Among my concerns are what I didn't see on their strategic partners list, which leads me to rationalize conflict of interest for producing the performance report. Where are the J2EE vendors?

    Atleast with some J2EE vendors as strategic partners they will have an incentive to do what's best for J2EE and not just Microsoft and Company.
    Reply to this Reply to original

  8. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Certainly, it is not fair to accuse in conspiracy.
    and it is good to be critisized to improve, it is a
    part of evolving.
    Everyone knows the advantages of Java, and all the
    while MS was trying to undermine popularity of Java
    by implementing DOT PET, modifying Java API and
    refusing to licence Java 2. See it as a credit
    from MS given to Java :)
    Reply to this Reply to original

  9. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    This "retraction" is bogus. TMC should just say it was a bogus report and bow out.
    Reply to this Reply to original

  10. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    This is stupid. An application highly optimized by the so called "J2EE experts" known for the best ejb/j2ee patterns from TSS/TMC found in such a bad shape.
    These are people who are giving training to future developers and architects?

    Setting TX_REQUIRED field for read only methods??

    If the Server B doesn’t support all J2EE features to implement in the application, why are they calling this J2EE Vs .net benchmark? Why not Server B Vs.net benchmark?

    Actually I was planning to take the classes. Thanks to this whole episode, I won’t go for it.

    Ramaraju.
    Reply to this Reply to original

  11. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Ramaraju: "Setting TX_REQUIRED field for read only methods??"

    Yes. On WebLogic, that would be the most efficient setting.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  12. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    rotflmao
    Reply to this Reply to original

  13. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Hi,

    I have heard from several sources at Microsoft that there is work underway to provide "best pratice" references for .Net. If the output of this work is a .Net reference application then I imagine the war of words will be reversed.

    David
    Reply to this Reply to original

  14. HOW KIND![ Go to top ]

    The Damage is already done to both TSS and SUN. People has already seen J2EE in action using a lame unchanged best practices .To say how good and why we should choose J2ee, for now,is irrelevant.As a J2EE developer I don't expect SUN, BEA or IBM to save this technology. Open Source projects such as apache and Jboss will,definitly, show the world how things should be done properly. SUN won't like it but I will...
    Faisal
    UK,Bir
    Reply to this Reply to original

  15. HOW KIND![ Go to top ]

    Hi,

    Business will always looks at the main technology players like IBM, BEA, SUN and Microsoft for technical direction and comparisions. Lets face it if these companies are not actively promoting their own technology base then why bother using the technology?

    As for open source showing the way forward, well in some ways it already does. However it is just part of a big picture that includes and always will include vendors.

    David
    Reply to this Reply to original

  16. HOW KIND![ Go to top ]

    I don't think it's damage control as much as reiterating the benefits of the Java platform. You have few choices to build enterprise level quality applications today. So you pick the one-stop shopping player (Microsoft) or the puzzle builder without a picture (Sun, IBM, BEA, Oracle, Open Source, etc.). Companies and people who evaluate and chose software based upon speed alone will fail 90% of time. This is still a battle of Java vs. .Net, company leaders should dictate the standards and move onward. It's funny we have all the java app server vendors having this same argument over speed yet a completely different tool enters the picture and the java community freaks. This is worse than java open source products competing with commercial java products. The point I'll bring up is who cares if .NET is faster, will the next benchmark showing Java 15% faster actually prove anything? If i've committed my company down a path with Java then it doesn't matter, I'll focus on best practices, product improvements and 3rd party enhancements to build a world class environment. The same goes for .NET should I decide to go down that path, but if I do I had better prepare for the platform culture shock to my people, infrastructure changes, security surprises, and the one-stop shopping mentality I've just moved towards. It's a tough pill to swallow if you’re not a total MSFT shop.

    I'll take a quality framework and products over the most recent overnight wonder product any day. Do all the testing you want but mileage varies with every application and regardless of the outcome I doubt many people will jump ship over this comparison benchmark. Unfortunately Sun does little to actually promote the benefits of it’s technology, especially new api’s and releases. They should let their engineers out of the closets more often and have them publish real-world solutions. Microsoft is just playing with them as usual.
    Reply to this Reply to original

  17. not speed but rather "failure"[ Go to top ]

    Joe,

    you not alone who would be willing to trade performance for other benefits. The issue, at least to me, is not that .NET is 10% faster, or 50% faster, or even 700% faster, but rather how benchmark has characterized java application severs as. Would you consider a server that is "unable to sustain any throughput beyond 4 hours, destabilizing over that period of time to the point of failure"? What does it tell you about J2EE given that it is a sever, I assume, that holds over 30% of market share? (either websphere or weblogic)

    The beauty of that report is that we now know who owns TSS and who pays its employees. It is not "independent unit" of TMC or news agency, but rather both are "dependent" units of Microsoft strategic partner.

    I am sure that Floyd and other TTS employees have a very hard time of facing Java comunity and "striking the balance" between what their supervisors expect from them and what they are known as in Java comunity. This may be the beginning of TSS end and they would do us all favour if they leave that company.

    The "evil empire", this time, has decided to strike from the heart of Java community.
    Reply to this Reply to original

  18. not speed but rather "failure"[ Go to top ]

    The "evil empire", this time, has decided to strike from

    >the heart of Java community.

    TSS deserves scorn for their skewed benchmark.

    Looks like TSS rides Bill Gates' donkey.
    Reply to this Reply to original

  19. Should IBM and Sun be Bothered.[ Go to top ]

    Come to think of it ....J2ee is older than .net and to see .net already kicking ass makes me worry.
    Reply to this Reply to original

  20. Should IBM and Sun be Bothered.[ Go to top ]

    Neeraj, you said:

    >> "Come to think of it ....J2ee is older than .net and to see .net already kicking ass makes me worry. "

    Please, don't believe everything you read.

    The Middleware (TMC) J2EE vs. .NET test is invalid. Overwhelming evidence (http://dreambean.com/petstore.html)proves TMC pulled a scam. TheServerSide (TSS) is now claiming they had no part in this and just posted the link. Don't think so, TMC and TSS are the same, to think that the J2EE "experts" had no knowledge of this external test is silly.

    I wanted to throw Floyd's book out the window and delete my favorite link to TSS, but, Neeraj - your comment makes me want to keep lurking and point out these deceptions.

    Floyd, I have your book and have promoted TheServerSide in the past; I don't understand why your company used this forum for this scam.

    TSS has become a wonderful community for J2EE knowledge exchange.

    However, now TSS has become just a FUD portal...
    Reply to this Reply to original

  21. Should IBM and Sun be Bothered.[ Go to top ]

    George,
    I is Javalobby.com, If it is alternative ot theserverside.com, then we should move to it.
    Definately, Who ever grows big, get mean. Same is MS and now theserverside
    Reply to this Reply to original

  22. Best Practices demo apps[ Go to top ]

    Microsoft has had several "best practices" demo apps available since before the public release of .Net framework. The one that's closest to PetStore is the IBuySpy storefront. There is also a .net version of their long-running demo, Duwamish Books. The oh-so-long url for the many samples is:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetsamp0.asp

    Your sources are probably right that they're working on yet more since they seem to have a small army doing these things most of the time.
    Reply to this Reply to original

  23. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Why is this damage control? Because of the recent "showdown" with .NET? First, that wasn't the scathing indictment that our "DAMAGE CONTROL" writer would like us to believe. And, I'm still not convinced that .NET is going to be faster on equivalent hardware. Running a different J2EE server, without EJBs, on Linux or not windows: that's a common scenario and I think one more likely to go head to head with .NET. Even if it came up slower, i know from experience that it wouldn't be slower by much, and that overall J2EE would remain a solid value proposition.

    What Sun needs to do is talk directly about the things that J2EE can do that .NET can't, and won't for a while. EJBs aren't useful for too many web applications but they are useful in other enterprise apps. .NET doesn't have an equivalent. JMS has a poor stepchild on the .NET side in MSMQ. No CORBA support in .NET. Etc., etc., etc. Can .NET scale up to heavy duty UNIX machines? No. And despite MS's spin, it won't, ever, not reliably. Can .NET scale out (cluster) as effectively? All signs indicate that it can but not to the degree that J2EE can (OS limitations and no clustering app server).

    I think both .NET and J2EE are great frameworks. In some situations, .NET is wildly more appropriate. In a lot of others, especially where truly heavy lifting is involved, J2EE wins hands down. It is a complete enterprise stack, where .NET is just a nice way to build web apps and web services.
    Reply to this Reply to original

  24. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    exactly. The fact that there are several reasons to use a J2EE solution that are more compelling than raw performance show something.
    Reply to this Reply to original

  25. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    TSS needs to addresss the concerns of it's userbase in regards to the dotnet/j2ee performance report before COMDEX. This needs immediate urgency before sheeps are herded at COMDEX by Mr.Gates.


    "Top Five Reasons to Choose J2EE as Your Application Server" after the dotnet/j2ee performance report debacle is ludicrous.
    Reply to this Reply to original

  26. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    COMDEX

    Bill Gates Keynote to Kick Off COMDEX Fall 2002(http://www.comdex.com/)

    Bill gates at the podium with his sparkling Windex glasses and seedy eyes

    Mid level managers and their blow dried side parts try their best to look distinguished

    Bill slides out the gold embossed performance report stamped “from: The Server Side”

    <Bill does his blurb and hand gestures>

    Mid level managers run back home with the headlines. They’re in the know now.

    Mid level managers never realized they were playing three card Monte at COMDEX.

    And never will because they don’t know what a URL is.
    Reply to this Reply to original

  27. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Just a few words. THIS IS THE 1.0 VERSION OF THE FRAMEWORK.
    Reply to this Reply to original

  28. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Posted by Drew McAuliffe 2002-10-31 10:47:15.0:

    "EJBs aren't useful for too many web applications but they are useful in other enterprise apps. .NET doesn't have an equivalent."

    And what is COM+?

    "JMS has a poor stepchild on the .NET side in MSMQ."

    Where is MSMQ poor compared to JMS?

    "All signs indicate that it can but not to the degree that J2EE can (OS limitations and no clustering app server)."

    And what is COM+ CLB on Windows App Center?
    Reply to this Reply to original

  29. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    "JMS has a poor stepchild on the .NET side in MSMQ."


    Steffan: "Where is MSMQ poor compared to JMS?"

     
    MSMQ is a product, a messaging implementation.

    JMS is a standard, an API.

    The only way that MSMQ is "poor" compared to JMS is if there is no standard (e.g. JMS) way to utilize MSMQ. That wouldn't be surprising, of course, since most of the people that use MSMQ are building directly to the product's proprietary APIs. However, that doesn't make the product bad ... similarly, developers were still coding COBOL directly to use various proprietary mainframe databases in the 80s, right?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
    Reply to this Reply to original

  30. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    and only certain types of them should be used in your application,

    > but Stateless Session Beans, and Message Driven Beans are good.

    IMO this oversimplified statement does no one any good and depreciates the value of the news article. Are you suggesting you're going to find universal agreement that Entity beans are !"good" ?. pffft
    Reply to this Reply to original

  31. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Idiots. Documents like this take months to produce, especially given that they had an (external) writer work on it. It's not a response to anything recent.
    Reply to this Reply to original

  32. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    An excellent code-level analysis of the J2EE-.NET benchmark can be found here:

    http://dreambean.com/petstore.html
    Reply to this Reply to original

  33. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    But in my experiance, all true...I work somewhere where we were able to take all of our apps and port them from app server a to app server b, which saved us a ton of money...now we're looking at switching from operating system/hardware a to operating system/hardware b, again saving a ton of money. I fully expect to see this stuff running on additional environments from even more vendors, as more of our base technology becomes Java enabled.

    Also, I've found the Java J2EE stuff to run great...in fact, it screams...and it's been super stable 24x7, not on departmental apps, but on enterprise apps...EJB's included (session ejb's, not entity ejb's...where I'm a bit skeptical).

    I'd even give that .net may be faster than java...a lot of .net is running on unmanaged c code, and it does not have to cover multiple os's. But hardware is becoming a commodity, and other considerations, such as those outlined at the head of the thread, are actually more important.

    I've been pretty pragmatic about .net, and have been actively evaluating it, as I'm sure I'll have to deal with it...my most recent evaluation result has been to find a seemingly up-to-date patched IIS server running a rogue ftp server handing out german-overdubbed copies of monsoon wedding...I'm sorry, but that is ridiculous. As a further observation, I just went to a .NET dog-and-pony show that I did find interesting, but one thing I did note was how paranoid the .net people also were about Java/J2EE...I'd venture to say they are EVEN MORE paranoid about J2EE than Java developers are about .NET.

    Regards,
    Mike
    Reply to this Reply to original

  34. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    anyone know other site like this, but not owned by company like precise. i mean "real independent source", not for making money like this site.

    I really need help in my next project (framework/architecture/ejb design ?/solaris or linux ? etc), i am the only java developer here and just 1 year experience with jsp/servlet/struts/little ejb. it was great success, i love it. my boss love it too and will convert others developers.

    regards,
    Reply to this Reply to original

  35. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Wawan,

    Check out http://www.onjava.com/onjava , really good J2EE information from many sources. Also, http://www.sys-con.com/java/ , provides good J2EE articles.

    I'm glad you disqualified this site for acurate information, this will be a good example to show others, that people in this business are demanding "real" advice.
    Reply to this Reply to original

  36. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    "Check out http://www.onjava.com/onjava , really good J2EE information from many sources."

    But they've also got http://www.ondotnet.com, furthermore they make money with Microsoft technologies: http://dotnet.oreilly.com, therefore they are not independent, therefore they are not trustable. Ah, conspiracies... ;-)
    Reply to this Reply to original

  37. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    I'll throw in my 2 cents, here.

    We've been using .NET pretty much full-time now, for the last six months, as a result of a decision by an outsider. Our app is a robot workflow programming GUI that someday may be web-enabled. Previous to this used Java for about 4 years on typical server-side work, and before that several years of scientific/engineering programming using various tools.

    IMHO, software engineers have nothing to fear from .NET - I seriously doubt it will go anywhere in the long run.

    It's not well thought-out, the IDE is clunky, and the documentation is sparse. Java isn't perfect, but it's a much cleaner, more straight-forward design than .NET. This is ironic because .NET (particularly c#) is largely a ripoff of Java. What happened is that MS tried to make automated 'easier' methods to do many of the common programming tasks. Unfortunately, being MS, they violated good design practices (particularly with regard to encapsulation) when the going got tough. This'll sound familiar to those who wrestled with early versions of DirectX and MFC.

    In regard to documentation, I think we forget how large a community of people, packages, and documentation there is with Java. It's just not the same with .NET - in spite of MS priming the pump with cash a bit. Further, when you're between a rock and a hard place with Java, you always can go through the source code; with .NET you're stuck surfing the web hoping to find someplace/someone who knows what's going on inside that black box.

    My two cents...
    Reply to this Reply to original

  38. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Comparing an SUV and a Car on flat road would be always controversial, especially when the SUV is highly modular & configurable - "build your own" type!
    Reply to this Reply to original

  39. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    These five are legitimate reasons to prefer J2EE. Having read this thread, I think the unflattering comparisons of J2EE and .NET are off the mark. My 2c worth:

    * I've taken a very close look at .NET. It's good. I'd be happy working with it. However, it's not a great advance on J2EE, and I don't see anything that would make me switch from J2EE to .NET. I think multi-language support is clever, but I've discussed it with lots of colleagues in different companies and they're worried about what it will do to maintainability. (For example, I'd like to try some .NET coding in Werth's Oberon-F. You could subclass my class in C# and the junior down the corridor could subclass your class in VB.NET. Sound like a good idea to you?)
    * .NET owes a lot to J2EE, so it's not revolutionary and actually endorses much of the J2EE way of doing things.
    * Pet Store performance controversy: The Pet Store is a very poor application. Period. Rickard provides an excellent analysis of its many flaws in his article (although I'm not going to comment on his dispute with TMC). What's more, the benchmark used an old version. It is a great pity that Sun have produced such a lame "reference application." This application is verbose, slow and disproportionately complex for its functionality. Don't blame J2EE, blame the designers of the Pet Store.
    * Finally, a lot of performance problems I've seen in J2EE applications stem from dogmatic use of entity beans where they're inappropriate. There are times where JDBC, or the use of stored procedures (as in the Microsoft Pet Store) is warranted on performance grounds. While we don't want business logic in the database, persistence logic is a different thing and it can be best to put that in stored procedures. And, as Rickard points out, BMP entity beans are unusable, for performance reasons, in most cases.

    In my new book, I look in detail at these issues, and how we can build J2EE applications for performance. See Expert One-On-One J2EE Design and Development. Before you decide J2EE is better than .NET, I strongly looking at this book. There's a sample chapter on the Wrox site.
    Reply to this Reply to original

  40. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Rod, you wrote:

    >> "I've taken a very close look at .NET. It's good. I'd be happy working with it. However, it's not a great advance on J2EE, and I don't see anything that would make me switch from J2EE to .NET."

    I agree, Microsoft is doing a better job with .NET now. However, why is everyone so concerned about having to switch? J2EE and .NEY could and should coexist to provide solutions, which are appropriate.

    For example, I've just developed a large distributed software application that required Rich GUI clients. We have .NET/Windows clients calling J2EE servers via SOAP and this works great.

    The reality is, a lot of environments already have Unix servers stacked in the computer rooms and Windows on most desktops. If one was to start developing an application for Unix servers - What would you choose, C, C++, PL/SQL, Cobol or J2EE?

    This J2EE vs. .NET should move over to the WWF arena...
    Reply to this Reply to original

  41. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    So what if TSS and TMC made a mistake. So what they got in over their heads (why? because people WANTED to misunderstand the report?). So what if Precise has a 'partnership' with M$? I really don't care. Everyone knows that J2EE and .Net are different, and that you can almost impossibly compare apples to apples here. They are TOO different, and it makes no sense trying to argue for the one or the other. People should not waste their time fingerpointing here, and spend more time reflecting on the lessons to be learned here.

    I for one will continue to read TSS whenever I can - it's not because a couple of extremist J2EE-ers (never any good to be too extreme, if you ask me) want to blow this thing entirely out of proportion. TSS is a great source of info, and will undoubtedly continue to be so in the future.

    With the words of C. Purdy: Peace!

    Rik
    Reply to this Reply to original

  42. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    So what if TSS and TMC made a mistake. So what they got in over their heads (why? because people WANTED to misunderstand the report?). So what if Precise has a 'partnership' with M$? I really don't care. Everyone knows that J2EE and .Net are different, and that you can almost impossibly compare apples to apples here. They are TOO different, and it makes no sense trying to argue for the one or the other. People should not waste their time fingerpointing here, and spend more time reflecting on the lessons to be learned here.

    I for one will continue to read TSS whenever I can - it's not because a couple of extremist J2EE-ers (never any good to be too extreme, if you ask me) want to blow this thing entirely out of proportion. TSS is a great source of info, and will undoubtedly continue to be so in the future.

    With the words of C. Purdy: Peace!

    Rik
    Reply to this Reply to original

  43. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    "(never any good to be too extreme, if you ask me) "

    I imagine that is why in some places they renamed "Extreme Programminng" as "Agile Methods". ;-)

    Sorry could not resist.

    David
    Reply to this Reply to original

  44. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    The report means very little except to Microsoft who paid to see better results for their marketing people. Most decision makers in companies should ask the question “who is TMC?”. These are also people who have their heads buried in Gartner, Forrester, Meta reports that have more value in the long-term. So this little company comes along and publishes a document that probably should have been designated for internal msft usage and upsets a few folks. If you want a valid benchmark then do it yourself. If you want some development guidelines then read TMC for the overview, not the details.
    I would expect the above major analyst companies mentioned above would probably make a comment concerning this report to set the record straight.

    Also there are positives out of this, Sun needs to do some better marketing, I further continue slapping the app server vendors around concerning price/performance factors to drive down costs, and the Java community is very active in building better solutions than .net.

    TSS has a great audience and invaluable information, those who leave just hurt themselves. Microsoft is a smart company and you can’t underestimate the $$ being poured into r&d. Did you really expect a crappy solution for their customers? The problem I see is it that they will continue to make it better and better so can Sun keep up?
    Reply to this Reply to original

  45. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    George, I agree regarding interoperability via web services. I've also used SOAP successfully to integrate Microsoft and J2EE applications. It's great news that platform choice only really matters within a single enterprise now. The external world can see a platform-independent interface.

    Regarding fat clients using Windows/.NET, this is one area where .NET (and Windows generally) is very strong. Microsoft have a stranglehold on the desktop, Swing hasn't got a great reputation, and VB makes GUI development very easy. Although there are performance issues, there are certainly good arguments for developing fat clients using Microsoft technologies contacting application servers using SOAP. Of course, there are lots of situations in which we don't want to use any kind of fat client.
    Reply to this Reply to original

  46. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    There are some good reasons not to also. As long developers continue to use Windows specific tools MS will continue to have a stranglehold on the desktop and the developers' wallets.

    I've done VB for years. While it makes GUI development easy it doesn't make good GUI development easy.

    I've done some things with .Net but not Winforms yet (I may have played a little). I've not heard much about component building just subclassing forms and things like buttons.
    Reply to this Reply to original

  47. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Here's the million dollar question:

    How does BEA and IBM feel about lifting up their skirts for Microsoft and discovering they went down the wrong hole?

    ahhh...the good ole days..scorpion on the turtle's back. Here we go again!
    Reply to this Reply to original

  48. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    How does BEA and IBM feel about lifting up their skirts for

    >>Microsoft and discovering they went down the wrong hole?

    Please mind ur language here. No reason to talk cheap when you know linux and java will kill M$
    Reply to this Reply to original

  49. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    Update. Check out the Microsoft Email:

    http://www.dreambean.com/petstore.html#microsoft

    Guess who is behind this? Yes, the one and only Greg Leakes.

    Remember him? The rat that "tried" to rig the web services poll and was caught red handed:

    http://news.zdnet.co.uk/story/0,,t269-s2102244,00.html
    Reply to this Reply to original

  50. Top Five Reasons to Choose J2EE as Your Application Server[ Go to top ]

    ...don't be affraid - MS won't win in any time.

    And do you know why ? It's not because of performance, money or any other technical related reason.

    MS won't win because the majority doesn't like MS.

    It will be a totally emotional decision.

    Eyerybody has seen what MS has done with its competitors in the last 15 years and they don't want to see something comparable again.

    We all don't want to drive the same car as we now "have" to use the same desktop, browser, office...

    Look back 20 years...do you know why people invented the C/S-Modell ? Not because it was superior to the mainframe model...no...they invented it because it was the only way to beat (in these times) unloved IBM...

    And because of this managers will decide for J2EE...one way to keep our IT alive and FREE...against all odds...

    Oliver.Lauer@sk-koeln.de
    Manager Software Development
    Banking
    Reply to this Reply to original

  51. Carbon AS - J2EE Application Server[ Go to top ]

    We are in the process of developing a J2EE Application Server called Carbon AS, http://sourceforge.net/projects/carbonas/ . We are inviting talented J2EE developers to be a part of our team. If you like to be a part of our development kindly drop me a mail : carbon_developers at yahoo dot com.
    Reply to this Reply to original