Arun Gupta, Miles to go ...

BizTalk Services SDK, GlassFish and Metro

Microsoft BizTalk R11 CTP was released last week and now contains a sample that is based on GlassFish, Metro and NetBeans. Even though today is April 1st, this is not intended to be an April Fool's Day joke. Read more about the sample in this blog entry. The relevant bits from the entry are quoted below:

The sample shows how to use the BizTalk Services Identity Security Token Service (STS) to secure the communication between a Java client and a Java service providing federated authentication and claims-based authorization. The sample, which you can find in ./Samples/OtherPlatforms/StandaloneAccessControl/JavaEE5 once you installed the SDK, is a pure Java sample not requiring any of our bits on either the service or client side. The interaction with our services is purely happening on the wire.

The Metro team over at Sun Microsystems has made a very significant contribution to making this all work. Before we started making changes to accommodate Java, there would have been very little hope for anyone to get this seemingly simple scenario to work. We had to make quite a few changes even though our service did follow the specs.

As a result of this collaboration, Metro 1.2 is going to be a better and more interoperable release for the Sun's customers and the greater Java community and BizTalk Services as well as our future identity products will be better and more interoperable, too. Win-Win. Thank you, Sun.

Thank you Microsoft for adding this sample to the BizTalk Services SDK.

Metro team demonstrated a similar demo at JavaOne 2007. The demo shows how an Excel 2007 client can invoke a secure and reliable endpoint deployed on GlassFish. The entire source code for the sample, along with instructions to build, are available here.

This is possible today because of our participation in previous 6 plugfests (Mar 2008, Nov 2007, Jul 2007, Oct 2006, Mar 2006, Nov 2005) hosted by Microsoft.

Technorati: glassfish netbeans metro webservices biztalk microsoft interoperability

Posted by Arun Gupta in webservices  |  Comments[3]

Silicon Valley Code Camp Trip Report

Rama and I presented on Metro and jMaki in Silicon Valley Code Camp last Saturday. Here are the pictures

