Mytec

Fast Infoset: JAX-RPC API to JAX-WS API migration.

If you migrate a Web service client, written on top of the JAX-RPC API, to the newer JAX-WS API and need to keep it communicate using Fast Infoset – you need to follow easy migration procedure.
Very likely old code enables Fast Infoset using one of the following JAX-RPC API specific methods:

1. Setting the System property
   java -Dcom.sun.xml.rpc.client.ContentNegotiation=pessimistic ...
2. Setting Content Negotiation on a Stub
   stub = ...; // Obtain reference to stub
   stub._setProperty(com.sun.xml.rpc.client.StubPropertyConstants.CONTENT_NEGOTIATION_PROPERTY, "pessimistic");
3. Setting Content Negotiation on an instance of Call
   call = ...; // Obtain reference to call call.setProperty(com.sun.xml.rpc.client.dii.CallPropertyConstants.CONTENT_NEGOTIATION_PROPERTY, "pessimistic"); 

For JAX-WS API based Web services, Fast Infoset could be enabled very similar way to JAX-RPC cases (2) and (3), described above. JAX-WS API uses different property name, though supported property values are same: “none”, “optimistic”, “pessimistic”.

After migration to a JAX-WS API, a Web service client will be represented either by Stub or Dispatcher object. However the Fast Infoset enabling procedure is the same for both representations. It's required to set Content Negotiation property on a Web service Stub or Dispatch.
So JAX-WS API specific way to enable Fast Infoset is following:

1. Setting Content Negotiation on a Stub or Dispatch
   stubOrDispatch = ...; // Obtain reference to Stub or Dispatch ((BindingProvider) stubOrDispatch).getRequestContext().put("com.sun.xml.ws.client.ContentNegotiation", "pessimistic"); 

Additional links:
[1] How to enable Fast Infoset
[2] Fast Infoset in Java Web Services Developer Pack, Version 1.6 

Posted at 01:41PM Mar 26, 2008 by oleksiys in Web Services  |  Comments[1]

FastInfoset 1.2.2 was released!

FastInfoset version 1.2.2 was recently released!

It includes fixes for the following bugs:

• Parsing of escaped characters was not normalized (bug report)
• Hexadecimal encoding algorithm fix: typo in transformation table
• Stateful mode fix. When vocabulary max memory limit was reached - vocabulary stopped to work not just for a new values, but even for values, which are already indexed.

Here are links for complete distribution package and separately for sources.

Posted at 04:51PM Nov 06, 2007 by oleksiys in Web Services  |  Comments[0]

SOAP/TCP makes Web services faster

Last month two important events happened related to SOAP/TCP.
First of all, as part of project Metro, SOAP/TCP 1.0 implementation is now available in Glassfish v2 release.

Next great thing is: SOAP/TCP now is .NET interoperable!!! Read more on Paul's blog.

Now I wanted to stop on topic, what advantages SOAP/TCP brings to Web services.

We always mentioned, that main target for SOAP/TCP is performance, however never showed any numbers. Here I would like to publish some benchmark results, which I've got using Japex.

Testing environment configuration:

• localhost
• Sun X4100 server, 4 CPUs
• Sun Solaris 10
• Sun JDK 1.5.0_13
• Glassfish v2 release
• 16 client threads
  

Web Service test operations: 

Most of tests are echo-like (except getOrder), it means the same data set (depending on test) is sent to and returned from a Web service. For example echoInt test executes Web service operation, which implements following logic:

public int echoInt(int value) {
    return value;
}

Here is complete description of tests (provided by Ken Cavanaugh):

• EchoVoid: no data sent or returned
• EchoString: "Hello World" sent and returned
• EchoStruct: a small class with an int, a float, and a String sent and returned
• EchoSynthetic: a small class with a String, a Struct (as in EchoStruct), and a variable-length byte[] sent and returned.  The size of the byte array is indicated by the name of the test.
• EchoArray: basically an ArrayList of an Item, with each Item initialized to the same data (so Strings are shared in the marshaled representation).  The number of Items is given in the name of the test.  An Item contains:
• String
• String
• float
• int
• Location, which is 3 Strings
  
• XMLGregorianCalendar (standard Java type; the BigInt or BigDecimal fields are null)
• GetOrder send a very small request (customer ID and order number), and returns a large Order class containing:
• int
  
