Thursday Sep 21, 2006

WS-Addressing and WSIT M2

Other than performance improvements and minor bugfixes, the biggest change in WS-Addressing from WSIT M1 to M2 is enabling interoperability with a publicly available release of .NET 3.0 runtime (a.k.a. WCF or Indigo). The problem was identified few weeks ago and fixed right away but this is the first milestone build to incorporate the fix.

As mentioned earlier, WS-Addressing functionality is getting subsumed in JAX-WS 2.1. If everything goes well, a subsequent release of WSIT will use WS-Addressing functionality from JAX-WS 2.1 instead of JAX-WSA. As a developer, this change will not be visible to you except that it will be a faster and better performing implementation. Read Vivek's blog for more details on JAX-WS 2.1 roadmap. I'll provide more details on WS-Addressing implementation in a later entry.

Other than that, there is not much activity on JAX-WSA. Hope you are enjoying WSITing.

Technorati: WSIT Web-services JAX-WSA WCF

Monday Sep 18, 2006

Upcoming WCF Plugfest

Microsoft is hosting a Windows Communication Foundation (a.k.a. Indigo) interop plug-fest in Seattle from Sep 26-28. Sun Microsystems will participate in this plug-fest as we did during the previous two (Mar 2006, Nov 2005). We will be taking WSIT and GlassFish for all the interop testing.

I'll post another blog entry, with our interop report, after the plug-fest.

Technorati: Interoperability WSIT WCF Indigo

Thursday Aug 17, 2006

WSIT Milestone 1

WSIT Milestone 1 release has been available for few days now.

Follow 4 simple steps to download the binary release or build from the source and build a secure, reliable and interoperable Web service using the comprehensive tutorial. The samples range from simply adding the two numbers to a price quote service using secure, reliable and brokered trust pattern. All the samples can be installed on GlassFish or Tomcat.

Although the milestone binary does not interoperate with a publicly-available Windows Communication Foundation the current version of the sources does interoperate with the July CTP (runtime and SDK). A WSIT binary release that does interoperate with WCF will be available soon.

Your feedback is very appreciated.

Technorati: WSIT Web-services WCF Indigo GlassFish

Monday Aug 07, 2006

JavaOne 2006 Keynote WSIT Demo

A new sample is added to WSIT samples that shows an enterprise Web service enabling integration both within and across boundaries. This sample demonstrates a price quotation service that provides list price to clients based on the product identifiers. The client makes a request to a Retail Quote Service (RQS)  which then communicates with multiple Wholesale Quote Service (WQS) to get the best price and returns that to the client. In the first version of this sample, the client and all the service endpoints (RQS + 2 WQS) are built and deployed using WSIT. A later version of the sample will replace one of the WQS to be built and deployed using Windows Communication Foundation (WCF) and also have a WCF client, in addition to WSIT client, invoking the RQS.

The sample demonstrates secure reliable communication between RQS and two WQS. It also demonstrates secure MTOM between the client and RQS. A picture is worth a thousand pictures and so this graphical representation should help visualize.

This sample was demonstrated in JavaOne 2006 keynote and used as the basis of my JavaOne 2006 technical session (TS-5540). In case, you need more technical details, the StarOffice version of slide has speaker notes and animation.

Instructions to check out the sample

This sample can be checked out using the instructions given here. These instructions will retrieve WSIT sources along with the sample sources as both are required to build, run and deploy the sample. The sample exists in wsit/wsit/samples/pricequote directory. Once checked out, follow the instructions in readme.html in the pricequote directory to build and deploy the sample on GlassFish.

Technorati: Javaone Indigo WCF Web-services Interoperability presos

Friday Aug 04, 2006

WCF Interop: Workaround for Incorrect Action values from WCF client

In my last blog entry, I described how WS-Addressing Action header value is calculated. A WSIT-enabled client/endpoint generates/expects the correct values per W3C Candidate Recommendation.  However Microsoft's WCF (Windows Communication Foundation) client does not generate the correct value of Action header in all cases. This blog describes the issue and workaround. 

