Home

News: Roger Sessions on .Net vs J2EE

  1. Roger Sessions on .Net vs J2EE (25 messages)

    Read .NET vs. J2EE (word doc), but Roger Sessions.

    This is quite a biased comparison of .Net and J2EE, but I feel it does make some interesting observations:

    Sun's J2EE vision is based on a family of specifications that can be implemented by many vendors. It is open in the sense that any company can license and implement the technology, but closed in the sense that it is controlled by a single vendor, and a self contained architectural island with very limited ability to interact outside of itself.

    One of J2EE's major disadvantages is that the choice of the platform dictates the use of a single programming language, and a programming language that is not well suited for most businesses.

    One of J2EE's major advantages is that most of the J2EE vendors do offer operating system portability.

    Microsoft's .NET platform vision is a family of products rather than specifications, with specifications used primarily to define points of interoperability. The major disadvantage of this approach is that if is limited to the Windows platform, so applications written for the .NET platform can only be run on .NET platforms.


    Threaded Messages (25)

  2. Roger Sessions on .Net vs J2EE[ Go to top ]

    Interesting article. He says a Java coder can learn C# in a few hours, but doesn't mention learning the opposite direction, let alone the libraries that make you productive in any language. I'd be interested in others responses, especially to his many claims that .NET performs better and on cheaper hardware. Do we really not have any good performance numbers for J2EE?

    Ted
  3. Roger Sessions on .Net vs J2EE[ Go to top ]

    It would be very easy indeed to dismiss this article as being biased.

    I'll begin to say where he conciously misleads people.

    So, .NET is not a reality today, although he mentions that some technologies which .NET will be derived from have existed for several years.

    However he is absolutely false in saying .NET is having years of advantage over J2EE because the cornerstone of .NET, namely Common Language Runtime, is absolutely new and Microsoft has no experience to build upon.
    So, it will take a while for .NET to be launched and after that to mature (including service packs, patches to serice packs, etc)...

    Unfortunately, it does contain some unpleasant truths about J2EE.

    The most unpleasant is that we do not have J2EE performance figures.
    You can see for instance a nice press release for ATG Dynamo product which has nice figures, but the performance benchmark was not standard, and it was run on terribly expensive hardware (Sun E10000 - the most expensive thing you can buy from Sun).

    No J2EE vendor has had the courage to post any figure on any TPC benchmark, more they are in the process of creating a J2EE only benchmark that would make it effectively imposible to compare J2EE with any competingtechnologies.

    So if Sun will be complacent in the situation where J2EE is now, I'm affraid it is very possible that next time we won't have any serious reasons to dismiss Mr. Session.

    Costin
  4. I read it too..very biased. I can't take his comments seriously when he says .Net preceded J2EE by three years, in the form of MTS/COM+/ASP... He certainly has no problems playing around with the semantics of words if it suits him.

    He impunes his own credibility...

    J.M.

  5. Roger Sessions on .Net vs J2EE[ Go to top ]

    Hey Roger, how is your CORBA Persistent Object Service specification doing?

    But seriously, ever since Roger was uncerimoniously dissed by the CORBA community, it has been a constant stream of pro-Microsoft, anti-CORBA, and anti-J2EE tirades. The man is on a mission to avenge his past humiliation, and he is betting on Microsoft technology as the platform that will allow him to do it. After all, it was the OMG community (including Sun) who betrayed him.
  6. Roger Sessions on .Net vs J2EE[ Go to top ]

    I don’t wanna go that far and criticize Mr. Roger for no reason. I don’t care for his past, but he got some solid points that have to be addressed, especially some issues with bench marking transactions for J2EE systems. It is very objective (one of very few things in our filed) and needs some consideration. Bottom line is that both J2EE and .NET lock us, formal in the form of language the latter in the form of platform. I still think being a mature developer we all have to sit tight and see how .NET back up all their claims; I am also not sure how reliable and mature the IL translators right now?

    Rashid.
  7. I have actually been following up on Roger's ObjectWatch newsletters for quite some time - they have been less frequent of late, but they're usually very funny. ;-)

    I'm not quite sure that Roger really knows what he's talking about. Agreed, he's an ex-CORBA guru, but a lot of the stuff he churns out seems more M$-propaganda-oriented than technical.

    In any case, the necessity of having true business-oriented, transaction-based benchmarks a-la the TPC for J2EE cannot be understated. But does that necessarily imply, for example, a TPC-C submission that would involve using some J2EE app server as the TP engine. I do not think that it ever be possible for any J2EE setup today to rival M$'s current TPC-C figures (the current clustered results).

    M$ has really taken advantage of the partitionability that TPC-C offers in terms of workloads. Furthermore, M$ SQL Server uses distributed partitioned views and shared nothing configurations, as well optimized native code to run these TPC-C benchmarks. (How relevant these results are from everyday business perspectives is a question that has been raised time and time again, particularly by Oracle buffs). Anyway, there is really no reason that we in the J2EE community should try and rival these benchmarks right now. What we need is an independent J2EE-based benchmark that will at least let us compare different app servers against each other on specific OSs and hardware.

    In the future, maybe with the next generation of JITs and JVMs and EJB servers, the J2EE community can really take on some of these TPC figures. Though I do really not see that happening in the next couple of years.

    Sandeep Dath

  8. "What we need is an independent J2EE-based benchmark that will at least let us compare different app servers against each other on specific OSs and hardware. "

    That means we are fooling ourselves.

    Even if we criticize the current TPC benchmarks for not being complex enough, or being "clusterable" (aren't clusters the biggest hype in J2EE ?), or being resolved by low level C + embedded SQL code as we can see in thier disclosures, that doesn't mean we solve anything with J2EE based benchmark.

    If the current ECPerf project goes live, I can only imagine low integrity guys like Roger Session laughing in our face.

    If we think TPC-W is not complect enough,then we can construct a more complex bussinesscase as benchmark.
    If we want to avoid TPC-W being implemented in C + Embedded SQL, then we could introduce in a new benchmark code complexity metric that would discourage such thing.
    Please note that nobody has submitted a TPC-W based on ASP + VB.

    But to create a benchmark that refuses competition with alternative technologies, that only shows narrow mind and cowardness.

    If we are not able to compete now, then Sun would better say that upfront and focus on fixing the problem.

    But if ECPerf hoes live I'll be ashamed that I'll be still programming in Java!

    Costin
  9. Roger Sessions on .Net vs J2EE[ Go to top ]

    So personal attacks against Roger Sessions aside, we're basically saying that J2EE cannot compete on performance with a clustered-Intel box. Even though we have some serious Unix hardware (perhaps also using a cluster?!) to fall back on (Note: non-clustered Unix still beats non-clustered Intel, although the Intel platforms still dominate the price/performance).

    The whole point of something like TPC, is that it _IS_ a level playing field. Rather than whinge about partitioning (which depending on your app, is a good tactic for your live system!) and use of "optimised" code (so I might use C++ in an ISAPI filter - this is not that hard, and we're all big boys and girls here :-), why not also use the same pattern for a J2EE submission.

    We don't really care if a J2EE container does not get #1 spot (although in the top 10 or top 20 would be _nice_) - we are not picking for J2EE specifically for performance, it gives us other advantages over C++ solutions (such as a cheaper development and maintenance cycle). (IMHO)

    Lee.

  10. QUOTE
    In the future, maybe with the next generation of JITs and JVMs and EJB servers, the J2EE community can really take on some of these TPC figures. Though I do really not see that happening in the next couple of years.
    UNQUOTE

    Mr. Sessions also places some serious questionmarks concering the ability of entity beans and statefull sessions beans to scale (see www.objectwatch.com). So far I haven't read any comments from mr. Session's opponents regarding these issues (although I'm very curious to read about it). In future projects should I use these kind of beans or should I avoid them and stick to stateless sessionbeans and in essence using the same model as traditional TPs and COM+ (my projects will have a lot of non trivial business logic, asking for high throughput and high load). Can anybody comment on this or has anaybody experience with this kind of scalibility issues in EJB?


    QUOTE
    M$ has really taken advantage of the partitionability that
    TPC-C offers in terms of workloads. Furthermore, M$ SQL
    Server uses distributed partitioned views and shared
    nothing configurations, as well optimized native code to run these TPC-C benchmarks. (How relevant these results are from everyday business perspectives is a question that has been raised time and time again, particularly by Oracle buffs).
    QUOTE
    To complete this picture: there are some non clustered TPC benchmarks from Unisys where a TPC level of 61390 is reached using W2K datacenter/COM+/SQL Server. This benchmark doesn't use the latetst ES7000 Unisys hardware with 32 processors but a Unisys ES5085R with 8 processors. So in near future we can expect some better non-clustered COM+ TPC benchmarks when ES7000 is used. In bechmarks for the SAP application the ES7000 is gaining ground on and nearing the high end unix boxes.
  11. Just to complete the picture.

    Please note thast the actual Win2k/Winnt benchmarks don't really use the COM+ technology.
    They are in low level C + embedded SQL, and they only use the MTS part of COM+.
    A transaction monitor is not the key thing in transactional performance.

    They are done this way mainly because they are posted by hardware vendors that want to squeeze the best performance out of their hardware, and of course hardware bvendors need not be concerned about software complexity issues.

    However this doesn't excuse in any way what's happening with J2EE benchmark.
  12. QUOTE
    Just to complete the picture.

    Please note thast the actual Win2k/Winnt benchmarks don't really use the COM+ technology.
    They are in low level C + embedded SQL, and they only use the MTS part of COM+.
    A transaction monitor is not the key thing in transactional performance.

    They are done this way mainly because they are posted by hardware vendors that want to squeeze the best performance out of their hardware, and of course hardware bvendors need not be concerned about software complexity issues.
    UNQUOTE
    I agree on most part of this posting, however, perhaps not that important in the TPC benchmark (I think only the DTC part of COM+ is used), I think in real world large scale 3tier client server apps a TP monitor is essential for getting good throughput against reasonable costs (why doesn't traditinial 2tier client server scale that well?), from that perspective I am just curious where EJB stands when compared to traditional TP monitors like Tuxedo and Encina on the same hardware, these results are not available. I certainly agree with you that when comparing WinDNA (.Net, COM+, ....) to J2EE you have to take into account all the other technologies provided (platform indepence vs language indepence, ADSI vs JNDI, JDBC vs ADO(+), JSP vs ASP(+), JMS vs MSMQ, MTS vs EJB, DCOM vs RMI, COM vs JavaBeans, DTC vs JTS/JTA).

    Besides that mr. Sessions places questionmarks at the ability of the scalibility of entity beans and statefull sessionbeans. I am just very curious, should I use these kind of beans or stick with the stateless sessionbeans, adoption in essence the same programming model as COM+ and traditional TP monitors.

  13. Hi,

    To start with, this is not flame-bait.

    So the folks out there really believe that an entity bean (CMP or BMP - either way)-based application with an elementary session bean facade can outdo custom-written optimized code native to an RDBMS native to an operating system (almost) native to a specific processor base?

    Get real. We are not talking VB/ASP (thought with VB and ASP in .NET can perhaps scale much better - among other things, VB's current scalability issues relate to apartment threading). We are talking little bits of code floating around in transaction space that are have been brought into existence for the sole purpose of getting incredibly high numbers on those TPC tests. Call the whole show rigged if you like.

    TPC should really read TP-Squeeze. Every possible ounce of juice that can be squeezed out of a TCP configuration from every imaginable component IS!

    You put those J2EE figures out there on a TCP list, hundreds of thousands of Java Programmers will cringe at working with a technology that requires really really scrolling down on the results page to find the entry. Of course, the TPC-W doesn't have too many entries, so that's a relief ;-)

    How will that help us J2EE programmers. Are you looking for performance placebos? <sing-song>Oh, wow we are in the top <place your large number here>. We are not losers. Nyah-nyah-nyah.</sing-song>.

    IMHO, TPC-C (or W for that matter) is not the forum where we need to introduce J2EE performance comparisons. To start off with we still don't have anything that seriously compares different application servers. What does the technical staff of a company go on, for Chrissakes?

    J2EE performance benchmarks should also deal with systems that are realistic, that we will use today, here and now. How many TPC-C configurations do you know of that are actually in production?

    I'm not saying that we (the J2EE community) should shy away from the world's meanest performance benchmarking efforts. What I'm saying is that the net benefit to the community at large that will result from this (intangible benefits like "wow, that's cool" do not count) is not really worth the effort. Think of all the CIOs, CTOs, software architectes project managers and technical leads in the J2EE development community out there - we need a benchmark FOR them. That is why these benchmarks are out there in the first place, not to assuage somebody's unsure ego, but to help people make decisions.

    My 2 cents. And a lot of my life. ;-)

    Sandeep Dath
  14. Roger Sessions on .Net vs J2EE[ Go to top ]

    As an afterthought,

    1) Why mention the entity bean with the session bean facade scenario in the last post - simple, lots of in-production EJB-based systems run that way. Its representative of lots of people approach the problem.

    2) Like TPC-C and TPC-W, we really need separate J2EE benchmarks for measuring simple, vanilla OLTP performance and for measuring performance in a web-based e-com scenario..

    To end with, I would like to make a weird analogy - some sceptics often say that time travel is impossible because if it had been possible, we would be inundated with people from the future. (Of course it is possible that inherent hyper-dimensionality issues prevent us from seeing them!)

    Similarly, if J2EE performance in the TPC world could have been convincing enough, we would have seen 'em numbers being advertised all over the place. We don't. Any guesses why?

    Sandeep Dath
  15. There's no such thing asd J2EE performance.
    There is performance, period.

    And are you sure that Session as facade to Entity within the curerent state of EJB technology is not a stupid way to moving bytes around, wasting CPU cycles for no good reason, and other many goodies ?

    Guess what, you don't.

    And a benchmark that is open only to J2EE is not going to help you find out.
    And if you think you need J2EE benchmark for CTO,CIO ... you can only imagine how the situation where J2EE world refuses competition (it's the naked truth: with ECPerf, EJB world refuses to compete) will favor Microsoft marketing.
  16. "..And are you sure that Session as facade to Entity within the curerent state of EJB technology is not a stupid way to moving bytes around, wasting CPU cycles for no good reason, and other many goodies ?

    Hmmm.. Dear me, did I ever say that the Session facade is a good/stupid/obsolete/whatever way to do anything. You seem to assume that I said that, Costin. But then nearly every project that I have seen does it that way, so it is to an extent representative of the way people do things TODAY in EJB. On a lighter note, this also probably means that it really does not qualify for TPC submission - because TPC configurations are rarely representative, if anything else. :-)

    "Guess what, you don't. .."

    Well, you seem to know me better than myself. ;-) Remember, there is a difference between getting the best performance out of an EJB-based application and getting the best performance out of it by using the EJB technology the way it is recommended to be used.

    In my opinion, EJB as a technology is not mature enough today to compete in the world of raw transaction processing. Maybe that, Costin, is the reason that the EJB world refuses to compete. Maybe its like taking potshots at the moon when the Wright brothers are still getting their act together. And maybe we SHOULD wait. And maybe we should do something WHILE we wait. ECPerf maybe?

    Sandeep Dath
  17. Sandeep,

    You pretend you don't uderstand inconvenient things.

    "... by using the EJB technology the way it is recommended to be used."

    If Sun recommends you to jump from 10th floor what do you do ?

    "In my opinion, EJB as a technology is not mature enough today to compete in the world of raw transaction processing. "
    So maybe they better shut up, keep their heads in the send like ostrich does, and work to fix their problems.
    Instead they charge around 30K per CPU for EJB servers licenses and tell everybody that the square is round.

    "And maybe we SHOULD wait. "
    No, that would be stupid. Waiting for Godot or what ?
    We have to do our business that means programming, and we can do so by diregarding the EJB antipatterns proclaimed as patterns. there are still a bunch of good things in EJB spec that you can take advantage of (like declarative transaction management ),
    so responding to Frank, you can still use stateless session beans with SQL and I guarantee that it can scale to the moon.

    "And maybe we should do something WHILE we wait. ECPerf maybe? "
    In Romania we have a saying, "If the stupid is not proud, he's not stupid enough", it even rhymes in Romanian.
    It fits perfectly to the ECPerf.

    So we have a technology that is immature and we can't make it compete.
    Instead of taking the challenge and making it work,
     we cowardly devise a competition only for our technology, like who is the best of fools.

    What we SHOULD do as a community is to get the word out to Sun (Java One is near) to take the damn thing out and fire all the documents that would show it ever existed.

    ECPerf is a disgrace to Java community.
  18. Concerning expensive J2EE/Unix: why not use the cheap J2EE/Windoze as a comparison? It is after all Java!

    Concerning expensive Java training: Isn't VB.net something completely new? Threads and inheritance and so on! And wait Cobol and Perl and... A veritable nightmare! Who would want to support this?

    Concerning IIOP beeing so useless on the internet: SOAP? Who uses this right now? Nobody?! DCOM on the internet? No can do!

    Concerning scalability problems: Well, I think that the developers are the root to most scalability issues. So letting the developers do as little coding as possible (using for example entity beans) makes your product more scalable. And reduces the number of bugs! And reduces your time to market!

    My 2c's
  19. Roger Sessions on .Net vs J2EE[ Go to top ]

    Very biased....some interesting points.

    Correct points:
    - Need for more standardization among J2EE vendors.
    - Need for more benchmarks of any kind
    - .NET tools easier to use
    - ASP.NET is a good technology
    - Both platforms lock you in to a single vendor
    - J2EE is still very new technology (as is .NET)

    Incorrect (massively) points:
    - .NET as "proven platform"
    - J2EE performance assumptions (50% of existing specs)
    - Training people on Java will be more expensive than training people on .NET. The real issue in the training is object-orient programming techniques, not the language choice.

    I think we'll just have to see how .NET comes out - I'll be very curious to look at Beta 2.

    Oh, and someone else in another thread said "SOAP? Who's using this?" Well, we've done 2 integration projects since the beginning of the year between different sites and the technology was SOAP. And it wasn't us who pushed the technology - each of the companies we were talking to had already done an implementation.

    My 2 cents....

    Damian
  20. Aren't we all in some way or another biased? When is someone unbiased? The situation in my company is such that choosing for J2EE is very evident but I can imagine that there are situations that u consider the use of a WinDNA/.Net architecture. Reading the J2EE vs .Net I think all writers are in some way or another biased. All opinions have to be placed in some kind of validation context (the situation in my company is such and so and based on such and so I choose to use or I advise to use technology such and so). Almost always the context is not provided, only the result.....
  21. Roger Sessions on .Net vs J2EE[ Go to top ]

    Someone asked it previously, but does it really take a UNIX/RISC platform for J2EE to be competive against .NET?

    Does anyone have any idea of what the 'tpmC' and 'Total Sys. Cost' columns would contain when using the same Company / System as used for .NET?

    The comparison should only reflect a difference of the competing "application frameworks" -- ie, OSes, DBMS, hardware, etc. should be the same... otherwise, we are just snuggling up to "proprietary" systems, protocols, etc.

    These comparisons should use hardware, products and feature sets that are available to all competitors. Yes there are proprietary back door ways of doing things to gain speed and other advantages, but as far as comparing apples-to-apples, what is the value of allowing such an implementation?

    Maybe the nature of the comparison just yields a smaller set of comparable areas -- but isn't this more valuable than trying to compare test results from totally dissimilar offerings?

    My 2 cents...
  22. Roger Sessions on .Net vs J2EE[ Go to top ]

    The problem I've always had with TPC + J2EE has been that TPC is mainly about database+hardware vendors milking performance out of their hardware using 90% tuned C code and some generally unrealistic partitioning schemes.

    J2EE on the other hand is more about developer productivity and fostering a marketplace of servers based on Java. It's less about performance (otherwise why aren't we doing things in COBOL?)

    As for Roger, I've given up on him years ago. The .NET/COM+ team at my company even thinks some of his comments are rather dubious (.NET is mature? COM+ still has a *ton* of issues outstanding...)

    I'd like to see benchmarks not only to compare servers but to see how much performance is -really- lost when going to an object/relational CMP mapper, depending on the product.

    Stu
  23. I agree with your comments on J2EE, it's about developers not about performance right now but the marketing unfortunately gives a different impression and people swallow it, using J2EE makes your application scalable. You as always need to design for scalability, you never get it for free unless you're very lucky.

    I think benchmarks on OR would be definitely be useful but given the range of needs, it'd be a difficult task to do. BOM type database models are a problem for example. Plus, once you cluster etc then it becomes more difficult as caching/stale data becomes an issue. Maybe, extending ECPerf to include some more types of data models with more diverse usage scenarios would be a solution.

  24. Billy and Stu,

    ECPerf is technically flawed because it doesn't define a problem, it defines an implementation .

    More, it is commercially flawed because it is a safe-heaven for EJB technology to avoid competition.
    Microsoft marketing will take advantage of it, and it would be one of the few times they are justified.

    The worst, it is psychologically flawed.
    Java community evolved from a tradition of Unix and people who bashed Microsoft for its technical problems.
    It was no question, only a few years ago, that Unix was the serious stuff: stable, performant and scaleable, while Microsoft was a toy for workgroups and small businesses.
    We were like BMW technicians while MS developers were like Ford technicians and we had our pride for that.
    Now imagine that the old Crown Victoria suddenly runs faster than the Z8. And worse, BMW drops out of competition under the pretext:
     - "No, we are not talking performance here,we're not that interested in raw performance, we sell BMWs for leather quality and interior comfort, we'll create a separate competition for cars that have to have leather and look exactly like BMWs and have BMW engines under the hood."
    Would you want to work for BMW any longer?

    For me there's no excuse.
    I am very open and ready to switch to C# or Eiffel or go back to my good old Delphi (do I need to mention to OO folks like you that each of these is a more complete OO language than Java ?).
    In case it turns out that Java drops out of competition I beleive many will do the same

    The last point I wanted to make is that you can't have scalability without performance.
    And COBOL maybe is not the best language there is, it is certainly the best language for those who master COBOL, and Java language has its share of limitations.

  25. I think that most developers waste far too much time thinking and worrying about "performance" and "benchmarks".

    I am not saying that performance should be ignored - it is just that there are just more important things to worry about, like:
    1) Getting the development finished on time
    2) Getting the application to run reliably
    3) Desigining the application to be able to adapt to future requirements.

    Are there benchmarks on these performance statistics? No? Pity. These are the more important things that IT managers would like to know...
    I am not to sure many of them care about TP*...

    I think if more developers concentrated on just getting the VolksWagon applications built, there would be a whole lot less money wasted... - it is the typical difference in mindset between boffins and bean-counters.

  26. Another way of wasting money is by wasting performance and scalability for no good reason.

    And performance can be a secondary concern as long as it stays within reasonable distance (50% is the lowest, most generous limit) of what one can reasonably expect from the underlying hardware.

    Less than that is really a waste of money, and lack of professionalism on developers' and project manager's part.

    So, we know for sure that certain aspects within J2EE specs waste performance, we know for sure they waste it for no good reason (like giving you an easier way to develop), but we DON'T KNOW whether it fits at least in the 50% margin.

    If you're not interested to find out, well, you can have your ways ...