Monday Feb 12, 2007

GlassFish and Vista - Interoperable out-of-the-box

GlassFish v2 M4 and Windows Vista were released two weeks ago. I installed GlassFish M4 on my machine and Vista Enterprise on a different machine. In this blog, I explain the steps followed to invoke a Web service deployed on GlassFish by Vista client and vice versa.

First, lets deploy a service on GlassFish and invoke it using a client on Vista.

  1. Using screencast WS#1, I developed a trivial Web service using NetBeans IDE and deployed on GlassFish.
  2. On Vista machine, I generated the client-side artifacts using the command:

    svcutil /config:Client.exe.config
  3. Then I coded the client code to invoke the service endpoint as:

    using System;
    using System.Collections.Generic;
    using System.Text;

    namespace ConsoleApplication1
       class Program
           static void Main(string[] args)
               NewWebServiceClient client = new NewWebServiceClient();
               string response = client.sayHello("Duke";);
               Console.WriteLine("Response from WSIT endpoint: " + response);
  4. Next step is to compile the client code using the command:

    csc.exe /r:"C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.0\\Windows Communication Foundation\\System.ServiceModel.dll"
            /r:"C:\\WINDOWS\\Microsoft.NET\\Framework\\v3.0\\Windows Communication Foundation\\System.Runtime.Serialization.dll"
            Client.cs AddNumbersImplService.cs

    I wonder if there is a way by which csc.exe compiler can be made smarter to recognize WCF assemblies by default. But for now, I need to explicitly specify the assemblies during compilation otherwise the compiler throws bunch of errors like:

    NewWebServiceService.cs(100,63): error CS0234: The type or namespace name 'ServiceModel' does not exist in the namespace 'System' (are you missing an assembly reference?)
  5. After a successful compilation, invoking the client shows the result:

    Response from WSIT endpoint: Hello Duke

Now let's deploy a similar Web service on Vista and invoke it using GlassFish.

  1. There are multiple ways a WCF Web service can be created from scratch but I find the following steps easiest. Create  service endpoint service.svc as:

    <%@ServiceHost language=c# Debug="true" Service="WCFEndpoint.Hello" %>

    using System.ServiceModel;

    namespace WCFEndpoint
       public interface IHello
           string sayHello(string name);

       public class Hello : IHello
           public string sayHello(string name)
               return "Hello " + name;
  2. In the same directory create Web.config as:

    <?xml version="1.0" encoding="utf-8"?>
                   <behavior name="MetadataBehavior">
                        <serviceMetadata httpGetEnabled="true" />
               <service behaviorConfiguration="MetadataBehavior" name="WCFEndpoint.Hello">
                   <endpoint address="" binding="basicHttpBinding" bindingConfiguration=""
                       name="Hello" contract="WCFEndpoint.IHello" />
  3. I installed IIS after installing Vista so WCF extensions need to be explicitly registered as shown here.
  4. Create a virtual directory, say wsit, in IIS mapping to the directory where service.svc and Web.config are present. You should now see the default WCF/IIS page as shown here. The service endpoint now should be hosted at http://localhost/wsit/service.svc.
  5. Using screencast #WS2, create a JAX-WS client to invoke the Web service.

This is an example of a trivial interoperable Web service between GlassFish M4 and Vista but the key fact is that, as a developer, this is provided as out-of-the-box experience. No extra tweaks or no special configurations required.

I plan to build upon this Web service by adding enterprise Web services features such as Reliable Messaging, Security etc. and show how WSIT enables interoperability with WCF.

Technorati: WSIT Web Services Interoperability GlassFish Vista

Wednesday Oct 04, 2006

WSIT and WCF Plugfest

"I" in WSIT stands for Interoperability. To ensure WSIT is interoperable with .NET 3.0, WSIT engineers made a third visit to Microsoft headquarters in less than a year. Microsoft hosted the third plugfest at their campus and Sun Microsystems showed up to test WSIT and GlassFish interoperability with their upcoming .NET 3.0 stack.

Harold, Mike, Jiandong, Joe, Ken and myself (all from Sun) "wsited" Microsoft last week. We were just representations of the bigger team and effort scattered all over the globe (Santa Clara, Burlington, Salt Lake City, Portland, Prague, Germany, France, Bangalore). And then there were some engineers doing remote testing as well.

As mentioned earlier, WS-Addressing functionality in JAX-WSA is cleaned up and now an integral part of  JAX-WS 2.1 RI. That has been my focus for the past few weeks. So in this plug-fest, I took our JAX-WS 2.1 RI for interop on WS-Addressing test cases. Microsoft has caused a few interop problems with WS-Addressing in the past (Member Submission policy assertion namespace change, incorrect Action from WCF client, WS-Addressing WSDL namespace change). But this time everything worked, it just worked. And that's what is out-of-the-box interoperability.

Other than that, we had a good success rate doing interop on WS-Atomic Transactions, WS-Reliable Messaging, WS-Secure Conversation, WSS 1.0 and 1.1, WS-Trust. We achieved interop on composite scenarios like Secure Reliable Messaging and Secure MTOM. And this interop is two-way meaning that WCF client invoke WSIT endpoint and WSIT client invoke WCF endpoint.

We care about "I", the most, in WSIT. GlassFish v2 now integrates WSIT bits on a regular basis. When GlassFish v2 goes final, be assured it will be interoperable with .NET 3.0 framework shipping in Windows Vista and other platforms.

Read about our success stories from first and second plugfests.

Technorati: WSIT Interoperability Indigo WCF Dotnet

Tuesday Oct 03, 2006

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:


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.

Technorati: WSIT Web-services  WCF Interoperability WSIT

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


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


« July 2016