|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 159
Messages: 159
Messages: 159
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
IBM and Microsoft respond to Websphere vs. .NET Study
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).
|
|
|
Message #144112
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I am sorry
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.
|
|
|
Message #144113
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the real issue is the people not the tool
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.
|
|
|
Message #144121
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Question about a statement in the IBM response
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
|
|
|
Message #144126
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends
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.
|
|
|
Message #144128
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No need to be sorry
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.
|
|
|
Message #144129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Connection pooling question
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.
|
|
|
Message #144130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TMC: Bought and Paid for
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.
|
|
|
Message #144131
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and Microsoft respond to Websphere vs. .NET Study
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...
|
|
|
Message #144135
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not surprised....WebSphere blows.
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. ;-)
|
|
|
Message #144138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A bit of a laugh
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!
|
|
|
Message #144139
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the personification of the Well-meaning Impractical Theoretician
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
|
|
|
Message #144143
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM's criticism is valid...
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.
|
|
|
Message #144144
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the personification of the Well-meaning Impractical Theoretician
You certainly have guts to dare to show yourself in the IT business at all
People in glass houses...
-Nick
|
|
|
Message #144147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Another massive study
I guess IBM can pay TMC for another "massive" study that would certainly prove WAS is better than .NET.
|
|
|
Message #144148
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not surprised....WebSphere blows.
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
|
|
|
Message #144150
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM's criticism is valid...
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
|
|
|
Message #144152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not surprised....WebSphere blows.
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.
|
|
|
Message #144156
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a bit unfair on eclipse
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.
|
|
|
Message #144158
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM is a Consulting Company
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.
|
|
|
Message #144161
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and Microsoft respond to Websphere vs. .NET Study
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.
|
|
|
Message #144164
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To EJB or not to EJB that was a question
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.
|
|
|
Message #144165
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends
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
|
|
|
Message #144167
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
out of curiousity
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.
|
|
|
Message #144168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and Microsoft respond to Websphere vs. .NET Study
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
|
|
|
Message #144173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not surprised....WebSphere blows.
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.
|
|
|
Message #144177
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the personification of the Well-meaning Impractical Theoretician
Trollfy you little schmuck !
|
|
|
Message #144179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What's the fuzz about?
Every good programmer knows that the only benchmark that holds water is his own.
So what's the fuzz about?
|
|
|
Message #144189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the real issue is the people not the tool
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
|
|
|
Message #144199
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
was j2ee performance tested or just estimated
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.
|
|
|
Message #144201
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM's criticism is valid...
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)?
|
|
|
Message #144202
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What Happened to the Open Process?
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
|
|
|
Message #144212
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why could EJB be faster?
"...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?
|
|
|
Message #144214
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not surprised....WebSphere blows.
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
|
|
|
Message #144215
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To EJB or not to EJB that was a question
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.
|
|
|
Message #144216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fud on J2EE vs .Not study just like Linux vs Windows
M$ funds these study even runs the test on their lab and TSS publishes them . Monkey dances in the back ground.
|
|
|
Message #144219
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why couldn't EJB be faster?
"...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.
|
|
|
Message #144228
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Question about a statement in the IBM response
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.
|
|
|
Message #144241
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TMC: Bought and Paid for
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.
|
|
|
Message #144243
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends on the quality of the developers
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
|
|
|
Message #144245
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
first hand experience
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.
|
|
|
Message #144246
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM is a Consulting Company
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
|
|
|
Message #144250
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TMC: Bought and Paid for
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
|
|
|
Message #144251
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and Microsoft respond to Websphere vs. .NET Study
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.
|
|
|
Message #144252
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM is a Consulting Company
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.
|
|
|
Message #144265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM is a Consulting Company
.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
|
|
|
Message #144272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and Microsoft respond to Websphere vs. .NET Study
Seems like a 'fair and balanced' report to me. ;-)
|
|
|
Message #144276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM is a Consulting Company
Must be one of those YMMV type of things. I've had nothing but good experiences with Websphere.
|
|
|
Message #144280
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RFG Study
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.
|
|
|
Message #144290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why "WebSphere/J2EE"?
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.
|
|
|
Message #144291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends
That is not true. We use the Opta driver and it has internal pooling. Calling Driver.getConnection will return a pooled connection.
|
|
|
Message #144297
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please bury the body
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
|
|
|
Message #144299
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please bury the body
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
|
|
|
Message #144313
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please bury the body
"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...
|
|
|
Message #144317
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please bury the body
"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.
|
|
|
Message #144324
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
please bury the body
"The "only" problem with EJB, is all the Borders weekend educated software "engineers" can't put it together.
+1
-Pete
|
|
|
Message #144325
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The rebuttal is true
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.
|
|
|
Message #144326
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and Microsoft respond to Websphere vs. .NET Study
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.
|
|
|
Message #144330
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends on the quality of the developers
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
|
|
|
Message #144331
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What's wrong with EJB's and app. servers?
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
|
|
|
Message #144336
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm not surprised....WebSphere blows.
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
|
|
|
Message #144340
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks
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.
|
|
|
Message #144342
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Chomsky said it better
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.
|
|
|
Message #144348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
whom do you think you are deceiving?
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"
|
|
|
Message #144349
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not in my resume.
"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.
|
|
|
Message #144353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
whom is to respected in the IT community?
"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
|
|
|
Message #144354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks
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
|
|
|
Message #144359
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
you're missing the point
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.
|
|
|
Message #144367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how well does Petes know programming algorithms?
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.
|
|
|
Message #144370
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RFG Study
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.
|
|
|
Message #144372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends on the quality of the developers
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?
|
|
|
Message #144378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends on the quality of the developers
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
|
|
|
Message #144381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how well does Petes know programming algorithms?
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?
|
|
|
Message #144383
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how well does Petes know programming algorithms?
<< What's your motivation Rolf? Attention? >>
He is a compulsive troll.
|
|
|
Message #144386
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
putting words in my mouth
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>
|
|
|
Message #144391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a typical day by day committee meeting
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
|
|
|
Message #144392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends on the quality of the developers
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.
|
|
|
Message #144394
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
P.S.
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.
|
|
|
Message #144399
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how well does Petes know programming algorithms?
<< What's your motivation Rolf? Attention? >>He is a compulsive troll. +11
For a good answer for that question.
|
|
|
Message #144403
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I give up
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.
|
|
|
Message #144408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wow, more gibberish
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.
|
|
|
Message #144414
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I give up
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! :)
|
|
|
Message #144416
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wow, more gibberish
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.
|
|
|
Message #144419
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
that makes sense, but ....
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?
|
|
|
Message #144425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Retraction
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
|
|
|
Message #144427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
thanks for mentioning the book
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.
|
|
|
Message #144435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wow, more gibberish
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
|
|
|
Message #144439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
interesting
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?
|
|
|
Message #144440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
interesting
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
|
|
|
Message #144441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
interesting
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.
|
|
|
Message #144442
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
interesting
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
|
|
|
Message #144447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
good point
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.
|
|
|
Message #144452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how well does Petes know programming algorithms?
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
|
|
|
Message #144455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cameron back from the dead?
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.
|
|
|
Message #144459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
so I'm an EJB fanatic?
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".
|
|
|
Message #144460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
how well does Petes know programming algorithms?
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
|
|
|
Message #144462
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I will not leave you without one last prediction
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! :)
|
|
|
Message #144464
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I will not leave you without one last prediction
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
|
|
|
Message #144467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I would rather sit in the same boat as Cameron
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
|
|
|
Message #144471
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I will not leave you without one last prediction
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
|
|
|
Message #144472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
while we're at it
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.
|
|
|
Message #144473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
while we're at it
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!
|
|
|
Message #144476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I will not leave you without one last prediction
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.
|
|
|
Message #144479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It all comes down to one thing...
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
|
|
|
Message #144482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
email me directly
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.
|
|
|
Message #144483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rolf is a wolf... and thus frend of the forest.
...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.
|
|
|
Message #144496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It all comes down to one thing...
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
|
|
|
Message #144498
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It all comes down to one thing...
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?
|
|
|
Message #144509
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one billion dollar: a "small" IBM contract
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
|
|
|
Message #144510
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wow, more gibberish
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 :)
|
|
|
Message #144535
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It all comes down to one thing...
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
|
|
|
Message #144538
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
one billion dollar: a "small" IBM contract
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
|
|
|
Message #144549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Depends on the quality of the developers
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.
|
|
|
Message #144550
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cameron back from the dead?
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.
|
|
|
Message #144580
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
distributed or partitions database configuration
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.
|
|
|
Message #144587
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
distributed or partitions database configuration
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.
|
|
|
Message #144602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
distributed or partitions database configuration
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 :)
|
|
|
Message #144605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the last stand
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
|
|
|
Message #144669
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the last stand
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.
|
|
|
Message #144682
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
the last stand
"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
|
|
|
Message #144768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web Server MArket Share
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/
|
|
