J2EE vs. Microsoft.NET: A comparison of building web services


News: J2EE vs. Microsoft.NET: A comparison of building web services

  1. In this whitepaper, we will make a powerful comparison between the two choices that businesses have for building XML-based web services: the Java 2 Platform, Enterprise Edition (J2EE), built by Sun Microsystems and other industry players, and Microsoft.NET 2 , built by Microsoft Corporation. After reading this white paper, you will have a solid understanding of how these architectures compare, and be empowered to make intelligent decisions in new web services initiatives

    Read White Paper

    Threaded Messages (36)

  2. This document is totally pro for J2EE. This document simply point outs the Adventages of Java Plotform against .NET. So it is clear that, authors intention not to compare but to
    promote J2EE.
    >>>1. We promise to compare these choices at a logical, neutral, and unbiased level.
    This document is totally biased. Front page itself says, it is prepared for Sun micro System.
       The way they compared is good. but,In each comparision, they r promoting J2EE. ofcourse,J2EE is wonderful architecture.
    >>>Microsoft for doing the best job in hyping their platform--so far.
       This is true. Microsoft is the Best in marketing. But .NET has stuff and recently
    Microsoft announced to provide a linux compatable .NET version. So we should not take it easy.

      Document gave much importance to JCA. But JCA is not fully metured/implemented by all vendors.

    >>>Java, which is better than C# due to market-share and maturity.
    On which basis this statement made is un known.

        Before borning itself, .NET giving a tuf fight with J2EE. Once M$ introducted .NET for
    other plotforms like linux, that will be interesting.
        Only 'PLOT FORM INDEPENDENCE' is THE BEST/FIRST adventage of Java plotform.
    its is not J2EE Vs .NET. It is
    any how its an interesting article.
  3. No question about it, any article by Ed Roman is definetly going to be biased towards j2ee. But most of what he says is pretty acurate. M$ insists on doing it there own way, how sad, if they did java properly they would probably have the best dev tools out there. .net on linux? hmmmmm... that might be interesting.
  4. Can you be more specific of where the bias is? My intention was not to make it biased.
  5. Sources of bias[ Go to top ]

    Overall a pretty comprehensive article and an interesting read.

    Areas which appear to show bias:
    - Market perception: dismisses Microsoft marketing as "hype" which means "exaggerated claims" or "deliberately misleading". Probably best to use a softer term if one does not want to present a bias.
    - Maturity of Platform: Should probably consider that Microsoft has the excellent argument in that their platform can leverage existing server platforms within .NET and thus parts of the arch. are mature, i.e. MTS.
    - Skills transfer: argument applies equally well to C# as to Java when hiring a new skillset
    - Scalability: it is simply too trivial to say that a "multitude of machines may be difficult for organizations to maintain" since J2EE solutions are also using parallel architectures for scalability.

    One very important point I don't think gets hammered home enough is that:
    Developing Enterprise-class applications/ web services / components requires significantly more design and engineering effort than a smaller scale piece of code. This means a) more cost, b) need experienced developers, and c) previously built components will probably need to be refactored and thoroughly tested. Thus the migration is going to be expensive regardless of the technology.

    Another important point not explicitly addressed: .NET introduces a component management and deployment strategy which is still lacking in vendor's J2EE solutions. I burn a lot of my time trying to get EJB's etc to work with different vendor products and many products don't support live updates or component versioning.

    I think it is becoming clear that the .NET solution, leveraging IT resources, Windows XP, exising tools etc, is going to make it cheaper and easier to take your application to market. But this may not play as well for the high-end enterprise systems which traditionally are not so sensitive to price; companies will pay for ability to scale to "big iron" and gain the advantages of reliability, manageability, availability, etc.

    The bonus is that when web services are commonly implemented it will be quite simple to implement architectures mixed between .NET and J2EE. Won't that be fun!
  6. In writing the "J2EE vs. Microsoft .NET" whitepaper, Ed and I focused diligently on providing an unbiased perspective. I am quite interested in both platforms. Any "bias" in the paper may be (at least I hope) the result of an educated perspective in which the J2EE offers a "better" approach to building and deploying web services in most, but not all, cases.

    Chad Vawter
  7. Hi,

    I think it is not proper to say that the document is biased. If the document is biased it should contain any CONS of J2EE but it does as mentionned below.

    <B>Arguments for .NET and against J2EE
    &#8226; .NET has Microsoft's A-team marketing it
    &#8226; .NET released their web services story before J2EE did, and thus has some mind-share
    &#8226; .NET has a better story for shared context today than J2EE
    &#8226; .NET has an awesome tool story with Visual Studio.NET
    &#8226; .NET has a simpler programming model, enabling rank-and-file developers to be productive
    without shooting themselves in the foot
    &#8226; .NET gives you language neutrality when developing new eBusiness applications, whereas J2EE
    makes you treat other languages as separate applications
    &#8226; .NET benefits from being strongly interweaved with the underlying operating system

    What ever Ed Roman talks about J2EE are true. The document gives a clear idea of what platform to choose.
    <B>In my personal opinion the document is neutral.</B>

  8. ertfrdtgsd
  9. Overall a well formed (no pun intended) paper.

    Platform costs and tool quality were mentioned but not given enough weight in my opinion.

    MS has consistently had far better tools and has been much cheaper. Price will play a major role as it always has.

    MS has always done a good job in integrating their tools also. It makes it much easier for more junior developers to be productive.

    That said, given my druthers I'd choose J2EE. But it's my customers who drive the decision (based mostly on price).

    And why-o-why can't MS include Java as a CLR language? Is it simply egos or is it licensing or what? It's hairpulling!
  10. There seems to be a widespread assumption that J2EE is incredibly expensive. While Solaris + Web(Logic/Sphere) + Oracle is going to cost a huge amount of money, Linux + JBOSS + PostgreSQL is free/open source. While JDK is not "free" in the open source or free software sense, you can use it without paying anything. So you can actually deploy a J2EE application without paying a single $ in software licensing. JBOSS & PostgreSQL don't currently support clustering, so you may not have the scalability that .NET or the commercial appservers provide. Anyway, my take is that if you really need the scalability clustering gives you, you can probably afford the more expensive J2EE solutions as well. And for really high end stuff, commercial UNIX iron + J2EE + Oracle is more scalable than MS .NET anyway, imho.
  11. "While Solaris + Web(Logic/Sphere) + Oracle is going to cost a huge amount of money, Linux + JBOSS + PostgreSQL is free/open source. "

    That is quite true but the flip side is the ease-of-use (I am currently working on a small project using JBoss and MySql - not too bad!). MS tools/technology are easy to use and cheap. JBoss is not going to be easy for many, the tools are cryptic if existent at all.

  12. Note that Linux + Apache + Tomcat + (JBoss) or (Jrun) is
    a relatively inexpensive scaleable solution.

    If you need to have load balancing and the like you can
    always get weblogic or websphere with some minor configuration changes.
  13. Note that Linux + Apache + Tomcat +

    > (JBoss) or (Jrun) is
    > a relatively inexpensive scaleable solution.

    None of these application servers support clustering, I wouldn't call them scalable.
  14. None of these application servers support clustering, I >wouldn't call them scalable.

    JRun 3.0/3.1 Enterprise provides clustering, loadbalancing and failover support via its ClusterCATS technology. That sounds scalable to me. ;)

    JRun 3.0/3.1 Enterprise prices around $4995 / CPU with volume discounts available (so I've been told from a Macromedia/Allaire sales rep).

    JRun 3.1 is an attractive offering ... and its pricing makes it competitive with the .NET equivalent.
  15. I don't meet many enterprise clients who have settled on this kind of infrastructure. They've either gone J2EE (with Websphere or Weblogic) or Microsoft (DNA, now looking at .NET).

    JBoss doesn't support clustering...and in general, I hate to say it, enterprise clients are not going to bet their middleware application on open-source (that's just my opinion - you can make an arguement about Apache). They may with something like Linux because it has support from large established companies. JBoss does not have this (yet).

    That said, I'll get on my soapbox again (no pun intended): the cost of the J2EE application servers is too high. At $10k per CPU, the .NET solution is very attractive if only because of price. Windows 2000 Advanced Server is $4k + $2k (Internet connector) = $6k per box with any number of CPUs. For a 2 CPU box running Weblogic, you're looking at $20k for the license.....not very easy to scale!

  16. Windows boxes are certainly more affordable than their Unix-oriented counterparts. Keep in mind, though, that machines running Unix typically offer support for more processors thereby keeping processing power within fewer machines. Fewer machines equates to a lower cost of system administration and fewer points of failure.

    You'll notice that in pages 21-22 of the whitepaper that Ed and I discuss the "system cost" or "total" cost of ownership of an enterprise architecture and its dependent applications. Consider the following expenses:

      1. Enterprise software architecture
      2. Enterprise hardware architecture
      3. Code maintenance costs
      4. System administration costs
      5. Development costs (including training needs)


    While 20K per CPU may seem expensive, that 20K will be dwarfed in a large-scale project by the cost of the developers working on the project. Large-scale deployments will need CPUs to accomodate, and those CPUs can be colocated or spread across many PCs which are constrained in terms of support for multiple CPUs.

    If your system is not a large-scale system then you are likely to not need the fully-featured and most expensive J2EE solution. Go with a smaller vendor who offers a less expensive solution. Ultimately, you get what you pay for. If you don't need a 20K solution then don't buy one.

    Application server expense is important but only a fraction of total cost of ownership.

  17. My point is that *all* the "real" vendors of J2EE application servers are priced similarly. So, your idea of "going for the cheaper solution" is fine - as long as you don't need the functionality.

    As far as the 20k per CPU dwarfing the cost of development, I don't believe that to be true in large scale deployments. 100 servers x 2 CPUs per server = 200 CPUs x $10k per CPU software cost = $2 million in software licenses.

    Management might be slightly easier, but you pay through the nose for those boxes. I've got a friend who's working on a large deployment - J2EE wouldn't be possible for him to deploy and still make margin on his transactions.

    As for big iron verses horizontal scaling (basically cost verses management headache), I'll take more smaller boxes than one big one any day - but hey, that's just my opinion. Obviously, every situation is unique!

  18. Look out here comes JBoss 3.0 with clustering. What does that mean for BEA et al.
  19. JBoss 3.0 to support clustering[ Go to top ]

    Considering that development on JBoss 3.0 hasn't started yet, it means we're all going to have to wait before we find out :-)

  20. Well, even if this article is a little biased, at least it counters the pro-Microsoft .Net vs. J2EE article posted here by Roger Sessions a little while ago. Ed Roman runs a J2EE consulting company (the MiddleWare Company) and Roger Sessions works for a Microsoft Solution Provider (ObjectWatch) so you can see where these authors would get their bias. Reading both of these articles might provide the most objective insight into each technology (since one is pro-J2EE and the other is pro-.Net). As for my 2 cents, I like to be able to choose best of breed products from numerous vendors so I'll take J2EE any day.
  21. I just finished reading the whole article. I thought it was a completely fair and balanced article which acurately portrayed the pros and cons of each side. In no way would I consider it to be biased.
  22. Here are some examples of the inaccurate statements in this paper:

    1. J2EE has been extended to support web services.

       Maybe this is a nit, but this is not really true as stated. J2EE has not been extended. This may happen in J2EE 1.4 (JSR 153?). Granted, there are numerous Java-based web services toolkits. Many of them are "unsupported" at this time (WebServices on BEA?)

    2. .NET replaces COM+, MSMQ, and other pieces of Microsoft's stack.

       Not true. The .NET Framework, including the languages like C# and VB.NET, replaces VC and the VC runtime, as well as VB and the VB runtime. But COM+ and MSMQ remain, everything else remains.

    3. MSIL is interpreted.

       Not true, MSIL is never interpreted, at least not with tools shipped in the .NET SDK. MSIL is always compiled into native executable code. Options: JIT or pre-compiled. There is no interpretation.

    4. .NET lacks features such as programmatic transactions,
       session state management, page caching, custom tags.

       None of this is true. All are provided in .NET. On custom tags, in addition to providing a toolkit for building tags, .NET provides a library of over 40 deployable custom tags, featuring intelligent device-dependent rendering. These are real tags, not just a specification for how to build them (as with J2EE). The authors fail to note this important point.

    5. .NET doesn't or won't support standards.

       This is false. .NET supports SOAP 1.1, WSDL 1.0, XML 1.0 including DOM Level 2, and XML standards such as Schema, Namespaces, and XPath. Certainly .NET proposes new technologies beyond the standards. For example, the BizTalk framework covers an area where the standards are not ready.

    6. JCA is a strength of J2EE systems.

       JCA is just-approved, everyone is talking about it but no one is doing it. On the other hand, Web Services appear to be the preferred method for integration and interop, in lieu of the tightly-coupled model proposed by JCA.

    With basic, fundamental errors such as these, and incomplete treatement of technical topics, I have to ask, are the authors just plain biased? or innocently uninformed?

    The note on the front of the paper, indicating that Sun paid for the paper, makes it pretty clear to me which of those conclusions is true.

    But bias or not, either way, the analysis is of low value.

  23. The authors state that .Net is multilangual whereas J2EE is Java only. This is what most people think but this it not true! It is true that SUN only supports/develops Java on the Java virtual machine (and hence the J2EE platform) but other people have written compilers for other languages than Java that compile to Java Byte code. The best known example is Jython (previously called JPython)(www.jython.org) but there are many others as well see for example http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

    So J2EE is quite capable of support MANY (in fact there already much more (~130) for J2EE than .Net languages with a common runtime environment (=the JVM) like .Net

    Steven Sagaert
  24. Technical reasoning fails in the real world when it comes to comparison of product X with the Microsoft product. Only business and marketing reasoning survives.

    So, it does not matter how many languages can be compiled into java byte codes. What does matter is that .NET runtime will be built into EVERY installation of Windows. And later versions of MS Office will require it. So network effect will prevail again...


  25. I would like to make a comment about the tools / support for the two technologies. I think this is a section that could be expanded upon in the comparison.

    In particular, many CIOs view .NET developers as cheaper resources than J2EE resources -- whether or not this is really true. This perception exists because Microsoft classifies anything coding related as .NET. For example, if you write a macro for Excel, you are a .NET developer.

    Marketing will ultimately have an impact on the market shares for these two platforms. Something that J2EE needs to do better to overcome is this perception by executives that J2EE developers are more expensive. Evangelizing to companies the differences between doing application extensions versus true e-business development across the enterprise is important for the long term viability of J2EE. When it gets down to it, a .NET developer who can develop with the full range of Microsoft technologies and a core J2EE developer cost the same -- but if companies don't think that, many will migrate to the solution that saves them fixed and personnel costs.

    Evangelist, BEA
  26. To qoute Larry Ellison,

    "Good marketing, mediocre product beats good product, mediocre marketing any day."

    Unfortunately I agree with him, and see this as the most important advantage MS .Net has over J2EE
  27. Although you can cross-compile some languages like Python into java byte code, that is not really widespread, nor is it the issue here.

    Increasingly integration depends on cross-platform interfacing, not language uniformity. This is the basis for multilingual support within .NET and should also enable multilingual systems across .NET to J2EE and reverse.

    As such it is critical that Sun, IBM, Oracle, and M$ enable smooth interoperability of web services built and hosted by their various products. So far that seems to be the case, although untangling cross-platform SOAP support can be challenging. This is due to the newness of the platforms, not vendor malice as far as I can tell.

    Anyway, provided this interoperability at the component interface layer exists for real, the issue of language should become moot except for high-performance tightly coupled processes that cannot afford the SOAP bridge. These should be in the minority, and can be managed as a separate issue.

  28. Java - a multi-language platform?[ Go to top ]

    Come on, you all know that Java binds the language to the platform. It's just not true that there are over 130 languages supported on the Java runtime, or 130 languages that can compile to java bytecode.

    The link referenced above, http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html, may have 133 links, but they are not all languages. Many of them are dead links. Few are actual compilers that produce Java bytecode (Roger Sessions says 8). Two of the "real compilers" are Ada compilers. Mmmm, how interesting. JPython is the most interesting example, but not (yet?) commercially viable.

    The real truth is that, today, Java is a one-language platform. Sun is not investing in any other languages. I'm not passing judgement, but that is the fact of the matter. On the other hand, Microsoft is investing in support for multiple languages in .NET, now even Java. (See thread 9470, Microsoft to release Java version of .NET, which should really say "Microsoft to release a .NET version of Java")

    Another note - traditionally languages have brought along their own runtimes or class lib support (look at C's stdlib or the Java base classes, or the VB runtime). But .NET implies the .NET framework, a common class lib. So support a language on .NET means adopting a bunch of new classes, and some other baggage (CLI). The language is no longer pure. For example, VB.NET is different than VB. And Perl.NET is different than plain vanilla Perl. [yes, Perl is a real .NET language]. And J# does not get JDK1.3, it gets the .NET Framework. Again, I'm not passing judgement, just stating facts.

    By the way, if you want Microsoft's view on how the CLR/CLI and JVM tackle the problem of multi-language support (and others), check out this paper: CLR.pdf by Erik Meijer.

  29. Good ad for J2EE[ Go to top ]

    The author knows really well J2EE, but seems to lack information about .NET, and in a more general way, Microsoft platform.

    As a conclusion, he writes : "Only J2EE lets you deploy web services today". This is totally false. You can deploy web services with the Beta 1 of Visual Studio.NET (which actually is only beta), but you can also deploy it with the Soap Toolkit for Visual Studio 6, released a few months ago.

    This is just an example of how the author is sometimes wrong, just because he does not know enough MS Platform. When he does not know if something exists on MS platform, he assumes it does not.

    Maybe (as someone else proposed) Ed Roman should write a white paper with someone like Roger Sessions. Together, they would write an interesting and as unbiased as possible white paper.

    My 2 cents,

  30. Good ad for J2EE[ Go to top ]

    To me, 'deploy' means go-live. Would you seriously consider going live on a mission-critical system until Microsoft GA's the final product?
  31. Good ad for J2EE[ Go to top ]

    With out .NET (VS.NET and CLR) we can deploy mission-critical web services using SOAP 2.0, Visual Basic 6.0.

    Here is a scalable, reliable, secure site implementation created using SOAP 2.0, Visual Basic 6.0 and C++. We can see so many other reference implementations from msdn.

  32. Good ad for J2EE[ Go to top ]

    Microsoft certainly has first-mover advantage with web services. Interestingly, though, web services built with Visual Basic 6.0 are rendered legacy code by the CLR. The future of MS development is .NET which has the CLR as its foundation. Web services built with VB 6.0 instead of VB.NET will not have all of the runtime benefits of the CLR such as exception handling (and the code robustness afforded by it), seamless interaction with .NET components running with the CLR, etc.

    VB 6.0 code can be transitioned into the CLR by recoding it with VB.NET. VB.NET is dependent upon the data types of the Common Type System (CTS), though, some of which differ from the data types available with VB 6.0. The VB 6.0 code will be likely to break when compiled as VB.NET code. VB.NET also has more support for object-orientatation which is an unfamiliar paradigm for most VB developers. In summary, migration of web service implementations from VB 6.0 to VB.NET will be cumbersome.
  33. Like it has been said before the SOAP toolkit (no .net or anything) has been available for a very long web-time now. Giving automated ASP listener pages, ROPE for proxy objects etc. The latest toolkit is much better, but this is not new stuff to bog-standard VStudio 6 developers. Yes, deployable too.
  34. The discussion of both paper and this thread are all certainly interesting.

    While developers of both camps are defensing their platform of choice ("platform of experience" to be more accurate), many of us simply know that this is the beginning of the competition (well, arguably). By and large, we as application developers/technologists should put our focus on constructive comparisons and our efforts in pushing whatever platform into the right direction of evlolution. Unless you are in middleware business :)

    One addtional thought. The cost factor would likely change during the course of competition. (It's certainly to become a justifying factor for J2EE today, though.) However, the platform factor would NOT, or at least NOT LIKELY. So, yeah, I have my attachment, too. :)
  35. The comparison can't see the forest for the trees. Fact is J2EE is a very limited framework technology. Its like the authors are comparing an raw engine on a test harness with a fully functional car. The J2EE framework is just a skeleton with no services. Major product offerings like Exchange 2000, with world wide file distribution/replication are essential for shared collaboration, and can be used within the MS.Net framework as prebuilt services (and there are numerous other integrated services within the MS.Net framework you don't have to build yourself). In comparison, J2EE is service poor.

    In addition, the existing/vaporware offerings such as connector, jsp+, etc., are fairly mature in the MS.Net world. MS.Net is simply ahead of J2EE, and Sun will be playing catchup for years.

    ASP.Net rocks, Sun trys to play catch up. The J2EE transparent transaction approach has been available in MTS/COM+ for years. The "connector" type technology has been available for years with MTS/COM+ resource dispensers and managers. Transparent transaction distribution across mutiple J2EE vendors doesn't seem likely, but no problem on MS.Net. MS.Net web service protocols *will* revolutionize web services. The interoperability requirement is real - Java is and will always be a minority language. Java language interop is horrible. [only my java] language bigotry is not the way to work with others. The Java development tools are primitive, and quite frankly intolerable if you are spoiled by MS dev tools.

    The reality is that J2EE is a lowest common denominator approach, and the primary Sun objective is to sell big mainframe hardware.

    Sun would be better served by seeking interoperability with Microsoft, and opening a strong technical cooperative dialog between SM and BG.

  36. I'd like to underline two very important J2ee advantages that authors did not mention in their paper:

    1. Many (if not most of) Fortune 500 (and many other corporations for that matter) have already embraced Java and J2EE as their strategic enterprise platform. Also, many of them already have a very positive experience with the pre-j2ee middleware and db vendors that currently ship j2ee implementations (IBM, BEA, IONA, GemStone, Oracle, ..). Enterprises care a lot about reliablity and predictability and unlike many of its competitors Microsoft is neither reliable or predictable.

    2. With regards to the previous point (predictability in particular), during the past decade Microsoft has demonstrated a very unnatural and inconsistent progress curve saturated with very short life technology strategies. COM, COM+, DCOM, DNA were all short sighted, not as much in technology sense as in the sense of the company strategy. Who can tell (guess) how long it'll take .NET to get thrown by another (backward incompatible or semi-compatible) technology. It seems to me as if MS is spending enormous amounts of money trying to find itself in the enterprise market (rather unsuccessfully so far). This kind of immature behavior is something enterprises (conservative by nature about their investments) simply cannot consider as an option.

    With regards to price and developer interest, I think MS is going to attract one great deal of developer audiance (especially young and inexperienced developers). MS tools are typically easy to install and use and this is a clear advantage over any J2ee product. Price does count and it'll certainly help MS create a huge army of potentially professional developers. In the end this may turn out as a very smart move unless, of course, MS overrides .NET with yet another platform (as previously mentioned).

    My guess is that enterprises will continue to rely on UNIX/j2ee while there will be a lot of small development efforts concentrated on .NET. Hopefully, j2ee vendors will learn their lessons and cut the prices significantly as well as introduce tools that are more intuitive, more comprehensive and easier to use.

    My 2c worth.

  37. Nice article, but I have some issues.
    I played around with J# and I found out that I needed the J# redistributable to deploy J# applications. Why is that? If VS.NET compiles to IL, then we should need only the CLR on the deployment machine ? Can anybody help me on this ?