It was good to meet Peter Kellner (SVCC Orgaznier, Aaron Houston (Program Coordinator for JUGs), Van Riper (Silicon Valley JUG Founder), Kevin Nelson (Silicon Valley Web JUG Founder), Juval Lowy (of iDesign) and many others.

And here is a recap of the question/answers asked during the two sessions:

• Takes 2 Tango: Java and .NET Interoperability
  • Are slides available ?
    
    Yes, very well. They are available here. A link to the demos shown in the talk is available at:
     
    • Excel 2007 (source code, screencast)
    • NetBeans 6 screencast demo (screencast)

  • There are changed signatures when using JAX-WS 2.1.3 with JDK 6. How does it work ?
    
    JDK 6 U3 contains JAX-WS 2.0 APIs. JAX-WS 2.1.x contains JAX-WS 2.1 APIs. In order to override the default APIs, the endorsed directory mechanism needs as explained here.

  • How can I send PDF files in SOAP messages ?
    
    Metro implements MTOM/XOP that allows to send any form of binary attachments (including PDF).
  • How do I achieve higher performance in Web services messages ?
    
    Metro is a high-performance stack. It can be further boosted by using FastInfoset that uses standard binary encoding for the XML Infoset.
  • How does a client know the request expects a String or Integer ?
    
    The JAXB specification defines Java-to-XML and XML-to-Java mapping. JAX-WS uses JAXB for mapping of all XML schema to Java constructs..
• jMaki: Multiple Languages, Multiple Toolkits
  • Are slides available ?
    
    Yes, very well. They are available here. A link to the demos shown in the talk is available at:
     
    • jMaki Maps mashup
    • jMaki on Rails
    • Sun Tech Days
  • How can the messages in jMaki be localized ?
    
    Client-side localization is achieved using JSON on the client and is described here. Server-side localization will use property files and will be delivered in the next release.
  • What part of Flash is supported ?
    
    Flash can be wrapped and the only example we have is jMaki sound. In general, jMaki strives to be 100% plug-in free.
  • How much support is available in Eclipse ?
    
    The jMaki plugin for Eclipse is available here. A detailed screencast showing all the steps clearly is available here.
  • Why do we use embedded JavaScript instead of keeping it in a separate .js file ?
    
    Even though jMaki does not promote embedded JavaScript, but in this case we have to use it to get the correct JavaScript parameters in. There is easy way in a platform neutral way around this to allow for multiple calls back to the server. There is a complicated alternative that requires more steps and that's why not followed.
  • Can custom layouts be used for index.jsp ?
    
    Yes, jMaki layouts are CSS-based and can be replaced with any standard CSS.
  • How much drag/drop support is available in NetBeans/PHP ?
    
    NetBeans PHP support is available in Daily Build. Once PHP support is baked, jMaki modules will be made available.
  • What are minimum browser requirements for jMaki ?
    
    jMaki runs on all current generation of browsers as mentioned here.Here is the list:
     
    • IE 6 and 7 on Windows XP and Vista
    • Firefox 1.5 and 2.x on Solaris, Linux, Windows XP/Vista
    • Safari 2.x and Firefox 1.5 on Mac OS X
  • Can jMaki CSS layouts be used instead of Rails layouts ?
    
    This functionality is not available in jMaki 1.0. However you can create a Stylized RHTML using jMaki CSS layouts.

Next stop, GlassFish Day @ Beijing.

Technorati: conf siliconvalleycodecamp metro webservices interoperability jmaki web2.0 glassfish netbeans

Posted by Arun Gupta in webservices  |  Comments[2]

Metro & jMaki @ Silicon Valley Code Camp - FREE event on Oct 27 & 28

	Metro (Takes 2 to Tango: Java Web services and .NET interoperability)	Room 4306	Saturday (10/27)	11:15am
	jMaki: Multiple Languages, Multiple Toolkits	Room 4204	Saturday (10/27)	1:45pm

Venue: Foothill College, Los Altos Hills, CA

In the first session (Metro), I'll show how Metro enables interoperability with .NET 3.0 platform. The talk shows how a Secure and Reliable Web service deployed on GlassFish V2 can be invoked from Excel 2007 spreadsheet. It also shows how such a Web service can be easily built using NetBeans 6 IDE.

The second talk explains how jMaki provides a light-weight framework to build Ajax-enabled applications using standard practices and using the best toolkits and libraries. Using multiple demos, it shows how this framework spans multiple languages.

Aaron promised to distribute some nice goodies if you attend these two talks :)

Technorati: conf siliconvalleycodecamp metro webservices interoperability jmaki web2.0 glassfish netbeans

Posted by Arun Gupta in webservices  |  Comments[6]

Excel using WSIT - Metro and .NET interoperability sample

If you attended JavaOne 2007 or any other conference afterwards where Metro (JAX-WS + WSIT/Tango) team presented, then you've probably seen this demo. The demo shows an Excel 2007 spreadsheet invoking a Secure and Reliable endpoint deployed on GlassFish. Today, I'm announcing the availability of the WSIT endpoint and Excel client code with full instructions to build, deploy and run the sample. Metro Release Candidate 1 was announced recently and is integrated in GlassFish RC4. You can learn more about .NET interoperability aspects of Metro by watching this deep dive interview or reading this 26-page article.

The source code for this sample is available in "wsit/wsit/samples/excelclient" directory. It can be checked out using the command:

cvs -d :pserver:yourid@cvs.dev.java.net:/cvs co wsit/wsit/samples/excelclient

A compressed bundle of the sample is available here.

Running the demo involves an extensive setup for .NET client. Please make sure to review the software requirements before proceeding with the installation.

Try it and send us feedback at users@metro or Metro Forum.

Technorati: webservices metro glassfish dotnet .net interoperability netbeans wcf

Posted by Arun Gupta in webservices  |  Comments[14]

wsHttpDualBinding - a non-interoperable binding

