Discussions

News: Roger Sessions' comparison of J2EE and .NET is fatally flawed

  1. Randy Heffner at Giga has written a Giga Critique officially criticizing points made by Roger Sessions in his whitepaper: J2EE versus The .NET Platform; Two Visions for eBusiness. Although both of these papers are a bit dated, they are definitly still relevant.

    Read Roger Sessions' comparison of J2EE and .NET is fatally flawed.(PDF)

    Read Roger Sessions' J2EE versus The .NET Platform.(word doc)

    What do you think?

    Threaded Messages (25)

  2. I do agree with Randy. .NET is not mature.
    Most of the underlying .NET technology is not that mature: SOAP is still evolving, UDDI is a "design by commitee" specification (The spec changed weeks after releasing the first one). These protocols are good for B2B exchanges but IIOP is way more efficient for distributed applications.
  3. So why did they have to do it in PDF?

    Here are a few of my takes on the Giga response.

    "Sessions is correct that J2EE does not achieve 100 percent portability"

    No he's not. Roger is completely wrong. J2EE achieves 100% portability everywhere Java achieves it - among operating systems and even among JVMs.

    Just because it takes time to port from one J2EE container to another now doesn't mean it will always take the same amount of time. Moreover, Microsoft doesn't even *have* *any* statistic for inter-container portability since the only .Net is their .Net. So far.

    "Sessions is correct that .NET on Windows will be less expensive than J2EE on Unix. For that matter, .NET on Windows will be less expensive than J2EE on Windows (which Sessions fails to mention as an option), but not by so big a margin as the difference on Unix."

    No he's not! I would argue that J2EE work-alikes such as JBoss will drive the cost of J2EE ownership down rapidly. In fact - it's just a matter of interpetation already. If you count a J2EE work-alike as "J2EE without the license fee" then the cost is already 0. If you require that J2EE means "J2EE with a license" then the cost can never be 0. But this fact makes the question one of linguistics - not one of cost. By any other standard, J2EE is less expensive.

    There are several other things to consider here:

    1) Java is very far ahead on both object transaction monitoring (EJB), and on rationalizing the design of the interoperability framework (JSP+MVC: See Java Skyline: Learn JSP http://www.javaskyline.com/learnjsp.html)

    2) Microsoft is father ahead on Web services. However, this whole discussion has so far ignored Sun's latest (and plentiful) information on Web services (See today's http://www.javaskyline.com/servernews.html for a summary). Some of Sun's own answers to Web services have yet to be produced; some are in beta. And for some, the IBM and Apache equivalents are much farther along.

    3) It's good to look at Roger's slides because he's giving you the general design of .Net.

    One area of .Net I'm concerned with is the DTC (Distributed Transaction Controller). It's probably not at this point ready. And when it is ready the name alone and the design seems to indicate that it's going to be a DTM rather than an OTM. That may limit its use somewhat, keep Microsoft out of the mainframe connectivity market. One gets the sense that they would want to have an OTM since C# and VB .Net are both OO, but this may not be the case.

    Many thanks to the Giga group for their analysis.

    Regards,

    Rich Katz
    Java Skyline: 'The Web' (noun) A book that describes how to build 'The Web.'


  4. One area of .Net I'm concerned with is the DTC

    >(Distributed Transaction Controller). It's probably not at
    >this point ready. And when it is ready the name alone and
    >the design seems to indicate that it's going to be a DTM
    >rather than an OTM. That may limit its use somewhat, keep
    >Microsoft out of the mainframe connectivity market. One
    >gets the sense that they would want to have an OTM since
    >C# and VB .Net are both OO, but this may not be the case.

    I do not realy understand what u mean, as I understood it DTC is already in place (SQL Server 6.5, SQL Server 2000, MSMQ, COM+ are already using DTC (=Distributed Transaction Coordinator)). DTC is not meant to be the OTM, the OTM in the MS world is COM+ (and before W2K it was MTS), this is where declarative transactions, declarative role based security and such can be found (DTC's function is like JTS/JTA in J2EE and J2EE EJB is the OTM).

    So I think the is already a OTM for .NET which is COM+ .Net applications will use (existing) COM+ runtime services for e.g. transaction management, role based security etc. .Net (the CLR) will bring another (a far better) component/object model to Windows development, a model which has IMHO features already found in the Java model (some remarks on this new programming model see: Don Box column House of COM on http://msdn.microsoft.com/msdnmag/issues/1200/com/com1200.asp) A quote from Tim Ewald's book Transactional COM+ , appendix A: "The CLR is a replacement for COM, but not for COM+. CLR classes can be configured to use COM+ runtime services the same way COM classes do. In fact you can mix both classes using both component technologies in the same COM+ based system. This works because the CLR is backwards compatible with COM. The .Net Framework SDK simplifies COM+ programming...."

  5. There is an old saying "All roads lead to Rome". J2EE and .NET or whatever technology, if it helps you to make profit from your e-Biz projects, then go for it.
    I like the competition between the two or even more, since without this, who knows what the hack .NET going to look like without the competition. Competition drives MS and Sun crazy to always improve their stuff, which eventully benefits the customers.
    My advice is that, for a Internet application developer, you would better know Java and one language from .NET,since no one knows for sure if .NET will be the hot language later on.
    For an investor, always keep your eyes on your project plan and budget.If you have to spend extra $ to train your tech people to use J2EE and outsource a big part of your project, then you will have serious problems just like lot of other dead Dot-Coms.
  6. Thank you Randy!, what a well written response.

    I don't think for a second that Roger believes he wrote an unbiased paper.

    Is he a salesman by any chance ?

    ==

    J2EE / .net and portability

    One simply cannot compare J2EE and .net in terms of portability. Why? because .net has _no_ sense of portability, while J2EE has portability in several different contexts.

    JVM/ Platform portability ? yes - insofar as java is portable.

    Application portability ?
    J2EE 1.2 portability is very good, however several key parts of an enterprise application are not convered by the specification.
    -authorisation and authentication mechanisms (as far as i can tell, covered in J2EE 1.3 by JAAS, yay)
    -persistent services (JMS consumers, startup classes etc); largely covered by EJB 2.0 (message driven beans)
    -entity finder methods (covered by ejbql in 2.0)

    These are the main parts of a j2ee app that aren't portable - has anyone else discovered non portable services that are (or are not) covered by j2ee 1.3 ?


  7. Roger wrote COM/COM+ and J2EE comparisons when he didn't understand anything about J2EE and was totally clueless. Due to this, he always gets a lot things wrong about J2EE. And he is biased. A lot. Just read his ObjectWatch newsletter,

    bye
    -stephan
  8. And according to the Giga paper, Roger Session was paid by Microsoft for this paper.

    bye
    -stephan
  9. I hope people participating in or reading this discussion will actually go to the trouble of reading his article. It seems, from some of the comments, that just to connect Sessions to Microsoft means he doesn't have to be taken seriously.

    A good illustration of where he is coming from: in his book, 'COM+ and the Battle for the Middle Tier', Sessions expresses extreme skepticism about entity beans. But this was not a pro-Microsoft rant against something 'not invented here'. He applied the same criticisms to the in-memory database that Microsoft were developing.

    If you raised concerns about entity beans at the time his book was published you were held up for ridicule. How the times have changed! Try finding a BEA consultant who will advocate the use of entity beans now. Look at the reports from JavaOne!

    So it would pay people to consider the arguments, rather than indulging in cheap, ad hominem attacks.

    GIGA mentions not comparing apples with apples. One of the parts of Sessions' paper I really liked was his exposing the fact that the transaction statistics submitted by BEA and IBM for WebLogic and Websphere were generated from Tuxedo and Encina, respectively. Is this true? Where are the law suits from BEA and IBM? If it is true, it makes you wonder how much the opinions of zealous J2EE advocates is based on hype rather than reality. How many of the high-volume sites claimed for J2EE are actually using non-J2EE technology like Tuxedo? (Often vendors muddy the water. BEA made a big play about VISA International. Lots of people would have heard that. How many heard that it was Tuxedo, not J2EE?)

    Another contributor makes a point about the weakness of .Net's transaction model. One of the biggest hype-to-reality disappointments I have experienced is the reality of transactions within J2EE servers. What version of WebLogic do you have to run to get a transaction across 2 different connection pools? (Clue: not 4.5.1, not 5.1) What version of WebLogic do you have to run to get a transaction across Oracle and SQL Server? What about across JDBC and CICS? Even BEA's own Tuxedo product is not (or was not, until *very* recently) integrated into the transaction model. Is this just a WebLogic problem? I doubt it.

    I think the greatest benefit of considering arguments put by Sessions and other Microsoft advocates is to puncture some of the J2EE hype which, in my view (as a J2EE developer), people seem to be swallowing whole.

    Kind Regards,

    Matt
  10. My opion about Roger Session is based on several COM+/J2EE papers written by him, I'm a regular reader of ObjectWatch and I have read the article (although distributing papers as .doc is biased in itself, I think.)

    About benchmarks: TPC is imho not very suited for e-commerce websites, which involve a lot more than sales-transactions. TPC may be suited for ASCII-flight-order-transactions but .NET and J2EE claim do a lot more to do (XML, rendering, web requests, business logic) than transactions.

    About TPC/$: why choose AIX (when indeed IBM tries to replace AIX with Linux ?) You may choose AIX/WebSpehre/Oracle8i if you are in the high end transaction field, for most websites and enterprise frameworks something like Linux/Jboss/Interbase will do the job (Or Linux/Jboss/Oracle). Some friends have big clients that even run Linux/PHP/MySQL. The number of Stock Traders and Airlines is limited.

    bye
    -stephan
    bye
    -stephan
  11. Stephan,

    your view of TPC is quite common, and may or not be correct, but you neatly side-stepped the main point. If BEA and IBM thought it was valid enough to submit benchmarks for WebLogic and Websphere, why did they (allegedly) use Tuxedo and Encina code rather than Java?

    Your previous contention that Roger Sessions 'didn't understand anything about J2EE' is, frankly, ludicrous and just makes you look like a zealot.

    Matt
  12. Matt,

    yes I sidestepped your point, because this was not a direct reply to your post. I'm sorry that I didn't make that clear. My guess is, they know that they loose at TPC and so supplied Tuxedo/Encina benchmarks. This is wrong but quite understandable, because Tuxedo/Encina are what comes closest to the level where TPC is important. When TPC is important for your application, then use TPC to compare .NET and J2EE. When you really depend on it, use a java API that wraps your transaction monitor, don't use J2EE. We produce an intranet 95% read, 5% write knowledge and document manangent system. TPC is clearly wrong for us. J2EE replaces our own distributed objects / O-R mapping tool, so there might be more to choosing an AS than TCP for a lot of people.

    I may look like a zealot but I'm not interested enough to go through old ObjectWatch letters to prove your opinion wrong.

    "Roger wrote COM/COM+ and J2EE comparisons when he didn't understand anything about J2EE and was totally clueless." which is quite different from:
    "Your previous contention that Roger Sessions 'didn't understand anything about J2EE". Perhaps my English is not good enough, I tried to state the past. And there are parts in his ObjectWatch newsletter around 28 I think that make him look clueless.
    (His mixing of product and specification comes to mind,
    his disliking and not understanding the sense of remote objects ,
    ...)

    About TPC-W: Yes, I would like to see TCP-W benchmarks, is there a port for J2EE ? The specification on tpc.org is where thin.
    Does ecPerf use HTTP ? Could ecPerf be ported to .NET ?

    bye
    -stephan
  13. Let's hear it for Roger Sessions![ Go to top ]

    How about TPC-W then? Nice and open spec, designed for e-commerce performance measuring.

    "TPC Benchmark™ W (TPC-W) is a transactional web benchmark. The workload is performed in a controlled internet commerce environment that simulates the activities of a business oriented transactional web server. The workload exercises a breadth of system components associated with such environments, which are characterized by: "

    http://www.tpc.org for the rest...
  14. Let's hear it for Roger Sessions![ Go to top ]

    I did go to the trouble of reading both articles and I am not a 'zealot'. I develop and install production systems that utilize both Microsoft and Java-based approaches.

    I find it difficult to take Mr. Sessions' opinion's seriously, without a high-degree of skepticism. There are several factual errors in his paper. To illustrate my point, I reference a statement he makes on page 20 of his paper.

    "The second flaw is that IIOP, like all proprietary communications protocols, is not amenable to transport over the Internet."

    The OMG specifies IIOP and I don't consider the OMG to be a proprietary organization, nor do I consider the IIOP to be a proprietary protocol. This seems to me to show a lack of understanding of the products he is comparing.

    If this were a speech, one could accept this mis-statement as a slip of the tongue. In a comparison white paper, Mr. Sessions should be more careful.

    If you can't get something that straight-forward correct, how can anyway take the overall analysis seriously?

    This is not to say that I don't find his papers useful. In reading this paper, he does make me think about some things in ways I had not thought of before and for that I find it useful. That being said, I do not feel I can accept his statements or opinions without researching them myself.

    My point is you should read these articles and form your own opinions. Mr. Sessions comes at this with a biased viewpoint. Understand it and learn from the thought he has put into it.
  15. I am not sure if everyone knows the history of Roger but he used to be on our team...

    After reading his article I am quite sure he is still upset over his experience with CORBA and it is quite evident in this article.

    He used to work for IBM and was one of the Chief Architects for their database and worked on the CORBA POS (Persistent Object Services). He was a huge supporter of CORBA until everyone noticed that the POS system was really a P.O.S. Then he jumped on the DCOM bandwagon after his ideas were so ill received by the community.

    The whole story is an interesting read for anyone who is interested in what motivates some of his comments. (The CORBA-DEV archive has a bunch of info about it.)

    He writes a lot of his comments because of his past experiences with the whole CORBA community.

    I have a lot of respect for Roger and some of the things he has done. He has a lot of passion for technology and I like how he challenges the J2EE community all the time. Very few people bring passion and energy to the technology market these days.
  16. "The second flaw is that IIOP, like all proprietary

    >communications protocols, is not amenable to transport
    >over the Internet."

    >The OMG specifies IIOP and I don't consider the OMG to be
    >a proprietary organization, nor do I consider the IIOP to
    >be a proprietary protocol. This seems to me to show a lack
    >of understanding of the products he is comparing.

    I agree that IIOP is not a proprietary protocol at all, but I think one can read this sentence in two possible ways:

    u could read it with the meaning: "IIOP, like all OTHER proprietary communications protocols....."

    (like u did and like I did the first time I read it)

    but u could also read it as: "IIOP, like proprietary communications protocols such as DCOM....."

    when u read it in such a way, it makes sense and I think one should read it as such

  17. I think, actually, that he does mean that IIOP is a proprietary protocol. In the context of his article, he talks about IIOP only being available to those who have made a commitment to J2EE or CORBA, and it's in that sense that he means proprietary.

    Of course, that opens an interesting semantic discussion about whether something can be considered "proprietary" for presuming the use of "open" standards.

    SOAP certainly has a wider theoretical applicability to more platforms than IIOP, but he certainly errs in not acknowledging that real-world J2EE products will support SOAP.
  18. Let's hear it for Roger Sessions![ Go to top ]

    Dan,

    you say:

    "This is not to say that I don't find his papers useful. In reading this paper, he does make me think about some things in ways I had not thought of before and for that I find it useful. That being said, I do not feel I can accept his statements or opinions without researching them myself.

    My point is you should read these articles and form your own opinions."

    I agree wholeheartedly with this sentiment. But I think this should also be the approach we should adopt when listening to the opinions of J2EE advocates, too.

    One of the areas where Roger's books/papers have made me think about 'things in ways I had not thought about before' was the relative importance - in practice - of portability and interoperability.

    From my own experience: our shop is using the same hardware platform and app server vendor that we always planned to use. Most of our biggest issues relate to how to interoperate J2EE in a heterogeneous environment e.g. connecting from Delphi/VB apps, connecting to mainframe resources, getting transactions to work across 2 different databases, getting transactions to work across J2EE and tuxedo, having a common security model across all of these environments and so on.

    I would be nice to see at least some recognition from J2EE advocates that there is a long way to go!

    Matt
  19. There is a long way to go. I have no problem admitting that. There are flaws in the EJB spec (why are there no automatic bulk accessors ? why can't I have bulk selects in BMP find methods to populate my beans and have to use fat keys ? why is there no integration for custom key generation in CMP ? why have attributes to be public and EJB can't use Bean setters/getters ?)

    Everyone should read all available documentation relevant to his realm.

    But, J2EE is quite usefull and we had to deploy our product in several heterogenous enviroments and java did a fine job, so portability is useful for some of us.

    bye
    -stephan
  20. Let's hear it for Roger Sessions![ Go to top ]

    Matt,

    Point well taken... as was the previous post about Roger's previous work with OMG/CORBA. I actually did remember his work with IBM after reading Frank's reply to my post. I suppose had I remember that, I would have taken that particular phrase differently.

    I would also agree that J2EE has ways to go. I am not going to stand up and say J2EE is the be all and end all for server development. It isn't. Just as Java is not always the best choice for a language, there can be no "best choice" for server-side development. Only competing methodologies, with different attributes. As professionals, we must choose the right one at the right time.

    I suppose the point from my previous post can best be expressed with an analogy. To me, it seems as if Mr. Sessions looked at his Mother's apple pie and his Aunt's apple pie and said "You shouldn't eat Auntie's pie because it will make you fat. You should eat Mom's pie, because it tastes good."

    In a paper comparing two methodologies, you cannot change the comparison criteria in mid-stream. In my opinion, Mr. Sessions does this when he says .Net is mature because it is based on COM+ and J2EE is immature because it's only been in production 2-3 years.

    For this reason, I do not put a lot of faith in Roger Sessions opinions.

    As for his contention that portability is irrelevant, my own experience is different. My reasons for utilizing Java in the first place came from Microsoft. I use to be a self-proclaimed "Microsoft-biggot". Anything that Microsoft put out that came close to my sphere of interest, I jumped on. I did this not because I felt they were technologically superior, but because I was in the business to make money and hanging onto Microsoft, I felt, was the best, fastest way for me to make money.

    In the end, I almost lost my company. On three separate occasions, I developed applications using Microsoft technologies that failed in production. In each of those occasions, Microsoft said "Yep, we know we have a problem. We'll fix it when the next release comes out in 3-6 months."

    I had no place to go and no options, except a complete re-development. I vowed never to be locked in again.

    I have yet to attempt a port from one EJB server to another. It seems as if that will be some work, but it is possible. I have moved from JSP/Servlet provider to another, without so much as a recompile. So it is possible for at least some parts of J2EE applications to be moved from one server vendor to another.

    Unfortunately, when my Visual Basic program ate up 500 Meg of virtual memory, I had no options. There is no "third-party" Visual Basic.

    We each have our own reasons for choosing the development platforms and approaches we utilize. I still use VB and VC++ for certain applications. That is different, however, than building entire applications around a single companies vision & methodology.

    Anybody who says "Microsoft is the best server platform." or "J2EE is the best server platform." without addressing a particular situation or application is selling, not providing independent analysis.
  21. My view...[ Go to top ]

    I agree with Dan's last statement. Each technology has it's place and it's value. To say that one is just better than the rest is pointless. Even in some of our courses at The Middleware Company, we talk about this very topic. Are Entity Beans right for you?, Are EJBs as a whole the right solution?, etc, etc.

    I came from a VB background, and yes I do Java now and prefer it, that doesn't mean I think VB doesn't have it's place. I'm sure that .Net will also have it's place, and I look forward to seeing how well it gets accepted.

    Several good points were brought up about portability. Roger makes a somewhat good point about J2EE apps not being 100% portable. To some extent this is true, especially if you are relying on specific technologies, like how one vendor implements CMP over another, or caching, or integration products. However, what I think some, including Roger, fail to see is that with J2EE we have a choice of vendors. Almost all vendors will now agree that the J2EE specs are just a check mark on their product's spec sheet. The BEAs and IBMs are packaging other items, such as web services, integration capabilities, etc., into their products. if we do not need any of these, then we have a choice to not buy them. You can go with the JBoss (free), JRun (MUCH less expensive than most), and others. Options, Options, Options!

    One other thing that I only saw once brought up are frameworks. How many equivelant STRUT (from Apache), Cocoon (also from Apache), Resin's XTP (XML Template Pages), Gemstone's PCA, and other such frameworks/Products do you see in the Microsoft world? Not to say they can't be done, but they are not as common (from my perspective). Does that make J2EE better? No, just more flexible in my view.

    The point of SOAP vs. IIOP is almost a hilarious one. If .Net ONLY communicates via SOAP between all components, it sure isn't going to be fast! SOAP has it's place, IIOP has it's place, but I don't see them as competitors, just like EJB and WebServices don't compete, they complement.

    Just my .02

    Robert McIntosh
    The Middleware Company
  22. Re: My view...[ Go to top ]

    "One other thing that I only saw once brought up are frameworks. How many equivelant STRUT (from Apache), Cocoon also from Apache), Resin's XTP (XML Template Pages), Gemstone's PCA, and other such frameworks/Products do you see in the Microsoft world?"

    Dan,

    Zero. My point exactly. I think MS and MS integrators will eventually develop some now that there is CLR. However, Java far ahead in the interoperability layer currently.

    Java not only already has frameworks, but its frameworks are serious design efforts - OO design pattern based frameworks

    "Does that make J2EE better? No, just more flexible in my view."

    Flexible is very good though. If MS had continued to try to build .Net on top of IIS they wouldn't very far very fast.

    J2EE with JSP/Servlet is horizontally extensible with things like tag libs and vertically with beans. As you know, since you were a VB developer, MS has basically had the bean accessor methods concept for a long time - built in to the VB language. But Windows has lacked an object transport layer like IIOP to give Visual Studio products scalability and make the bean idea really work.

    I also agree with you that SOAP may not be very fast as a transport layer.

    Regards,


    Rich Katz


  23. Re: My view...[ Go to top ]

    Oops..that was to Robert.

    To Dan,

    "Yep, we know we have a problem. We'll fix it when the next release comes out in 3-6 months."

    That's why having more than one app server company, more than one framework is a good thing. By the way, what you're saying reminds me so much of what IBM used to say in the 1980's before they realized they weren't being competitive (with the Apple II, CP/M, VisiCalc and WordStar).

    Regards,

    Rich Katz
  24. It is worth noting that .Net hasn't been released yet. The thing that amuses me about this article is that Sessions speaks as if you could go out and develop using .Net today, but you simply can't. I would never call anything that is currently in Beta a 'mature' platform. COM+ is mature, however and simply a part of .Net.

    Related to this the TPC stats are certainly not using .Net technology but highly optimised C++ COM+ components. This has been long acknowledged by Microsoft. I would be certainly be surprised if it is even using ADO...my guess would be highly efficient native OLEDB database calls.



  25. The fall of Roger Sessions[ Go to top ]

    I think this "comparison" is a sad example of how deeply Roger Sessions has fallen for the latest time.

    I have read "Object Watch" for some time and always, although I have not agreed, thought him to make sensible critique against the J2EE-platform.

    This "comparison"'s total lack of objectivity is saddening.

    Comparing J2EE to .NET which has not even been delivered. And, really, web-services not much more than just a hype.
  26. I am interested in reading GIGA's article published under the title "Roger Sessions' Comparison is totally flawed".
    Can you provide me with a valid URL?

    Thanks!