• int
• XMLGregorianCalendar
• Customer, which is a class containing:
• int
• String
• String
• String
• XMLGregorianCalendar
• String
• String
• Address (which contains 7 Strings)
• Address
  
• ArrayOfLineItem which contains an ArrayList of LineItem, each of which contains:
  
• int
• int
• int
• String
• int
• float 

Test results are measured in "transactions per second %". SOAP/TCP benchmark result is taken as 100%. Red bar represents SOAP/TCP results, blue bar is FastInfoset encoded SOAP over HTTP, and green bar is regular SOAP/HTTP.

Let's start from results for smaller testcases.

 

We can see, that for small testcases, where HTTP headers could be even bigger than SOAP message - SOAP/TCP header compactness plays very big role. And we can get over 50% performance improvement with SOAP/TCP comparing to FastInfoset over HTTP, and over 70% comparing to SOAP/HTTP.

Medium testcases:

Here we can see that for echoStruct and echoArray40 SOAP/TCP is getting less advantage comparing to FastInfoset/HTTP, because SOAP messages are getting bigger and header processing gets relatively cheaper. Though for bigger messages, SOAP/TCP stateful characteristic (FastInfoset stateful mode) does its work (in SOAP/TCP, FastInfoset vocabulary is not transferred with each message, but is kept alive both on client and server until SOAP/TCP connection is alive).

On echoSynthetic testcases we can see SOAP/TCP throughput advantages. With changing transferring byte buffer size from 4K to 12K - difference between SOAP/TCP and HTTP results grows.

Big testcases:

On bigger tests, when transferring complex structures, SOAP/TCP also wins regarding its stateful FastInfoset vocabulary and better throughput. Though, its advantage is not so huge as for smaller messages, 15% performance improvement is also significant.

So, from graphs above we can see, that SOAP/TCP makes Web services faster: over 50% for smaller structures, 15% for bigger ones.

Posted at 11:08AM Oct 22, 2007 by oleksiys in Web Services  |  Comments[9]

How to make Web service use TCP transport with JAX-WS

SOAP/TCP right now is the part of WSIT project, but it's also possible to use it with clear JAX-WS framework.
There are lots of places, which should be improved, however nothing could stop us using it right now :)
Several steps, especially for the server side, are similar or even same to WSIT ones, however the client side configuration is completely different.

So, "how to deploy web service to Glassfish and make it reachable via SOAP/TCP?".

1. JavaEE 5 or JSR109 WS deployment.
   Actually all Web services deployed to Glassfish using this deployment method become TCP transport enabled. They are automatically registered on SOAP/TCP listener and ready to process.
   *One known issue with JavaEE 5 deployment of WS is: if WS is being deployed to a Web container - then it is required for this WS to have the descriptor web.xml, where it will be specified to load on startup. In this case the SOAP/TCP listener will get to know about this web service.


2. Servlet deployment.
   For this deployment type, things are not much different. In this case one more servlet context listener should be added to a web service's (web appliction's) web.xml file [1].
   And the servlet should be set to load on startup. Otherwise the SOAP/TCP listener will not be aware know about Web Service, until WSStartupServlet will not be started.  

"How to make client to choose SOAP/TCP as transport to work with web service?"

We need to configure JAX-WS client to be aware of SOAP/TCP transport. For that reason, we have to provide following service provider file [2], located on client classpath, and contain line [3] in it.
Web service WSDL file, which is provided to a client, should contain Web service endpoint address (/definitions/service/port/soap:address@location) with SOAP/TCP specific protocol schema [4]. Only in that case SOAP/TCP transport pipe will be attached and used for sending/receiving SOAP messages. Currently server side WSDL generation doesn't support protocol schema changing for SOAP/TCP, so this change should be made manually.

[1] <listener-class>com.sun.xml.ws.transport.tcp.server.glassfish.WSStartupServlet</listener-class>
[2]  META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory
[3]  com.sun.xml.ws.transport.tcp.client.TCPTransportPipeFactory
[4]  vnd.sun.ws.tcp

Posted at 06:05PM Jun 07, 2007 by oleksiys in Web Services  |  Comments[13]

Fast Infoset Interoperability between IBM's JVM and GlassFish

