Arun Gupta, Miles to go ...

Arun Gupta is a technology enthusiast, a passionate runner, and a community guy who works for Sun Microsystems.

« Day 1 @ The Server... | Main | Day 3 @ The Server... »

Friday March 23, 2007

In the opening keynote of Day 2 (Day 1), Joe Ottinger, Editor-in-chief of TheServerSide, asked the following questions, to an audience of approx 500 Java developers, receiving instant feedback using little handy devices on each attendees table. As with any surveys, the data may be skewed because of multiple reasons (not all participating, voting twice, pressing the wrong key etc). But here are the questions and their answers:

Which languages do you use most often ?

I could not capture the exact percentage but the priority order is listed below. This being a Java conference, the percentage for Java developers is well expected.

Java	80%
C#
C/C++
Visual Basic
PHP
JavaScript

Which version of JavaEE API do you use ?

1.2	1%
1.3	4%
1.4	45%
5	36%
None	13%
1.1	1%

How do you call Remote services ?

RMI	21%
REST	1%
SOAP	46%
CORBA	5%
Other	17%
None	10%

I gave a talk on JAX-WS and WSIT: Tangoing with .NET yesterday and it went well. The two demos in the talk are also available as screencast in #ws1 and #ws3. I always leave time for Q&A and this time the discussions were way after the session was over. And I like it that way The key message is WSIT, available in GlassFish v2, gives you first-class interoperability with Microsoft .NET 3.0 framework and comes with fully integrated development experience in NetBeans 5.5.1 IDE.

I enjoyed a panel discussion on "Open Source Business Panel" and there were representatives from Alfresco, JBoss, SpikeSource, LifeRay, Interface21. The monetization model for all the participating companies was by selling professional services, technical support and training. Sun Java System Application Server (product version of GlassFish v2) offer training, services and support. Read Ed Ort's detailed summary of the session here.

I spent the afternoon with Joe Ottinger, Editor-in-chief of TheServerSide.com, deploying a trivial deployment-descriptor-free Web service on GlassFish v2. Basically we used the instructions as I described in an earlier entry. He was using GlassFish v2 b33 and was not able to get it working. On my laptop, with v2 b39, the service deployed easily. And even with b33 it worked. Anyway, Joe is going to install a fresh copy of b33 and try it. He also gave some good feedback in terms of how java.sun.com/webservices should be structured. We are already working on cleaning up the website and you'll see the changes in the weeks to come.

I spent the evening walking on the strip and took bunch of pictures.

Technorati: theserverside webservices wsit glassfish

Posted by Arun Gupta in webservices | Comments[6]

|
|

Comments:

Hi Arun, I attended your session the other day at TSSJS. I didn't have a chance to follow up with you immediately after the session though. I wanted to relay one comment. In your session you claimed 3-10x performance improvements when using FastInfoset. Thats not near the truth.

The original FI benchmark compared it to Xerces which is incredibly slow. I believe they have since updated some of their benchmarks. But in our benchmarks, which test a variety of documents, we've seen that FI is about 75% faster on the read side, and about 8% faster on the write side (these are the median scores). With GZip enabled, it is about 90% faster on the read side and -10% faster on the write side. Also, these factors do not include all the overhead that goes into web services such as databinding. So in essence you're probably looking at an improvement in the order of 30-40% when using FI with the JAX-WS RI.

(Unless you're using something like SXC, which can act as a JAXB runtime supplement to provide a compiled parser/writer for your JAXB context - see my blog for more info ;-))

Posted by Dan Diephouse on March 24, 2007 at 09:45 PM PDT #

[Trackback] In the opening keynote of last day (Day 1 & Day 2) of TheServerSide Java Symposium, Joe asked the following questions, to an audience of approx 500 Java developers, receiving instant feedback. How  satisfied are you with Sun ? Very...

Posted by Arun Gupta's Blog on March 24, 2007 at 09:50 PM PDT #

Dan, I'd agree with you that Xerces isn't fast, but it is the most popular parser nonetheless. Can you explain a bit more what your benchmark is doing? Is it public? What parser are you comparing it against? As always performance will vary (mainly due to Amdahl's Law) but the numbers that you're getting are very low, so I suspect that your benchmark isn't comparable to ours. We have several customers reporting improvements in the X's, not just a few percentages.

Posted by Santiago Pericas-Geertsen on March 26, 2007 at 06:12 AM PDT #

They aren't public at the moment, but they use woodstox, not the SJSXP parser. I'm not sure about the relative performance between the two at the moment, but I know in the past Woodstox has been significantly faster than SJSXP and Xerces - on the order of 2-3x on average. Maybe that is the source of the discrepancy?

https://fi.dev.java.net/performance-reports/General/parse/report.html seems to confirm my suspicion that Xerces and ~SJSXP are approximately the same speed. I've been told by some in Sun that SJSXP has gotten faster recently, but I still haven't seen a proper benchmark against woodstox.

Posted by Dan Diephouse on March 26, 2007 at 06:18 AM PDT #

SJSXP has improved, especially on small messages. I don't have recent data, but I suspect that Woodstox may be faster on medium to large messages. Note that most of our FI benchmarks are based on the SAX API. For some strange reason, we never managed to make our StAX implementation as fast as our SAX one. Let us know when you make the benchmark available. It's much easier to have discussion when code is available for others to run. In a real-world system, not just a micro-benchmark, the bandwidth savings offered by FI can have a significant impact too. So, for many use cases, raw parsing performance is just one aspect of the equation.

Posted by Santiago Pericas-Geertsen on March 26, 2007 at 06:32 AM PDT #

For some strange reason, we never managed to make our StAX implementation as fast as our SAX one. Let us know when you make the benchmark available. It's much easier to have discussion when code is available for others to run. In a real-world system, not just a micro-benchmark, the bandwidth savings offered by FI can have a significant impact too. So, for many use cases, raw parsing performance is just one aspect of the equation.

Posted by BATTERY on November 27, 2008 at 05:20 PM PST #