IBM and Microsoft respond to Websphere vs. .NET Study

Home

News: IBM and Microsoft respond to Websphere vs. .NET Study

  1. TMC in September released a study comparing WebSphere J2EE vs .NET by productivity, manageability, reliability, and performance. Recently a draft response to the study, attributed to IBM, was 'leaked' to the media. The response concluded that the study was flawed and inaccurate. Today Microsoft also released rebuttal to IBM's response concluding that it was a "very fair study".

    The Middleware Company study Comparing Microsoft .NET and IBM WebSphere/J2EE: A Productivity, Performance, Reliability and Manageability Analysis generated a massive thread of over 394 comments when it was reported on TSS (among other places).

    The keypoints from the the leaked draft response, attributed to IBM, include:
    The latest Middleware Company study is flawed and does not accurately reflect the capability of WebSphere J2EE vs. Microsoft .NET...While expert Microsoft programmers were allowed to contribute to the .NET side, neither IBM nor other WebSphere J2EE product experts were invited to contribute to the testing...The products and toolsets compared in the testing were mismatched, and relatively crude WebSphere J2EE programming techniques were used...The cost comparison between IBM and Microsoft also is inaccurate and does not represent a real-world environment.
    Microsoft's response was released today on TheServerSide.NET, which rebutted:
    ...criticisms IBM raises in this document about the case study report recently published by TMC are by and large, not valid...The IBM WebSphere configuration was approximately 10x as expensive as the Microsoft configuration...The suggestions that the use of ServiceDomain and Application Blocks by the Microsoft team indicate a higher level of skill than the WebSphere team, are unfounded...The productivity advantage of the Microsoft platform is real and well documented....In conclusion, this was an exhaustive and very fair study.
    The Middleware Company was reached for comment, and according to Tyler Jewell, CEO of The Middleware Company:
    There are a number of factually incorrect areas in this document, not reflective of the quality standard IBM follows in their publications. So, we are not sure if this is an IBM sponsored and reviewed document. If IBM creates an official response, we would eagerly post and provide counter-perspective.

    We provide these research documents to the community to give them additional data points to help them in the difficult decisions that have to be made. We've evolved our processes to live by a Research Code of Conduct, publish all of the processes used to achieve the results (full disclosure), and welcome all commentary. The community is free to reject the results of these studies, but we will continue to pursue more studies of significant size – we assume that the community values the opportunity to have more data points rather than not have these results at all.
    TheServerSide Editors' Note: This research is produced and hosted by The Middleware Company, a research and media company, and the parent company of this site. TheServerSide.com and TheServerSide.NET are independent media sites of The Middleware Company and as such do not produce research themselves, and have no involvement in this study beyond providing this thread of discussion for your positive and negative comments alike, just as other media organizations have reported on it (eWEEK, InternetNews).

    Threaded Messages (159)

  2. I am sorry[ Go to top ]

    Look, I do understand that J2EE specialists that
    prepared code for Java-IBM side are real people,
    with families, good and bad habits.
    Yes, it is bad to say bad words about collegues.
    But let us be honest.
    Not using connection pool, source control and
    missing some basic database knowledge means only one thing.
    They are not good for the task.
    My apology to the these people, they are, I am sure
    nice people...

    Alex V.
  3. No need to be sorry[ Go to top ]

    Alex, as one of the nice people who worked on this study, I can say confidently that the issues you cite from the IBM response are among those that the IBM author misrepresented or misunderstood.

    The notion that "a new connection had to be created for EVERY call to the database" (as the IBM doc states) is just plain wrong:

    * Our application obtained database connections from a J2EE data source representing a connection pool. The data source object itself was cached by a ServiceLocator class.
    * We even created separate data sources to the same database for XA and non-XA transactions to avoid incurring extra overhead for the latter.
    * We optimized our JDBC to perform multiple operations in a single DB invocation without having to use stored procedures.
    * As for the persistence-tier POJOs themselves, most were singletons, further reducing overhead.

    Regarding source control, we did use it: RRD hooks directly into Visual Source Safe, which we used. It's cited in our report.
  4. No need to be sorry[ Go to top ]

    David, thanks for clarification.
    I was too quick to judge...

    Alex V.
  5. when are managers going to realize it is the people who work for you that make it happen. no tool is going to magically make your project scale like a skyscraper, zoom like the roadrunner and pound your competition like the hulk.

    About the only thing the study proves to me is hiring the wrong people for the wrong job results is poor productivity. Hiring experienced programmers and give them tools they are familiar with produces good results. How is this different than common sense?

    Regardless of what IBM and Microsoft say about the study, I think the right thing to do is to revise the paper or withdraw it completely. Not only thing the paper achieves is it cloud the issues, and ends up making life harder for programmers. I'm sure most programers have been asked to use "technology x" because it is hot and the new fad.

    A study is only valid to me, if it directly applies to what I'm working on right now. If my requirements change drastically, I have to re-evaluate the tools and make sure they are still sufficient. If not, the right thing to do is change the tools. More often than not, the requirements change, but management insists on using the same tools and keeping the same deadlines, even when it's obvious it's not possible. but that's life.
  6. no tool is going to magically make your project scale like a skyscraper, zoom like the roadrunner and pound your competition like the hulk.About the only thing the study proves to me is hiring the wrong people for the wrong job results is poor productivity. Hiring experienced programmers and give them tools they are familiar with produces good results. How is this different than common sense?.

    +10 - Perfect
  7. +11
  8. I`d like to hear from the TSS guys if their performance judgement (ejb vs. jdbc&pojos) was based on results (measured) or they simply said well jboss rocks for jdbc&pojos go for it chap?

    Yes the real issue is the people.
  9. +1
  10. That's Why Dan Rather Said...[ Go to top ]

    ...oops, wrong biased media scandal...
  11. I am a little bit puzzled about a statement in the IBM respone. It suggests that when using jdbc eg direct from a servlet there is no connection pooling. However when I read the WebSphere documention I get at least the impression that there is connection pooling also when accessing a database through JDBC from eg a servlet.

    <QUOTE from the IBM response>
    The J2EE developer team used POJO (Plain Old Java Object) instead of what best practice might have indicated
    here – EJBs. It was noted later in the report that the team created a “framework” to handle the JDBC access. If they
    had used EJB’s, they would have had the container handle the pooled requests and it can be argued that the
    performance would have been better. In the POJO scenario, a new connection had to be created for EVERY call to
    the database which is very expensive. In addition, they spent extra time developing a “crude” framework to handle
    the requests, which counted against them.
    </QUOTE>

    <QUOTE from the WebSphere documentation>
    Connection pooling
    When accessing any database, the initial database connection is an expensive operation. Connection pooling enables administrators to establish a pool of database connections that applications can share on an application server. When connection pooling capabilities are used, performance improvements up to 20 times the normal results are realized.

    Each time a resource attempts to access a backend store (such as a database), the resource must connect to that data store. A connection requires resources to create, maintain, and then release the connection when it is no longer required.

    The total data store overhead for an application is particularly high for Web-based applications because Web users connect and disconnect more frequently. In addition, user interactions are typically shorter. Often, more effort is spent connecting and disconnecting than is spent during the interactions. Also, because Internet requests can arrive from virtually anywhere, you can find usage volumes large and difficult to predict.

    To help lessen these overhead problems, the WebSphere Application Server enables administrators to establish a pool of backend connections that applications can share on an application server. Connection pooling spreads the connection overhead across several user requests, thereby conserving resources for future requests.

    WebSphere Application Server supports JDBC 2.0 Standard Extension APIs to provide support for connection pooling and connection reuse. The connection pool is used to direct JDBC calls within the application, as well as for enterprise beans using the database.
    </QUOTE>

    Can somebody help me out and clarify for me what is meant in the quoted IBM respone snippet?

    Gr,
    Frank
  12. Depends[ Go to top ]

    I have not seen the WebSphere version of the code, but if it calls DriverManager.getConnection(...) using a direct url for the database (for example jdbc:db2:database), no connection pooling will be used.
  13. Connection pooling question[ Go to top ]

    I have not seen the WebSphere version of the code, but if it calls DriverManager.getConnection(...) using a direct url for the database (for example jdbc:db2:database), no connection pooling will be used.

    The J2EE team in the study created two separate implementations of the project spec: one with RRD, the other with WSAD.

    The code RRD generates by default uses DriverManager to get connections. But RRD can be configured to use a J2EE datasource / connection pool, which is what we did.

    In the WSAD implementation, all JDBC code was explicitly written. We used a datasource to get connections and even cached the DS object in a ServiceLocator class for added efficiency.
  14. Depends[ Go to top ]

    But it is not that is not possible without EJB, by using the right jdbc calls it also possible to get connection pooling, isn't it?

    Gr,
    Frank
  15. Depends[ Go to top ]

    That is not true. We use the Opta driver and it has internal pooling. Calling Driver.getConnection will return a pooled connection.
  16. Another massive study[ Go to top ]

    I guess IBM can pay TMC for another "massive" study that would certainly prove WAS is better than .NET.
  17. In the "IBM" article, they stated:
    The J2EE developer team used POJO (Plain Old Java Object) instead of what best practice might have indicatedhere – EJBs. It was noted later in the report that the team created a “framework” to handle the JDBC access. If they had used EJB’s...

    We did, of course, consider using EJBs. The ones they are alluding to here are obviously Entity Beans. In previous internal work we have done tests on various persistence frameworks and found Entity Beans to dramatically reduce performance. Quite obvious really, since everything ends up using JDBC in the end, what could perform faster than writing a small compact JDBC framework through connection pools. A container just adds unwanted bloat.

    Since the study covered productivity and performance, amongst other things, the decision had to be a balance. Yes WSAD had wizards for entity beans, so productivity may have been slightly higher, but the performance would have sucked.
  18. out of curiousity[ Go to top ]

    why not just use hibernate to take care of data access instead of writing your own think jdbc layer? Since EJB for this case would be way over kill, I would think hibernate would have made life easier. my apologies if this question was already answered, since I didn't read the entire paper. just a few pages.
  19. Why could EJB be faster?[ Go to top ]

    "...what could perform faster than writing a small compact JDBC framework through connection pools"

    How about an EJB container that caches materialized entities to avoid round tripping and impeadance mismatch costs?
  20. Why couldn't EJB be faster?[ Go to top ]

    "...what could perform faster than writing a small compact JDBC framework through connection pools"How about an EJB container that caches materialized entities to avoid round tripping and impeadance mismatch costs?
    Obviously, if caching is permitted. In this case it was not. The specification clearly stated that nothing could be cached at the data level - the web pages had to represent live data. The only entity stored across pages is the user information which was required to be stored in the users session.

    If caching had been allowed, hibernate would probably have given good results too. I would be interested in learning about any solution that could have given better performance than the solution we provided - JDBC (using connections pools, cached prepared statements) straight into POJOs or collections of POJOs.

    One interesting touch point here is that the messaging aspect of this study was performing database inserts (adding work tickets) in a transaction that included consuming a JMS message (used XA) and beat the .NET implementation by a factor of almost 3:1 (actually 526:198 messages per second). If the database side or .NET use of stored procedures had really been a factor, would it not have been evident here also?

    It would be interesting to me, and I think the community at large, to understand just where the bottlenecks in J2EE applications really are. If it really is the web tier (as this small data point implies) we have learnt something and can focus our attention on improving that aspect of our systems.
  21. The rebuttal is true[ Go to top ]

    This is what makes the study such a piece of dire rubbish. As they did not use EJB's, then WAS express would have sufficed at a cost equal to microsoft's. However, they chose to use the full version of WAS, but without using it's superior scalability features (activity sessions, bean cache, JDBC rowset cache, servlet cache) - with features WAS would have seriously blown .net out of the water.

    It's funny how the .net team got to use the very latest features, yet the WAS team did not even use Struts! .. let alone JSF.

    And why a seperate server for MQSeries? every moron knows it's built in to WAS.
  22. There seems to be an interesting relationship between what is stated in the "Research Code of Conduct" and the attitude of the researchers. For example, Steve said thusly:
    We did, of course, consider using EJBs. The ones they are alluding to here are obviously Entity Beans. In previous internal work we have done tests on various persistence frameworks and found Entity Beans to dramatically reduce performance. Quite obvious really, since everything ends up using JDBC in the end, what could perform faster than writing a small compact JDBC framework through connection pools.
    This is a belief, not a fact.
    A container just adds unwanted bloat.
    This is a belief, not a fact.
    Since the study covered productivity and performance, amongst other things, the decision had to be a balance. Yes WSAD had wizards for entity beans, so productivity may have been slightly higher, but the performance would have sucked.
    "would have". "could have". "should have". "might have".

    Belief, not facts.

    The conduct states as first point:
    We publish only what we believe and can stand behind.

    It appears that it is actually very accurate, although perhaps not in the intended way. TMC does indeed publish what they *believe*, although that doesn't necessarily have anything to do with facts.

    Considering the attitude above it seems almost impossible to conduct a fact-based study, regardless of all other technical and non-technical factors.
  23. I can give you more informations.
    I have put online this kind of pool.
    You have to use a datasource registred in Websphere thru JNDI.
    You don't have to code any pool.
    If you do so, Websphere will catch any connection created and send it to the database pool.
    It increase a lot the performance (up to 10 times faster for some heavy load).
    Note that other products do the same : at least Weblogic and Tomcat.
    look at http://jroller.com/page/brunochevalier/ for code example.
  24. TMC: Bought and Paid for[ Go to top ]

    When I saw this report come out, I couldn't believe that the TMC was at it again. Look, you would have to be a complete idiot to believe that their findings are not sculpted to meet the needs of their client, Microsoft.

    I didn't bother to look at the code, but if they did not leverage J2EE connection pooling for JDBC DataSource objects, than this is obviously the product of either very ignorant developers or shills.

    There are two types of analyst companies in the world: Honest ones that actually do the research and provide unbiased analysis, and the others. The others are analysts for hire. They find the results that they are paid to find. If an analyst company provides their reports for free, it’s a good indication that they may be analysts for hire. The fact that the analysis is free indicates that they are making money form the sponsor, not the public who reads their research. TMC is, without a doubt, an analyst-for-hire company. I would not trust anything they said.

    In fairness its important that you understand that I work for Burton Group, an IT analyst company that charges a fee for those who subscribe to their research. Burton Group doesn’t do work for hire. We are one of the honest companies. Anyway, the fact that I come from another analyst group is important in judging the value of this post. However, I don’t think we compete with TMC at all because they are chasing a completely different kind of customer: Vendors will to pay for analysis that makes their products look good.
  25. A bit of a laugh[ Go to top ]

    Hi RMH -

    I had to laugh when I saw this post and your bio has:

    "Primary Distinctions: Named one of the 50 most influential people in J2EE by The Middleware Company."

    ;)

    Dion

    ps. just teasing!
  26. Richard Monson-Haefel!

    Are you still in computer business? After such a major catasrophe? After havin been so capital wrong? After propagating EJB for years? Are you inventing new server-side pseudo-technologies nowadays? No?

    Working fot the Burton Group? OK.
    An IT analyst? hi hi

    Sorry. Got something in my throat..

    Well you have at least one thing going for you.. You certainly have guts to dare to show yourself in the IT business at all! :)

    Best regards
    Rolf Tollerud
  27. You certainly have guts to dare to show yourself in the IT business at all

    People in glass houses...

    -Nick
  28. Trollfy you little schmuck !
  29. TMC: Bought and Paid for[ Go to top ]

    MS chose TMC because it owns TSS with its wide Java audience. The Java community was the main target of this study financed and orchestrated by MS. Many of this site readers (and I don't mean the big shots who post regularly here) will start to believe Java technology is inferior to MS's. That is exactly what the marketing army at MS wants us to believe and they have the money to "prove" it. Since the release of .NET, TSS has been posting one news item after the other, one flawed study after the other all showed Java unfavorably. In the big scheme of things TMC and TSS are playing their part in the MS marketing campaign (they are hired and paid for it.) And considering the trust the Java community have placed on this site until now, what they are doing is harmful to Java and its community. This site has been going downhill when comes to the quality of its contents. I personally spend less time here and more time on blogger sites (where no "massive studies are done. Only the real thing.) Now it is not only the content, but the mission of this site and its parent company.
  30. TMC: Bought and Paid for[ Go to top ]

    Many of this site readers (and I don't mean the big shots who post regularly here) will start to believe Java technology is inferior to MS's

    Been working with .NET for last six months and I am glad to switch back to Java. IMO .NET still has ways to go to catch up to Java and its broad community and natural knowledge base. That is why these studies get funded by MS, so instead of catching up in technology they will catch up in comparisons and skewed benchmarks.

    In the end knowing both is a big plus IMO...

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  31. I did not read either the first article nor the responses, but usually these kind of studies are all useless, IMHO.

    Both platforms have their pro and cons. Lets face it : there are people writing good software in C++, Pearl, PHP, Ruby, Phyton, ColdFusion, etc, etc...

    The really important thing in any sucessful project is the people involved : clients, developers, management.

    Technology used usually simply does not matter. Things like productivity, manageability, reliability, and performance are all lost if the people involved does not know exactly what are doing.

    Really boring thread...
  32. Technology used usually simply does not matter.

    +1
    Probably technology matters if you are developing product, but it does not matter for short term project.
  33. I'm truly not surprised.

    First I'll say: I've worked with TMC on past studies, and I am confident in the quality and accuracy of their work....I've witnessed first hand how they apply a lot of effort for the underdog case.

    BUT....(excuse my bluntness, I'm about to exercise my right to free speech)

    I'd wonder why this study was done at all. Everyone knows that WebSphere blows pickle. It's simply the worst J2EE platform in existence. We all know what app server "B" was in past studies. Not to mention other studies where even Tomcat blows the pants off of IBM's sad commercial offering.

    In my experience, WebSphere is bar-none the worst performing, least compliant and most troublesome J2EE platform there is. It sucks.

    I want to see a comparison of stuff that people WANT to use, not the stuff that some of us are forced to use because some sales leech took a CIO to a football game.

    But that's just my opinion.

    Cheers!
    Clinton

    PS: Eclipse sucks too (might as well start a flame war if I haven't already). <-- Bait. Here fishy, fishy. ;-)
  34. I'm not surprised....WebSphere blows.[ Go to top ]

    I feel a bit uniquely qualified to comment on this thread. I say so for a few reasons. First off, I spent many years very ingrained in the J2EE community. I was a Principal in the development of a J2EE branded application server for a major software firm. Clearly in that role I was very involved in the community, the direction and implementation of server-side Java. I am a three time speaker at JavaOne, etc.

    Secondly, I also worked at Microsoft in their .NET Servers group as a Product Manager. I know Greg Leake the Group Product Manager who was at least in the past the driver behind the development of the .NET Petstore fury and I assume involved in this one. I was a speaker at Microsofts TechEd (Actually, now I wonder. How many people have spoken at both.... Hmmm trivia question) I know how Microsoft and their marketing group work.

    So I have a damned good inside view of this debacle.....
    I'm truly not surprised. First I'll say: I've worked with TMC on past studies, and I am confident in the quality and accuracy of their work....I've witnessed first hand how they apply a lot of effort for the underdog case.

    I agree absolutely. I have met and worked with folks at TMC and TSS.com and I have great respect for them. I do not for one believe that Ed or anyone else involved in this would lie, cheat, steal or whatever other conspiracy garbage people are going to throw out here. <Ok Rickard, I opened the flamebait door LOL>

    Did MSFT pay for the study? Of course. They chose TMC to try their best to make this look resonable. To make it not look, how it will always look, as a one-sided marketing gimic. What else could they do? But guess what. They pay for and outsource most everything. Thats how things get done at Microsoft. Its a very different mind-set, its a very different culture, its just like no-where else (good and bad trust me). Look guys, every study on earth has been paid for by someone. I can tell you I have seen "dependable" analyst firms let their customers write their whitepapers, and tout software that was bought lock-stock-and-barrel. Welcome to the ugly world of sales. Live with it.


    Everyone knows that WebSphere blows pickle. It's simply the worst J2EE platform in existence.

    Now truer words havent been spoken in this thread so far. Again, thats not an accident. Plus to be fair, MSFT has laser focus when it comes to a competitor. They knew YEARS ago that Webspehere was going to slaughter BEA in the market. You can look at some of their "aquisitions" of product managers on that team, and what company they came from and thats pretty damned clear. So they saw IBM as the eventual threat here, they also knew where IBM blows (because they own it, have it in their labs, and prolly know more about it then you do!) I've never seen any company who knows their competition as well as MSFT does. And they pay dearly to get that information.

    I personally think MSFT made a big mistake here, and on the JPS. A lot of it boils down to the personalities of the folks driving it. Ya know what? I wouldnt have beat IBM's socks off (Go Red Sox!). Nope. No way. I'd have tied them. Or maybe lost but just barely. Ya know why? A tie, or even a damned close, is a MASSIVE win for MSFT with business decision makers (BDMs). Because the CIO's and the VP's at major firms want predictable delivery at a resonable cost. Guess what folks. VS.NET does that. Is it the utmost tool on earth? Is .NET massively better then J2EE? Who the hell knows. In the end every project is different, every developer has his own strengths. BUT the issue here is the J2EE community, unlike MSFT doesnt know their competitor. They throw crap FUD like "it doesnt scale, it performs bad, its rat posion" out into the market. And guess what? MSFT just debunks that myth. BDM's only remember sound bites guys. And they got fed a BS sound bite, and MSFT just proved it. Managers now think their developers have lied to them about MSFT being slow, and now want to do what they always wanted to do. Give MSFT a shot.

    They are very fond of the story of the two hunters and the bear at Microsoft. You know the one.... Two hunters run into a bear. The bear charges and they run. One hunter says to the other one. "Boy, I dont think I can outrun that bear". The other hunter says "I dont need to, I just need to outrun you!" This is what this is about.

    Shame on us. If SUN and IBM spent as much time learning about their competitor as they did preaching they'd be doing a lot better.

    To quote Sun Tzu.

    "It is a doctrine of war not to assume the enemy will not come, but rather to rely on one's readiness to meet him; not to presume that he will not attack, but rather to make one's self invincible."

    Microsoft knows this well. Everyone else blew it.



    Eclipse sucks too (might as well start a flame war if I haven't already). <-- Bait. Here fishy, fishy. ;-)

    Hey thats usually my job!

    Dave Wolf
    Cynergy Systems
  35. Everyone knows that WebSphere blows pickle. It's simply the worst J2EE platform in existence.
    Now truer words havent been spoken in this thread so far. Again, thats not an accident. Plus to be fair, MSFT has laser focus when it comes to a competitor. They knew YEARS ago that Webspehere was going to slaughter BEA in the market.

    This is the saddest part about the whole thing. IBM has become the standard bearer for J2EE and it's just as bad as this study makes it out to be. When I was interviewing with TMC as they were setting up this research business, I don't think they were too thrilled that I was pushing comparisons of lightweight frameworks vs. the full J2EE stack or .NET. There's no money in that, I guess, but it's pretty apparent that developing J2EE apps on WebSphere is not competitive.
  36. I'm not surprised....WebSphere blows.[ Go to top ]

    I agree absolutely. I have met and worked with folks at TMC and TSS.com and I have great respect for them. I do not for one believe that Ed or anyone else involved in this would lie, cheat, steal or whatever other conspiracy garbage people are going to throw out here. <Ok Rickard, I opened the flamebait door LOL>
    The greatest conspiracy of all is that there are no conspiracies.

    As for the rest history speaks for itself with regard to the quality of work and honest of said people.
  37. The greatest conspiracy of all is that there are no conspiracies.

    As for the rest history speaks for itself with regard to the quality of work and honest of said people.

    It cannot be a surprise to anyone that the study happened. Microsoft has $50 billion and a lot of ground to make up in the market. TMC had a good name and reputation, and wanted to get some market spotlight and a piece of the $50 billion.

    Knowing some of the participants, I can say that TMC did not throw the contest. In fact, they tried quite hard to make Java/J2EE come out ahead. In other words, they did their best. So to say that TMC intended that Microsoft win this because Microsoft was paying for it is simply wrong.

    Microsoft "won" the first round outright for several reasons, including that the J2EE application servers being used (BEA and IBM) were either non-operational (in the Websphere case it couldn't even finish the tests) or non-optimized (Weblogic was heavily optimized after these tests, and to some extent because of the outcome of these tests, and also related to the new spec tests.) Further, the implementations for .NET and J2EE were totally different, and Microsoft's implementation (disguised as an outside vendor's to make it look like Microsoft wasn't involved ;-) was fully optimized for the .NET environment -- including many bad design decisions that made it into an unmaintainable mess that was even heavily criticized by .NET developers.

    The real coup for Microsoft, though, was the ability to get a study out without its own name on it. For a whole week, no one (except for a few "in the know") realized that this study had actually taken place in Redmond, under Microsoft supervision, on Microsoft's own computers, with Microsoft engineering support, on Microsoft's own dime, and in Microsoft's own offices. Simply brilliant. I guess every once in a while, $50 billion comes in handy.

    Of course, it has to be pretty boring to have so many tens of thousands of bright people, and still only be able to make money off of two 20-year-old products. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  38. I'm not surprised....WebSphere blows.[ Go to top ]

    I agree absolutely. I have met and worked with folks at TMC and TSS.com and I have great respect for them. I do not for one believe that Ed or anyone else involved in this would lie, cheat, steal or whatever other conspiracy garbage people are going to throw out here. <Ok Rickard, I opened the flamebait door LOL>
    The greatest conspiracy of all is that there are no conspiracies.As for the rest history speaks for itself with regard to the quality of work and honest of said people.

    Damn..... That might be one of our shortest exchanges Rikard. And in the end I cant decide if we agree or not? Those are my favorites :)

    Dave Wolf
    Cynergy Systems
  39. IBM's criticism is valid...[ Go to top ]

    especially considering the relative skills of the development teams.

    It was obvious that the developers on the "Websphere" side weren't at all experienced in Websphere....the report itself said as much in its findings. How is it, then, that these developers were considered of similar skill level to the Microsoft Solution Provider developers, who obviously were practitioners of .Net??

    This, in and of itself, invalidates the study. In order to make a comparison between development teams of comparable skill, you actually have to have development teams of comparable skill. It is very obvious that the more skilled team was working on .Net.

    The problem with the study's methodology was exascerbated because it pitted *one* .Net development team against *one* J2EE development team. Statistically, it's hard to call the results representative when the sample size was n=1. The results of the study were that *these* .Net developers were much more productive than *these* J2EE developers.
  40. IBM's criticism is valid...[ Go to top ]

    Robert,

    In fact, the J2EE team had markedly greater experience (a total of 16 years among three members of the J2EE team vs. 10 years for the .NET team). The more significant difference between the two teams lay in their experience with the respective product platforms. To augment any experience gaps, the J2EE team hired two independent, IBM WebSphere-certified consultants with 7 years’ experience with the WebSphere platform.

    The point we were making in the report is that because the VS product has been around a lot longer than the comparable J2EE developer tools that the tool is more mature. Likewise the respective developers have had longer to get familiar with the idiosyncrasies of that product.

    I hope that helps straighten the point out a bit.

    Cheers,
    Will
  41. IBM's criticism is valid...[ Go to top ]

    Robert,In fact, the J2EE team had markedly greater experience (a total of 16 years among three members of the J2EE team vs. 10 years for the .NET team).

    There is a difference between "experience" and "skill". The .Net guys were better solution architects than the J2EE folks.

    It's a moot point anyway, the next release of both Microsoft's and IBM's tooling will blow the current releases out of the water.

    Maybe next time we can see a statistically valid study? Say, one where n > 10 (see original post)?
  42. a bit unfair on eclipse[ Go to top ]

    do we really need to slam eclipse in the discussion? I use eclipse as my primary development environment and I've written plugins for eclipse. by far, it is one of the better environments and makes writing plugins easier.

    not only have I learned a ton from reading eclipse SWT source code, but the design patterns and implementation in eclipse platform are solid. Of course, that doesn't necessarily mean WSAD is better than VS.NET. Having used VS.NET the last 2 years, there are some things I like about VS.NET, but there are other things that really annoy me.

    I haven't used WSAD myself, since it's expensive and I don't need it. but from what I hear, IBM recommends a system with 1GB of ram to run the darn thing. Some people I know like it, while others hate it. IBM does things their own way, so it takes a certain mindset.

    the effectiveness of WSAD doesn't necessarily reflect on eclipse the IDE and platform. just for some perspective.
  43. IBM is a Consulting Company[ Go to top ]

    I think it is not in IBMs interest to make their J2EE offering of Websphere and WSAD/Eclipse/Rational XXX usable or understandable to the average developer. The consulting revenue from helping customers make sense of this quagmire is very attractive.

    Microsoft wants to sell you an operating system and software and seems to be doing a good job at it (where IBM has many times failed).

    I'm certain that with the correct army of IBM consultants the Websphere project could be made to run as well as the .NET project.
  44. IBM is a Consulting Company[ Go to top ]

    I think it is not in IBMs interest to make their J2EE offering of Websphere and WSAD/Eclipse/Rational XXX usable or understandable to the average developer

    What is the average developer in your understanding? Stupid and inexperienced?

    Interesting thing is that it is usable and understandable, and those who complain, especially about something like Eclipse, are just ignorant about the technology around them and lack experience and will to gain it.

    Anybody can come up with criticizm about any J2EE server, but IMHO market caps speak for themselves and WebSphere's is not the smallest one. I've worked with Weblogic, Webspehere and JBoss and all of them had problems just different ones.

    I do not even see how one can compare .NET - a platform locked-in and specific architecture (no Mono references please) and a crosplatform J2EE implementation. WebServices/Service or COM Objects running on IIS/Component Server vs. J2EE container? Do not see any value in this kind of study besides marketing goals...

    Any, just my 2 cents...

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  45. IBM is a Consulting Company[ Go to top ]

    Eventually, poor developers (who even complain about Eclipse) will migrate to .NET (could still beat VB6 converts, isn't it?) and skilled developers will prefer Java.

    Eventually Java solution will prevail at the high end while .NET will get its share at the lower end.

    Just check how many responses you can find to the same subject at theserverside.NET, you will laugh.
  46. Thanks[ Go to top ]

    Artem D. Yegorov "..just ignorant about the technology around... and lack experience and will to gain it"

    George Jiang "poor developers... complain about Eclipse and skilled developers will prefer Java"

    2 not so thinly-veiled personal attacks for an opinion about a company.

    Remember when Big-Blue was the bad guy? Then along came Borg Gates and now IBM is the savior.

    Computer Technologists are as fickle as Western Europeans.
  47. Thanks[ Go to top ]

    2 not so thinly-veiled personal attacks for an opinion about a company.

    For those who take it personally I can't help but remember the proverb: "Truth hurts the most".

    What you see as a personal attack is nothing but an opinion on my part. IMO any developer should not attack any technology because he or she can not bring themselves to learn how to deal with it. There are no flawless solutions out there and it is more personall openly saying that something sucks although there are plenty of people successfuly using it than merely suggesting to invest more time in learning and analysis. Doing that is plain ignorant of other people's opinions and thoughts.
    Remember when Big-Blue was the bad guy? Then along came Borg Gates and now IBM is the savior.

    I was not defending IBM or blaming MSFT, it is a general suggestion. I've been on both sides of the fence and I would really prefer if the fence would not exists at all and developers instead of bashing each other would just cooperate and be agnostic to other's being in favor of .NET or J2EE or any particular vendor. That's why I am against studies like the one discussed in this post and think that such do not bring any value but just incur developer battles, IMHO.

    In the end the more you learn the better off you are as a professional.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  48. IBM is a Consulting Company[ Go to top ]

    .I'm certain that with the correct army of IBM consultants the Websphere project could be made to run as well as the .NET project.

    I would doubt even that. I've used that junk - and IBM's consultants weren't able to help us with our Websphere problems. I don't have much experience with comparable project architectures in .NET, however.

    Regards,
    Stefan
  49. IBM is a Consulting Company[ Go to top ]

    Must be one of those YMMV type of things. I've had nothing but good experiences with Websphere.
  50. I think Osvaldo's post at JL makes it all pretty clear.

    See below...


    Some favourite pieces:

    1) TMC decides to run IBM's tools on the Sun JVM (any idiot knows that WSAD, WAS and related IBM tools require IBM's own JRE), of course it causes problems that cut productivity points from the J2EE competitor

    2) The .NET team (who are top-skilled developers from a MS parter) uses Visual SourceSafe, the J2EE team (developers from TMC showing weak WebSphere skills) doesn't benefit from any version control system (even though the IDE offers two -- CSV and ClearCase), and loses time copying and merging sources manually

    3) The J2EE and .NET tests were performed on different platforms (different databases and OSes)

    4) Different designs, like using stored procedures in the .NET implementations but not in the J2EE version. It's funny that these distinctions are always in prejudice of the Java competitor. Add this to restrictions like not allowing multi-tier configurations (as J2EE would make a better figure than .NET)

    5) Performance tests wouldn't try to saturate the servers; this produces results that don't show the superior scalability and robustness of the J2EE platform under heavy loads. See next item too

    6) Cost comparisons are totally bogus, the J2EE solution used loads of high-end hardware without need, and this didn't even benefit the performance scores because the perf tests didn't stress that hardware. IBM says that WebSphere would handle the same workload cutting $200,000 worth in hardware. And in the .NET side, they make mistakes in the opposite direction (of course), failing to account for equivalent support terms and client access licenses

    7) This one is hard to believe, I'll quote IBM literally: "On the integrated scenario, the testers conveniently chose to implement 75% of the application where Microsoft is slightly better than IBM, and only 25% of the application where IBM is better than Microsoft on a 2 to 1 ratio, when run together. If one does the math on the separate scenarios, IBM should have been 650 vs. 550 for Microsoft, yet with integrated scenario IBM is 482 vs. 855 for Microsoft."

    http://www.javalobby.org/thread.jspa?forumID=61&threadID=15159
  51. What's the fuzz about?[ Go to top ]

    Every good programmer knows that the only benchmark that holds water is his own.

    So what's the fuzz about?
  52. I wonder... ?[ Go to top ]

    I wonder how could .NET be superior to WebSphere in reliability and manageability while its MVC architecture is nothing but a small wooden shed?
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ASPNet-ASPNet-J2EE-Struts.asp


    How could it be superior while it has a major vulnerability in its authentication framework?
    http://www.microsoft.com/security/incident/aspnet.mspx
  53. I wonder... ?[ Go to top ]

    How could it be superior while it has a major vulnerability in its authentication framework?

    Here is some java vs dotnet security statistics

    http://blogs.msdn.com/michael_howard/archive/2004/10/25/247470.aspx
  54. I respect the guys at TSS, and applaud them for sticking their necks out again!

    However, I think TSS nailed the problem when they published their "retraction" of their original JPS study:

    "A 2nd round test would fully involve vendors from both the Microsoft side and the J2EE side. It would also involve you -- the J2EE community at large. The process would be public, open, and auditable. The community would have the chance to review code as it is developed, and provide feedback to ensure J2EE is well represented. "

    http://www.linuxbusinessweek.com/story/46828_2.htm

    How one could conduct a (commercial) study under these conditions is of course an exercise for the reader! ;-)

    Sincerely,

    Daniel Selman
  55. M$ funds these study even runs the test on their lab and TSS publishes them . Monkey dances in the back ground.
  56. I agree with many of the posters here that the teams were unbalanced. Quality developers will develop a quality solution given good tooling. If an experienced team is given either WebSphere or .NET as the tool, they will produce good results with either one. In test like this, you're only proving one team of developers is better then the other.

    I do, however, have to agree with the MS response regarding the various architecture choices that a J2EE architect needs to make. There are too many options. If a J2EE project does not have a top-notch architect at the onset, then the project is in big trouble. Questions such as: Should you use a framework? Which one? What presistence? Should you use EJBs at all? Even fundamental decisions such as logging need to be decided up front. And what about design? How do you get the design out to the developers? Basically, you can have 2 teams work off the same specs and both will create completely different code while both are doing "J2EE". I'm certain there will also be a disparity in the development time too. I have feeling that .NET is much more consistent then this.

    Having never done much with .NET, it is my feeling that you don't need a "top-notch" team to develop a .NET solution. Due to the limited choices provided by just one vendor, it seems easier during design time because you only have the Microsoft "best practices" method to go from.

    Then again, you have to deal with all the VB turned .NET converts who think they are real programmers now... :P
  57. first hand experience[ Go to top ]

    Due to the limited choices provided by just one vendor, it seems easier during design time because you only have the Microsoft "best practices" method to go from.Then again, you have to deal with all the VB turned .NET converts who think they are real programmers now... :P

    having spent the last 2 years trying to build a high performance system, the hard part is when the stock "best practices" only cover 25% of what you need. though in my case, it was more like 10-15%. We ended up writing a ton of infrastructure related stuff, because the stock stuff wasn't sufficient. If we had better programmers on the project with experience building event driven systems, it would have been less painful. that by no means proves .NET scales/doesn't scale. It did show in this particular case that trying to build an event driven architecture with .NET 1.1 is significantly harder than using java open source stack.

    for stock webservice stuff, I'd agree VS.NET 2003 does make life easier for programmers used to winforms and ASP programing. when it comes to integrating with mainframes, J2EE and other non-microsoft systems, I find .NET requires much more work. but that's my bias perspective.
  58. Robert,
    I have feeling that .NET is much more consistent then this.Having never done much with .NET, it is my feeling that you don't need a "top-notch" team to develop a .NET solution.

    You are exactly right in what you say here and we have experienced this many times. Most of the less-experienced developers can deliver higher quality software in .NET without me watching over the shoulder all the time than they can in Java. I think the reason for this is the whole package: VS.NET, .NET and SQL Server, just works so well together. However, on the flip side of this, when you move out of this comfort zone things start to lean back towards Java in a big way.

    The more experienced developers on my team, working on the more difficult projects can deliver much better software with Java than .NET even though some of them are more conversant with .NET as a language.

    I think for a given subset of features .NET has a well defined toolset and set of practises that makes building solutions for this subset of features a walk in the park. Outside of this subset of features thinks start to look a bit peaky and things are not quite as clear cut. An example of this is MSMQ messaging which in my experience is no where near as comprehensive a solution when coupled with .NET as JMS.

    Overall, we have found that using Java we can produce a quality solution for all the projects that we work on, but on some of the smaller projects we could have done it a lot easier with .NET.

    As far as Websphere vs .NET goes I have never used Webspehere so I can't comment, but I know that I could build a solution using something like Resin or Tomcat/Spring and have it perform better than the equivalent solution in .NET - this is the reason we choose Java for most of our clients over .NET.

    Rob Harrop
  59. Overall, we have found that using Java we can produce a quality solution for all the projects that we work on, but on some of the smaller projects we could have done it a lot easier with .NET.

    How is .NET easier? Is the API or tooling easier?
  60. It is the combination of the API, the runtime and the tooling that makes it easier. One of the areas this is particularly obvious is ASP.NET. Without VS.NET ASP.NET is quite complex to build, but with ASP.NET it is simple.

    Each component individually is not necessarily better than the corresponding component in Java, they are just integrated in such a way to make development easy. However, as I said, this is only really evident in simple applications. More complex apps mean using tools like Nant in place of the VS.NET build and moving away from core ASP.NET to alternative solutions to gain MVC support and other useful bits. In these cases Java benefits from tools that are more prevalent, more comprehensive and generally more mature.

    Rob
  61. I have feeling that .NET is much more consistent then this.Having never done much with .NET, it is my feeling that you don't need a "top-notch" team to develop a .NET solution.
    You are exactly right in what you say here and we have experienced this many times. Most of the less-experienced developers can deliver higher quality software in .NET without me watching over the shoulder all the time than they can in Java. I think the reason for this is the whole package: VS.NET, .NET and SQL Server, just works so well together. However, on the flip side of this, when you move out of this comfort zone things start to lean back towards Java in a big way.
    I would tend to agree. I started to learn .NET recently (well, not the whole .NET thing, but ASP.NET part only). Unlike J2EE, ASP.NET has a lot of defaults and standard patterns built in. Which is great while you are staying within the operating model that is provided by ASP.NET. But if you want to move out, it is way much harder, than on J2EE.

    I asked my fellow dot-netter, how to map URLs to modules. He looked at me: "What modules? We do have assemblies, but they are just DLLs. To load an aspx page you just type its name in the browser". I clarified: "What if I want to have URL which does not look like aspx page, and I want to dispatch it to a certain module?" He stared at me and replied with a question: "Why would you want to do THAT?" Of course, URL mapping IS possible with ASP.NET, but many developers are not aware of it simply because IIS/.NET provide easy and reasonable default settings, which are accepted by most.

    The same thing with forms. ASP.NET 1.1 does not allow to submit input to a page different from the one which rendered the input form (ASP.NET 2.0 will allow to do this). For those who came from desktop development this seems natural, but it screwes up MVC model big deal. What is more, it does not take into account issues with HTTP protocol, so now we have an aspx page, which looks like desktop window, but in reality is a result of POST request. So if you go back and then forward you would get "Browser needs to send POST again" type of message. Consequently, you would get double submit problem and nasty confirmation windows. But this does not seem to be an issue for ASP.NET guys, they simply say "Do not click Back button". Huh, why would not have they redesigned HTTP first? Of course, one can do redirects in ASP.NET, but who would go an extra mile, if everything which is needed is already provided by MS. Why bother?

    View state, which is passed between forms in requests/responses as a hidden field, makes me sick. I know that a lot of Java developers use this model too, but at least J2EE does not make it look like a standard. ASP.NET implementation of view state makes developers believe that this is a proper, MS-endorsed way of keeping state, thus shutting the lid on the ASP.NET coffin.

    The good thing with ASP.NET that you do not need to learn that much as with J2EE.
  62. Most of the less-experienced developers can deliver higher quality software in .NET without me watching over the shoulder all the time than they can in Java. I think the reason for this is the whole package

    I wouldn't call it "high quality software". Even in .Net "less-experienced" developers need to be watched.
  63. These studies are just like political campaigns. They tell half the truth and leave the inconvenient details out.

    The result of this study is somewhat true and believable, but the setting and environment are rigged to show one side of the story only.

    1) Microsoft knows very well not to arrange comparisons with products that even have a remote chance of beating their product. They have tested all these things a million times in their own labs so that they can set all the parameters of these studies in their favor.

    2) It's hard to find an honest study that is fair in its setting, if that's even possible. Depending what is studied and how it is studied has big consequences. Typically J2EE and .NET have their own strengths and areas of excellence, which might turn the tables depending on the circumstances.

    3) Nobody bites the hand that feeds them. In this case, like in other studies TSS has done is far from impartial no matter how much they try to convince people. They can even have a totally honest approch and good intentions but they can't escape the final truth - nobody bites the hand that feeds them. In this case they have accepted the rules of the game set by Micrsoft and rules define the outcome of the game.

    The study could be impartial if Microsoft sets no parameters like which application server to use, or to use any application server for that matter. Define an application, let two camps implement the application any way they want, and then judge the work done: how much work, how easy is it to test and maintain, how well does it perform, and what is the cost for hardware, software, and finally the total cost of ownership over say 5 years (estimated). Let them run their system in a real life situation and estimate how much work it is to maintain it, what the costs are etc.

    Given such parameters it's anybody's guess who would win...but Microsoft would not go with something like that, nor would any other company since the victory is not guaranteed.
  64. I haven't had a chance to read this over, but here's an IBM-funded study that finds the opposite is true. What a shock!!!

    http://www.rfgonline.com/reprints/ibm/RFGJ2EEvsNET.PDF

    Rob
  65. Seems like a 'fair and balanced' report to me. ;-)
  66. please bury the body[ Go to top ]

    comparing RFG paper to the TMC paper

    To compare TMC massive study with a bunch of loose opinions show the quality of the EJB fanatic’s arguments, we safely assume that the rest of the work from this camp is of the same quality.

    When can we se some interesting comparison with Spring/Tomcat and/or the type of solutions that Vic Cekvenich endorses? The Big EJB Applications Servers has been thoroughly debunked enough, not only from all the benchmarks but also from hundreds of opinions and posts here in the TSS forum.

    Shall we call the case closed? Is it possible to agree upon the color of an orange?

    Regards
    Rolf Tollerud
  67. please bury the body[ Go to top ]

    When can we se some interesting comparison with Spring/Tomcat and/or the type of solutions that Vic Cekvenich endorses? The Big EJB Applications Servers has been thoroughly debunked enough, ...

    That would be a much more useful benchmark. Forget .Net. Let's see all-J2EE Big Elephant vs Springy Tomcat.

    Kit
  68. please bury the body[ Go to top ]

    "The Big EJB Applications Servers has been thoroughly debunked enough, not only from all the benchmarks but also from hundreds of opinions and posts here in the TSS forum."

    TSS forum is just a noise factory; I haven’t heard any quantifiable fact that EJB can't deliver the goods when it comes to distributed technology. In fact, the EJB specs are battle tested (by capable), and will continue to evolve. I wonder how many TSS EJB posters wrote a distributed transaction domain engine.

    The "only" problem with EJB, is all the Borders weekend educated software "engineers" can't put it together. Well, Rolf, I bet you only needed an afternoon. A little more than the hour you needed with VB...

    Again, this J2EE vs. .NET is just simply unbearable; all the interest regarding this useless fiasco is just an indication of how many lost souls are out there...
  69. please bury the body[ Go to top ]

    "The Big EJB Applications Servers has been thoroughly debunked enough, not only from all the benchmarks but also from hundreds of opinions and posts here in the TSS forum."TSS forum is just a noise factory; I haven’t heard any quantifiable fact that EJB can't deliver the goods when it comes to distributed technology.

    I agree. What's wrong with EJB's and app. servers ?

    I work for a company whose product - large J2EE based financial transaction processing system is used by many banks worldwide. We use EJB's (including entity beans) and there is nothing terrible. Clients use either WL or WS on Unix (or some of them - Linux) boxes.
  70. Yes, what's wrong with it?

    In the words of Emerson.

    The vendors of the American EJB Servers hopes to be rich on credit, win competence without studies, mastership without apprenticeship, outlets for products by pretending that they sells, winning power by luring people to think that you are powerful. In short, all about bluff, advertising and manufacturing of public opinions.

    I hope I made myself clear! :)

    Regards
    Rolf Tollerud
  71. Chomsky said it better[ Go to top ]

    Yes, what's wrong with it?In the words of Emerson.The vendors of the American EJB Servers hopes to be rich on credit, win competence without studies, mastership without apprenticeship, outlets for products by pretending that they sells, winning power by luring people to think that you are powerful. In short, all about bluff, advertising and manufacturing of public opinions.I hope I made myself clear! :)RegardsRolf Tollerud

    Emerson is ok, but chomsky said it much better in "Manufacturing Consent". Just because marketing droids lie, cheat and generally babble on endlessly about technology they don't know or understand, it doesn't mean there's a better way to manage and integrate complex transactional requirements. If you can provide an implementation proving it is better at handling complex transactions and integrations, I'll gladly use it. I'm sure others would gladly drop EJB if you can provide a concrete example proving it is clearly better then EJB for the most complex cases.

    until then, Dumbo will keep flying around the circus.
  72. whom do you think you are deceiving?[ Go to top ]

    What an endless nagging about transactions Peter. 99% of developers never encounter distributed transactions in their life. I have never had the need in 15 years of computing. Vic Cekvenich hasn't had the need in 20 years of computing, moreover, according to Mike Spille, they are treacherous, unreliable, and work only under the most perfect conditions.

    Other places in the world, you are expected to be polite enough to assume that your opponent has a certain minimum of intelligence and discernment. But go on. Talk about distributed transactions ad infinitum instead of solving real problems. Make a fool of yourself, that is what well-meaning impractical theoreticians usually do, isn’t it?

    It’s your choice.

    Regards
    Rolf Tollerud
    "curious, audacious and impertinent"
  73. Not in my resume.[ Go to top ]

    "99% of developers never encounter distributed transactions in their life. I have never had the need in 15 years of computing. "

    This this not something I would want to appear in my resume.
  74. "Those that has developed a product single-handedly, including written all the documentation and driven up a user base to some thousands of customers, and finally, sold to a big company for a nice tidy sum"

    That is my definition. You are free to present yours.

    Best regards
    Rolf Tollerud
  75. Not in my resume.[ Go to top ]

    "99% of developers never encounter distributed transactions in their life. I have never had the need in 15 years of computing. "This this not something I would want to appear in my resume.

    I agree. Firstly, this implies that 99% of the developers are not in the area of enterprise computing. Secondly, it sounds like the person has 15 x 1 year of same experience.
  76. Not in my resume.[ Go to top ]

    "99% of developers never encounter distributed transactions in their life. I have never had the need in 15 years of computing. "This this not something I would want to appear in my resume.
    I agree. Firstly, this implies that 99% of the developers are not in the area of enterprise computing. Secondly, it sounds like the person has 15 x 1 year of same experience.

    Experience? Are you considering the time he spents "posting" on this website as work experience?

    mmm... maybe so...
  77. Do you think bashing me is going to make Java EJB Servers more successful? hi hi.

    Don't think so.
  78. you're missing the point[ Go to top ]

    What an endless nagging about transactions Peter. 99% of developers never encounter distributed transactions in their life. I have never had the need in 15 years of computing. Vic Cekvenich hasn't had the need in 20 years of computing, moreover, according to Mike Spille, they are treacherous, unreliable, and work only under the most perfect conditions. Other places in the world, you are expected to be polite enough to assume that your opponent has a certain minimum of intelligence and discernment. But go on. Talk about distributed transactions ad infinitum instead of solving real problems. Make a fool of yourself, that is what well-meaning impractical theoreticians usually do, isn’t it?It’s your choice.RegardsRolf Tollerud"curious, audacious and impertinent"

    you nag endlessly about how bloated EJB's are, so I happily remind you not every does simple transactions. Just because you have never needed it, doesn't mean there aren't thousands of developers who actually need it. feel free to attack me as much as you want, but I've been working in the financial sector in boston and guess what? a large percent of the jobs are in this area do need it for the most complex stuff.

    I never claimed to be intelligent. You don't hear me saying "heavy clients are such bloated beasts, what a huge lie microsoft has sold to the world." It would be silly and useless because that's not true. Heavy clients have their place.

    don't take my word for it. go look at the SEC regulations financial companies have to follow and think about how that impacts real-world requirements. you probably don't know this, but many of the largest firms pay huge fines every year because they aren't able to run compliance rigorously. if I told you the amount you would be shocked.

    there is a real-world need for distributed transactions that have very complex validation logic and requirements. I said it once and i'll say it again. Stupidly using a tool without understanding what it is good for is incompetence. Blaming someone else for one's own laziness is irresponsible and simple minded.

    I'll make you a deal. you come up with a solution which solves two of the complex cases I've described in the past and I'll gladly shut up about distributed transactions :) my goal is to see how people really solve these types of cases, not throw generalized babble. Perhaps you've come across a solution which I've missed, but so far in my 4 years of active research I haven't found anything measurably better. there probably is something out there, I just don't know about it.
  79. Peter: "I've been working in the financial sector in boston and guess what? a large percent of the jobs are in this area do need it for the most complex stuff"

    First you have to solve some of the problems in Donald E. Knuth book "The Art of Computer Programming", (sometimes presented on a single page!) Until then, you have not convinced me that you know some "complex stuff".

    The financial sector is childs stuff.
  80. The financial sector is childs stuff.

    LOL! What an unbelievable statement.

    I take from that statement that you wouldn't mind if the band that houses your life savings didn't bother with ACID distributed transactions. I'm sure you wouldn't miss a few bucks here or there. "Child's stuff" eh?

    What I can't figure out Rolf is why you even post here? If you are SO annoyed by the conversations/rants here, why not go to the sister TSS .NET site so you can be around with the 3 other members on that site, sit in a big circle jerk, and sing fireside songs about the how you've one up'ed the entire IT industry.

    What's your motivation Rolf? Attention?
  81. Small correction .. s/band/bank
  82. <He is a compulsive troll.
  83. << What's your motivation Rolf? Attention? >>He is a compulsive troll.
    +11
    For a good answer for that question.
  84. I give up[ Go to top ]

    Ok, I leave you to your idiotic musings then. To hammer some sense of logic or proportions into the head of EJB gurus is hopeless, so why try? The EJB camp's "lofty attitude" and penchant for discussion far out unimportant things forever is balsam for their egos while their ship sinks.

    Why try to change the nature of evolution.
  85. wow, more gibberish[ Go to top ]

    Ok, I leave you to your idiotic musings then. To hammer some sense of logic or proportions into the head of EJB gurus is hopeless, so why try? The EJB camp's "lofty attitude" and penchant for discussion far out unimportant things forever is balsam for their egos while their ship sinks. Why try to change the nature of evolution.

    ya know. all you have to do is prove how to solve transactions that have to connection to multiple databases with multiple database models and the EJB world will shut up. Is that so hard of a task? if you do that, you can retire a rich man on your own tropical island.

    unfortunately I'm not smart enough to solve those problems, so I'll have to keep chugging away building one solution at a time with the most appropriate technology.
  86. wow, more gibberish[ Go to top ]

    ya know. all you have to do is prove how to solve transactions that have to connection to multiple databases with multiple database models and the EJB world will shut up. Is that so hard of a task?

    What if you want to leverage an asynchronous messaging architecture in your application?

    In MSMQ, how do you ensure that when a process, triggered by a message event fails, the message will remain on the queue, retry the process again to a certain retry threshold, and then automatically get pushed to a DLQ for either manual or automatic intervention to correct the problem, and then relaunch the message and its subsequent process again?

    This requires distributed transactions between the JMS queue and whatever database(s) you may alter along the way in your business process. If you have to have guaranteed message deliver, and what solidly designed system doesn't?, this is something you have to deal with.

    All this is possible today by leveraging JMS, MDBs and JCA all of which are apart of the J2EE suite and found in almost every J2EE container. They also require very little if any coding to get that core functionality.

    I have not used MSMQ, but I know that if they have implemented a guaranteed message delivery sub-system, they have to utilize distributed transactions to interact with outside resources, otherwise, there is no guarantee.

    If MSMQ does provide that, is that considered a solution to a fringe problem set? Sounds more like a basic core level service needed by many enterprise level apps.
  87. that makes sense, but ....[ Go to top ]

    What if you want to leverage an asynchronous messaging architecture in your application? In MSMQ, how do you ensure that when a process, triggered by a message event fails, the message will remain on the queue, retry the process again to a certain retry threshold, and then automatically get pushed to a DLQ for either manual or automatic intervention to correct the problem, and then relaunch the message and its subsequent process again?This requires distributed transactions between the JMS queue and whatever database(s) you may alter along the way in your business process. If you have to have guaranteed message deliver, and what solidly designed system doesn't?, this is something you have to deal with.All this is possible today by leveraging JMS, MDBs and JCA all of which are apart of the J2EE suite and found in almost every J2EE container. They also require very little if any coding to get that core functionality.I have not used MSMQ, but I know that if they have implemented a guaranteed message delivery sub-system, they have to utilize distributed transactions to interact with outside resources, otherwise, there is no guarantee. If MSMQ does provide that, is that considered a solution to a fringe problem set? Sounds more like a basic core level service needed by many enterprise level apps.

    that makes sense to me, but if I read Rolf's comments correctly, his opinion is that distributed transactions are bloated. Even though COM+ is a transaction monitor and it supports distributed transactions through DTC.

    If distributed transactions are so exotic as Rolf would have people believe, then why is microsoft building Indigo, Biztalk and recommending .NET asynch block. My own experience tells me distributed transactions are useful and a good way to scale large systems.

    Perhaps Rolf can clarify his position on why distributed transactions are useless, or why Microsoft is moving in that direction. Or am I trying to make sense from non-sense?
  88. wow, more gibberish[ Go to top ]

    What if you want to leverage an asynchronous messaging architecture in your application?

    In MSMQ, how do you ensure that when a process, triggered by a message event fails, the message will remain on the queue, retry the process again to a certain retry threshold, and then automatically get pushed to a DLQ for either manual or automatic intervention to correct the problem, and then relaunch the message and its subsequent process again?

    If you are using MSMQ with .NET, you attempt to trick the machine into what you want, perhaps by offering gifts. Although seriously, we built a sizable billing systems for a client on .NET and we experienced no end of problems with MSMQ, which seems to get into moods and just stop processing. It is bizarre. Messaging is one of the areas where experience tells me that Java is far superior to .NET.

    MS have addresses this by offering a new messaging solutions in SQL Server 2005, which on the face of it seems okay, but I have not tested it in detail so I don't know how it works.

    Rob
  89. interesting[ Go to top ]

    If you are using MSMQ with .NET, you attempt to trick the machine into what you want, perhaps by offering gifts. Although seriously, we built a sizable billing systems for a client on .NET and we experienced no end of problems with MSMQ, which seems to get into moods and just stop processing. It is bizarre. Messaging is one of the areas where experience tells me that Java is far superior to .NET.MS have addresses this by offering a new messaging solutions in SQL Server 2005, which on the face of it seems okay, but I have not tested it in detail so I don't know how it works.Rob

    recently I used MSMQ on a project for routing transactions. At one point we ran a week long stress test to make sure the application didn't have any memory leaks or zombie threads. The test ran without any problems, so I would say MSMQ is decent running on windows XP, .NET 1.1 and with non-transactional messages ranging from 1-3K. I understand you probably can't go into detail, but were you using transactional messages?
  90. interesting[ Go to top ]

    Peter,

    Yes, we were using MSMQ under COM+ transactions as part of a fairly long running process. The problem was that threads associated to the processing of MSMQ would just stop running even though they weren't interacting with shared state and no exceptions were thrown on the threads. It was absolutely bizarre since we have never seen this problem before when using COM to access MSMQ. In the end we had to replace the standard MSMQ async processing model with our own thread pool which is, fingers crossed, running fine now.

    Rob
  91. interesting[ Go to top ]

    Peter, Yes, we were using MSMQ under COM+ transactions as part of a fairly long running process. The problem was that threads associated to the processing of MSMQ would just stop running even though they weren't interacting with shared state and no exceptions were thrown on the threads. It was absolutely bizarre since we have never seen this problem before when using COM to access MSMQ. In the end we had to replace the standard MSMQ async processing model with our own thread pool which is, fingers crossed, running fine now.Rob

    that makes sense. in our implementation we created our own thread thread also. now I'm glad we didn't use the stock support and implemented our own.
  92. interesting[ Go to top ]

    This is my point, I bet you've never said you were gald you didn't stock MDB support for JMS, since it works really well. With Java most of the components outside the basics work a lot more reliably than those shipped in .NET 1.1. That said MS have identified this and many other shortcomings in .NET which are getting fixed .NET 2.0 and the associated product releases - they have the money and the inclination to fix any problems that put their platform at a perceived disadvantage to Java.

    Rob
  93. good point[ Go to top ]

    This is my point, I bet you've never said you were gald you didn't stock MDB support for JMS, since it works really well. With Java most of the components outside the basics work a lot more reliably than those shipped in .NET 1.1. That said MS have identified this and many other shortcomings in .NET which are getting fixed .NET 2.0 and the associated product releases - they have the money and the inclination to fix any problems that put their platform at a perceived disadvantage to Java.Rob

    I would agree the commercial JMS offering out there are more mature than MSMQ and you're absolutely right about MS not sitting by. They definitely are improving the situation with indigo and biztalk.

    though there are some things with JMS that can be challenging for new users. Right now I'm writing a JMS sampler for JMeter to load test the various JMS servers and boy it takes a lot of work to figure out the right settings. In fact, I spent the last week profiling one JMS provider and discovered a bug in the thread management. Took me a while to finally trace the bug in OptimizeIt, but it was a fun exercize.
  94. doh, correction[ Go to top ]

    that should be "thread pool also"
  95. wow, more gibberish[ Go to top ]

    ya know. all you have to do is prove how to solve transactions that have to connection to multiple databases with multiple database models and the EJB world will shut up. Is that so hard of a task? if you do that, you can retire a rich man on your own tropical island.

    I am not expert, but some people use distributed databases without any application servers , Is it something wrong in distributed databases ?

    (It looks like single database from user point of view, but it is "distrbuted" and it can be not ralational in theory. EJB application is a some kind of home made distributed database too, is not it ? )

    BTW you must sell new big thing to own tropical island not to prove some truth, nobody needs it :)
  96. I am not expert, but some people use distributed databases without any application servers , Is it something wrong in distributed databases ?(It looks like single database from user point of view, but it is "distrbuted" and it can be not ralational in theory. EJB application is a some kind of home made distributed database too, is not it ? )BTW you must sell new big thing to own tropical island not to prove some truth, nobody needs it :)

    That depends on what you define as distributed. many people use partition databases to distribute load, but they use the same database model. Usually some middle tier does the routing so that queries goes to the right database. Other approaches with paritioned databases is to have a smart data access that knows where to query for data. Basically the driver reads a configuration at start up and knows which database to hit.

    It was my lame attempt at humor. There really isn't much new under the sun (pun intended) for distributing work across several physical systems. EJB could be classified as a in-memory database of sorts. Many people wrote their own distributed memory system before EJB's came along. I don't believe there's any "true" way honestly. there's only what is appropriate for the job at hand.
  97. Yes, I understand this humor, but I do not think distributed transactions is a good motivation for EJB. People do it with EJB and without it (distributed database is not the same as partition, it is a farm of databases conneted to single "view" and they can be provided by different vendors too ). I do not use this stuff in practice, but I hope it must work better, it less error prone because it needs no programming, just configuration. I use home made solution in practice, but it is not because I like to distribute databases myself. EJB doe's not help in most "complex" cases for me, some home made binary protocols do not support any transaction propagation, some can not reject dublicates some are based on single user databases.
    It is fine if EJB solves your problems, but it solves no problems for me, it is too heavy for "simple" stuff like home pages and too light for "complex" cases like integration with some legacy farms.
  98. Yes, I understand this humor, but I do not think distributed transactions is a good motivation for EJB. People do it with EJB and without it (distributed database is not the same as partition, it is a farm of databases conneted to single "view" and they can be provided by different vendors too ). I do not use this stuff in practice, but I hope it must work better, it less error prone because it needs no programming, just configuration. I use home made solution in practice, but it is not because I like to distribute databases myself. EJB doe's not help in most "complex" cases for me, some home made binary protocols do not support any transaction propagation, some can not reject dublicates some are based on single user databases.It is fine if EJB solves your problems, but it solves no problems for me, it is too heavy for "simple" stuff like home pages and too light for "complex" cases like integration with some legacy farms.

    In a previous job, their database was partitioned to improve performance. It didn't use EJB's at all and when some people suggested EJB as a migration path, I suggested they forget EJB. In this specific case, the working dataset was very large, so the system cached a lot of the data in-memory. This meant when the front-end queried for data, the data access routed it to the right machine. The in-memory cache was rather large, so sending a query to the wrong machine would dramatically increase the total query time. Much of this system was written in house by a team of guys with several years of experience building large systems.

    From first hand experience with EJB, I tend to lean towards it when the requirements include: distributed transactions, semi-realtime response, propogating the changes and state management. I find that if I remove one of the four, I can do without EJB. Back when I worked on a wireless platform, we needed to propogate contact and calendar data across multiple sessions. When ever an individual made a change to a meeting, we needed to propogate those changes out to all participants. since it was a mobile platform, the business guys demanded rapid near realtime response to changes.

    had they changed the requirements to several minutes (instead of real-time), we could have easily used simple distributed transactions and message filtering to propogate the updates. Or if we removed the transactional requirement, we could have gone to a simple messaging approach. I find taking time to really understand the business case helps avoid making bad technical decisions. Recently I was asked whether it was feasible to have a system react instantly to changes in stock prices. After several weeks of asking very specific questions (more like months), I was able to distill a high level requirement to something that's practical and technically feasible :)
  99. I give up[ Go to top ]

    Ok, I leave you to your idiotic musings then. To hammer some sense of logic or proportions into the head of EJB gurus is hopeless, so why try? The EJB camp's "lofty attitude" and penchant for discussion far out unimportant things forever is balsam for their egos while their ship sinks.Why try to change the nature of evolution.

    Look Rolf, it nothing to do with lofty attitudes and you know it. You are just being directly challenged about some of assertions and instead of addressing them head on, you whine and moan about how we all have our heads jammed up the big fat elephant's ass.

    You bring it all on yourself when you make stupid comments like "The financial sector is childs stuff." So, stop making stupid comments and I think you'll find most people here are willing to contribute to a good argument or technical discussion.

    I apologize for my frankness, but I just get frustrated trying to read any thread on this site and low and behold, there you are, hi-jacking the threads and steering the conversation it into your tired old mantra of the big fat elephant servers.

    The truth of the matter is the fat elephant is really a metaphor that equally applies to many of Microsoft's past, current, and more then likely future products that you continue to trumpet.

    I am certain that when it comes to which technology will lose weight faster when it is needed, it will be the J2EE/Java world. The reason for this is simple. Agility is best achieved thru a wealth of solid, industry proven options and choices. All of which can be found in Java land.

    You can cry Mono all you want, but the fact is that if you want the true .NET experience, you must run it on a Windows server. That my friend, is certainly alot of weight to have to carry around. So enough with the elephant metaphor ok?

    I can't even look at a real elphant without thinking of Rolf! Enough! :)
  100. A post well worth a child. Grow up, Rolf!
  101. putting words in my mouth[ Go to top ]

    Peter: "I've been working in the financial sector in boston and guess what? a large percent of the jobs are in this area do need it for the most complex stuff"First you have to solve some of the problems in Donald E. Knuth book "The Art of Computer Programming", (sometimes presented on a single page!) Until then, you have not convinced me that you know some "complex stuff".The financial sector is childs stuff.

    on more than one occasion I've stated I consider myself light weight in the area of complex transactions. I've never claimed to be an expert in complex transactions. I'm simply citing real world use cases I know of first hand, or know from discussion with close friends.

    I readily admit my focus is very narrow and there are whole domains of complexity, which I absolutely no nothing about and probably will never get a chance to explore. What I do know is this. Achieving high transactional throughput for transactions that require 2A7, 1940 and FSA regulation compliance is rather difficult. I know guys with 10-20 years of experience building compliance systems and I always ask them for their input. There's areas of complexity even within regulatory compliance, which I am a total newbie.

    when I'm given the task of trying to reach 1-10K transactions per second, while performing rigorous compliance validation the only way I know to achieve this is through distributing the process. That means identifying which processes can be broken into it's own task and sent to a dedicated system. Doing that is not easy and performing aggregate calculations on the fly for large datasets with multiple concurrent transactions is rather difficult.

    My focus is narrow, but I do have a decent understanding of compliance validation for trading systems. I regularly tell co-workers I wish I had 10 more years of experience in this specific domain, but that's something I'll have to acquire over time.

    Are you saying reading "the art of programming" means you know complex programming? I better run out and buy 100 copies. that will solve all the problems thousands of programmers are trying to solve. Will it also make flying cars, cook my meals and balance the US budget?
    </joke>
  102. a typical day by day committee meeting[ Go to top ]

    The meeting starts.

    1) First the obvious solution in immediately discarded. "Of course we are to smart for that"!
     
    2) Then a very odd and far out solution is discussed for a lengthy period of time, until they discover that their time is almost upp..

    3) A second best solution is hurriedly chosen without much discussion.

    The meeting ends.

    So how come it is always so easy to convince anybody that the "very odd and far out" is important and worth discussing for ever and forever? Don't ask me. I don't know. But discussing the very odd and far out obviously makes them feel important in some way.

    Reason, logic, and common sense is always the first victim.

    Regards
    Rolf Tollerud
  103. P.S.[ Go to top ]

    The whole matter reminds me of the story of a london dandy, that refused to go out if not hit tie was perfectly knotted. Often it could take half a day, He was much admired for that...

    I compare the tie-knot to distributed transactions, so much effort - so much wasted energy - so much hopeless ambition. Meanwhile huge amount of money is lost.
  104. thanks for mentioning the book[ Go to top ]

    First you have to solve some of the problems in Donald E. Knuth book "The Art of Computer Programming", (sometimes presented on a single page!) Until then, you have not convinced me that you know some "complex stuff".The financial sector is childs stuff.

    thanks for mentioning the book. my knowledge of general computer science algorithms is deficient, since I only use/implement algorithms for the specific applications I'm working on. The algorithms I know are very specific to the applications I've worked on, but I do try to make an effort to research before writing code. I find it funny you criticize J2EE as "invented by computer scientists" and yet you refer to Knuth's book.

    I'll have to get the book and read the sort/search sections for fun.
  105. Rolf:
    The financial sector is childs stuff.

    And there you have it, folks: Hundreds of thousands of software developers, working on every continent save Antartica, feverishly sweating over reliable transactions, legal compliance, disaster recovery planning, customer-accessible systems, provable security, real-time risk management, complete auditing, etc. .. and in one sentence, Rolf is able to sum it up so neatly: child's stuff.

    Apparently, the HTML-based Human Resources system he's building in Mono to support a half dozen concurrent users will show us all how technology should be done ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  106. Cameron back from the dead?[ Go to top ]

    I think I take a rest from TSS for a while. It is impossible to make the EJB fanatics take reason anyway. Meanwhile anyone is free to compare my posts and for example Cameron’s posts in the 3 years that we have been in the forum and decide who that did the best forecasts.

    But as I said, you certainly go down in style! More arrogant now that ever even in J2EE's heydays.
  107. so I'm an EJB fanatic?[ Go to top ]

    I use both .NET and J2EE. By no means do I make silly claims like "only use .NET" or "only use J2EE". I use what my employer prefers. If that means using ADO.NET, COM+, MSMQ, C# and Sql Server then I do the best job I can. If my employer wants J2EE because that's what they'd invested in, that's what I use.

    I don't know squat about HR applications, but I imagine they can get very complex quickly. Then again, business guys like to make things complex for developers. I'm sorry if you feel like people on TSS aren't reasonable, but I find the best way around that is to speak in concrete terms with specific low level details.

    reproducible results you've obtained through first hand experience is the best weapon in a debate. You still haven't answered the question of why is microsoft pushing towards distributed systems in indigo, if distributed transactions is "childs play".
  108. As you know, I hold Sun and the Java EJB Applications server vendors responsible for the worldwide recession, at least as a catalyst. On the other hand - and here comes the good things - the Avalon/XAML/Indigo part of longhorn will ignite a equally long worldwide boom in the economics!

    So for everyone that has product plans, the time to start is now, or to be exact, the time around February 16th, when Longhorn Beta is released. That will give you 9 months to work on the product in time for your own beta release a few months before Longhorn gets final.

    So see you then, in the midst of the Longhorn boom!

    Regards
    Rolf Tollerud
    (A human resourse program for Mono? Where does he gets all from! :)
  109. Yes, why bother solving problems now using mature Java technology when you can gamble the future of your product on a Microsoft product that is not released and has no fixed release schedule.

    Rolf, your inability to grasp simple business concepts such as risk management, points to the fact that your economic predictions are no more than bluster and have no founding in reality.

    As an aside, I was unware that there was a worldwide recession, since here in the UK our economy is doing really well and we are all enjoying a period of relative calm (aside from property prices which are ridiculous).

    Rob
  110. when the high waves come in and the big elephants make the boat sink (as Rolf the forecaster says). I'm sure Cameron will be able to find a way out of there, he seems to be doing some real business with real customers using real products.

    Best regards,

    Erik
  111. As you know, I hold Sun and the Java EJB Applications server vendors responsible for the worldwide recession, at least as a catalyst.

    I've never seen Rolf Tollerud anywhere in the respected economic predictions and analysis articles as well as not on a single decent software product, so who are you to hold companies like Sun, BEA and etc. responsible? This smells like a case of schizophrenia to me. You probably think of yourself as a misunderstood genious, do you? That's one of the signs, you know...

    Regards,

    Artem D. Yegorov
  112. Im wondring why TSS.com does not Suspend Mr Rolf Tollerud 's
    Account for a while.He allways hijack Threads or try to lead it away from its original path.
    Threads quality drop low because of Mr Rolf Tollerud 's Posts.
  113. It all comes down to one thing...[ Go to top ]

    Given the best programmers, fastest implementations,
    best programming practices and design patterns...
    It comes down to the language... and there C is faster than
    java. We have to see how fast is .NET's IL and its interpreter as against java bytecodes and JVM.

    I am a J2EE consultant ...but something tellsme .NET's machine is faster than J2EE...i will be happy if somebody proves otherway...without becoming defensive.

    -Sri
  114. email me directly[ Go to top ]

    I've run several dozen benchmarks comparing real apps using jdk1.4.2 and .NET 1.0 and 1.1. I don't want to post those results publicly, so email me directly at woolfel AT yahoo DOT com.
  115. It all comes down to one thing...[ Go to top ]

    I am a J2EE consultant ...but something tellsme .NET's machine is faster than J2EE...i will be happy if somebody proves otherway...without becoming defensive.

    Low-level, it's a mix. Virtual calls are much faster in Java with Hotspot Server edition, so heavily OO designs tend to run much more optimally in Java.

    Within a particular method, the .NET virtual machine implementation tends to do a better job producing native code, and in tests I did it was significantly ahead in math-related stuff. (BTW - Sun's JVMs varied widely from release to release on math stuff.) IBM's JVM was pretty good on the math stuff, but not as good on the virtual calls, because it's a JIT like the Microsoft CLR.

    All in all, at a low level, it really depends on the mix of operations you'll be doing, but the various JVMs are all pretty good, and the Hotspot Server edition was usually the fastest option in the tests that I did, although it did use more memory than any of the other options.

    As for the higher level stuff, .NET access to Microsoft SQL Server is very good. There is no JDBC in .NET, but as long as you are fine being stuck with SQL Server, .NET is going to be faster than Java. I think some of the JDBC drivers are just not very good when it comes to optimizations (hey! Oracle! this means you!) You'll notice that the benchmarks that Microsoft publishes are all .NET with SQL Server .. this is no accident.

    For web stuff, .NET performs well, but it's apples and oranges comparing Servlets etc. to ASP.NET. Further, having to deploy on IIS is a non-starter for a lot of companies, so it doesn't really matter. (Heck, having to deploy Windows servers is a non-starter for a lot of companies.)

    For GUI, .NET Winforms seem to perform better and are more tightly integrated with Windows. If you only ever have to support Windows, then .NET for GUI is a good choice. It is no biggee to integrate .NET for GUI with a J2EE app server .. we have customers doing this for their applications and it works well. If you do have a possibility of having to support any non-Windows clients, and you need a GUI, then you'll probably have to stick to Swing. (There are other GUI choices outside of .NET and Java, but I have little experience with them.) This is probably Java's biggest weakness vis-a-vis .NET -- Windows GUIs.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  116. It all comes down to one thing...[ Go to top ]

    It is no biggee to integrate .NET for GUI with a J2EE app server .. we have customers doing this for their applications and it works well.

    How is this implemented? Using SOAP based Web service?
  117. It all comes down to one thing...[ Go to top ]

    It is no biggee to integrate .NET for GUI with a J2EE app server .. we have customers doing this for their applications and it works well.

    How is this implemented? Using SOAP based Web service?

    I have seen it done with XML over HTTP (SOAP, etc.) but you can also do various long-lived connections including custom, CORBA or RMI (yes, even from .NET), jnBridge, JMS (some JMS vendors provide .NET APIs), etc.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  118. This is all well and done if you only disregard the little slights (IIS is a non-starter for a lot of companies, Windows servers is a non-starter..). Obviously that is not true since IIS/Windows are 4-5 times as common in enterprise business as Apache/Linux if you discount the ISPs that carry thousands of IP addresses at a single computer and only counts these installations that have their own computer.

    One thing Cameron forgets to mention is that to obtain this more or less similar speed as C# Java has to use much more memory, which creates its own set of problems as can be seen in the general low uptime of EJB servers.

    As to however IBM is a "new" IBM or the same old you can judge for yourself. They "create" a product by gathering together some 300 apps and call it "Websphere". Then they go out selling and consulting with this package charging 11 dollar in consulting for every dollar the customer has bought for (according to their own calculations). That seems exactly as the old IBM IMO!

    Regards
    Rolf Tollerud
  119. This is all well and done if you only disregard the little slights (IIS is a non-starter for a lot of companies, Windows servers is a non-starter..). Obviously that is not true since IIS/Windows are 4-5 times as common in enterprise business as Apache/Linux if you discount the ISPs that carry thousands of IP addresses at a single computer and only counts these installations that have their own computer.

    Rolf, I suppose you could be right, because I have seen Windows servers and IIS being used for enterprise applications at at least three or four companies, and my sample size being only five hundred or so, there could be a large margin of error.

    I think it's safe to say that the market looks quite different to various vantage points. In the enterprise application space, we see very little Microsoft. In the ISP case as you mentioned, you will see very little Microsoft. But in the SMB market, Microsoft is very dominant, and their products are very cost effective and (for the general market) without peer. Perhaps you are well acquainted with the SMB market; I assume from the description of the software that you work on that the SMB market would be your target, although I'm not sure that they're ready to adopt Mono .. ;-)
    One thing Cameron forgets to mention is that to obtain this more or less similar speed as C# Java has to use much more memory, which creates its own set of problems as can be seen in the general low uptime of EJB servers.

    Rolf, this makes no sense. In latin, which you appear to know so well, it is called a non sequitur. If you want to talk about low uptimes, talk about low uptimes. If you want to talk about higher memory usage, talk about higher memory usage. From my own experience (which again, is just one reference point) these two items have little or nothing to do with each other.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  120. the last stand[ Go to top ]

    Cameron: "But in the SMB market, Microsoft is very dominant, and their products are very cost effective and (for the general market) without peer"

    Cameron: "In the ISP case as you mentioned (the ones that carry thousands of IP addresses at a single computer), you will see very little Microsoft."

    OK, now we agree on at two cases.
    Now we have only left the big companies. There we have,

    1) The department server, more common that water-coolers and coffee machines, often used by several departments. (as file server doing the job of 3 Linux)

    Top 1000 corporate Web sites:
    According to the survey, 53.5 percent of the sites surveyed ran Microsoft IIS. This was more than double the 19.3 percent running Apache. http://thewhir.com/marketwatch/mic030304.cfm

    2) The enterprise applications.

    It is probable that Java still has the lead here, as per tradition these applications needed more "hardware power" than a typical PC could deliver.

    But with clusters of Intel processors even this ares is under siege from Microsoft. So if you want, you could call it "the EJB server’s last stand"

    Regards
    Rolf Tollerud
  121. the last stand[ Go to top ]

    It is probable that Java still has the lead here, as per tradition these applications needed more "hardware power" than a typical PC could deliver. But with clusters of Intel processors even this ares is under siege from Microsoft. So if you want, you could call it "the EJB server’s last stand"RegardsRolf Tollerud

    Ah, but Microsoft isn't the only player in the clustered Intel/AMD space and they have their work cut of for them to overcome their past reputations in the enterprise space. Not impossible, but not a shoe-in either.

    Linux will certainly have it's own marketshare here as well and is certainly on the minds of CTOs these days.

    Sun is also aggressively pursuing the x86 market as well and are certainly the encumbant, along with IBM, in the enterprise hardware space. The company I work for is currently testing Solaris 10 and Linux on AMD Opteron blades built by Sun.

    Under siege? .. I dunno if reality matches that rhetoric.
  122. the last stand[ Go to top ]

    "Linux will certainly have it's own marketshare here as well and is certainly on the minds of CTOs these days."

    Well, I could have said, "under siege from Microsoft and low-fat Linux solutions type Spring/Tomcat".

    Sun and IBM on the other hand, are on the way down, as is the Java EJB Application Server. (Thank god)

    Or I could have said, "the Java EJB Application Server is first victim in the coming gigantic struggle of epic dimensions between Linux and Microsoft.

    Regards
    Rolf Tollerud
  123. Web Server MArket Share[ Go to top ]

    Cameron: "But in the SMB market, Microsoft is very dominant, and their products are very cost effective and (for the general market) without peer"Cameron: "In the ISP case as you mentioned (the ones that carry thousands of IP addresses at a single computer), you will see very little Microsoft."OK, now we agree on at two cases.Now we have only left the big companies. There we have,1) The department server, more common that water-coolers and coffee machines, often used by several departments. (as file server doing the job of 3 Linux)Top 1000 corporate Web sites:According to the survey, 53.5 percent of the sites surveyed ran Microsoft IIS. This was more than double the 19.3 percent running Apache. http://thewhir.com/marketwatch/mic030304.cfm2) The enterprise applications.It is probable that Java still has the lead here, as per tradition these applications needed more "hardware power" than a typical PC could deliver.But with clusters of Intel processors even this ares is under siege from Microsoft. So if you want, you could call it "the EJB server’s last stand"RegardsRolf Tollerud

    Rolf,
    The Web Server survey you mention was done by Port 80 Software, a company who sells IIS add-ons. In fact, I believe that is all they do (though I could be wrong).

    The numbers from November 2004 Netcraft survey of over 55 million sites, show nearly %70 to be running Apache, and the relative Apache/IIS markshares to be relatively static.
    Details can be reviewed at http://news.netcraft.com/
  124. Web Server Market Share[ Go to top ]

    Cameron: "In the ISP case as you mentioned (the ones that carry thousands of IP addresses at a single computer), you will see very little Microsoft."

    We are not interested in the folks that share a computer with hundreds or thousands of others are we?

    Regards
    Rolf Tollerud
  125. Web Server Market Share[ Go to top ]

    Cameron: "In the ISP case as you mentioned (the ones that carry thousands of IP addresses at a single computer), you will see very little Microsoft."
    We are not interested in the folks that share a computer with hundreds or thousands of others are we?
    RegardsRolf Tollerud

    Rolf,
    Cameron's quote was "In the ISP case as you mentioned, you will see very little Microsoft". You added the "(the ones that carry thousands of IP addresses at a single computer)".
    And yes, since the comments were about Web Server market share, it is important to point out a comprehensive survey from a source that is not affiliated with Microsoft. I thought you would be interested in an additional data point that shows the overall market share. This survey includes ISPs but is certainly not limited to them.
  126. Web Server Market Share[ Go to top ]

    Tom: "I thought you would be interested in an additional data point that shows the overall market share."

    Of course I am not interested in Netcrafts numbers, that is quoted everywhere. People that share a computer are not serious business users and should not be in the tally.

    The Netcrafts numbers is a good example of Mark Twains "There are three kinds of commonly recognised untruths: lies, damn lies and statistics".

    Regards
    Rolf Tollerud
  127. Web Server Market Share[ Go to top ]

    People that share a computer are not serious business users and should not be in the tally.

    We use a hosting service for tangosol.com and it easily saves us thousands of dollars a year compared to administering an IIS server .. of course you could claim that we're not serious business users ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  128. Ha ha, you never give up, do you?

    I know, and what else, I know that you know, and I know that you know that I know, what is a serious business application and what is some simple pages to advertice for your company.

    (BTW I would recommend you get some professional advertising company to look over your pages)

    Regards
    Rolf Tollerud
    (horrible)
  129. Web Server Market Share[ Go to top ]

    The Netcrafts numbers is a good example of Mark Twains "There are three kinds of commonly recognised untruths: lies, damn lies and statistics".RegardsRolf Tollerud

    That's why you have to study "Theory of Statistical Inference" as part of any sciences bachelor degree.

    Haven't you studied it at uni?

    It is very useful...
  130. overused quotes[ Go to top ]

    Rolf: The Netcrafts numbers is a good example of Mark Twains "There are three kinds of commonly recognised untruths: lies, damn lies and statistics

    I was waiting for you to use that quote.
    IT is ironic, because I thought of that exact quote when I read your original note.
    By the way, that phrase was originally said by Disraeli. It was, of course, used by Twain (and about a million people on TSS).
  131. overused quotes[ Go to top ]

    The quote is overused but it is seldom you can find a so good example of it! :)

    I give you another one then, not so much used!
    Be my guest.

    "The supreme end of education is expert discernment in all things - the power to tell the good from the bad, the genuine from the counterfeit." Samuel Johnson

    Regards
    Rolf Tollerud
  132. overused quotes[ Go to top ]

    Rolf:
    "The supreme end of education is expert discernment in all things - the power to tell the good from the bad, the genuine from the counterfeit." Samuel Johnson

    So now you are one of those useless academics that you go on railing about? ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  133. overused quotes[ Go to top ]

    Hey Troll!!!

    Can't you answer the following : ?
    Peter: "I've been working in the financial sector in boston and guess what? a large percent of the jobs are in this area do need it for the most complex stuff"First you have to solve some of the problems in Donald E. Knuth book "The Art of Computer Programming", (sometimes presented on a single page!) Until then, you have not convinced me that you know some "complex stuff".
    mmm... Just curious: How many have you solved so far?
    The financial sector is childs stuff.
    mmm... again, Just curious: Have you ever worked in the financial sector?
  134. I have read with interest the IBM response document to the Middleware study, and would like to comment on some information mis-represented there and repeated on this thread.

    1. IBM claims the pricing information is incorrect becuase Middleware should have used Websphere Express, and not the Network Deployment Edition.

    It should be noted that Websphere Express would not be appropriate for hosting the ITS application as specified in the study. Websphere Express does not include support for JMS (message driven EJBs were used to support the messaging aspects of the application, across all servers in the SUT). It also does not support clustering or failover, also requirements of the application specification. For details, you can check out the IBM spec sheet that compares editions of Websphere at

    http://www-306.ibm.com/software/webservers/appserv/express/WASexpress51-spec.pdf

    2. The study was rigged becuase it was run on 4-way servers and not 2-way servers, causing WAS pricing to be higher since WAS is licensed on a per-processor basis.

    This is an interesting statement. Its clear from the auditors document, contrary to what some people have posted here, that the servers were run to full saturation (full CPU utilization) in the performance tests (for both .NET and WAS). So its not the case that WAS could have been run on 2-proc servers and achieved the same perf results. Its interesting that IBM is saying to reduce costs of WAS customer shouldn't run on servers with more than 2 procs. This of course simply cuts the number of concurrent users/workloads that can be supported by the config. 4-way servers are supported by Windows Server 2003 Std Edition, and neither Windows Server or .NET (included with Windows Server) are licensed on a per-proc basis. To run on 8-CPU servers and support greater loads, customers would buy Windows Server 2003 Enterprise Edition, which costs about ~$2000 more than Std Edition. On a 4-server 8-proc per box cluster Windows Server Enterpise Edition would add about $8000 to cost of MS config vs. running Std Edition on 4-proc boxes; but would add 4 x 4 x 15,000 = $240,0000 to cost of IBM/Websphere config. Interestingly, the Middleware report quotes the price of Win Enterprise Edition in the document, although Windows Server STD Edition works fine on 4-proc boxes and has all the features (clustering, failover, full .NET support, etc) to support the ITS app used in the study.

    The bottom line is that the pricing differential is huge, roughly a factor of 10x more expensive (~$20,000 vs. ~$250,000) for WebSphere than .NET to build/host the ITS app (a pretty proto-typical enterprise app imho).

    3. MS pricing should have included the external connector license and CALs in its pricing.

    In fact CALs are not required in this case, no authentication happens against Active Directory (or in IBMs case against an LDAP server), instead typical forms-based auth is used against a registered database of users, typical of many hosted/web apps. Windows External Connector license should have been included for each server; this is another $3000 per Windows server in the SUT, or another $12,000. However, if you also appropriately price Windows Std vs. Enterprise Edition, the MS .NET pricing as published by Middleware is essentially unchanged, at $21,000.00. The pricing for IBM per points above remains completely valid despite IBM attempts to paint it otherwise, at ~$250,000.00 for Network Deployment Edition. A huge difference for customers.

    4. MS did not include same support in pricing.
    This is false, in fact MS support for one year (24 x 7) across the board is included in everything priced, equalized to WebSphere pricing which also includes support for one year. This is clearly documented in the report and notes on pricing.


    5. A separate and dedicated message queue server was not needed, this was included just to make the IBM pricing even worse--everyone knows JMS/MQ support is built into WAS.

    The use of a separate and dedicated message queue server is quite typical of an enterprise deployment, where they want to centralize messages in a durable store. It also makes the app more interesting from a perf perspective, since all reads/writes to the queue are remote. And of course, MS also has built in MSMQ support, so technically each platform could have run the app with a local queue, and this box could have been eliminated. However, this would not match the spec of the physical deployment required for the ITS app as specified (again, having a separate dedicated message server is NOT atypical at all). And even if you remove this box from the pricing, it only elimates about $15-20K from the IBM pricing; somehow IBM claims it eliminates $200K from the IBM pricing--this is simply wrong. Not sure how they made that mistake. So even this does not change the pricing significantly.

    Anyway, these are some of many factual errors in IBM's response, just to clear the record. There are many more. We would be EAGER to repeat this study or do a similar one with MS and IBM each paying 1/2 the cost to a reputable analyst of mutual choosing. That should take care of the 'bias' question. IBM could choose an IBM solution provider to complete the Websphere portion of the test; MS would choose a .NET solution provider/consultancy to complete the .NET portion. That should take care of the 'experience question.' In the end, the study was very carefully done, despite attempts to paint it otherwise. The J2EE developers had more combined experience in J2EE than the .NET developers had in .NET (although its true the .NET developers had been using Visual Studio prior to introduction of .NET, but frankly, C# and .NET completely changed the nature of MS development in VS anyway), just was WAS changed the nature of IBM-platform development in COBOL, RPG, Smalltalk, C++ etc all used prior to J2EE.

    The report speaks for itself, as some have noted on this thread, compare the detail, time and care evident in this study to IBM's study done awhile back comparing .NET and Websphere. There is a huge difference. Plus, we are perfectly willing to repeat this or do similar with each of us ponying up 1/2 the cost of the analyst that monitors/conducts. In the meantime, customers might look at the report, ask some hard questions, call IBM on the pricing question, and conduct their own internal comparison based on an application they themselves spec and dev teams they themselves assemble.

    -Greg Leake
    Microsoft Corporation
  135. (although its true the .NET developers had been using Visual Studio prior to introduction of .NET, but frankly, C# and .NET completely changed the nature of MS development in VS anyway), just was WAS changed the nature of IBM-platform development in COBOL, RPG, Smalltalk, C++ etc all used prior to J2EE.

    The is just another misinformation from Microsoft!

    The report does state that the .NET developers had solid previsouse experience with .NET platform and VS.NET (C# implied).

    The study also demonstrated that the J2EE team had no experinece with WSAD (in the report) and WebSphere (e.g. using Sun's JVM and other evidences found by the community).

    Even the application development skill in general and J2EE skill in particular of the J2EE development are challengable based on the following facts:

    1. Did not use a source control such as CVS for serious software development.

    2. Decided not to using Struts due to 'performance overhead' (a claim cannot be found in any other source), though there is built-in wizard support for Struts in WSAD (also in JBuilder, JDeveloper etc.). Struts alone without IDE support was already a productivity boost for the Java/J2EE community.
  136. They haven't learned anything, they haven't seen anything, they haven't heard anything. They don’t have a clue and are going to continue to throw away money for the customers just as before.

    "I will not go to the conference because TSS always invites these anti-EJB speakers like Rod Johnson and Bruce Tate" :(

    The Java Elephant Applications Server advocates most be the most thick-headed people of all time!
  137. Yes, thick headed.

    Even the application development skill and J2EE skill of the J2EE team in the study are questionable based on the following facts:

    1. Did not use a source control such as CVS for serious software development.

    2. Decided not to use Struts due to 'performance overhead' (a claim cannot be found in any other source), instead, re-invented the wheel by building their own little Web presentation framework.

    BTW, there is built-in wizard support for Struts in WSAD (also in JBuilder and JDeveloper). And Struts alone without IDE support was already a productivity boost for Java based Web application development.
  138. You would be....wrong[ Go to top ]

    Sorry,

    They did have experience not only with J2EE but also with Websphere. Take a look at the replies posted by David Herst, Stephen Wilkes and Will Edwards on this thread...its very evident they are smart, focussed, experienced developers. And their experience with J2EE is well documented. But sometimes its easier to blame the messenger for the message, I guess.

    -Greg
  139. You would be....wrong[ Go to top ]

    Sorry,They did have experience not only with J2EE but also with Websphere. Take a look at the replies posted by David Herst, Stephen Wilkes and Will Edwards on this thread...its very evident they are smart, focussed, experienced developers. And their experience with J2EE is well documented. But sometimes its easier to blame the messenger for the message, I guess.-Greg

    It is very evident they are not very smart, focussed nor experienced. And if they are... why did they pick the wrong,bloated, most inefficient way of doing things?

    Perhaps... it was an order?
  140. You would be....wrong, how?[ Go to top ]

    Source control is used in the RRD version, but not the WSAD version.

    Who will use RRD for serious development on the first place?
  141. Reply[ Go to top ]

    I think they covered the bases with Websphere by both using a model-driven approach, as advocated by IBM (RRD); and a code-centric approach (WSAD). Had the study just been based on WSAD, many folks would have said "but they should have used RRD model-driven approach for productivity!"; had they just used RRD, the same folks would have said "but they should have used WSAD to get the fastest most reliable implementation--everyone knows RRD creates apps that are bloated and slow!"

    There are real tradeoffs between model-driven tools and code-centric tools--IBM even seems to back away from RRD in their response by saying they would never advocate it for 'mainstream WebSphere development'. Of course you never heard them say this publicly before this study was done.

    No study is perfect; however this study was done with care...no orders were issued to use one approach vs. another with Websphere or one tool vs. another; they simply went with the tools that IBM markets for Websphere, and in developing the WSAD implementation went with their experience in building fast, efficient, non-bloated J2EE apps---in part by not going the EJB route except for the message-driven beans. And if you read the report, you would see the WSAD implementation performed very well---winning 2/4 performance tests.

    Perhaps one of the most important things customers should look at it is the price comparison; as this shows a remarkable difference between .NET and Websphere. In terms of comparing .NET license costs to WebSphere (and BEA might I add), the two most widely used J2EE app servers in the enterprise, its tough trying to hide from the fact these products are up to 10x more expensive than .NET in typical deployments (cluster of 4 4-way servers cannot be labelled 'atypical' as IBM tries to do!).

    Everyone has their preferences; that's fine. But the study was not rigged, and I am sure many customers are objective enough to download the code, examine the results, and do their own technical comparisons. In the end, the competition benefits both sides; I think most would agree on that. In the meantime, I am sure the debate will continue...

    -Greg
  142. Reply[ Go to top ]

    ...But the study was not rigged, and I am sure many customers are objective enough to download the code, examine the results, and do their own technical comparisons. In the end, the competition benefits both sides; I think most would agree on that. In the meantime, I am sure the debate will continue...-Greg

    Code? so?? The code does not tell anything except the level of skill and experience of its author.

    Results? Well, again... skill and experience of the ppl involved in delivering a solution.

    What TMC did was to compare 1 team from a MS partner against 1 from its own people. Nothing else. And from that we can not derivate the results of the TMC "study" as tipical for WebSphere and by extension J2EE as MS/TMC marketing machines want to do.

    The study is rigged and flawed. Full stop. You can argue whatever you want, but from a technical standpoint, the study is flawed.

    Hard to admit buddy but people is not blind.
  143. no comparable skill and experience?[ Go to top ]

    If one should judge by the discussion in this thread one has to come to the conclusion that there are no intelligent "Big Jave EJB Server" people at all. So where should these come from?
  144. competition?[ Go to top ]

    Everyone has their preferences; that's fine. But the study was not rigged, and I am sure many customers are objective enough to download the code, examine the results, and do their own technical comparisons. In the end, the competition benefits both sides; I think most would agree on that. In the meantime, I am sure the debate will continue...

    Greg, I actually was with you until you mentioned "competition." You've got to be kidding me to call it competition .. for a number of reasons:

    1) Not only was this a Microsoft-sponsored test, but (not to beat a dead horse or anything) it was performed in secret, at Microsoft, and that particular bit of information was purposefully hidden. I'm not a conspiracy theorist, but you have to admit that such a thing doesn't quite qualify as a competition, does it?

    2) Competition in the business sense is good, yes. But usually when companies compete, it is because they want to be profitable with their wares. Microsoft rarely has that desire; usually Microsoft "competes" (in quotes, on purpose) just to destroy competition. Please tell me, for example, how much net profit Microsoft has made from browser sales? How about from X-Box sales? How about from MSN? All of those are huge money-losing ventures, although MSN finally "showed" (again, in quotes) a minor profit after billions and billions were poured into it. If I were a stock-holder, I'd be pretty upset at how fixated the company is about "investing" billions in loss-making ventures just to weaken or kill off other companies. Greg, you should personally be ashamed to use the word competition.

    I'm not taking anything away from the technical work in .NET, which I highly respect, and many of the technical people behind it, whom I also respect. However, when you use the word "competition," you are disrespectful to hard-working people everywhere that actually do compete.

    As for the point about cost, you are right that the IBM list prices are way higher than the Microsoft list prices. That's "enterprise software" for you. The real cost isn't what's shown in those list prices, because the software is often steeply discounted or even free .. but that's to the big customers that are paying maintenance on mainframes, and/or buying large amounts of kit, and/or making extensive use of IBM Global Services. It's really hard to compare IBM's pricing model with Microsoft's .. it's like comparing a full-service 4-star hotel with a WalMart: Both have their place in this world, but there's no valet parking at WalMart and the hotel bill will remind you of that for a long time to come ;-).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  145. Hmmm[ Go to top ]

    Cameron,

    Your response is not even worthy a reply.

    Cheers,

    Greg
  146. Hmmm[ Go to top ]

    Cameron,Your response is not even worthy a reply.

    Greg, your ability to perceive the obvious truth of the situation or hide it from yourself is your own personal battle.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  147. Reply to Microsoft's reply[ Go to top ]

    First you havn't responded to the following in my original post:

    Source control was used in the RRD version, but not the WSAD version.
    IBM even seems to back away from RRD in their response by saying they would never advocate it for 'mainstream WebSphere development'. Of course you never heard them say this publicly before this study was done.

    I work for a major Australian goverment agency here in Canberra. We have used WSAD 4 & 5 for the past two years. We are also a major Rational customer (RUP, ClearCase, ClearQuest and RequisitePro etc, etc.). Neither IBM nor Rational has ever recommended RRD to us, as far as I know.

    I seldom post messages on this site, only depised by Mirosoft marketing machine this time.

    Personally, I am looking to work with .NET in my next project, probably in a non-government setting, while retaining long term career on the Java side.
  148. Reply to Microsoft's reply[ Go to top ]

    Personally, I am looking to work with .NET in my next project, probably in a non-government setting, while retaining long term career on the Java side.

    I am currently doing more .Net than Java. The plethora of Java APIs (from the source and 3rd party) and the power and flexiblity of current day Java IDEs makes me long for them everytime I am not using them. It is those "little" things that get me. The initial creation of the .Net app might be easier (with the right Java toolset it isn't). But maintenance isn't. Neither is making it robust an flexible. This is more of a VS.Net issue than a .Net one. There are definitely things I do like about it. But to quote a (goofy) song - "It is those little things that piss me off".
  149. ...weak and sick are his targets, so nothing wrong here.
    And when, instead of hunting, he starts crying
    on the moon, well, it is also part of been a wolf ...

    Alex V.
  150. while we're at it[ Go to top ]

    Let's also blame alien abductions on Sun, IBM and J2EE. In fact, let's blame WWI, WWII, Vietnam, and the Crusades on application servers also.

    Joking aside. Indigo, longhorn and xaml are copying most of it from J2EE, open source and other operating systems. I take it as a form of flattery that Microsoft is trying to copy JMS with indigo. XAML is improved version of XUL in my mind. Much more powerful than XUL, but it's obviously a copy of the good ideas. Look at the new .NET triggers in the next release of SqlServer. That's copied from Oracle and IBM also.

    to me, it's more of the same. that's good because it makes it easier for me to build solutions using either technology. Instead, right now I have to find work arounds when I really something like Java Triggers. Or when i need a robust messaging server with built in failover and robust XA manager, I can't really rely on MSMQ. Biztalk maybe, but I haven't used it, so I can't say.

    on the otherhand, I can use ActiveMQ, JBoss, tomcat, spring, openjms, joram and a dozen other mature technologies with full access to the source code.
  151. while we're at it[ Go to top ]

    Or when i need a robust messaging server with built in failover and robust XA manager, I can't really rely on MSMQ
    Peter

    If it isn't too much to ask would you mind contacting me offline (username: rdilipk; domain: gmail)? In more than one post in different places you've mentioned some problems with MSMQ. I have the ear of some well-placed folks inside MSFT. Maybe I can cross-check whether you concerns are addressed in the System.Messsaging/System.Transactions namespaces in Whidbey release?

    thanks!
  152. Cameron back from the dead?[ Go to top ]

    I think I take a rest from TSS for a while. It is impossible to make the EJB fanatics take reason anyway.

    Apparently, not throwing the baby out with the bath water makes one a EJB fanatic.

    From what I can tell, there are few EJB "fanatics" here.
  153. Apparently, the HTML-based Human Resources system he's building in Mono to support a half dozen concurrent users will show us all how technology should be done

    So that's the application he sold for a 'tidy sum' to a 'large' corporation. I wonder if it was to Enron?

    -Pete
  154. Peter: "I've been working in the financial sector in boston and guess what? a large percent of the jobs are in this area do need it for the most complex stuff"First you have to solve some of the problems in Donald E. Knuth book "The Art of Computer Programming", (sometimes presented on a single page!) Until then, you have not convinced me that you know some "complex stuff".

    mmm... Just curious: How many have you solved so far?
    The financial sector is childs stuff.

    mmm... again, Just curious: Have you ever worked in the financial sector?
  155. please bury the body[ Go to top ]

    "The "only" problem with EJB, is all the Borders weekend educated software "engineers" can't put it together.

    +1

    -Pete
  156. RFG Study[ Go to top ]

    I haven't had a chance to read this over, but here's an IBM-funded study that finds the opposite is true. What a shock!!!http://www.rfgonline.com/reprints/ibm/RFGJ2EEvsNET.PDFRob

    wow, talk about a study that is totally lacking in value. comparing RFG paper to the TMC paper, I'd say the TMC paper is much better. If I wasn't holding my tongue, a can of profanity would be spilling out right about now.

    It's so bad that I'm not even going to bother pointing out the distortions and logical flaws. Before reading that paper I thought these types of studies are useless, but after reading it, I'm thinking companies that write this drivel should be fined and their business license revoked.
  157. RFG Study[ Go to top ]

    Before reading that [IBM] paper I thought these types of studies are useless, but after reading it, I'm thinking companies that write this drivel should be fined and their business license revoked.

    According to Microsoft's article, "Why lying in your marketing isn't worth it", false advertising already has federal penalties.
  158. Why "WebSphere/J2EE"?[ Go to top ]

    My initial response on reading about this study was: Why was it titled "Comparing Microsoft .NET and IBM WebSphere/J2EE", rather than "Comparing Microsoft .NET and IBM WebSphere"?

    Aside from the objections raised by IBM and others, the study was flawed as a comparison of .NET with J2EE in that the best and most cost-effective J2EE tools and servers weren't used.

    It appears to me to be an attempt to tarnish J2EE as a whole as well as WebSphere in particular.
  159. On this site the darling technologies/products change all the time. It has been Jboss, Tomcat, WLS, EJB. Now EJB is out of favor here. WLS overnight stopped to be the favorite server by most people who post here. The new Messiah is light-weight frameworks powered by AOP. How the sentiments on this site reflect the real world is your guess. I still have to meet someone in person who heard about Spring.
  160. Retraction[ Go to top ]

    Earlier in this thread I accused TMC of being nothing more than a shill or complete incompetents. I am retracting that statement for the following reasons:

    1. It was horribly unprofessional of me to make those accusations without proof. I would be appalled if someone was to treat me in a similar manner.
    2. I have only skimmed the TMC report and have not read it thoroughly, and so I don't have sufficient knowledge of their research methods to judge them as good or bad.
    3. Although Microsoft funded the research, I have no idea under what conditions the TMC executed the research.
    4. I forgot that behind that report are people who are more than likely putting forth their best efforts and are real professionals.
    5. When I speak I represent not just myself, I represent the Burton Group. What I said, was not representative of the Burton Group at all.

    Eating-crow is never easy. It sucks to be wrong especially in such a public forum, but that is what I was when I made my previous post. Wrong. In my mind being wrong is not a bad thing, its refusing to admit you were wrong when you know you are that is bad. I made a mistake and I apologize to TMC, its employees, and this community.

    Richard Monson-Haefel