Bharath Mundlapudi's Weblog: Bharath Mundlapudi's Weblog

I just thought about sharing how we did with our BOF on 'Meet the Java EE Performance Experts'. If are not aware of this BOF then read on. We have this BOF pretty much every year and very lively one. In this BOF, we share our experience in performance and at the same time we do receive audience experience. Usually, Java EE performance BOF starts after Java SE BOF and in the same room. Even though our performance BOF started pretty late, we were surprised to see good number of audience. So Thank you! Most of the questions were towards XML and Web Services performance. I am sure you might be aware that JAX-WS impl is highly efficient, faster and now part of Metro stack which comes with the GlassFish. Some questions popped out in general application server tuning and profiling. Overall, it went well. We hope to see you again next year with more information.

I love this subject. So here are my thoughts on this. I sometimes wonder why some best software engineers make design and interfaces very complex for an average user. May be, we feel proud sometimes by doing BIGO( POW(N,4) * 5 #### ... ) and presenting this to an user. The most complex job, i think, is making systems and user interfaces 'Simplistic'. IMO, This is one way to claim we are creative. Think outside the box and work inside the box.

JavaOne Talks:

Session ID	Session Title	Session Type	Date/Time	Venue/Room
BOF-6248	Meet the Java Platform, Enterprise Edition, Web 2.0 and ESB Performance Experts	Birds-of-a-Feather	Wednesday 05/06/2008 9:30 PM - 10:30 PM	Moscone Center - 102
BOF-2953	Implementing High-Performance Web Services With Next-Generation Java™ Technology APIs	Birds-of-a-Feather	Wednesday 05/17/2006 8:30 PM - 9:30 PM	Moscone Center - Hall E 135
BOF-9213	Writing Performant WSDLs to Build Enterprise Web Services Applications	Birds-of-a-Feather	Monday 06/27/2005 7:30 PM - 8:20 PM	Marriott Hotel/G. Gate A2

List of my contributions to technical articles, blog articles etc:

Date	Title	Role	Description
June, 2007	Performance Regression Testing Using Japex and WSTest, and Future Tips	Co-Author	Tracking performance regressions
February, 2007	JAX-WS 2.1 and Axis2 Performance Comparison	Technical Contributor	JAX-WS 2.1 and Axis2 Performance Comparison
August, 2006	Implementing High Performance Web Services Using JAX-WS 2.0	Author	JAX_RPC and JAX-WS performance comparison
December, 2005	Web Services on CoolThreads	Author	JAX-WS performance on CMTs
October, 2005	Java Web Services Performance	Technical Contributor	Java Web Services Performance - Analysis and Benefits of Fast Infoset
June, 2004	Web Services Performance	Technical Contributor	Web Services Performance - J2EE vs .NET
June, 2004	XML Performance	Technical Contributor	XML Performance - Java vs .NET

Welcome to Project SailFin! I will be looking into SIP Container Performance going forward. We are currently evaluating the benchmarks for tracking performance. Thanks for all the community support. We will keep you posted on our progress.

For more information on Project SailFin visit:
SailFin Announcements
SailFin Development
SIP Servlet Specification - JSR 289

You might have already heard the latest news... yes, JAX-WS 2.1 is avaliable for public and yes, you can download it from here and it will be part of Glassfish Beta.

So what's new in JAX-WS 2.1 anyway?

Simple answer would be - 'A lot of things are new'

1. Features
Well, you must read Vivek's blog about all the new features in JAX-WS 2.1. Jitu talks about the new asynchronous architecture which went in JAX-WS 2.1.
2. Performance
This is where things get interesting to you! For this release, we looked at the performance from bottom to top of the web services stack - from JVM to Glassfish application platform to StAX Parser to JAXB Binding to JAX-WS. Koshuke highlights some of his contributions to performance here and Santiago boosted the SJSXP StAX parser performance.

Here are some nitty-gritty details:
1. Expect performance boost in Java Reflection in the upcoming JDK releases, fixes already went into JDK, you will see this boost specifically in XML Binding.
2. Some synchronization and scalability fixes went in Glassfish for web services path. This should be available in Glassfish Beta.
3. StAX, JAXB & JAX-WS 2.1 Improvements
I think, you got to try it on your own benchmark/application to see the performance improvements for yourself. A lot of performance improvements went into this release. Our benchmarks show some stellar performance numbers. StAX/JAXB/JAX-WS Engineering team is amazing and a 'big thanks' to community for your suggestions and comments!
4. Axis2 vs JAX-WS 2.1 Performance
You can find all the details about the benchmark and comparison here.

We always welcome your comments and suggestions.

If you are using JAX-RPC 1.1 and planning to migrate to JAX-WS 2.0 or Thinking of using JAX-WS 2.0 for your projects then here is some good news. JAX-WS 2.0 performance is good and going in the direction you would want to see. If you want to know the nitty-gritty details then refer this article which talks in depth about the details.

Let us know your feedback on JAX-WS 2.0 stack.

In 4 easy steps you can host your static web pages up and running in GlassFish. At times, we only need static web pages in application servers. GlassFish makes this feature easy for you. So you can share your photos, media or information to others in an easy way.

Are you ready to explore GlassFish? Here you go...

Step1: Download and Install GlassFish
Get the instructions from here.

Step2: Copy your web pages into GlassFish
cp myworld [GlassFish]\domains\domain1\docroot\myworld

Step3: Start the GlassFish
[GlassFish]/bin/asadmin start-domain domain1

step4: Access your web pages... boom boom boom!
http://localhost:8080/myworld/index.htm



Got GlassFish?

Namespaces are ubiquitous and they wander in almost every XML document, SOAP message and WSDL you name it. Initially, namespaces seems confusing but once you understand its purpose then you will appreciate its power and flexibility. Namespaces plays a vital role in the WSDL design. To simply put, the basic purpose of namespace is to avoid element name conflicts in the XML documents. There are many other advantages with namespaces like readability, reusability, extendibility, version tractability and modularity. Let me walk you through these terms explaining its meaning and high lighting its usefulness in designing WSDLs efficiently.

Readability, Modularity & Reusability:

Namespaces allows clarity and readability to the XML document saying which elements falls under which modules and sort of reusing them by importing from other wsdls or other schemas.

Example:

Suppose we have a sun.xsd which contains the following:

<element name="sun">

<java/>

<solaris/>

<dtrace/>

...

</element>

And we have a microsoft.xsd which contains the following:

<element name="microsoft">

<vista/>

<c#/>

<java/>

...

</element>

If we want to access these two xsds in a xyz.xsd, then we have a conflict with java element!

<element name="xyz corp">

<solaris>

<vista/>

<c#/>

<java/> <!-- sun/microsoft java? -->

...

</element>

To avoid this, we can use namespaces as follows:

<element name="xyz corp" xmlns:sun="hhtp://www.sun.com" xmlns:msft="http://www.microsoft.com" ... >

<sun:solaris/>

<msft:vista/>

<msft:c#/>

<sun:java/> <!-- Now, this is clear here -->

...

</element>

Extendability:

Now, what's the relationship between xml namespaces and wsdl design. I will explain this in a bit. If you want to design wsdl's in modular and scalable way, namespaces is the way to go about it.

Consider for example, You have a supply chain management application which needs schemas like ubl-orders, ubl-invoice & ubl-shipments. The schemas for these business functions are complex. Each has its own elements and some might be in conflict with others etc.

One way to solve this problem is, we can embed all the schema elements in one huge gigantic wsdl file... like

<definition ...>

<schema>

<orders>

...

</orders>

<invoice>

...

</invoice>

<shipments>

...

</shipments>

</schema>

...

</definition>

Now, lets see the pros and cons for this type of design. This design we can call embedded schemas.

pros:

1. For smaller schemas, its easy to have all the schema elements in a single wsdl file.

2. All the elements in single namespace, so no confusion with namespaces, assuming no name conflicts.

cons:

1. Managing the wsdl document is difficult if the complexity of the schema increases like if we want to add more modules etc.

2. In web services world, schemas come from different parties, so name conflicts will occur.

3. Doesn't scale (physically like file size etc) well.

Lets see the other way to solve this problem by importing the schemas.

We can define 3 schemas like orders.xsd, invoice.xsd and shipment.xsd with respective schema elements and we can efficiently import these into the wsdl. This way, we know which elements belongs to which xsd and easy to read the wsdl. Also gives us a good room for scaling with some more xsds.

<definition ...>

<schema>

<import namespace=”...” schemalocation=”orders.xsd”>

<import namespace=”...” schemalocation=”invoice.xsd”>

<import namespace=”...” schemalocation=”shipment.xsd”>

...

</schema>

...

</definition>

As you can see this reduces the size of your wsdl drastically depending on your complexity of your schema elements and provides a cleaner way to expand your wsdls.

pros:

1. Scales well and managing is easy as the document complexity increases.

2. No name conflicts since each imported xsd has its own namespace.

3. Cleaner design

cons:

1. Reading elements with multiple namespaces is tedious.

Version Tracking:

Well, everyone might have come across supporting multiple versions of software products or providing a backward compatibility with the previous versions. There are couple of ways to do it using namespaces either by embedded schemas or importing schemas and by changing the version numbers in the namespace declarations.

Example:

1. The following example shows version tracking by embedding the schemas.

<definition ...>

<schema xmlns:inv_v1=”http://www.sun.com/invoice/v1.0”

xmlns:inv_v2=”http://www.sun.com/invoice/v2.0”>

<element name=”invoicev1” types=”inv_v1:Invoice”>

<element name=”invoicev2” types=”inv_v2:Invoice”>

</schema>

...

<definition ...>

2. The following example shows version tracking by importing the schemas.

<definition ...>

<schema>

<import namespace=”http://www.sun.com/invoice/v1.0”

schemalocation=”invoice_v1.xsd”>

<import namespace=”http://www.sun.com/invoice/v2.0”

schemalocation=”invoice_v2.xsd”>

...

</schema>

...

</definition>

We are excited to present you all the performance facts about 'Next-Generation Java Web Services APIs' a.k.a JAX-WS 2.0. We want to save your energy, time and money by presenting all the performance results we have been seeing in our lab. We will present you what works and what doesn't, right way to implement for performance and many more...

Title: Implementing High-Performance Web Services With Next-Generation Java Technology APIs
Speakers: Santiago Pericas-Geertsen, Sameer Tyagi & myself

Take away points from this presentation are:

1. JAX-RPC 1.1 vs JAX-WS 2.0 Performance
2. Binding Performance (JAXB & DOM)
3. MTOM vs XML vs Fast Infoset Performance
4. Secured vs Non-Secured message performance
5. SSL vs Message level Security
6. RESTFul vs JAX-WS Services
7. XML & Web Services Security
8. JAX-WS vertical scalability on CMTs

so see you all @ java one.

Ever wondered what each thread in the GlassFish is doing at any given point of time? Or Do you want to see where the objects are getting locked? Or Do you want to analyze the deadlock situation? Well, taking the snapshot of thread state (i.e. thread dumps) will help you in all these circumstances.

Lets see what are the different ways we can achieve this on GlassFish.

1. The Traditional Way
This is well known in the java community, i.e. sending kill -SIGQUIT [pid] (on solaris) or CTRL + BREAK (on windows) for the respective java process. This will dump the current stack trace of all the threads in the java process, in our case its GlassFish.

2. The Java SE Way
You know the answer. Yep, its the JConsole! Personally, I like the 'look and feel' of JConsole in Mustang (Jave SE 6) over Tiger (Java SE 5). Once you launch the Jconsole, you will be presented with the following connection setup screen.



Once you feed the {host,port} and {glassfish admin user , admin password}, you will be presented with the JConsole screen showing various monitoring stats like classes, memory, threads etc. If you click on the threads tab, you will be presented with the following screen showing stack trace for all the threads in the GlassFish.



3. The GlassFish Way
asadmin command line tool provides this nice feature to fetch the threads trace for a particular server instance you are interested in from a single point. Isn't it simple and convenient to have this information from a single location?

Here is the way to invoke it:



This will result in thread dump of the GlassFish, which look like the following:



I hope this information is useful for you. If you want to profile your application on glassfish then here is the nice read about the profiling tools.

The first step in exploring the GlassFish is to get our hands dirty by actually installing it and seeing its ambiance. Get the latest GlassFish bits from here first. I will walk you through the installation process on Windows XP with JDK 1.5.0. Download the bits and try the following command to install the GlassFish.

Installation Process

Step1: Unpackage the downloaded bits

E:\downloads\glassfish>java -jar glassfish-installer-b35.jar Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Oops! Wait a sec, looks like the default heap space is not sufficient. So the obvious next step is to increase it.

Lets try with next minimum heap size of 64MB. Well, i would think still someone on the board hangs on with 128MB or less RAM machines at home. (Ofcourse, I am included in this one. But hey i just use for browsing)

E:\downloads\glassfish>java -Xmx64m -jar glassfish-installer-b35.jar Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Even this is not sufficient. so lets increase it to 65MB.

E:\downloads\glassfish>java -Xmx65m -jar glassfish-installer-b35.jar



Hurray! This works and you will landup with the license screen. Scroll down and accept it and here you go, GlassFish is successfully unpackaged on your machine!



The point here is that, I was just trying to figure out whats the minimum heap space required to install GlassFish on Windows XP and the answer is 65MB. But the GlassFish team recommends 256MB heap size. So you can try with this size (if you have memory) and you won't run into any hassle!

Step2: For complete installation, you need to run the setup on the unpackaged bits (Make sure your JAVA_HOME path is setup)



Finally, here is the first ocean view of the GlassFish ambiance after the successful installation.



I know, you are eager to get into the details of glassfish now. If you wanna explore more like how to start, deploy etc... your best bet is to start from here. Refer to the Aquarium Blog for the latest developments on the GlassFish.

Needless to say, Enjoy the GlassFish ride!

Welcome to my 'GlassFish' blog. GlassFish is the popular open source application server which implements the newest features in the Java EE platform. If you wanna hear the latest and the hottest gossip about the GlassFish then peek here!
Don't hesitate to contribute or provide your experiences both successes and failures (if any, so we can help you) with project . Moving forward, I will blog here, how to build, deploy, run and tune the web services applications on GlassFish.

The human brain is bifurcated down the middle into two parts, popularly known as the left brain and right brain respectively. We know that different parts of the brain control different bodily and mental functions.

People who use right half more: imaginative, intuitive and creative
People who use left half more: logical and analytical in their thinking

But this does not mean that a person who is left or right brain dominated does not use the other part of his brain. For most people, the two parts of the brain work in tandem to enable them to function as well-rounded personalities. Do you know which part of your brain you use more?
Worth knowing! Fun exercise for the new year. Wish you a very happy new year 2006!

      By now, You might have heard and seen class diagrams, sequence diagrams from UML/OOD/OOM blah blah... I just thought, whats the fun in doing same things you already know. So here i am with a WSTest (Web Services workload) Architecture from a creative perspective. I hope, you get the gist of it!

The following diagram illustrates the main components in the WSTest:



1. Configuration
    This component is responsible for reading the configuration from INI file.

2. Driver
    This is the main component which reads the configuration and controllers the Agents.

3. Agents
    Agent does what driver asked it to do, like what usecase to invoke, how long to run etc.

4. Reports
    Finally, this component generates the report for you, namely, average response time and transactions per second.    

I must tell you, I really like Star Office (For a number of reasons, talk for another day) and these cartoon images are from star office. Yea!

WSTest is a very simple and yet powerful benchmark to simulate the real world use cases for web services. For example, if you have an online bank system, which you have decided to implement using web services. At one point in time, you will start thinking about how many users this system can serve in a given moment? What is my peak system performance? How many transactions system can execute in a second ie. throughput? and the list goes on...The performance benchmarks answers these type of questions before your system goes to production. Isn't that information nice to have prior to going to production? Absolutely!

Lets see what WSTest can do for these requirements. First, Map your usecases into transactions.

Let T1 = User logs in to the online system = Login()
    T2 = Views the account summary = GetAccountSummary()
    T3 = Pay my bill = BillPay()
    T4 = User logs out of the online system = Logout()

Lets think for a moment and come up with a frequency for these usescases for a certian number of users.

T1 = 25%  (Meaning 25% of the time, users log into the system)
T2 = 40%  (Meaning 40% of the time, users view account summary)
T3 = 10%  (Meaning 10% of the time, users pay bills online)
T2 = 25%  (Meaning 25% of the time, users log out of the system)

We call this a 'Transaction Mix'. This is pretty much configurable based on your application preference in WSTest. Each agent  (which you can treat as an user in the real world) performs this mix for the predefined period and finally results are gathered in the report for the run.

Come, share and join our web services performance forum.