As described in the previous blog, in the first case, where wsaw:Action is explicitly associated with wsdl:input message, WCF client generates the correct Action header value. In the second case where a non-empty soapAction is specified on wsdl:binding/wsdl:operation, WCF client generates the correct Action header value. In the third case where either soapAction is not specified or defined with an empty string as it's value, WCF client generates empty string as Action header instead of the default action. This causes an interoperability issue between WSIT and WCF starting Jun CTP. Lets understand this issue and see how it can be worked around.

If the WSDL has either of the following binding sections:  

<binding name="..." type="tns:wsaTestPortType">
  <operation name="echo">
    <soap:operation soapAction="">

where soapAction's value is an empty string, or

<binding name="..." type="tns:wsaTestPortType">
  <operation name="echo">

where soapAction is not specified, then WCF client sends empty string as Action header value.

This is incorrect as W3C WS-Addressing WSDL Binding requires a default action to be generated/expected in this case. But because WSIT-based endpoint expects the correct value according to W3C Candidate Recommendation, there is a conflict and thus WSIT and WCF do not interoperate. Without getting into why there are different interpretations of the spec (probably another blog later), lets see how we can work around this.

WSIT Java-first endpoint, WCF client

If you build your Web service endpoint starting from Java (as opposed to starting from WSDL), then wsimport tool will generate a WSDL with soapAction="" in the SOAP binding. The reason it does that is because JSR 181 (Web Services Metadata for the JavaTM Platform) says all methods in a SEI (service endpoint interface) are mapped to WSDL operations. A @WebMethod annotation may be used to customize the mapping, but in it's absence a default @WebMethod is assumed on each method. The @WebMethod annotation has a member with name "action" that determines the value of soapAction for SOAP bindings. This member has a default value of "" (empty string). And thus, in this case, any WSDL generated by WSIT, either at runtime or using wsimport tool, where SEI does not have @WebMethod.action set to any non-empty-string value, has soapAction="" in the SOAP binding section.

So if your SEI looks like:

public class AddNumbersImpl {

