Tuesday Aug 09, 2011

FastInfoset 1.1.9 and 1.2.11 have been released

FastInfoset 1.1.9 and 1.2.11 have been recently released.

Here is the list of fixed issues/tasks:

As we see from the last item on the list above, from this release on all the FastInfoset maven artifacts will be deployed to the maven central repository.

Thursday Jan 20, 2011

FastInfoset 1.2.9 has been released

The first FastInfoset release after migrating project to kenai.

As you may know as part of migration, we had to change the version control system and now using new SVN repository.

Once it happened, we decided to take advantage of the situation and make other changes we had in mind, but never had time to work on

  1. Swap 1.1.x and 1.2.x branches. So the latest FastInfoset branch 1.2.x was moved to SVN trunk, and older 1.1.x branch, which was located on trunk, was moved to a separated FastInfoset-1_1-branch;
  2. Mavenize the project. FastInfoset become a maven 2 based project, which simplifies its usage and building process. More details here and here;

Please note, due to the mentioned mavenization, we've moved to different maven repository.

Coming back to the 1.2.9 release, besides the mentioned project administrative changes, we've also fixed 2 issues.

The complete release notes could be found here

 

Wednesday Mar 26, 2008

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 

Tuesday Nov 06, 2007

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.

Monday Oct 22, 2007

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.

benchmark results (small 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:

benchmark results (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:

benchmark results (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.

Thursday Jun 07, 2007

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

Friday Mar 02, 2007

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)
 

Friday Jan 05, 2007

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.


Tuesday Jan 02, 2007

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

Wednesday Dec 06, 2006

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.

    Thursday Jun 01, 2006

    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 :)

    Thursday May 25, 2006

    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.
    About

    oleksiys

    Search

    Categories
    Archives
    « April 2014
    SunMonTueWedThuFriSat
      
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
       
           
    Today