Arun Gupta, Miles to go ...

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]

WSIT install on GlassFish v2 Milestone 1

GlassFish v2 Milestone 1was released last week. The scripts to install WSIT on this release did not work because of a change in domain.xml script that was breaking the WSIT install script (wsit-on-glassfish.xml). I fixed the script and got a positive report this morning that the fix is indeed working (always fun!).

So if you are you installing WSIT on GlassFish v2 Milestone 1 and it's not working, then this could be one highly likely reason. The solution is to update your workspace, rebuild and then install on GlassFish. This install script will however not work with GlassFish builds prior to v2 Milestone 1.

Leave a comment if you see any other problem.

Posted by Arun Gupta in webservices  |  Comments[0]

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 Web-services WCF Indigo GlassFish

Posted by Arun Gupta in webservices  |  Comments[0]

WSIT Anonymous checkout

As of Aug 14, 2006, java.net community has 262,445 members and growing. Each of these members can check out any of the 3131 projects (as of 8/14) and view the underlying source code, web pages and other content. There are numerous benefits to become a java.net member. I definitely encourage you to join the community but in case you choose not to, you can still check out the the projects using anonymous checkout. 

For example, given below is the command to checkout the WSIT workspace using anonymous account ("guest":

cvs -d :pserver:guest-AT-cvs.dev.java-DOT-net:/cvs co wsit/wsit

Check out the WSIT workspace, try it and send us feedback.

Posted by Arun Gupta in webservices  |  Comments[0]

Marathon training: More mental than physical

Practicing for a marathon, to me, is a more mental exercise than physical. I think physically most of us are capable of completing a marathon but training requires motivation, discipline and perseverance. All of these come are mental rather than physical aspects of human psychology. And of these motivation is the MOST important since others follow.

I love running and have been self motivated so far. I found a running buddy few weeks ago but that's only 2-3 days a week. Mostly it's me running alone on rest of the days and all my long runs, for instance, are alone only. I have approx 8 more weeks of intense training and then the taper down starts. Having run slightly over 400 miles in past 11 weeks, I'm hoping to stay motivated all through out.

This article (Getting the MOST Out of Training) accurately summarizes the importance of mental training for a race. Here is a great quote from the article:

"Far too often runners look at mental and physical training separately and this disconnect is usually most evident during training."

 Here are some other articles on staying motivated through the training:

1. Marathon Motivation (poem)
2. 25 reasons to run
3. Running motivation tips and techniques - Great quote from the article "Seek motivation first and the desire to run, and run successfully, will surely follow."
4. 10 Guaranteed Ways To Burst With Motivation
5. Psychology - 4Cs (Concentration, Confidence, Control and Commitment)

George W Bush is the only president to have run a marathon. He completed 1993 Houston Marathon in 3:44:52 for a pace of about 8:36/mile. Now that's another source of inspiration for some

Technorati: Marathon Training Running Motivation

Posted by Arun Gupta in Running  |  Comments[1]

Message Logging in WSIT

Updated properties available here.

THE FOLLOWING PROPERTIES ARE PROPRIETARY.  THEY CAN AND WILL CHANGE.

We are providing this information to help with development and debugging.  These properties should not be used in deployments.

WSIT Pipeline Assembler exposes multiple system properties to enable SOAP message logging using DumpPipe. Each property, if it's value is set to true, injects a DumpPipe before or after a WSIT component pipe in the pipeline. This allows the developer to monitor message dumps at several points through out the pipeline, for example before and after encryption.

The legend that derives the property names is given below. A detailed list of property names and their injection points are given in the table further below. Example usages of these properties is given at the end.

Legend:

1. com.sun.xml.ws.runtime.client prefix indicates client-side properties
2. com.sun.xml.ws.runtime.server prefix indicates server-side properties
3. .after suffix indicates after (before) on client outbound (inbound) and server inbound (outbound).
4. .before suffix indicates before (after) on client outbound (inbound) and server inbound (outbound). 

Example:

1. If a message dump is required before and after the message is processed by WS-A pipe on the client outbound, then the following properties need to be set:
   
   -Dcom.sun.xml.ws.runtime.client.wsa.before=true and -Dcom.sun.xml.ws.runtime.client.wsa.after=true
2. If a message dump is required before the message is sent and after it is received on the client, then the following property need to be set:
   
   -Dcom.sun.xml.ws.runtime.client=true 
3. If all messages received by the RM pipe on server-side needs to be captured, then the following property need to be set:
   
   -Dcom.sun.xml.ws.runtime.server.wsrm.before=true

Notes:

1. com.sun.xml.ws.runtime.client and com.sun.xml.ws.runtime.client.transport produce identical message dumps but allows an extensibility point if any other processing is required after the Transport pipe. This is valid for com.sun.xml.ws.runtime.server and com.sun.xml.ws.runtime.server.transport.

Technorati: WSIT SOAP Web Services Web-services

Posted by Arun Gupta in webservices  |  Comments[0]

wsmonitor (Web Services Monitor): A light-weight SOAP and HTTP Traffic Monitoring tool

This tool, wsmonitor, is a light-weight, easy to use SOAP and HTTP traffic monitoring tool. This tool uses port forwarding to capture the SOAP messages and HTTP headers between a sender and a receiver and displays them nicely formatted in a graphical user interface. The key features are:

• Easy to use
• Light weight
• Displays XML- formatted SOAP message
• Separate tabs for SOAP and HTTP traffic
• Transport-level data capture

The tool is available for free download at wsmonitor.dev.java.net.

Download, use and send comments to users-AT-wsmonitor.dev.java.net.

Technorati: Web Services Web-services JAX-WS SOAP HTTP

Posted by Arun Gupta in webservices  | 

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 WSIT Tango GlassFish Indigo WCF Web Services Web-services Interoperability presos

Posted by Arun Gupta in webservices  | 

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  | 

How WS-Addressing Action header is calculated ?

W3C WS-Addressing WSDL Binding defines the sequence to follow in order to calculate the value of Action header to be sent in a client outbound SOAP message or expected in a server inbound SOAP message. The sequence is explained below:

1. If wsaw:Action is explicitly associated with wsdl:input message, then use that. For example,

<portType name="wsaTestPortType">
  <operation name="echo">
    <input message="service:wsaEchoInMessage" wsaw:Action="http://example.org/action/echoIn"/>
    <output message="service:wsaEchoOutMessage" wsaw:Action="http://example.org/action/echoOut"/>
  </operation>
</portType>

The expected (or generated) Action in this case is "http://example.org/action/echoIn".

2. If wsaw:Action is not specified on the wsdl:input message and non-empty soapAction is specified on wsdl:binding/wsdl:operation, then use that. For example,

<wsdl:binding name="wsaTestSoap11Binding" type="service:wsaTestPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
  <operation name="echo">
    <soap:operation style="document" soapAction="http://example.org/soapaction/echoIn"/>
    <input>
      <soap:body use="literal"/>
    </input>
    <output>
      <soap:body use="literal"/>
    </output>
  </operation>

The expected (or generated) Action in this case is "http://example.org/soapaction/echoIn".

3. If wsaw:Action is not specified on the wsdl:input message and either soapAction is not specified or specified with empty string as it's value, then use the default action pattern. For example,

<definitions targetNamespace="http://example.org/wsaTestService" ...>
  ...
  <portType name="wsaTestPortType">
    <operation name="echo">
      <input message="service:wsaEchoInMessage"/>
      <output message="service:wsaEchoOutMessage"/>
    </operation>
  </portType>
  ...
  <binding name="..." type="tns:wsaTestPortType">
    <soap:binding style="document" transport="..."/>
    <operation name="echo">
      <soap:operation soapAction="">
      ...
    </operation>
  </binding>
</definitions>

In the binding above, soapAction's value is an empty string. The binding could alternatively be defined as (no soapAction):

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

The expected (or generated) Action in either case is "http://example.org/wsaTestService/wsaTestPortType/echoRequest".

In all the above cases, WSIT-enabled endpoint generates the correct Action header on the client outbound message and expects the same on the server inbound.

Download WSIT and get started on standards compliant and interoperable Web services.

Posted by Arun Gupta in webservices  | 

Breathing and Running

I've made a new friend on my running trail couple of weeks ago and we were talking about breathing styles. After 9 weeks of marathon training, I realized I've not read much on breathing so here is my learning over the past few days. There are a few terms associated with breathing:

• Inhale/Exhale method - Breath can be inhaled through mouth only, through nose only, through mouth and nose. Combine that with an exhale and there is a 3 X 3 matrix.
• Breath Control - Either chest or belly may be used to inhale/exhale. Belly breathing allows you to inhale more Oxygen and exhale more Carbon dioxide.
• Breathing Rhythm - When running you could inhale during 2 steps and then exhale during next 2 steps. Each of this could differ depending upon the length and pace of the run.

All these terms are nicely explained here.

For the first couple of miles, I tend to breath through nose only but then I switch to mouth and nose inhale/exhale pattern. I need to practice on belly breathing since I realize I'm a chest breather and runs out of breath when I run faster than my regular pace for few miles. I've not tried calculating my rhythm but I think it's mostly 2/1 during fast runs and 2/2 during normal pace.

Here are a few articles that I found helpful:

• Are you a noser ? - Open up your breathing.
• Nose Breathing - Forum discussion on nose and mouth breathing.
• Cadence Breathing - Explains Breathing rhythm.
• Breathing @ RunnersWorld - "Breathe through your mouth. Breathe through your nose. Suck the air in through your ears, if you can."
• Breathe Right And Win - Breathing techniques for different sports.
• Running Economy - talks about stride length and rate and correlate with breathing rhythm.
• Running Tips - Scroll to the bottom of the page for a good read on Belly breathing.

And here are my lessons on breathing:

• Just breathing through nose can cause hyperventilation, so breathing through both nose and mouth is better.
• Mouth should be open slightly and jaw completely rested. This is also called as "dead fish" position because that's what it looks like.
• Belly breathing is better than chest breathing since you are breathing in more Oxygen and exhaling more Carbon dioxide. I need to practice this.
• Don't try to achieve 2/2 or 2/1 or 3/1. Do what feels right, is comfortable to you, and go with the rhythm of your body. 

Technorati: Breathing Finess Running Marathon

Posted by Arun Gupta in Running  |