Based upon a user request, I'll explain why wsDualHttpBinding (a system-provided binding in WCF) is not an interoperable binding. This blog entry will explain the service endpoint code, client code, generated WSDL and the SOAP messages exchanged based upon the DualHttp Binding Sample that is bundled with the Windows SDK samples. This is also an update to an earlier attempt to explain wsDualHttpBinding.

In the sample, I replaced the default wsDualHttpBinding with an equivalent custom binding (after removing the security) as:

<bindings>
  <customBinding>
    <binding name="Binding1">
      <reliableSession />
      <compositeDuplex />
      <oneWay />
      <textMessageEncoding
                     messageVersion="Soap12WSAddressing10" 
                     writeEncoding="utf-8" />
      <httpTransport authenticationScheme="Anonymous"
                     bypassProxyOnLocal="false"
                     hostNameComparisonMode="StrongWildcard"
                     proxyAuthenticationScheme="Anonymous"
                     realm=""
                     useDefaultWebProxy="true" />
    </binding>
  </customBinding>
</bindings>

The wsDualHttpBinding, also known as Composite Duplex or Full Duplex Binding, provides a bi-directional communication between Client and Endpoint. In a single direction communication, the client can invoke a set of operations on a service and this interface is referred as primary interface in Duplex binding. The set of operations that a service can invoke on the client is called as callback interface.

The sample in Windows SDK is a trivial calculator service where primitive Math operations are performed in a running session on the "primary" interface and results are returned on the "callback" interface.

Service Endpoint Code

Let's understand the service endpoint code first. The "primary" service endpoint interface looks like:

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples", 
                 SessionMode=SessionMode.Required,
                 CallbackContract=typeof(ICalculatorDuplexCallback))]
public interface ICalculatorDuplex
{
  [OperationContract(IsOneWay=true)]
  void Clear();
  [OperationContract(IsOneWay = true)]
  void AddTo(double n);

  ...
}

Three points to note in this code:

• A duplex contract requires a session, because a context must be established to correlate the set of messages being sent between client and service. Even though this is specified using SessionMode=SessionMode.Required attribute but the default value of SessionMode=SessionMode.Allowed (equivalent of not specifying) will be sufficient as well. This is because all Duplex bindings in .NET maintain a transport session.

• Callback interface is specified using CallbackContract attribute.

• All the methods are declared as One-way operations otherwise the response can be returned on the transport back channel itself. The documentation on this particular binding is limited.

The "callback" interface is defined as:

public interface ICalculatorDuplexCallback
{
  [OperationContract(IsOneWay = true)]
  void Result(double result);

  ...
}

In order for a service endpoint to establish a connection with the "callback" interface on client, a CallbackChannel is obtained from the OperationContext in the implementation of the "primary" interface as:

public class CalculatorService : ICalculatorDuplex
{
  double result;
  ICalculatorDuplexCallback callback = null;

