Home

News: J2EE claimed to have better Web Services performance than .NET

  1. Sun has released a white paper which aims to compare the Web Services performance of J2EE and .NET. They claim that in all of their tested cases J2EE outperformed .NET. In some cases J2EE offers 2-3X better Web Services performance than .NET. The usual disclaimer on benchmarks applies: test it for yourself.

    Introduction
    Web services are Web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients. Web services are becoming the most important technology for communications between disparate applications in different enterprises. Even within an enterprise, web services are fast becoming a de facto standard as more applications use XML to communicate and store data.

    As web services deployments go mainstream, it is important for organizations to understand the features and performance of the implementations of this technology in various product offerings.

    In this paper, we consider the performance of web service technologies in the two primary middleware platforms today: J2EE and .NET. Both, the J2EE platform and .NET framework offer similar facilities for creating and using web services. We consider a basic web service method that is called with different types and sizes of arguments in both platforms and compare its performance.
    Read the white paper:
    http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf
  2. J2SE, not J2EE[ Go to top ]

    Interesting, in that the whitepaper shows that the testing was done with J2SE 1.4.2 and JWSDP 1.3 with Tomcat 5 as the Web server. There was no J2EE application server in the mix.
  3. J2SE, not J2EE[ Go to top ]

    Interesting, in that the whitepaper shows that the testing was done with J2SE 1.4.2 and JWSDP 1.3 with Tomcat 5 as the Web server. There was no J2EE application server in the mix.
    Its Exactly J2ee webservice Comparesion with .Net Webservice comparesion not j2se vs .net.
    JWSDP contain required WS Library and tools for servicing JWS (JAX APIs , Java WSDP Registry Serve ,...).
  4. J2SE, not J2EE[ Go to top ]

    Interesting, in that the whitepaper shows that the testing was done with J2SE 1.4.2 and JWSDP 1.3 with Tomcat 5 as the Web server. There was no J2EE application server in the mix.
    Last time I checked JSPs and servlets were in the J2EE spec (J2EE > EJB).

    p.s. Not meant as a flame.

    But like others said in this thread, I'm missing some major points in this publication, among others the source code.

    The way it looks now it's another completely useless publication, don't you just love the marketing blur? :-)
  5. Even Java XML-RPC could outperform .NET it does not change fact that XML-RPC is 50 times slower (in my tests year and a half ago) than binary potocols( CORBA ).
    Even within an enterprise, web services are fast becoming a de facto standard as more applications use XML to communicate and store data.
    Nice way to justify spendings on more powerful hardware...
  6. Even Java XML-RPC could outperform .NET it does not change fact that XML-RPC is 50 times slower (in my tests year and a half ago) than binary potocols( CORBA ).
    Crazy, isn't it? We have two in-house Java systems that are communicating via SOAP Web Services. As far as I can tell, the web services code is as complicated as EJB (stubs, skeletons, etc).
  7. As far as I can tell, the web services code is as complicated as EJB (stubs, skeletons, etc).
    Exactly!
    Well, IMO RMI was/is a huge mistake and should go away.
    But all RPC technologies are (equally ?) easy with tools.
    IDL->idl compiler-> plumbing code was working reliably long time before WS arrived and provided many features which WS stack still lacks ( security context propagation for instance).
    (Java Source -> Xdoclet -> plumbing code works very well too )
    Now we have WSDL->wsdl compiler -> plumbing code that works slow and inefficient. What is the point?
  8. The point is...[ Go to top ]

    interoperability between platforms and vendors (CORBA never achieved this), standardization on a software protocol, and right-sizing the granularity by moving to a document-centric data format (XML). These features enable re-purposing of component services and business processes into larger, more complex processes via BPML and BPEL.

    Web Services/SOA are a simplification of other serivce-oriented approaches. I can't stand when people overlook this and say, "we were doing this 10 years ago...". Yeah, and it sucked.
  9. The point is...[ Go to top ]

    Just for comparison, some other "neutral" reports: ;-)

    http://www.gotdotnet.com/team/compare/default.aspx

    Regards.
    Robert
  10. The point is...[ Go to top ]

    interoperability between platforms and vendors (CORBA never achieved this)
    Really? Well, that was a biggest mistake that initially CORBA spec did not specify wire protocol (IMO under pressure from vendors to allow them locking customers), but later that was addressed.
    standardization on a software protocol,
    Not sure what you mean by that. There is a whole bunch of protocols: wire level and above…
    and right-sizing the granularity by moving to a document-centric data format (XML).
    Document centric approach to RPC (SOAP) is a right-sized solution - I am afraid that is news for me!
    These features enable re-purposing of component services and business processes into larger, more complex processes via BPML and BPEL.Web Services/SOA are a simplification of other service-oriented approaches.
    There are some merits in Document oriented SOA, and it should be used in a certain cases, however it has almost nothing to do with low-level system-to system RPC.
    I can't stand when people overlook this and say, "we were doing this 10 years ago...". Yeah, and it sucked.
    In many cases they really did exactly what we do now and even better.
    But that ignorance of the past is in line with general path of evolution, which is a spiral by the way.
    Some solutions seem suck because of lack of understanding, and they start looking like “right-size” approach and reasonable compromise when developers really comprehend that problem domain....

    Cheers to all Spiral-Men
  11. Cheers.

    Tuning windows to its almost best performance options means that it is a fair comparesion.
    Tomcat is defacto servlet container which perform very good , but its opensource and free in this case Im wondering when tomcat as a opensource project could perform better in comparesion ,
    how would top quality commerical products will be in compete?

    Sun Microsystem did great job , but where are the source code for download ?
    I want check it myself and watch .net lagging.

    To be at peace
    Masoud Kalali
  12. Masoud: "but where are the source code for download ?"

    That reminds me of how Oracel claimed that their optimized Pet Store had 18 times better performance than .NET! Using just half the resources too :) From being 28 times slower to 18 times faster, 504 times faster than the orginal just with some small tweaks..
    "We found that without caching, Oracle9iAS was up to 18 times faster than Microsoft .NET, while using just half the resources".
    http://otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf

    Of course no source code was released there either..

    Regards
    Rolf Tollerud
  13. The source would be nice[ Go to top ]

    I read the pdf and the IIS settings look OK. Having stress tested Win2003 server for XML performance, those numbers are in line with my own benchmark results. It's quite easy to show JWSDP is faster if you use DOM documents for the .NET webservices. Comparing RPC to document style isn't really a fair comparison for performance. It is a fair comparison of different styles of development, if the .NET developer follows Microsoft's recommendation and doesn't bother to optimize his applications for performance. That happens every where and isn't unique to Java or .NET.
  14. It's unimportance for me.
  15. As with any performance report, it would be interesting to know
    what is the bottleneck in each case, namely what are the CPU loads on
    the client and the server,
    the network usage, and which parts of the code are consuming cycles (profiling)