  public int addNumbers(int number1, int number2) {

The generated SOAP binding will look like:

<operation name="addNumbers">
  <soap:operation soapAction="" />

As explained above, WSIT and WCF do not interoperate for such a WSDL. The default value (empty string) of soapAction can easily be overridden by adding a @WebMethod annotation on your method as shown below. So if your SEI looks like:

public class AddNumbersImpl {

  public int addNumbers(int number1, int number2) {

The generated SOAP binding in this case looks like:

<operation name="addNumbers">
  <soap:operation soapAction="addNumbers" />

WCF client will generate "addNumbers" as the Action header and WSIT endpoint will accept it as a valid value.

WSIT WSDL-first endpoint, WCF client

If you are starting from WSDL, then you can either explicitly specify wsaw:Action attribute on the input message, as shown below:

<portType name="AddNumbersImpl">
  <operation name="addNumbers">
    <input message="tns:addNumbers" wsaw:Action=""/>
    <output message="tns:addNumbersResponse"/>

Note, this is only required to be changed for input messages as WSIT endpoint generates the correct action on fault and output messages going back to WCF client.

Alternatively you can change, or add if missing, soapAction in the binding section, as shown below:

<operation name="addNumbers">
  <soap:operation soapAction="addNumbers" />

As a convenience, you can use the operation name as the value of either wsaw:Action or soapAction since that is guaranteed to be unique.

WCF Endpoint, WSIT client

A WCF endpoint always generates explicit wsaw:Action for each message in the portType and exactly same value of soapAction. WSIT client is interoperable with WCF endpoints out of the box in this case.

Hopefully WCF will be fixed in the upcoming CTP and behave as per W3C standards. Then this workaround will not be required and life will be simpler again :)

Technorati:   WSIT WCF Indigo Web-services Interoperability

Friday Jul 14, 2006

RESOLVED: WSIT and WCF Jun CTP Interop Bug

Taking on from previous post ...

Even though the list of breaking changes from Feb CTP to Vista Beta 2 and Vista Beta 2 to Jun CTP are documented. The list is missing a "minor" detail of changing the WS-Addressing 1.0 WSDL Binding namespace from (same as SOAP Binding namespace) to (WSDL Binding CR namespace). As a result a user reported interop problems between Jun CTP and WSIT.

I updated the namespace for WS-Addressing WSDL Binding in WSIT this morning. After deploying one of the JAX-WSA unit tests and invoking svcutil.exe to generate proxy, got the following warning:

Warning: The optional WSDL extension element 'UsingAddressing' from namespace '' was not handled.
XPath: //wsdl:definitions[@targetNamespace='']/wsdl:binding[@name='wsaTestPortTypeBindingAddressingRequired']

Seems like this CTP completely ignores a standard W3C extension element to indicate WS-Addressing on a binding/port. It generated the proxy correctly but of course the client did not send expected WS-Addressing headers and thus the endpoint faulted appropriately. Anyway, I specified UsingAddressing within a policy assertion, regenerated the proxy and invoked the client. The server returned the response correctly and CTP client displayed the response in console.

WSIT is now again interoperating with Jun CTP.

Technorati: WSIT Interoperability Web Services

WSIT and WCF Jun CTP Interop Bug

One of WSIT user reported an issue with WCF June CTP in WSIT user forums. And thus I tried installing the latest CTP from Microsoft. But as always, there are different runtime and SDKs floating on the website (dejavu). Lets see which one are required. 

The runtime components can be downloaded from here. There is a separate link for .NET Framework 3.0 Runtime Components Beta2 for Windows XP + SP2. But similar runtime components for Jun CTP are available for Windows XP only, no SP2. This is confusing but I took "Jun CTP" in the link name as the main indicator and hoped it was just a typo. Plug and Pray and yep, that was the correct runtime component.

The Windows SDK can be downloaded from here. If I click on 3rd bullet to download Windows SDK, then this is SDK for Beta2 of Vista and WinFX Runtime Components. This seemed incorrect but I still tried installing it and hoping it was a typo as in the previous case. But nope, not this time. Related Resources on the runtime website finally showed a link to the correct Windows SDK.

Why cant the runtime and SDK be published together in a consistent manner ? Once again, here is the correct runtime and SDK that gives you the functionality of Jun CTP.

Now I can get back to my work. 

BTW, The svcutil version is 3.0.4219.0.

Technorati: Bugs WSIT

Wednesday May 31, 2006

Project Tango @ SDN Channel

View Sun and Microsoft on Project Tango at Sun Developer Network Channel (SDN). SDN caught me and Kirill at the Microsoft pod in the JavaOne 2006 pavilion and talked to us about Project Tango and how developers can have access to this content. If interested in the content, you can view the video cast from 28:35 through 31:09.

Technorati: Javaone Microsoft Interoperability

Tuesday May 30, 2006

TS-5540 Summary by an audience

Read a brief summary of my talk (TS-5540, Making Java™ Technology-Based/.NET Web Services Interoperability Real) at JavaOne this year here by an audience. The slides were posted earlier.

Technorati: Javaone WCF Interoperability presos  

Project Tango @ Java One 2006 - Part 2

I posted the list of sessions and labs as part of Project Tango in JavaOne 2006 earlier.  It indeed got a lot of attention during JavaOne this year (see further down). I posted a collection of articles talking about Sun and Microsoft Web services interoperability effort earlier. Here is another article published on ZDNet Japan covering Project Tango and how it has fully embraced the keywords at JavaOne this year, namely SOA, Open Source and Web 2.0. Koji Tokuda, author of the article, told me that this was one of the top 50 articles reviewed on Google News Japan on the day following the general session keynote demo. Here is an English translation of the article using Google Translate English BETA. This article mentions me as the leader of Project Tango which is inaccurate since I'm just one of the team members but do touch lot of components in the project :) 

Here is another article in Japanese (English version) on Sun's SOA offerings and how they link to WSIT.

Coming back to Project Tango coverage in JavaOne, Googling Sun Project Tango JavaOne gives 17,200 entries.


Googling on Sun Project Tango gives 1,750,000 search entries and of course these entries are bound to grow as developers download and contribute to


Technorati: Javaone Indigo WCF Interoperability presos  


profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.

Java EE 7 Samples

Stay Connected


« June 2016