Wednesday Feb 18, 2009

Sun Tech Days Hyderabad 2009

India has always had the largest number of attendees of all the Tech Days, and this time is certainly no exception. 10,000+ attendees, the passion for technology, the eagerness to share their work, and everything else makes it certainly one of the most exciting venues for Tech Days.

The Hyderabad International Airport is certainly very impressive - big, clean, and very 21st centurisque with a 8-lane freeway connecting to the main city.

See a short video as the attendees were allowed to enter the Hyderabad International Convention Center (the venue for Tech Days):

I got a chance to talk to the General Manager of the convention center and very happy to know that similar convention centers are planned for Pune (1/2 the size of existing one), Mumbai (4x), and Bangalore (2x) in the near future.

As part of the opening, there was an excellent performance by an 11-year old percussionist, enjoy the video here:

Absolutely stunning performance!

It was funny, I was standing right next to the boy's parents while recording the video. Apparently the boy was allotted 10 minutes and the parents were trying their best to distract the boy right at the beginning of 11th minute :)

I presented on:
  • WSIT: Security, Reliability, Transactional, and .NET-interoperable Web services (slides). The screencast #ws7 is the demo shown during the talk.
  • GlassFish & Future of Java EE (slides)
There were 1000+ attendees in both the sessions and had some very interactive discussions post session. It was a great opportunity to meet lots of local Campus Ambassadors, students using GlassFish for their projects, engineers using GlassFish for their development/deployment, Sun colleagues and lots of other folks!

Here are some of the pictures:

And finally the evolving album:

Technorati: conf suntechdays glassfish metro wsit hyderabad

Friday Dec 21, 2007

Metro 1.0.1 and 1.1 are now available

Metro 1.0.1 (integrated in GlassFish v2 UR1) ad Metro 1.1 are now released. Metro contain stable releases of JAX-WS RI and WSIT. Read Vivek's blog for more details.

Even though Metro 1.1 is a stand-alone release, it can be easily installed on an existing GlassFish instance (for example override on v2ur1). A later release of Metro 1.1 will be integrated in GlassFish v2.1. Metro Roadmap provides all the details.

Please send us your feedback on users@metro or Forum. A pleasant change that happened earlier today was that cross-posting was enabled between user's list and forum. So all the questions posted on user's list are cross-posted to Forum and vice versa. This enables wider audience for your questions and more engineers to respond back :)

Technorati: webservices metro jax-ws wsit glassfish v2ur1

Thursday Aug 09, 2007

Understanding Security Token Service - New Whitepaper

Jiandong announced a new whitepaper: Building Trust in Web Services with Security Token Service. This papers explains how Security Token Service (STS) enable exchange of interoperable security tokens. It also explains how multiple STSs can be chained across security domains to realize Brokered Trust pattern. And then it provides a high-level architecture and the major components of the framework in Metro Web services stack for building a STS.

In an earlier entry, Jiandong explained how NetBeans WSIT module (part of Metro) can be used to build a STS. In a related entry, Shyam explained the extension points to implement STS according to a specific business requirement.

And this 26-page article provides a complete overview of how Metro provides an implementation of key WS-\* specifications.

Technorati: webservices metro wsit glassfish whitepaper

Thursday Aug 02, 2007

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:

    <binding name="Binding1">
      <reliableSession />
      <compositeDuplex />
      <oneWay />
                     writeEncoding="utf-8" />
      <httpTransport authenticationScheme="Anonymous"
                     useDefaultWebProxy="true" />

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", 
public interface ICalculatorDuplex
  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;

Generated WSDL

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

  <wsrm:RMAssertion xmlns:wsrm="">
    <wsrm:InactivityTimeout Milliseconds="600000" /> 
    <wsrm:AcknowledgementInterval Milliseconds="200" /> 
  <cdp:CompositeDuplex xmlns:cdp="" /> 
  <ow:OneWay xmlns:ow="" /> 
  <wsaw:UsingAddressing /> 

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">

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 "" 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;


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="" xmlns:a="">
    <a:Action s:mustUnderstand="1"></a:Action>
    <a:To s:mustUnderstand="1">http://localhost:8888/</a:To>
    <CreateSequence xmlns="">

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="" xmlns:a="">
    <a:Action s:mustUnderstand="1"></a:Action>
    <a:To s:mustUnderstand="1"></a:To>
    <CreateSequenceResponse xmlns="">

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 ?


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

Wednesday Aug 01, 2007

SOAP Message Logging in Metro and WCF

Metro provides Secure, Reliable, Transactional and .NET 3.0 interoperable Web services stack in GlassFish. This entry explains how to enable SOAP message logging in Metro and .NET 3.0.

The SOAP message logging in Metro is explained here.

In WCF (the Web services stack in .NET), the Configuration Editor Tool is the preferred way to enable SOAP message logging. But sometimes you may want to directly edit your configuration file, for example, if you do not want to re-generate the file again. In such cases you can include the XML fragments from the template configuration file given below into your application specific configuration and this will enable only SOAP message logging:

