Are we there yet ? Sameer Tyagi's Blog Honesty is the best policy, but insanity is a better defense.

Tango performance

In a recent exercise in tracking performance with WSIT (aka Tango), our project to enable interoperability between the Java platform and Windows Communication Foundation (WCF), we noticed a significant regression in JAX-WS performance. Tango builds on top of JAX-WS with additional pipes.The rearchitected branch of JAX-WS has a notion of pipes - following the pipe and filter architectural style. Turns out a chunk of the regression was originating from one of the pipes creating a JAXB context for every request, rather than caching it. Kohsuke sent out an email to the Tango dev mailing list, that can be found here. These actually apply to all developers in general using JAX-WS and JAXB. Context creation and factory lookups are expensive operations and shouldnt be repeated , especially for every request !
( Jul 29 2006, 04:55:49 PM EDT ) Permalink Comments [0]

DWR and Web Services

JAX-WS services can be easily accessed via a browser using AJAX technologies like Direct Web Remoting(DWR) to enable client access. The PurchaseOrder web service example discussed previously can easily be accessed from web pages with some simple JavaScript. Simply wrap the service proxy in a JavaBean,include the DWR Jar and configuration file in the WAR and access the JavaBean object in the JavaScript. Details on how to conifgure DWR can be found in the article here For our example the web page looks like

<script type='text/javascript' src='/docliteralfromwsdl-war/dwr/interface/POServiceDAO.js'></script>
<script type='text/javascript' src='/docliteralfromwsdl-war/dwr/engine.js'></script>
<script type='text/javascript' src='/docliteralfromwsdl-war/dwr/util.js'></script>
<script>
  function createPO() {
    POServiceDAO.createPO(showPO);
  }
  function showPO(order){
   	document.getElementById("field1").innerHTML = DWRUtil.toDescriptiveString(order, 2);
   	sendPO(order);
    }
  function sendPO(order){
		 POServiceDAO.sendPO(showStatus,order);
  	}
  function showStatus(status) {
    document.getElementById("field2").innerHTML = status.timestamp ;
    document.getElementById("field3").innerHTML = status.orderid ;
  }
</script>

The full war modified from the previous example fan be downloaded here
The advantages of DWR in particualr is that the proxy is located on the server and is serialized via JavaScript to the client. So architecturally you can have services that are located in the DMZ or even backends that are not exposd to clients directly. The other advantage is performance, when the cilent proxy and service are colocated you can avoid the serialization over the wire and use the JAX-WS local transport. Ahh the possibilities !!

( Jul 24 2006, 12:54:18 PM EDT ) Permalink Comments [1]

Accelerating Java XML digital signature performance

If you are considering using XML Digital signatures in real world application, a recommened article for reading published by our group can be found here
( Jul 19 2006, 05:07:34 PM EDT ) Permalink Comments [0]

Accessing JAX-WS endpoints with Java WebStart

Java Web Start is a software distribution technology and can be used to distribute JAX-WS clients. Essentially one writes and deploys a JNLP file on the server. The example I will use is the one described in a previous entry here. You still need to sign the jar files to grant them security permissions and Java Web Start also works on a sandbox model. Here is the except of the JNLP file. Note that you can use either the applet-desc or application-desc tag depending on your code. We use the applet-desc since our previous example was an Applet jar. Also you dont need the JAX-WS runtime on the client if you use Java SE 6 or Mustang and set <j2se version="1.6+" />

<?xml version="1.0" encoding="utf-8"?>
 <jnlp spec="1.0+" codebase="http://localhost:8080" href="webstart.jnlp">
 <information>
 <title>JAX-WS WebStart Demo</title>
 <vendor>Sun Microsystems</vendor>
 <homepage href="http://localhost:8080" />
 <description>A Java Webstart test</description>
 </information>
 <resources>
 <j2se version="1.5+" />
 <jar href="SignedApplet.jar" />
 <jar href="sjavaee.jar" />
 <jar href="sappserv-ws.jar" />
 </resources>
 <security>
 <all-permissions />
 </security>
 <applet-desc main-class="JAXWSApplet" name="JAXWSApplet" width="640" height="256"/>
 <param name="endpointURL" value="http://localhost:8080/docliteralfromwsdl-war/jaxws"/>
 </applet-desc>
 </jnlp>

( Jul 16 2006, 06:28:24 PM EDT ) Permalink Comments [0]

Accessing JAX-WS endpoints from Applets

Though the usecase for such an application is rare, some developers want to access JAX-WS web services via Applets - this is indeed possible. To demonstrate the steps, lets use the endpoint based on the "Using XML in the SOAP body" strategy described here. Assuming you have the endpoint deployed successfully, modify the client to work as an Applet. For our example we will have a simple TextArea and Button to make the web service call and display the results.The source for the Applet can be found in file JAXWSApplet.java To get this Applet running a few basic steps need take place
a) Package the Applet and artifacts generated by the wsimport in a Jar file
b) Make the JAX-WS runtime available to the client. If you're using Java SE 6.0 (Mustang) and the browser plugin for that, then you should be all set. However if you're using J2SE 1.5 or an older version of Java then the JAX-WS Jars need to be made available to the browser. You can make these available in one of two ways. i) Get the JAX-WS distribution from Java.net and get the jars from the lib directory or ii) If you're using JAX-WS with Glassfish then locate the appserv-ws.jar and javaee.jar files in the lib directory.
c) Sign all the necessary JAR files using keytool and the jarsigner utility. This is a two step process that involves key generation and Jar file signing. A good technical article detailing this can be found here keytool -genkey -alias signFiles -keystore mystore -keypass mykeypass -dname cn=Sun -storepass mystorepass
jarsigner -keystore mystore -storepass mystorepass -keypass mykeypass -signedjar SignedApplet.jar JAXWSApplet.jar signFiles
d) Place the signed JAR files and the HTML page with the Applet tag on the web server. In Glassfish, simply place all these contents in the glassfish\docroot directory
Run the above example using targets in the following order to first build deploy and test the endpoint using a stand alone client ant create-war deploy-war run-wsdl-client. Then run the target sign-jaxws-ri which packages the Applet , signs the applet and signs the Glassfish Jars, plaing them in the build/signedjars directory along with an HTML file. Place the contents of this directory on your web server.Access the web page through the browser or appletviewer and you should see a result similar to the screen below when the button is pressed. ( Jul 13 2006, 03:38:04 PM EDT ) Permalink Comments [6]