Arun Gupta, Miles to go ...

Why WS-Addressing ?

I've been asked this question multiple times and so finally decided to convert an internal presentation that into an external document.

Why WS-Addressing ? describes the different use cases served by WS-Addressing and explains the two commonly used versions.

JAX-WS 2.1 RI EA2 was recently released and supports W3C and Member Submission WS-Addressing. A more recent version of this RI is integrated in WSIT which is then integrated in GlassFish 2 days ago. Read about WS-Addressing support in JAX-WS 2.1 RI here.

Posted by Arun Gupta in webservices  |  Comments[0]

JAX-WS 2.1 EA2 and WS-Addressing

JAX-WS 2.1 EA2, with new features and better quality, is out. Read Vivek's message about the announcement and the list of features.

I'd like to highlight Users Guide that has been updated with an explanation for all the newly added features. I added a new section on WS-Addressing support in the RI. Rama published a blog on Support for WS-Addressing in JAX-WS 2.1 RI EA1 4 weeks ago. Based upon internal and external feedback, we've simplified the way WS-Addressing support is enabled starting from Java. This blog highlights those changes and provides a quick overview of the new WS-Addressing features.

1. Enabling WS-Addressing

The code to enable WS-Addressing in EA1 (given below):

@javax.jws.WebService
@BindingType(features={@Feature(AddressingFeature.ID)})
public class MyWebService { ... }

is now replaced with the following code in EA2:

@javax.jws.WebService
@javax.xml.ws.soap.Addressing
public class MyWebService { ... }

Similarly, specifying parameters to WS-Addressing feature is simplified. The code to enable WS-Addressing with required parameter true value in EA1 (given below):