  public CalculatorService()
  {
    result = 0.0D;
    callback = OperationContext.Current.GetCallbackChannel<ICalculatorDuplexCallback>();
  }

Another variable is initialized to return the running result. The implementation of each method in the "primary" interface then invokes a method on the "callback" interface to return the running result as:

public void AddTo(double n)
{
  result += n;
  callback.Result(result);
}

Generated WSDL

Now let's look at the generated WSDL fragments. The policy assertion elements are:

<wsp:All>
  <wsrm:RMAssertion xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy">
    <wsrm:InactivityTimeout Milliseconds="600000" /> 
    <wsrm:AcknowledgementInterval Milliseconds="200" /> 
  </wsrm:RMAssertion>
  <cdp:CompositeDuplex xmlns:cdp="http://schemas.microsoft.com/net/2006/06/duplex" /> 
  <ow:OneWay xmlns:ow="http://schemas.microsoft.com/ws/2005/05/routing/policy" /> 
  <wsaw:UsingAddressing /> 
</wsp:All>

The wsrm:RMAssertion and wsaw:UsingAddressing elements are bound to a known namespace and their behavior is clearly documented. However the specification of cdp:CompositeDuplex and ow:OneWay elements are unclear at this time. This does not allow any WSDL-based interoperability whenever these elements are included.

All methods from the "primary" and the "callback" interface are generated in one wsdl:portType. The methods from the "primary" interface are generated as One-way operations. But methods from the "callback" interface are generated as Notification operation. For example, one of the methods from "callback" interface looks like:

<wsdl:operation msc:isInitiating="true" msc:isTerminating="false" name="Result">
  <wsdl:output
      wsaw:Action="http://Microsoft.ServiceModel.Samples/ICalculatorDuplex/Result"
      message="tns:ICalculatorDuplex_Result_OutputCallbackMessage"/>
</wsdl:operation>

JAX-WS, the core of Metro, supports only Request-Response and One-way operations. This is the second place where WSDL-based interoperability will not work with any JAX-WS-based WSDL import tool, such as wsimport. Moreover, the WSDL-to-Java mapping defined by the JAX-WS specification requires each wsdl:portType map to a single Java interface. This WSDL design pattern requires two interfaces to be generated from a single wsdl:portType.

There are some other elements in namespace prefix bound to "http://schemas.microsoft.com/ws/2005/12/wsdl/contract" and their purpose is also unclear. Rest of the WSDL is pretty straight-forward.

Client side code

On the client side, svcutil (WSDL importing tool for .NET 3.0) generates the "primary" and "callback" interface from the WSDL. The "callback" is implemented as:

public class CallbackHandler : ICalculatorDuplexCallback
{
  public void Result(double result)
  {
    Console.WriteLine("Result({0})", result);
  }