It's nice to see, that now Fast Infoset binary XML encoding could be used in IBM SDK for Java 6 Early Release for web services communications.
The latest tests run for configuration [1] passed without any issue! However, configurations [2] and [3] didn't work out-of-the-box due to XML serializing problems.

In Paul's blog there is information how to enable Fast Infoset "pessimistic" mode. The "optimistic" mode could be enabled the same way. In the "optimistic" mode a client assumes a server supports Fast Infoset, and will not use XML encoding even for the first request.

[1] FastInfoset optimistic mode. "IBM SDK for Java 6 Early Release" client <->GlassFish V2 (b31)
[2] FastInfoset pessimistic mode. "IBM SDK for Java 6 Early Release" client <->GlassFish V2 (b31)
[3] FastInfoset disabled. "IBM SDK for Java 6 Early Release" client <->GlassFish V2 (b31)
 

Posted at 12:01PM Mar 02, 2007 by oleksiys in Web Services  |  Comments[0]

How to make Web service use TCP transport with WSIT: "Policies solution"

Before starting I would like to mention that for now the only app/web server that is supporting TCP transport (SOAP/TCP) provided by WSIT is Glassfish V2. But also Tomcat support is planned to be implemented.

Ok, as I said in prev. blog, Glassfish has the SOAP/TCP protocol listener represented as a lifecycle module, which should be enabled by default. But it's possible to check its status using admin tools provided by Glassfish (Web or console). And make sure the lifecycle module with name "WSTCPConnectorLCModule" is enabled. If yes - it means that the listener is initialized and waits on TCP port for SOAP/TCP requests. And each Web service that is supposed to be SOAP/TCP enabled should register itself on SOAP/TCP listener (lifecycle module).

Next question that arises is "how to deploy web service to Glassfish and make it reachable via SOAP/TCP?".

1. JavaEE 5 or JSR109 WS deployment.
   Actually all Web services deployed to Glassfish using this deployment method become TCP transport enabled. They are automatically registered on SOAP/TCP listener and ready to process. But the question is - How to say to WS client, that the service supports TCP transport? WSIT Policies is one possible way. In Web service's WSDL file (for fromwsdl case) or wsit-*.xml file (for fromjava case) to standard web service <binding> section (in most cases its HTTP <binding> section) should be added following policy:
   <soaptcp:OptimizedTCPTransport xmlns:soaptcp="http://java.sun.com/xml/ns/wsit/2006/09/policy/soaptcp/service" enabled="true"/>
   After client retrieves service's WSDL it will know, that in addition to the declared binding's transport, the web service also supports TCP transport.
   *One known issue with JavaEE 5 deployment of WS is: if WS is being deployed to a Web container - then it is required for this WS to have the descriptor web.xml, where it will be specified to load on startup. In this case the SOAP/TCP listener will get to know about this web service.


2. Servlet deployment.
   For this deployment type, things are not much different. In this case one more servlet context listener should be added to web service's (actually web appliction's) web.xml file:
   <listener-class>com.sun.xml.ws.transport.tcp.server.glassfish.WSStartupServlet</listener-class>.
   And the servlet should be set to load on startup. Otherwise the SOAP/TCP listener doesn't know about it before it starts . Then policies should be specified in same manner as for JaveEE 5 deployment. 

Next is "How to make client to choose SOAP/TCP as transport to work with web service?"

Again policies solve that. The WS client can pick up policies from the client's policy configuration file wsit-client.xml. Following policy should be added to <binding> section of WS description:
<transport:AutomaticallySelectOptimalTransport xmlns:transport="http://java.sun.com/xml/ns/wsit/2006/09/policy/transport/client"/>
This policy says to the client that it should choose optimal transport from all transports supported by web service. For example if a web service declares (using WSDL) that it supports just HTTP protocol - then a client will choose HTTP to work, but if in a WSDL file there is the policy declaration that SOAP/TCP is also supported by a web service - then a client will choose SOAP/TCP as the transport. Client makes this decision at runtime, that's why if transport policies will be changed on server side, it's not necessary to recompile client.

In this case how will the client know the address for WS SOAP/TCP endpoint, as it is nowhere specified?

A client will use the same address and port as it is using for the HTTP endpoint, thanks to new feature, implemented by Jeanfrancois , Glassfish "port unification". A SOAP/TCP request that will be sent to same port used for HTTP will be filtered out and passed to SOAP/TCP listener.