@javax.jws.WebService
@BindingType(features={
                       @Feature(value=AddressingFeature.ID,
                                parameters={
                                            @FeatureParameter(name=AddressingFeature.IS_REQUIRED, value="true"
                                           }
                                )
                      }
             )
public class MyWebService { ... }

is now replaced with the following code in EA2:

@javax.jws.WebService
@javax.xml.ws.soap.Addressing(enabled=true, required=true)
public class MyWebService { ... }

2. Explicit enabling/disabling

WS-Addressing can be explicitly enabled or disabled on the client irrespective of what the service endpoint WSDL advertises. The use case is when the client does WS-Addressing processing in the Dispatch client or via handlers. Another use case is when the client need to perform non-anonymous ReplyTo/FaultTo processing.

3. Support for wsaw:Anonymous  

W3C WS-Addressing WSDL Binding defines wsaw:Anonymous element to define assertions regarding a requirement or a constraint in the use of anonymous URI in EPRs sent to the endpoint. The syntax and semantics defined by the spec are now supported from both the client- and server-side.

This JAX-WS 2.1 EA2 is tested with GlassFish v2 b22. A more recent build is already integrated in WSIT and will soon be integrated in GlassFish. 

Posted by Arun Gupta in webservices  |  Comments[1]

JAX-WS 2.1, WS-Addressing, WSIT and GlassFish

JAX-WS 2.1 RI replaced JAX-WS 2.0.1 and JAX-WSA 1.0 EA2 in WSIT approximately 2 weeks ago. This is where I've been spending most of my time during the past few weeks. With this change, WSIT is now using WS-Addressing functionality natively provided in JAX-WS 2.1 RI is used instead of relying upon a pluggable JAX-WSA 1.0 EA2. This approach has several benefits as outlined earlier. A complete description of JAX-WS roadmap will help you understand the difference between the different version numbers.

Starting with GlassFish b22, this version of WSIT is also integrated in GlassFish. So, if you download GlassFish you get WSIT, JAX-WS 2.1 and all other great stuff. This is the very first integration of JAX-WS 2.1 RI in GlassFish and most of the functionality is working. I encourage you to download GlassFish b22 and give us feedback on how we can make it better for you.

Technorati: Web Services GlassFish WSIT WS-Addressing JAX-WSA

Posted by Arun Gupta in webservices  |  Comments[0]

WS-Addressing Member Submission Policy Assertion Namespace Change in WCF

WCF RC1 (probably in Jul CTP as well) changed the policy assertion namespace URI to declare the usage of Member Submission WS-Addressing. The namespace was changed from:

http://schemas.xmlsoap.org/ws/2004/09/policy/addressing

to

http://schemas.xmlsoap.org/ws/2004/08/addressing/policy

Thus any WSDL published by a WCF-based service endpoint using Member Submission WS-Addressing cannot be imported by WSIT clients directly. We will provide a fix in the days to come.

But in order to fix the problem, in the meanwhile, when importing such a WSDL using wsimport, you need to localize the WCF-generated WSDL, change the namespace to the original namespace (ending in 2004/09/policy/addressing) and then import it using wsimport.

Similarly, any WSDL published by a WSIT-based endpoint cannot be imported by svcutil directly. The temporary fix involves localizing the WSIT-generated WSDL, changing the namespace as it is recognized by their tools (ending in 2004/08/addressing/policy) and then importing it using their tool.

Posted by Arun Gupta in webservices  |  Comments[1]

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.

Posted by Arun Gupta in webservices  |  Comments[0]

JSR 261 and JAX-WSA Future

JSR 261 (Java API for XML Web Services Addressing, JAX-WSA) has been operating under the assumption that it would layer on top of JAX-WS 2.0 (JSR 224). This enabled us to provide WS-Addressing functionality without delaying the JAX-WS 2.0 EG. The plan was to later make this JSR into a required component of a future version of the Java web services stack.

After looking at the current state of JSR 261 and listening to the feedback we received from community, this API seems to provide a rich and powerful API for WS-Addressing that is more targeted to stack implementers rather than to the end developer. In order to simplify the programming model for WS-Addressing for JAX-WS developers, we are revisiting those initial assumptions at the first available opportunity, namely the upcoming JAX-WS 2.1 Maintenance Release (MR).

We are converging the JSR 261 specification and API with the upcoming JAX-WS 2.1 MR. Here is a top-level summary of the proposed changes:

1. Simpler abstraction of EndpointReference as a first-class citizen in JAX-WS.
2. Standard way to enable WS-Addresing in JAX-WS using @BindingType.
3. Various JAX-WS APIs expose/consume EPR.
4. Action/FaultAction moved from JSR 261 to JAX-WS MR.

The proposals are being discussed with JSR 261 and JSR 224 EG. Since all the relevant functionality from JSR 261 will be incorporated in the JAX-WS MR, this would also mean that JSR 261 will be withdrawn from the JCP.

We believe this approach is the right thing to do for the specifications, the platform and the community. Leave a comment or send your feedback.

Technorati: JSR JCP JAX WSA JAXWS WSAddressing Web Services

Posted by Arun Gupta in webservices  |  Comments[3]

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="">
    ...
  </operation>
</binding>

where soapAction's value is an empty string, or

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

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 Java^TM 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:

@WebService
public class AddNumbersImpl {

  public int addNumbers(int number1, int number2) {
    ...
  }
}

The generated SOAP binding will look like:

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

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:

@WebService
public class AddNumbersImpl {

  @WebMethod(action="addNumbers"
  public int addNumbers(int number1, int number2) {
    ...
  }
}

The generated SOAP binding in this case looks like:

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

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="http://example.org/action/echoIn"/>
    <output message="tns:addNumbersResponse"/>
  </operation>
</portType>

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" />
  ...
</operation>

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

Posted by Arun Gupta in webservices  | 

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: WCF Indigo Bugs WSIT

Posted by Arun Gupta in webservices  | 

JAX-WSA ED2

JAX-WSA (Java API for XML Web Services Addressing) Early Draft 2 was released right before JavaOne. The specification and javadocs can be downloaded from the JCP site. The javadocs can also be viewed online at jax-wsa.dev.java.net. The implementation, work in progress, will be made available shortly from jax-wsa-sources.dev.java.net.

Technorati: jaxwsa Web Services WSAddressing w3c

Posted by Arun Gupta in webservices  | 

WS-Addressing 1.0 Core and SOAP are Proposed Recommendation

W3C WS-Addressing 1.0 Core and SOAP Binding are now Proposed Recommendation. A final stamp from W3C Advisory committee will convert this into a Recommendation.

This has been a great effort so far for me especially since I was responsible for Sun's implementation in the CR interop testing. Marc Hadley and Pete Wenzel from Sun participated in the specification process.

Sun's WS-Addressing implementation (Java API for XML Web Services Addressing, JAX-WSA) is available as a source on java.net, binary in Java Web Services Developer Pack and will also be delivered in Glassfish.

Posted by Arun Gupta in webservices  | 

JAX-WSA is all green!

I've decided to cross-post my Java blogs from weblogs.java.net/blog/arungupta/ here.

Earlier this week W3C WS-Addressing testing task force spent hours to interoperate on WS-Addressing CR test cases. Well, this morning was pretty much the grand finale but we've been working for the past few months on testing. And finally we achieved a darn good test report.

I represented Sun for the interop using JAX-WSA APIs and implementation and achieved 100% interoperability. That means all the vendors who had a WS-Addressing client (IBM, JBoss, Microsoft, WSO2) were able to invoke Sun endpoints on all the required features. And Sun was able to invoke all the endpoints published (IBM, JBoss, Microsoft, WSO2, Apache Axis) for the required features. And invoking is just an understatement, since the report follows a rigorous XPath-based check on request and response messages, ensures all the messages (4 of them) are received for a non-anonymous ReplyTo, checks the reference parameters in request and response, defaulting of FaultTo and all sort of features. All the assertions applied to each test case are documented if you click on the link for each test case.

The source code for the JAX-WSA RI is available. The source code and binaries will also be delivered as part of JWSDP and Glassfish. The source code for test cases are available on java.net too.

The WG charter required to demonstrate four interoperable implementations so that the specification can be moved to Proposed Recommendation (PR). Now that the WG has demonstrated that, that's one less hurdle to move to PR and thus soon Recommendation.

Thanks to Paul Downey, Jonathan Marsh, David Illsley, Davanum Srinivas (aka Dims), Mike Vernal, Glen Daniels, Kevin Conner and all others involved for making it through. We resolved through all the red squares that we were getting in the initial stages and converted them to green after fixing bugs in test cases, supported assertions and our implementation. And thus "Green is happiness!".

Posted by Arun Gupta in webservices  |