<?xml version="1.0" encoding="utf-8"?>
      <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
          <add type="System.Diagnostics.DefaultTraceListener" name="Default">
            <filter type="" />
          <add name="ServiceModelMessageLoggingListener">
            <filter type="" />
      <add initializeData="LOG_DIRECTORY\\messages.svclog"
           type="System.Diagnostics.XmlWriterTraceListener, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089"
           name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
        <filter type="" />
      <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtTransportLevel="true" />

After the client application is invoked, all SOAP messages will be logged to LOG_DIRECTORY\\messages.svclog file. The message log can be viewed using svctraceviewer.

Technorati: wcf webservices wsit metro glassfish

Tuesday Jul 31, 2007

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

Sunday Jul 22, 2007

Metro on Tomcat 6.x

Rama described how to run JAX-WS samples with Tomcat 6.x. JAX-WS is part of Metro - the Web services stack in GlassFish. Another key component of Metro is WSIT (aka Project Tango) that provides Secure, Reliable, Transactional and Interoperable Web service. Read more about Project Tango in this 26-page article.

A stable version of Metro is integrated in GlassFish V2 and the latest nightlies of stand-alone bundle are also available. The stand-alone bundle comes with an install scipt (wsit-on-tomcat.xml) that allows it install on Tomcat 5.x. I followed the steps in Rama's blog to install Metro on Tomcat 6.x. But first, a little bit of explanation and then the actual code fragments.

Tomcat's classloading mechanism has changed slightly between 5.x and 6.x. The first change is that Tomcat 5.x used to have shared/lib directory to share classes across all web applications. This directory in turn used to be specified as value of shared.loader property in  conf/ In Tomcat 6.x, the property still exists but it's value is set to nothing and shared/lib directory no longer exists in the default installation. I see the motivation behind this change as it keeps the Tomcat installation directory clean and any shared resources can still be specified in conf/ But this means that wsit-on-tomcat.xml script, that copies the files in shared/lib directory, will work on Tomcat 5.x only. In order for this script to work on Tomcat 6.x, the value of shared.loader property need to be changed to include Metro jars.

Now, the code fragments! The value of shared.loader property in Tomcat 5.x is:


And in Tomcat 6.x is the value of this property is:


If Metro is installed in c:\\metro then changing its value to:


will enable Tomcat 6.x to host Secure, Reliable, Transactional and .NET 3.0-Interoperable Web services. And this mechanism will work for Tomcat 5.x too, so changing the value of this property in Tomcat 5.x installation to:


instead of copying the files in shared/lib will be sufficient as well.

The second change in Tomcat's classloading mechanism is required if you are using Java SE 6. Tomcat 5.x used to have common/endorsed directory which no longer exists in Tomcat 6.x. Java SE 6 is bundled with JAX-WS 2.0 and Metro needs JAX-WS 2.1. So if you are using Java SE 6 then copy webservices-api.jar in c:/jdk6/jre/lib/endorsed directory. Read Endorsed Directory Mechanism for more details.

Several screencasts are available that show how to develop Secure, Reliable and Transactional and Interoperable Web service. All the screencasts use NetBeans IDE but if you are more of a command-line user then follow this entry that shows how to develop a reliable endpoint and invoke it from WCF and vice versa.

Technorati: metro webservices wsit jax-ws glassfish tomcat

Friday Jul 13, 2007

users@metro = users@wsit + users@jax-ws

Metro - the Web services stack in GlassFish - was announced recently. It was basically creating a single entity for two related projects - JAX-WS RI and Project Tango. The next logical step is to create a single place where users can ask questions and search for already existing answers. Here are some of the changes Koshuke made in that direction:

We are working on consolidating the JAX-WS and JAXB and WSIT forums as well.

Technorati: metro webservices wsit jax-ws glassfish

Wednesday Jul 11, 2007

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

Tuesday Jul 10, 2007

Project Tango: An Overview - New Article

TheServerSide announced the availability of Project Tango: An Overview article. This 26-page article provides a comprehensive overview of Project Tango explaining topics such as:

  • What is Project Tango ?
  • What features does it provide ?
  • How is it related to Metro and GlassFish ?
  • How NetBeans IDE provide a simple and intuitive Tango programming model ?
  • How Project Tango can be used to solve real-life scenarios ?

And lots of other details.

Project Tango (Web Services Interoperability Technology or WSIT) is an open source implementation from Sun Microsystems of the key enterprise Web services specifications, commonly known as WS-\*, that provides interoperability with .NET 3.0 framework. This article is a good starting place if you don't know anything about Project Tango. If you are already familiar then it serves as a good reference with all different aspects of Project Tango.

Please leave a comment on this blog for feedback.

Technorati: tango wsit webservices glassfish netbeans theserverside whitepaper


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