Posted at 12:03PM Jan 05, 2007 by oleksiys in Web Services  |  Comments[1]

TCP transport for Web Services is integrated to GlassFish

TCP transport for Web Services (SOAP/TCP) was recently integrated into sources of project WSIT. Here is description from Paul about SOAP/TCP related to Fast Infoset, about its advantages and targets.

Now SOAP/TCP is integrated to Glassfish as lifecycle module and is enabled by default. Although till GlassfishV2 promoted build 29, its still disabled  and could be enabled using admin tools. For example: <AS_HOME>/bin/asadmin enable --port 4848 WSTCPConnectorLCModule

Posted at 06:01PM Jan 02, 2007 by oleksiys in Web Services  |  Comments[6]

JMS transport for JAX-WS: EJB deployment is available

Several changes were applied to JMS transport for JAX-WS:

• It was updated to supports latest JAX-WS 2.1 .
• And finally now its possible to deploy JMS enabled WS to GlassFish using service MessageDriven Bean, which is a part of JMS transport.

For more details please visit JMS transport page and check examples provided with it.

Posted at 03:38PM Dec 06, 2006 by oleksiys in Web Services  |  Comments[0]

How to create custom network transport for JAX-WS

In this entry I will try to describe how to implement custom JAX-WS transport from some experience I got with JMS and TCP implementations.

Client side:

1) Implement your own transport pipe, which implements Pipe interface. Mainly you have to implement interface's method process(Packet), which should do actual work on serializing Packet and send it, then wait(or not) for reply packet, deserialize it and pass back it as return param.
2) To plug your transport pipe, you need to create own transport factory. It means its required to write a factory, which extends TransportPipeFactory and actually plugs transport pipe to ws pipeline. Probably it makes sence to check it current service requires exactly this transport to be plugged by checking ws address schema. If return null as pipe - then default (http) transport pipe will be tried to be pluged.
3) And last: to say JAX-WS client framework to use just created TransportPipeFactory - its required to supply configuration file, which should be located at classpath META-INF\services\com.sun.xml.ws.api.pipe.TransportPipeFactory this text file have to contain a line with full classname of custom transport pipe factory.

Server side:

1) For server side first its required to build adapters for provided webservices. Transport Adapter class should do all transport specific work to deserialize and serialize Packet and make it ready for processing by jax-ws service-side pipeline. Its useful to use Adapter.Toolkit for processing packets, as common transport resources, packet encoder, decoder could be stored to pool and reused. Basically Adapter should deserialize Packet from underlying transport, pass it to pipeline head, get reply packet from it and serialize it back to underlying transport. Transport specific Adapter could be constructed manually, with self written code, or as it is in JMSTransport example - DeploymentDescriptorParser was used, which originally located in http specific package, but obviously could be reused for other transports. This parser uses webservice description file (sun-jaxws.xml) to create adapters, its just required to provide some artifacts for that including DeploymentDescriptorParser.AdapterFactory implementation class, which is responsible to create Adapter instances.
2) Actually it could be 1st step:) Its required to implement incoming message listener. If its tcp - listen on tcp port, jms - listen on some queue or topic and based on some transport specific header or some other agreement decide, what is the correspondent adapter for that request and pass transport specific artifacts to adapter for feature processing, including sending actual reply.

Looking at client and server side custom transport implementation, it seems to me, that client side is easier and more clear in implementation, server's is not perfect and requires more work, also don't like too much my solution to use http specific util like DeploymentDescriptorParser. So hope soon with help of jax-ws team I will be able to come with better solution :)

Posted at 04:12PM Jun 01, 2006 by oleksiys in Web Services  |  Comments[3]

JAX-WS JMS transport on java.net

I want to introduce java.net project JAX-WS JMS transport, which was created by me and Paul Sandoz.
In this project you can find simple JMS transport, which could be plugged into JAX-WS framework and instructions how to use it for your own web services. But what I think could be more interesting - using this example its clear to understand how relatively easy its possible to make own transport, let's say SMTP, TCP and utilize it for your web services regarding rearchitectured JAX-WS framework.
I hope to come out soon with some common schema or steps on how to make custom JAX-WS network transports.

Posted at 01:34PM May 25, 2006 by oleksiys in Web Services  |  Comments[2]