  public void Equation(string eqn)
  {
    Console.WriteLine("Equation({0})", eqn);
  }
}

This client instance is initialized with the callback implementation as:

class Client
{
  static void Main()
  {
    // Construct InstanceContext to handle messages on callback interface
    InstanceContext instanceContext = new InstanceContext(new CallbackHandler());

    // Create a client with given client endpoint configuration
    CalculatorDuplexClient client = new CalculatorDuplexClient(instanceContext);

And then the client invokes the service endpoint normally as shown below:

// Call the AddTo service operation.
double value = 100.00D;
client.AddTo(value);

...

SOAP messages

Lets look at the SOAP messages exchanged between client and endpoint now. The first call from the client to an endpoint triggers a protocol handshake for establishing a session. The CreateSequence protocol message looks like:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence</a:Action>
    <a:ReplyTo>
      <a:Address>http://iamfine.sfbay.sun.com/Temporary_Listen_Addresses/bfd8c103-b0f9-4c65-9cb6-fbebb7d1517b/4e0cdb31-2451-4fb6-84b8-dc286e5f26c8</a:Address>
    </a:ReplyTo>
    <a:MessageID>urn:uuid:51918652-9a78-4ba3-82f5-e68ecd664d42</a:MessageID>
    <a:To s:mustUnderstand="1">http://localhost:8888/</a:To>
  </s:Header>
  <s:Body>
    <CreateSequence xmlns="http://schemas.xmlsoap.org/ws/2005/02/rm">
      <AcksTo>
        <a:Address>http://iamfine.sfbay.sun.com/Temporary_Listen_Addresses/bfd8c103-b0f9-4c65-9cb6-fbebb7d1517b/4e0cdb31-2451-4fb6-84b8-dc286e5f26c8</a:Address>
      </AcksTo>
      <Offer>
        <Identifier>urn:uuid:b1116e69-f1dd-45b0-8495-129645038160</Identifier>
      </Offer>
    </CreateSequence>
  </s:Body>
</s:Envelope>

The WCF runtime uses the Windows HTTP.SYS library to host an endpoint at the address specified in a:ReplyTo. This address is used for all subsequent messages sent on the callback channel. This message is used to create a session for the "primary" interface. The message also carries an offer, in the SOAP Body, to create a "callback" interface session.

The CreateSequenceResponse protocol message returns "primary" interface session identifier and also accepts the offered "callback" session. The message looks like:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse</a:Action>
    <a:RelatesTo>urn:uuid:51918652-9a78-4ba3-82f5-e68ecd664d42</a:RelatesTo>
    <a:To s:mustUnderstand="1">http://iamfine.sfbay.sun.com/Temporary_Listen_Addresses/bfd8c103-b0f9-4c65-9cb6-fbebb7d1517b/4e0cdb31-2451-4fb6-84b8-dc286e5f26c8</a:To>
  </s:Header>
  <s:Body>
    <CreateSequenceResponse xmlns="http://schemas.xmlsoap.org/ws/2005/02/rm">
      <Identifier>urn:uuid:d483898c-4bd3-4077-ba04-07a9010ab27f</Identifier>
      <Accept>
        <AcksTo>
          <a:Address>http://localhost:8888/</a:Address>
        </AcksTo>
      </Accept>
    </CreateSequenceResponse>
  </s:Body>
</s:Envelope>

Now, because of the way each method is implemented (invoking callback.Result(result) method at the end of each "primary" operation), a response to a request received by an endpoint is returned over the callback channel. This happens under-the-cover even though all messages in the "primary" interface are defined as One-way operations.

The behavior is quite analogous to a Request-Response operation primitive. I wonder what are the usecases of wsDualHttpBinding ?

Summary

Finally, I summarize the reasons that makes wsDualHttpBinding a non-interoperable binding:

1. The specifications of cdp:CompositeDuplex and ow:OneWay are not available and these elements will thus be ignored by the Metro WSDL importing tool.

2. The operations from "callback" interface are mapped as Notification operation in the WSDL. This operation primitive is not supported by Metro.

3. On the service endpoint, all the operations from "primary" and "callback" interface are mapped to a single wsdl:portType. On the client side, wsdl:portType is mapped to separate "primary" and "callback" interfaces. The Java-to-WSDL mapping defined by the JAX-WS specification allows one-to-one mapping between Java interface and wsdl:portType.

Technorati: webservices interoperability wcf metro jax-ws wsit

Posted by Arun Gupta in webservices  |  Comments[8]

Transcript of Sun and Microsoft Interoperability Exchange Forum

A complete transcript of the Sun/Microsoft Expert Exchange Forum is now available. And if you still have questions, feel free to post them to users@metro or Metro Forum.

Try 3 things today:

1. Download GlassFish V2.
2. Develop and Deploy a Reliable Web service using NetBeans IDE following this screencast (complete list).
3. Read more details about Project Tango in this 26-page article.

Technorati: wsit metro webservices glassfish netbeans sun microsoft interoperability

Posted by Arun Gupta in webservices  |  Comments[1]

Fourth Microsoft Interop Plugfest Report

As reported earlier, Metro team from Sun participated in the fourth (third, second, first) Microsoft Interop Plugfest. Microsoft is working on .NET 3.5 (codename Orcas) and the focus this time was to ensure that there are no regressions with WSIT 1.0. Read Harold's report for more details.

Technorati: webservices metro plugfest glassfish microsoft interoperability

Posted by Arun Gupta in webservices  |  Comments[6]

Sun Expert Exchange FREE Forum - Sun and Microsoft Interoperability

Whether you watched Tango in Sun Net Talk or not, you can still participate in Sun Expert Exchange Forum, a FREE forum, asking questions about Sun and Microsoft interoperability. I'll be there, along with Harold Carr, to field all questions on Project Tango. And then there are experts on other topics from Sun as well.

You can read all about Project Tango in this 26-page article.

Technorati: webservices wsit sun microsoft interoperability

Posted by Arun Gupta in webservices  |  Comments[7]

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

GlassFish V2 beta3 is now available. I take this opportune moment for a follow up entry showing how a Reliable WSIT endpoint can be invoked from WCF client and vice versa. WSIT is already integrated in GlassFish V2.

The first part where a WSIT endpoint is invoked by a WCF client is now already available in this entry by Jesus Rodriguez. Couple of points in the entry:

• The Web Service configuration (a.k.a. WSIT configuration file) is not hand edited. Instead it is conveniently generated by NetBeans IDE as shown in screencast #ws3. The user experience really is to just check mark a box and all the relevant XML fragments are generated by NetBeans.
• Even though entry requires to rely on SOAP 1.1 (mistyped as WS-Addressing 1.1) , it workes with SOAP 1.2 very well. In fact, I've used SOAP 1.2 in the code below.

This entry provides the code to deploy a Reliable WCF endpoint and invoke it using a WSIT client.

1. Create a service endpoint service.svc as:
   
   <%@ServiceHost language=c# Debug="true" Service="WCFReliableEndpoint.Hello" %>

using System.ServiceModel;

namespace WCFReliableEndpoint
{
  [ServiceContract]
   public interface IHello
   {
     [OperationContract]
     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"?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="WCFReliableEndpoint.Hello" behaviorConfiguration="MetadataBehavior">
        <endpoint address=""
                  binding="customBinding"
                  bindingConfiguration="Binding1"
                  contract="WCFReliableEndpoint.IHello" />
      </service>
    </services>

    <bindings>
      <customBinding>
        <binding name="Binding1">
          <reliableSession />
            <textMessageEncoding messageVersion="Soap12WSAddressing10" writeEncoding="utf-8" />
            <httpTransport authenticationScheme="Anonymous" bypassProxyOnLocal="false"
              hostNameComparisonMode="StrongWildcard"
              proxyAuthenticationScheme="Anonymous" realm=""
              useDefaultWebProxy="true" />
        </binding>
      </customBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior name="MetadataBehavior">
          <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>

  </system.serviceModel>
</configuration>
3. If IIS was installed after Vista installation was complete, then you'll have to explicitly register WCF components with IIS following these instructions and as shown below:
   
   
4. Create a virtual directory, say wsit-reliable, in IIS mapping to the directory where service.svc and Web.config are present. You should now see the default WCF/IIS page as below:
   
   
   
   The service endpoint is now hosted at http://localhost/wsit-reliable/service.svc and the WSDL of the endpoint looks like:
   
   
5. Create a WSIT client, using NetBeans IDE, following the instructions in screencast #ws2. Enable WSIT message logging by adding the following property to domains/domain1/config/domain.xml:
   
   <jvm-options>-Dcom.sun.xml.ws.assembler.client=true</jvm-options>

6. The SOAP messages exchanged between the WSIT client and the WCF endpoint are given below:
   
   ====[com.sun.xml.ws.assembler.client:request]====
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
  <S:Header>
    <To xmlns="http://www.w3.org/2005/08/addressing">http://iamfine/wsit-reliable/service.svc</To>
    <Action xmlns="http://www.w3.org/2005/08/addressing">http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence</Action>
    <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
      <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
    </ReplyTo>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:fcaef2ab-bccf-4a08-a1d1-b10f7819f7ea</MessageID>
  </S:Header>
  <S:Body>
    <ns2:CreateSequence
        xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
        xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
        xmlns:ns4="http://www.w3.org/2005/08/addressing" xmlns:ns3="http://schemas.microsoft.com/ws/2006/05/rm"
        xmlns:ns2="http://schemas.xmlsoap.org/ws/2005/02/rm">
      <ns2:AcksTo>
        <ns4:Address>http://www.w3.org/2005/08/addressing/anonymous</ns4:Address>
      </ns2:AcksTo>
      <ns2:Offer>
        <ns2:Identifier>uuid:4953079f-3726-40b5-b6b4-255eb46c0fda</ns2:Identifier>
      </ns2:Offer>
    </ns2:CreateSequence>
  </S:Body>
</S:Envelope>
============
====[com.sun.xml.ws.assembler.client:response]====
<?xml version="1.0" ?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse</a:Action>
    <a:RelatesTo>uuid:fcaef2ab-bccf-4a08-a1d1-b10f7819f7ea</a:RelatesTo>
  </s:Header>
  <s:Body>
    <CreateSequenceResponse xmlns="http://schemas.xmlsoap.org/ws/2005/02/rm">
      <Identifier>urn:uuid:8ebe44c6-494c-4a43-8ade-dab90800d7f5</Identifier>
      <Accept>
        <AcksTo>
          <a:Address>http://iamfine/wsit-reliable/service.svc</a:Address>
        </AcksTo>
      </Accept>
    </CreateSequenceResponse>
  </s:Body>
</s:Envelope>
============
====[com.sun.xml.ws.assembler.client:request]====
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
  <S:Header>
    <To xmlns="http://www.w3.org/2005/08/addressing">http://iamfine/wsit-reliable/service.svc</To>
    <Action xmlns="http://www.w3.org/2005/08/addressing">http://tempuri.org/IHello/sayHello</Action>
    <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
      <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
    </ReplyTo>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:5ac7c151-8049-444e-8dd0-1e053b26895d</MessageID>
    <ns2:Sequence
      xmlns:ns4="http://www.w3.org/2005/08/addressing"
      xmlns:ns3="http://schemas.microsoft.com/ws/2006/05/rm"
      xmlns:ns2="http://schemas.xmlsoap.org/ws/2005/02/rm">
      <ns2:Identifier>urn:uuid:8ebe44c6-494c-4a43-8ade-dab90800d7f5</ns2:Identifier>
      <ns2:MessageNumber>1</ns2:MessageNumber>
    </ns2:Sequence>
    <ns2:AckRequested
      xmlns:ns4="http://www.w3.org/2005/08/addressing"
      xmlns:ns3="http://schemas.microsoft.com/ws/2006/05/rm"
      xmlns:ns2="http://schemas.xmlsoap.org/ws/2005/02/rm">
      <ns2:Identifier>urn:uuid:8ebe44c6-494c-4a43-8ade-dab90800d7f5</ns2:Identifier>
    </ns2:AckRequested>
  </S:Header>
  <S:Body>
    <sayHello xmlns:ns2="http://schemas.microsoft.com/2003/10/Serialization/" xmlns="http://tempuri.org/">
      <name>Duke</name>
    </sayHello>
  </S:Body>
</S:Envelope>
============
====[com.sun.xml.ws.assembler.client:response]====
<?xml version="1.0" ?>
<s:Envelope
    xmlns:s="http://www.w3.org/2003/05/soap-envelope"
    xmlns:r="http://schemas.xmlsoap.org/ws/2005/02/rm"
    xmlns:a="http://www.w3.org/2005/08/addressing">
  <s:Header>
    <r:Sequence s:mustUnderstand="1">
      <r:Identifier>uuid:4953079f-3726-40b5-b6b4-255eb46c0fda</r:Identifier>
      <r:MessageNumber>1</r:MessageNumber>
    </r:Sequence>
    <r:SequenceAcknowledgement>
    <r:Identifier>urn:uuid:8ebe44c6-494c-4a43-8ade-dab90800d7f5</r:Identifier>
    <r:AcknowledgementRange Lower="1" Upper="1"></r:AcknowledgementRange>
      <netrm:BufferRemaining xmlns:netrm="http://schemas.microsoft.com/ws/2006/05/rm">8</netrm:BufferRemaining>
    </r:SequenceAcknowledgement>
    <a:Action s:mustUnderstand="1">http://tempuri.org/IHello/sayHelloResponse</a:Action>
    <a:RelatesTo>uuid:5ac7c151-8049-444e-8dd0-1e053b26895d</a:RelatesTo>
  </s:Header>
  <s:Body>
    <sayHelloResponse xmlns="http://tempuri.org/">
      <sayHelloResult>Hello Duke</sayHelloResult>
    </sayHelloResponse>
  </s:Body>
</s:Envelope>
============

There were no custom settings or configurations required to make the WSIT client This shows, once again, that GlassFish V2 and .NET 3.0 (pre-bundled in Vista) are interoperable out of the box.

Technorati: webservices wsit glassfish reliablemessaging wcf interoperability

Posted by Arun Gupta in webservices  |  Comments[3]

Yet Another Microsoft Interop Plugfest

Microsoft announced a 3-day Web services interoperability plugfest from Jul 10-12, 2007. At Sun Microsystems, we love to Tango with Windows Communication Foundation component of .NET 3.0 framework and so we'll be participating using GlassFish V2. This may be the last plugfest before GlassFish V2 is released later this year.

As in earlier events, attendees implement a set of pre-defined scenarios based on WS-* specs using their Web services stack. They participate with implementation on their laptops and interoperate using their client and Microsoft endpoint and vice versa.

The set of scenarios are based on the following specifications:

• Basic Messaging Scenarios using protocols: SOAP1.1, SOAP1.2, WS-Addressing 2004/08 and 2005/10, MTOM
• Message Security Scenarios using WS-Security 1.0, WS-Security 1.1, WS Secure Conversation 2005/02, WS-Trust 2005/02, Username Token Profile (1.0, 1.1), X509 Token Profile (1.0, 1.1), SAML Token Profile (1.0, 1.1), Kerberos Token Profile 1.1.
• STS - Security Token Service scenarios
• Reliable Messaging using WS-ReliableMessaging v1.0 (2005/02)
• Transactions using WS-AtomicTransaction v1.0 (2004/10) and WS-Coordination v1.0 (2004/10)
• WS-Policy v1.2 (2004/09) and WS-Metadata Exchange (2004/09) are included in several scenarios
• Windows CardSpace scenarios

Microsoft is also looking for interop testing with pre-release version of .NET Framework 3.5 (codename Orcas) with the following versions of specifications:

• Message Security Scenarios using WS Secure Conversation v1.3 (2005/12), WS-Trust v1.3 (2005/12)
• RX - Reliable Messaging using WS-Reliable Messaging v1.1 (2007/02)
• Transactions using WS-Atomic Transaction v1.1 (2006/06) and WS-Coordination v1.1 (2006/06)
• WS-Policy v1.5

We run the interop tests regularly with our builds. The results for Tango M5 milestone build shows details for each technology.

Microsoft still need to work out some kinks before the real work can begin:

• The plugfest schedule still seem to be dated March
• Not all the scenarios and endpoints as mentioned in the announcement are available
• Invite logistics page is giving a 404
• Not all the endpoints are up, atleast RM endpoints are down. Anyway, the endpoints have been down at multiple instances (here, here, here, here and probably other times too!).

But we are still going to participate :) Sun's participation in the previous plugfests can be followed here.

Technorati: webservices wsit plugfest glassfish microsoft interoperability

Posted by Arun Gupta in webservices  |  Comments[7]

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 http://129.145.133.129:8080/WebApplication11/NewWebServiceService?wsdl
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
{
   [ServiceContract]
   public interface IHello
   {
       [OperationContract]
       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"?>
<configuration>
   <system.serviceModel>
       <behaviors>
           <serviceBehaviors>
               <behavior name="MetadataBehavior">
                    <serviceMetadata httpGetEnabled="true" />
               </behavior>
           </serviceBehaviors>
       </behaviors>
       <services>
           <service behaviorConfiguration="MetadataBehavior" name="WCFEndpoint.Hello">
               <endpoint address="" binding="basicHttpBinding" bindingConfiguration=""
                   name="Hello" contract="WCFEndpoint.IHello" />
           </service>
       </services>
   </system.serviceModel>
</configuration>
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}

Posted by Arun Gupta in webservices  |  Comments[1]

WSIT at TheServerSide

Read about WSIT at The Server Side Interoperability Blog.

Technorati: WSIT GlassFish Web Services Interoperability WCF Indigo

Posted by Arun Gupta in webservices  |  Comments[0]

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.

Posted by Arun Gupta in webservices  |  Comments[3]

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]

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.

Posted by Arun Gupta in webservices  |  Comments[1]