Thursday Aug 16, 2007

TOTD #2: Change the endpoint address on a pre-generated Web services Stub

The client-side stubs generated by JAX-WS (part of Metro) are pre-configured with the endpoint address specified in the WSDL. This allows you to invoke the endpoint directly without any additional configuration. However there may be a need to send the exact same Web service request to an endpoint hosted at a different address. For example, the stubs may be generated from a WSDL hosted in the test environment and the request needs to be sent to an endpoint hosted in production environment that is very likely to be on a different machine.

This tip tells you how to change the endpoint address on a pre-generated stub so that it invokes a different endpoint.

The code to invoke a pre-configured stub (using the endpoint address from the WSDL) looks like:

Hello port = new HelloService().getHelloPort();
String result = port.sayHello("Duke!");

As per the JAX-WS 2.1 specification, each proxy implements javax.xml.ws.BindingProvider interface. In order to invoke an endpoint whose address is different from the one specified in the WSDL, you need to insert the following line between the two lines shown above:

((javax.xml.ws.BindingProvider)port).getRequestContext().put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "NEW_ADDRESS_HERE");

Just replace NEW_ADDRESS_HERE with your new endpoint address and the exact same request will be directed to the new endpoint. The WSDL contract must be exactly same though otherwise you may get an exception back.

Please leave suggestions on TOTD that you'd like to see. A complete archive is available here.

Technorati: totd webservices metro soap glassfish

TOTD #1: SOAP Messaging Logging in Metro

I'm starting a new series today called Tip Of The Day. In this series I'll respond to technical questions asked directly to me, on forums or other aliases. These questions might have been answered else where and this will be a summary of such tips in that case.

This tip tells how to monitor SOAP messages in Metro (the Web services stack in GlassFish). There are couple of ways to monitor SOAP messages:

  1. For client-side message logging, set system property com.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true. For server-side message logging, set system property com.sun.xml.ws.transport.http.HttpAdapter.dump=true.

  2. If you want more fine-grained logging, then consider using the logging properties defined here.

Another option is to use wsmonitor.

How do you monitor SOAP messages ?

Technorati: totd webservices metro soap glassfish

Monday Dec 04, 2006

Message Logging in WSIT Updated

An update to original set of properties is now available.

THE FOLLOWING PROPERTIES ARE PROPRIETARY.  THEY MAY 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. The table also shows a convenience property, com.sun.xml.ws.assembler.XXX.action, that displays only the wsa:To and wsa:Action header on XXX (client or server) inbound and outbound messages.  

Legend:

  1. com.sun.xml.ws.assembler.client prefix indicates client-side properties
  2. com.sun.xml.ws.assembler.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). 

Table 1: List of property names and injection points

Property Name Location
Client-side Properties
com.sun.xml.ws.assembler.client Right before (after) the message is sent (received) on client outbound (inbound)
com.sun.xml.ws.assembler.client.action wsa:To and wsa:Action header value on client outbound and inbound
com.sun.xml.ws.assembler.client.transport Right before (after) Transport pipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wss.after Right after (before) SecurityPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wss.before Right before (after) SecurityPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wsrm.after Right after (before) RMPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wsrm.before Right before (after) RMPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wstx.after Right after (before) TxPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wstx.before Right before (after) TxPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wsa.after Right after (before) WsaPipe on client outbound (inbound)
com.sun.xml.ws.assembler.client.wsa.before Right before (after) WsaPipe on client outbound (inbound)
Server-side Properties
com.sun.xml.ws.assembler.server Right after (before) the message is received (sent) on server inbound (outbound)
com.sun.xml.ws.assembler.server.action wsa:To and wsa:Action header value on server inbound and outbound
com.sun.xml.ws.assembler.server.transport Right after (before) Transport pipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wss.before Right before (after) SecurityPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wss.after Right after (before) SecurityPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wsa.before Right before (after) WsaPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wsa.after Right after (before) WsaPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wsmex.before Right before (after) MexPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wsmex.after Right after (before) MexPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wsrm.before Right before (after) RMPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wsrm.after Right after (before) RMPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wstx.before Right before (after) TxPipe on server inbound (outbound)
com.sun.xml.ws.assembler.server.wstx.after Right after (before) TxPipe on 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.assembler.client.wsa.before=true and -Dcom.sun.xml.ws.assembler.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.assembler.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.assembler.server.wsrm.before=true

Notes:

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

Technorati: WSIT SOAP Web-services

Tuesday Aug 15, 2006

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). 

 

Table 1: List of property names and injection points

Property Name Location
Client-side Properties
com.sun.xml.ws.runtime.client Right before (after) the message is sent (received) on client outbound (inbound)
com.sun.xml.ws.runtime.client.transport Right before (after) Transport pipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wss.after Right after (before) SecurityPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wss.before Right before (after) SecurityPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wsa.after Right after (before) WsaPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wsa.before Right before (after) WsaPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wsrm.after Right after (before) RMPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wsrm.before Right before (after) RMPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wstx.after Right after (before) TxPipe on client outbound (inbound)
com.sun.xml.ws.runtime.client.wstx.before Right before (after) TxPipe on client outbound (inbound)
Server-side Properties
com.sun.xml.ws.runtime.server Right after (before) the message is received (sent) on server inbound (outbound)
com.sun.xml.ws.runtime.server.transport Right after (before) Transport pipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wss.before Right before (after) SecurityPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wss.after Right after (before) SecurityPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wsa.before Right before (after) WsaPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wsa.after Right after (before) WsaPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wsmex.before Right before (after) MexPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wsmex.after Right after (before) MexPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wsrm.before Right before (after) RMPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wsrm.after Right after (before) RMPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wstx.before Right before (after) TxPipe on server inbound (outbound)
com.sun.xml.ws.runtime.server.wstx.after Right after (before) TxPipe on 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

Thursday Aug 10, 2006

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 JAX-WS SOAP HTTP

About

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

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today