Achieving Web services interoperability between the WebSphere Web Services Feature Pack and Windows Communication Foundation, Part 1 Set up the test environment and run the samples for basic SOAP and WS-Addressing interoperability

Charles Le Vay Senior Software Engineer Web Services Interoperability Architect WebSphere Application Server Feature Pack for Web Services IBM, Research Triangle Park, NC Tom Link Advisory Software Engineer Web Services Interoperability Development IBM, Research Triangle Park, NC October, 2007 © Copyright International Business Machines Corporation 2007. All rights reserved. This article describes how to use the IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services Service Endpoint Interface samples to demonstrate interoperability with Microsoft Windows™ Communication Foundation. It provides step-by-step configurations and programming details to show you what is necessary for Web services basic interoperability for SOAP 1.1, SOAP 1.2, and WS-Addressing. This article is intended for Web services developers and architects who plan to develop Web services across these platforms. You should have a basic understanding of Java™ programming, Web services development, WSDL and SOAP. WebSphere Web Services Feature Pack Interoperability with............................................ 1 Windows Communication Foundation, Part 1.................................................................... 1 Introduction......................................................................................................................... 3

Basic Message Exchange Patterns .................................................................................. 3 Asynchronous programming model vs. asynchronous MEP.......................................... 5 Get started with the samples ........................................................................................... 8 Verify the SEI sample endpoints .................................................................................... 9 Run the SEI samples ..................................................................................................... 10

Start the SEI Samples demo UI ................................................................................ 10 Run the WCF samples .................................................................................................. 14

Start the WCF services.............................................................................................. 14 Run the WCF client .................................................................................................. 15 WCF client to WCF service Ping example ............................................................... 16 WCF client to WCF service Echo example .............................................................. 17 WCF client to WCF service Async Echo example................................................... 17

Test for basic SOAP 1.1 MEP Interoperability ............................................................ 18 Client to WCF service examples............................................................................... 18 Figure 9. Client to WCF service One-Way Ping ..................................................... 20 WCF client to Feature Pack for Web Services service examples............................. 25

WebSphere Application Server policy sets................................................................... 27 Windows Communication Foundation bindings .......................................................... 27 Define wsa:Action or SOAPAction for ........................................................................ 27 WCF interoperability .................................................................................................... 27

Define SOAPAction in the WSDL ........................................................................... 28 Define SOAPAction in the JAX-WS client .............................................................. 29

Configure the SOAP version ........................................................................................ 30 Configure the SOAP version in JAX-WS................................................................. 30 Define the.................................................................................................................. 30 SOAP version in the WSDL ..................................................................................... 30 Set the SOAP version using annotations .................................................................. 32 The SOAP version and the SEI samples................................................................... 33

Configure the SOAP version in WCF........................................................................... 33 Run the WCF samples using SOAP 1.2 ....................................................................... 39

Start SOAP 1.2 WCF services .................................................................................. 39 Test SOAP 1.2 WCF services with SOAP 1.2 WCF client .......................................... 40

SOAP 1.2 WCF client to SOAP 1.2 WCF service Ping example............................. 40 SOAP 1.2 WCF client to SOAP 1.2 WCF service Echo example............................ 40 SOAP 1.2 WCF client to SOAP 1.2 WCF service Async example.......................... 41

Test SOAP 1.2 Feature Pack for Web Services SEI client to WCF SOAP 1.2 services....................................................................................................................................... 41 Test SOAP 1.2 WCF client to Feature Pack for Web Services SOAP 1.2 services ..... 47

SOAP 1.2 WCF client to SOAP 1.2 Feature Pack for Web Services service Ping example ..................................................................................................................... 47 SOAP 1.2 WCF client to SOAP 1.2 Feature Pack for Web Services service Echo example ..................................................................................................................... 48 SOAP 1.2 WCF client to SOAP 1.2 Feature pack for Web Services service Async example ..................................................................................................................... 48

Configure WS-Addressing............................................................................................ 49 Apply the WS-Addressing policy set to the samples................................................ 49 Configure WS-Addressing using WCF bindings...................................................... 61

Test WS-Addressing configuration............................................................................... 62 Configure asynchronous over-the-wire behavior.......................................................... 63

Configure asynchronous over-the-wire behavior in a Feature Pack for Web Services client.......................................................................................................................... 63 Configure asynchronous over-the-wire behavior in WCF client or service ............. 63

Test async over-the-wire interoperability ..................................................................... 68

Test async over-the-wire Application Server to Application Server interoperability................................................................................................................................... 68 Test Application Server to WCF interoperability..................................................... 71

Summary ....................................................................................................................... 74 Resources ...................................................................................................................... 74

Specifications............................................................................................................ 74 Feature Pack for Web Services & developerWorks ................................................. 74 Windows Communication Foundation ..................................................................... 75

About the authors.......................................................................................................... 75

Introduction The WebSphere Application Server Version 6.1 Feature Pack for Web Services includes a set of Java API for XML-Based Web Services (JAX-WS) samples that demonstrate simple message exchange patterns (MEPs) using both a synchronous and asynchronous programming model. The samples support SOAP 1.1 and SOAP 1.2. Using these MEP samples composed with Web services standards such as WS-Addressing (WS-A), WS-Security, WS-Reliable Messaging (WS-RM), and WS-Secure Conversation (WS-SC), you can perform a broad range interoperability tests. These samples demonstrate the use of Java Bean artifacts, static service endpoints and proxy-based clients. The purpose of this series of articles is to highlight protocol-level interoperability between the Feature Pack for Web Services and Windows Communication Foundation (WCF) implementations. The articles will provide an explanation of the protocol level interoperability configurations used during Feature Pack for Web Services interoperability testing. The key to protocol level interoperability between the Feature Pack for Web Services and WCF is first to understand the MEP that is used, and second to configure the correct composition of Web service standards using policy sets and WCF bindings. This article focuses on setting up the test environment, running the Feature Pack for Web Services samples and the WCF samples, and basic SOAP 1.1, SOAP 1.2 and WS-Addressing configurations for interoperability. Future articles in the series will focus on topics such as interoperability between the Feature Pack for Web Services and WCF using WS-Security, WS-Secure Conversation, WS-Reliable Messaging and the composition of WS-Reliable Messaging with WS-Secure Conversation. These future articles will incorporate the test scenarios and MEPs described below, but will focus exclusively on the configurations for interoperability.

Basic Message Exchange Patterns The Service Endpoint Interface (SEI) samples were developed to drive simple MEPs used to test protocol level interoperability. Figure 1 shows the three MEPs used in the samples.

Figure 1. Basic message exchange patterns

Following is a description of these MEPs: One-way (Request) - Ping sample This scenario demonstrates a one-way MEP to send a ping application message from a client to a service. This MEP is request-only. Two-way (Request and Response) - Sync Echo sample This scenario demonstrates a two-way MEP that sends an echo string message from a client to a service and receives an echo string response from the service on the same request-response channel. This MEP is also called two-way anonymous since the client does not necessarily have to have a visible address. The client can be behind a firewall since the service sends the response back on the same channel, referred to as the backchannel, initiated by the client. For the purposes of this article, this MEP is described as Echo with synchronous over-the-wire communication or Sync Echo for short. Two-way Asynchronous (Request and Response) - Asynchronous Echo with Async Communication sample This scenario demonstrates a two-way MEP to send an echo string message from a client to a service, and expects the echo string response from the server on a different channel initiated from the service to the client. In this case, the client listens on a separate channel

Client Service

Request

Request / Response

Request

Response

One-way

Two-way

Two-way Asynchronous

to receive the response messages from a service-initiated channel. The client uses WS-Addressing to provide the ReplyTo endpoint reference (EPR) value to the service. The service initiates a connection to the ReplyTo EPR to send a response. In some Web services specifications, you might also see this MEP referred to as two-way addressable, since the client must have a visible address for the service to connect for a response.

Asynchronous programming model vs. asynchronous MEP Both JAX-WS and WCF support an asynchronous, callback programming model for Web services clients. In the callback approach, you pass a callback handler during the Web services method invocation. The handler's method is called when the response is available. The benefit of the asynchronous programming model is that the application is not blocked while waiting on the response from the Web services method invocation. It is important to note that the programming model is totally independent of the over-the-wire MEP. The asynchronous programming model applies only to the client. For a typical Web services invocation, a Web services client initiates an HTTP request containing a SOAP message to invoke the Web service and then a SOAP message containing the Web services response is returned over the same HTTP channel. This is defined as a synchronous two-way MEP over the wire. It uses a single HTTP connection. The Two-way (Request and Response) - Asynchronous Echo with Sync Communication Sample demonstrates the asynchronous programming model using a synchronous over-the-wire request and response. Therefore, the over-the-wire MEP looks identical to the Two-way (Request and Response) - Sync Echo Sample. The only difference between the two samples is at the programming layer, which determines whether the client blocks waiting for the response or not. The following are SOAP request messages for the Sync Echo Sample and Asynchronous Echo with Sync Communication Sample. They demonstrate the typical Two-way (Request and Response) MEP using the same HTTP channel. Notice that the request and response messages are virtually identical, other than the echoInput and echoResponse, which is intentional. The echoInput and echoResponse are different so that you can identify and differentiate the two messages. Sync Echo (Request) message <?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body>

<ns2:echoStringInput

xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">

<echoInput>Sync Echo</echoInput>

</ns2:echoStringInput>

</soapenv:Body>

</soapenv:Envelope>

Sync Echo (Response) message <?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body>

<ns2:echoStringResponse

xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">

<echoResponse>JAX-WS==&gt;&gt;Sync Echo</echoResponse>

</ns2:echoStringResponse>

</soapenv:Body>

</soapenv:Envelope>

Asynchronous Echo with Sync Communication (Request) message <?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body>

<ns2:echoStringInput

xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">

<echoInput>Async Echo with Sync Communcation</echoInput>

</ns2:echoStringInput>

</soapenv:Body>

</soapenv:Envelope>

Asynchronous Echo with Sync Communication (Response) message <?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body>

<ns2:echoStringResponse

xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">

<echoResponse>JAX-WS==&gt;&gt;Async Echo with Sync

Communcation</echoResponse>

</ns2:echoStringResponse>

</soapenv:Body>

</soapenv:Envelope>

An asynchronous over-the-wire MEP can be defined by a Web services client initiating an HTTP request that contains a SOAP message to invoke the Web service, which is

accepted by the Web services endpoint. The SOAP message containing the Web services response is then returned on a separate HTTP request initiated from the Web services to the Web services client. Another way to look at this is that the asynchronous over-the-wire message pattern is simply two separate one-way message patterns: one from client to service and the other from service to client. Therefore, it uses two separate HTTP connections. The Two-way (Request and Response) - Asynchronous Echo with Async Communication Sample demonstrates both the asynchronous programming model and the asynchronous over-the-wire message pattern. The SOAP request messages for the Asynchronous Echo with Async Communication and Sync Echo Sample with WS-Addressing policy set applied are provided below. Note that the WS-Addressing information is different for the two MEPs. The asynchronous over-the-wire request message contains a ReplyTo address for where the Web services client will be listening for the response. The synchronous over-the-wire MEP does not contain a ReplyTo. According to WS-Addressing, if the ReplyTo is not specified, the response is sent to the source endpoint, which implies the use of the same HTTP channel. Asynchronous Echo with Async Communication <?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsa="http://www.w3.org/2005/08/addressing">

<soapenv:Header>

<wsa:To>http://localhost:9081/WSSampleSei/EchoService</wsa:To>

<wsa:ReplyTo>

<wsa:Address>http://localhost:9081/IBM_WS_SYS_RESPONSESERVLET/services/Ec

hoService.Ec

hoServicePort/anonOutInOp?IBMwebservicesID=10261D1B27C0FE212C118590131682

9

</wsa:Address>

</wsa:ReplyTo>

<wsa:MessageID>urn:uuid:10261D1B27C0FE212C1185901316828</wsa:MessageID>

<wsa:Action>echoOperation</wsa:Action>

</soapenv:Header>

<soapenv:Body>

<ns2:echoStringInput

xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">

<echoInput>Async over-the-wire</echoInput>

</ns2:echoStringInput>

</soapenv:Body>

</soapenv:Envelope>

Sync Echo (Request) message with WS-Addressing Policy Set <?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsa="http://www.w3.org/2005/08/addressing">

<soapenv:Header>

<wsa:To>http://localhost:9081/WSSampleSei/EchoService</wsa:To>

<wsa:MessageID>urn:uuid:10261D1B27C0FE212C1185902350041</wsa:MessageID>

<wsa:Action>echoOperation</wsa:Action>

</soapenv:Header>

<soapenv:Body>

<ns2:echoStringInput

xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">

<echoInput>Sync Echo</echoInput>

</ns2:echoStringInput>

</soapenv:Body>

</soapenv:Envelope>

For the Feature Pack for Web Services, you configure the asynchronous over-the-wire message only on the client. However, for WCF, you must configure both the client and the service to handle the asynchronous over-the-wire MEP. The configuration for asynchronous over-the-wire messages is discussed in Configure asynchronous over-the-wire behavior.

Get started with the samples To run the SEI and WCF samples, complete the following steps on a Windows XP system:

1. Install WebSphere Application Server V6.1 (hereafter called Application Server). 2. 3.

Install the latest WebSphere Update Installer .

WebSphere Application Server V6.1 Feature Pack for Web Services, including the SEI samples. The samples are located in the <WAS_HOME>/samples/lib/WebServicesSamples directory. You can either install the EAR files (WSSampleClientSei.ear, and WSSampleServicesSei.ear ) using the Integrated Solutions Console, or use the installapps.cmd script provided.

You’ll find installation instructions for both methods in the WSFP_README.txt file located in the samples directory.

4. Install Microsoft .Net Framework 3.0. 5. Install the Microsoft Windows SDK. The SDK contains the svcconfigeditor,

which we’ll use to edit the client and service customBindings, so that we don’t have to edit them manually.

6. Download and uncompress the WCF samples for this article. The WCF folder

contains three folders: WCFClient, WCFService, and wsdls.

WCFClient contains: • WSWindowsClient executable - The compiled WCF Web services client. • WSWindowClient.exe.config - The customBinding file for the

WSWindowsClient. • WSWindowsClient.cs. - The C# code for the client, which was included to

show the source code used in the WSWindowsClient. • WCL.bat – A sample batch file to run the client, it demonstrates the

correct use of the command line variables for the WSWindowsClient.

WCFService contains: • WSWindowsService executable - The compiled WCF Web service. • WSWindowService.exe.config - The customBinding file for the

WSWindowsService. • WSWindowsService.cs. - The C# code for the service, which was

included to show the source code used in the WSWindowsService. • WSVC.bat - A sample batch file to run the service, it demonstrates the

correct use of the command-line variables for the WSWindowsService.

wsdls contains Ping.wsdl, Echo.wsdl, Ping12.wsdl, and Echo12.wsdl, all of which generate both the service and client for Feature Pack for Web Services SEI and WCF samples.

Verify the SEI sample endpoints Once the SEI sample client and service EAR files are installed and deployed in the WebSphere Application Server, both SOAP 1.1 and SOAP 1.2 endpoints should be available. The SOAP 1.1 endpoints are: http://<hostname>:port/WSSampleSei/PingService http://<hostname>:port /WSSampleSei/EchoService The SOAP 1.2 endpoints are: http://<hostname>:port /WSSampleSei/PingService12

http://<hostname>:port /WSSampleSei/EchoService12 Verify that the endpoints are correctly installed by pointing your browser to the full URI path of each service endpoint. Following is an example URI to verify your Ping endpoint: http://localhost:9081/WSSampleSei/PingService Note: The port may vary based on your WebSphere Application Server configuration. Figure 2 shows the response from the operational Ping Web service. Figure 2. Verify Ping endpoint

Verify that all the endpoints are correctly installed and operational before continuing to the next section.

Run the SEI samples In this section, you’ll learn how to run the SEI samples demo UI. The SEI samples demo UI is a simple servlet-based application used to demonstrate the SEI Web services. You can also demo the SEI Web services using a command line. For more information on using the command line, see the WSFP_README.txt file located in the samples directory.

Start the SEI Samples demo UI Once the SEI sample applications are deployed, point your browser to http://<hostname>:port/wssamplessei/demo. For example: http://localhost:9081/wssamplesei/demo Note: The port may vary based on your Application Server configuration. This command opens the SEI Samples demo UI, as shown in Figure 3.

Figure 3. SEI Samples demo

Below is a description of the Web Services Feature Pack SEI Samples Demo interface: Message Type lists the available MEPS, which are One-Way Ping, Synchronous Echo, Asynchronous Echo with Sync Communication, and Asynchronous Echo with Async Communication. Message String specifies the text to be transmitted from the client to the service. Message Count specifies how many times the MEP will be executed.

Service URI is the hostname and port number of the machine where the service endpoint is hosted. The SOAP check box defaults to SOAP 1.1 (when it’s not checked) and SOAP 1.2 when checked. The Send Message button executes the MEP. The response box displays the response from the service. Synchronous Echo example Figure 4 shows an example of the Synchronous Echo MEP: Figure 4. Synchronous Echo MEP example

In this case, we did the following:

• Selected Synchronous Echo for the Message Type. • Entered test for the Message String. • Specified 1 for the Message Count. • Specified http://localhost:9081 as the Service URI. • Left the default of SOAP 1.1.

The response box shows the connection status, the Message Request, and the Message Response. Note that the Message Response is JAX-WS==>>test. The service prepends

JAX-WS==>> to the Message Request string test. If SOAP 1.2 had been selected, the service would have prepended SOAP1.2==>>. Note: Although a separate section is reserved just for testing asynchronous over-the-wire behavior, for Feature Pack for Web Services no special configuration is required for the Asynchronous Echo with Async Communication Application Server to Application Server testing. You can run this MEP sample at anytime.

Run the WCF samples In this section, you’ll learn how to run the WCF samples, including how to correctly start the WCF services and then show the correct command line use for the WCF client.

Start the WCF services To start the WCF services, do the following:

1. Open a command window by selecting Start => Run => cmd.

2. Change to the \WCF\WCFService directory.

3. Enter WSWindowService.exe -? to see command usage information as shown here:

WSWindowsService –p [port] –e [echoSuffix] –f [pingSuffix]

Default values: port = 9080 echoSuffix = /WSSampleSei/EchoService pingSuffix = /WSSampleSei/PingService

Make sure that you start the service using an open port, such as port 9082. Otherwise, you’ll get an error stating that the port is already in use. The following is an example of the correct command line argument usage. You can also find this example in the WSVC.bat file. WSWindowsService.exe -p 9082 -e /WSSampleSei/EchoService –f /WSSampleSei/PingService

Figure 5. WCF services started

Figure 5 shows that the WCF services are correctly started. If you want to stop the WCF services, press Enter in the command window.

Run the WCF client To run the WCF client, do the following:

1. Open a command window by selecting Start => Run => cmd.

2. Change to the \WCF\WCFClient directory,

3. Enter WSWindowClient.exe -? to see command usage information as shown here:

WSWindowsClient –h [hostname] –p [port] –f [urlSuffix] –m [testMessage] –s [echo | ping | async] –t [asynctimeout]

Default values: hostname = localhost port = 9080 urlSuffix = /WSSampleSei/EchoService testMessage = hello service = echo asynctimeout = 120

The following examples show how to use the command line arguments correctly and verify that both the WCF services and client are configured correctly. It’s a good idea to always test the WCF to WCF interaction before attempting any interoperability tests between Application Server and WCF.

WCF client to WCF service Ping example Following is an example of the Ping MEP using the command line: WSWindowsClient.exe -p 9082 –f /WSSampleSei/PingService -m “ping test” -s ping Since Ping is a one-way MEP, there is no response; however, this command should end successfully as shown in the client output in Figure 6. Figure 6. WCF Client command line usage example for the Ping

Figure 7 shows the result of the Ping request. You should see your input string here. Figure 7. WCF service output from the Ping request

WCF client to WCF service Echo example Following is an example for the Echo sample using the command line: WSWindowsClient.exe -p 9082 -f /WSSampleSei/EchoService -m “echo test” -s echo The service response to the client request is DotNet==>>echo test. The service prepends DotNet==>> to the test message echo test. You should see the echo test message in the service window.

WCF client to WCF service Async Echo example It’s important to note that this example is for the asynchronous programming model with synchronous over-the-wire communication. It’s the same as the Feature Pack for Web Services Asynchronous Echo with Sync Communication Sample. For asynchronous over-the-wire behavior, you must configure WCF bindings. Configuring WCF bindings is covered in Configure asynchronous over-the-wire behavior. Following is an example of the Async Echo Sample using the command line: WSWindowsClient.exe -p 9082 -f /WSSampleSei/EchoService -m “async test” -s async

The service response to the client request is DotNet==>>async test. The service prepends DotNet==>> to the test message async test. You should see the async test message in the service window.

Test for basic SOAP 1.1 MEP Interoperability This section demonstrates Feature Pack for Web Services client to WCF service interoperability and WCF client to Feature Pack for Web Services interoperability using SOAP 1.1.

Client to WCF service examples Point your browser to the SEI sample application at: http://<hostname>:port/wssamplessei/demo For example: http://localhost:9081/wssamplesei/demo Note: The port may vary based on your Application Server configuration. This command opens the SEI Samples demo UI shown in Figure 8:

Figure 8. SEI Samples demo

Client to WCF service One-Way Ping example To demonstrate the Client to WCF service One-Way Ping MEP, do the following, as shown in Figure 9:

1. Select One-Way Ping for Message Type. 2. Enter a Message String. In this example, we use Ping WAS to WCF. 3. Specify http://localhost:9082, for the Service URI, which points to the WCF

service. 4. Assuming the WCF service is running, click Send Message.

Figure 9. Client to WCF service One-Way Ping

Figure 10 shows the output of the ping request in the WCF services window. You should see the input string here. You’ve now performed your first interoperability test.

Figure 10. WCF Service output from the Ping request

Client to WCF service Synchronous Echo example To demonstrate the Client to WCF service Synchronous Echo MEP, do the following, as shown in Figure 11:

1. Select Synchronous Echo for Message Type.. 2. Enter a Message String. In this example, we use WAS Sync Echo to WCF. 3. Specify http://localhost:9082 for the Service URI. 4. Click Send Message.

Figure 11. Client to WCF service Synchronous Echo

Figure 12 shows the output of the synchronous echo request and response in the WCF services window. You should see the input string here.

Figure 12. WCF service output from the synchronous Echo request

Client to WCF service Asynchronous Echo with Sync Communication example To demonstrate the Client to WCF service Asynchronous Echo with Sync Communication MEP, do the following, as shown in Figure 13:

1. Select Asynchronous Echo with Sync Communication One-Way Ping for Message Type.

2. Enter a Message String. In this example, we use WAS Async Echo with Sync to WCF.

3. Specify http://localhost:9082, for the Service URI, which points to the WCF service.

4. Click Send Message.

Figure 13. Client to WCF service Asynchronous Echo with Sync Communication

Figure 14 shows the output of the asynchronous echo request and response in the WCF services window. You should see the input string here.

Figure 14. WCF service output from the Asynchronous Echo request

WCF client to Feature Pack for Web Services service examples Open a command window and change to the directory \WCF\WCFClient. This is similar to running the WCF to WCF tests; however, in this case, the WCF should point to the Feature Pack for Web Services service on port 9081. WCF client to Feature Pack for Web Services service Ping example Following is an example of the command for the Ping sample for WCF to Feature Pack for Web Services: WSWindowsClient.exe -p 9081 –f /WSSampleSei/PingService -m “ping test” -s ping Figure 15 shows the examples of the proper usage of the WCF client request to WAS service.

Figure 15. WCF Client to WAS service command line usage example

You can see the Feature Pack for Web Services service output for the string Ping in the Application Server SystemOut.log. WCF client to Feature Pack for Web Services service Echo example Following is an example of the command for the Echo sample for a WCF client to a Feature Pack for Web Services service: WSWindowsClient.exe -p 9081 –f /WSSampleSei/EchoService -m “echo test” -s echo The response to the client request is JAXWS==>>echo test, since the JAX-WS echo service prepends JAXWS==>> to the input string for the output response. WCF client to Feature pack for Web Services service Async Echo example Following is an example of the command for the Async Echo sample for a WCF client to a Feature Pack for Web Services service: WSWindowsClient.exe -p 9081 -f /WSSampleSei/EchoService -m “async test” -s async This example is similar to the Echo example, and the response to the client request is JAXWS==>>async test.

WebSphere Application Server policy sets The Feature Pack for Web Services introduces a new method of configuring and applying Quality of Service (QoS) protocols to deployed JAX-WS service providers and service clients using policy sets and bindings. A binding is the specific configuration of a QoS protocol. For example, a binding contains the settings for WS-Security supporting a Username Token. A policy set may contain a composition of QoS’s. For example, the Web Services Reliable Messaging policy set contains WS-Addressing and WS-Reliable Messaging bindings. The Feature Pack for Web Services includes a set of preconfigured policy sets and bindings. We’ll demonstrate applying a policy set to both a client and service in Apply the WS-Addressing policy set to the samples.

Windows Communication Foundation bindings WCF is designed to interoperate with Web services applications by supporting a set of Web services specifications. The configuration of the supported Web services specifications is done through the use of bindings. You can configure the bindings using the Microsoft Service Configuration Editor, or manually edit the bindings. WCF provides three sets of bindings with a distinct set of Web services specification compositions and configurations: BasicHttpBinding, WsHttpBinding, and WsDualHttpBinding. You can also configure a customBinding, which is the most flexible way to compose Web services specifications for interoperability. For complete details on bindings and Web services specification versions supported by WCF, see the MSDN™ article Web Services Protocols Supported by System-Provided Interoperability Bindings. Because customBinding provides full control over the WCF stack, we’ll use the customBinding and the Microsoft Service Configuration Editor to configure the appropriate set of Web services protocols for interoperability. Note that you could use the three other binding types if they contain the composition of protocols required for interoperability. For more information on customBinding, see the MSDN article <customBinding>.

Define wsa:Action or SOAPAction for WCF interoperability For interoperability with WCF, either the SOAPAction or the WS-Addressing action parameter wsa:Action needs to be defined in each Web services client request. You can explicitly define the wsa:Action parameter in the WSDL or let it be defined by the default action pattern according to the WS-Addressing specification. The wsa:Action parameter is present only if WS-Addressing is enabled. If WS-Addressing is not enabled, WCF requires the SOAPAction to be defined in the HTTP header of the request. The WCF service implementation links incoming messages to target components using the wsa:Action or the SOAPAction information item. Neither action can be defined with an empty string (“”) value. Additionally, if the WCF service is generated from a WSDL file, the wsa:Action element in the WSDL should not contain an empty string (“”) value.

Furthermore, the SOAPAction or wsa:Action must match the SOAP or wsa:Action defined in the WSDL used to generate the WCF service. In this section, we’ll describe how to explicitly define the SOAPAction parameter for JAX-WS client. Depending on how a JAX-WS Web services client is implemented, you can configure it to read the WSDL and generate properties such as SOAPAction defined in the WSDL, or you can manually set properties if they are not defined in the WSDL.

Define SOAPAction in the WSDL Following is an example of the SOAPAction element: <soap:operation soapAction="pingOperation" style="document" /> The following WSDL contains a correctly defined SOAPAction element: Ping WSDL <?xml version="1.0" encoding="UTF-8"?>

<!--

* This program may be used, executed, copied, modified and distributed

* without royalty for the purpose of developing, using, marketing, or

distributing.

-->

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:tns="http://com/ibm/was/wssample/sei/ping/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="PingService"

targetNamespace="http://com/ibm/was/wssample/sei/ping/">

<wsdl:types>

<xsd:schema

targetNamespace="http://com/ibm/was/wssample/sei/ping/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="pingStringInput">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="pingInput" type="xsd:string" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

</wsdl:types>

<wsdl:message name="pingOperationRequest">

<wsdl:part element="tns:pingStringInput" name="parameter" />

</wsdl:message>

<wsdl:portType name="PingServicePortType">

<wsdl:operation name="pingOperation">

<wsdl:input message="tns:pingOperationRequest" />

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="PingSOAP" type="tns:PingServicePortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="pingOperation">

<soap:operation soapAction="pingOperation"

style="document" />

<wsdl:input>

<soap:body use="literal" />

</wsdl:input>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="PingService">

<wsdl:port binding="tns:PingSOAP" name="PingServicePort">

<soap:addresslocation="http://localhost:9080/WSSampleSei/PingService" />

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Define SOAPAction in the JAX-WS client If the SOAP action is not defined in the WSDL, you can configure it in the JAX-WS Web services client by setting the SOAPACTION_USE_PROPERTY to TRUE and setting the SOAPACTION_URI_PROPERTY, as shown in the following example, which sets the SOAP action to pingOperation. // Configure SOAPAction properties BindingProvider bp = (BindingProvider) (ping._getDescriptor() .getProxy()); bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,

endpointURL); bp.getRequestContext().put(BindingProvider.SOAPACTION_USE_PROPERTY, Boolean.TRUE); bp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY, "pingOperation"); The SOAP action is now set to “pingOperation.”

Configure the SOAP version SOAP version is the first configurable option that determines interoperability at the lowest level, the SOAP message. Both WCF and the Feature Pack for Web Services support SOAP 1.1 and SOAP 1.2 for interoperability. The client and service SOAP version must match. For Feature Pack for Web Services, the SOAP version is typically derived from the WSDL. For WCF, the SOAP version is determined in the bindings as shown below: BasicHttpBinding SOAP 1.1 WsHttpBinding SOAP 1.2 WsDualHttpBinding SOAP 1.2 customBinding SOAP 1.1 or SOAP 1.2 (configurable) If SOAP 1.2 is specified in the WSDL, the Microsoft svcutil.exe that generates C# code from a WSDL generates a WsHttpBinding by default. However, in this article we’ll use customBinding because of its flexibity. The following sections describe how to configure the SOAP version for the Feature Pack for Web Services and WCF.

Configure the SOAP version in JAX-WS For JAX-WS, the default SOAP binding is SOAP 1.1. A JAX-WS client determines the SOAP binding from the WSDL. You can configure a JAX-WS service SOAP binding via the WSDL, if a wsdlLocation is explicitly specified in the @ javax.jws WebService annotation or by using the @BindingType annotation. For a service, if a WSDL is specified, then the annotations for the SOAP binding must be defined and match the WSDL. This section provides information on how to configure SOAP 1.2 in both the WSDL and using the @BindingType annotation.

Define the SOAP version in the WSDL The following WSDL example defines the xml namespace for SOAP to be SOAP 1.2:

WSDL with SOAP 1.2 example <?xml version="1.0" encoding="UTF-8"?>

<!--

* This program may be used, run, copied, modified and distributed

* without royalty for the purpose of developing, using, marketing, or

distributing.

-->

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/"

xmlns:tns="http://com/ibm/was/wssample/sei/echo/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="EchoService12"

targetNamespace="http://com/ibm/was/wssample/sei/echo/">

<wsdl:types>

<xsd:schema

targetNamespace="http://com/ibm/was/wssample/sei/echo/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="echoStringResponse">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="echoResponse" type="xsd:string" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="echoStringInput">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="echoInput" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

</wsdl:types>

<wsdl:message name="echoOperationRequest">

<wsdl:part element="tns:echoStringInput" name="parameter" />

</wsdl:message>

<wsdl:message name="echoOperationResponse">

<wsdl:part element="tns:echoStringResponse" name="parameter" />

</wsdl:message>

<wsdl:portType name="EchoService12PortType">

<wsdl:operation name="echoOperation">

<wsdl:input message="tns:echoOperationRequest" />

<wsdl:output message="tns:echoOperationResponse" />

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="EchoSOAP12" type="tns:EchoService12PortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="echoOperation">

<soap:operation soapAction="echoOperation" style="document" />

<wsdl:input>

<soap:body use="literal" />

</wsdl:input>

<wsdl:output>

<soap:body use="literal" />

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="EchoService12">

<wsdl:port binding="tns:EchoSOAP12" name="EchoService12Port">

<soap:address

location="http://localhost:9080/WSSampleSei/EchoService12" />

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

Set the SOAP version using annotations The following annotation example is from the SEI sample Echo service. It shows how to configure a JAX-WS service for SOAP 1.2. The annotation is located above the EchoService12PortImpl service implementation class. The wsdlLocation specifies the

location of the WSDL. The WSDL should have SOAP 1.2 defined. In addition, the @BindingType must also be defined as SOAP 1.2. Annotation example @javax.jws.WebService(endpointInterface="com.ibm.was.wssample.sei.echo.EchoService12PortType",targetNamespace="http://com/ibm/was/wssample/sei/echo/", serviceName="EchoService12", portName="EchoService12Port", wsdlLocation="WEB-INF/wsdl/Echo12.wsdl") @BindingType(SOAPBinding.SOAP12HTTP_BINDING) public class EchoService12PortImpl{ . . .

The SOAP version and the SEI samples When running the SEI samples, the SOAP check box on the SEI sample demo UI dictates the SOAP version of the client request. At runtime, the SEI sample code implements the methods described in the previous sections.

Configure the SOAP version in WCF As described previously, we’re using customBinding for these examples. We’ll use the Microsoft Service Configuration Editor to edit WSWindowsService.exe.config and WSWindowsClient.exe.config, as described in the following steps.

1. Run the Service Configuration Editor. 2. Select File => Open => Config File, as shown in Figure 16.

Figure 16. Open configuration file

3. Open the WCFService folder. 4. Select the wswindows.exe.config file, as shown in Figure 17. Figure 17. Select configuration file to open

5. Click Open. You should see the screen displayed in Figure 18.

Figure 18. Microsoft Service Configuration Editor with wswindowsservice.config.exe loaded

6. Select Bindings => EchoSOAP(customBinding) => PingSOAP(customBinding).

7. Under EchoSOAP(customBinding), select textMessageEncoding, as shown in Figure 19.

Figure 19. Select Bindings

8. Select MessageVersion, and select Soap12 from the list, as shown in Figure 20.

Figure 20. Select SOAP version for EchoSOAP(customBinding)

9. Under PingSOAP(customBinding), select textMessageEncoding. 10. Select MessageVersion, then select Soap12 from the list, as shown in Figure 21.

Figure 22. Select SOAP version for PingSOAP(customBinding)

11. Select Save to save the changes to the WSWindowsService.exe.config file, as

shown in Figure 23.

Figure 23. Save changes

12. Repeat these steps for the WSWindowsClient.exe.config file.

Run the WCF samples using SOAP 1.2 When starting the WCF service after changing the customBinding to SOAP 1.2, make sure the SOAP 1.2 endpoint names match the Feature Pack for Web Services SOAP 1.2 endpoints. The SEI Sample demo UI expects the SOAP 1.2 service endpoint names to be /WSSampleSei/PingService12 and /WSSampleSei/EchoService12. The UI appends these names to the http://<hostname>:port that was entered as the value for the service URI based on the MEP selected, rather than requiring you to type in the full URI each time. This reduces typing mistakes when using the SEI sample UI.

Start SOAP 1.2 WCF services Following is an example of the command line arguments for starting the WCF services as SOAP 1.2 services after setting the customBinding, textMessageEncoding, and MessageVersion values to SOAP12. WSWindowsService.exe -p 9082 -e /WSSampleSei/EchoService12 –f /WSSampleSei/PingService12

You can see in Figure 24 that the WCF services are started correctly. Figure 24. WCF services started

Test SOAP 1.2 WCF services with SOAP 1.2 WCF client This section demonstrates how to correctly use the command line arguments for the WCF client to interact with the WCF services configured for SOAP 1.2. In each of these examples, it’s important to use the correct endpoints: /WSSampleSei/PingService12 for the Ping sample, and /WSSampleSei/EchoService12 for the Echo and Async samples.

SOAP 1.2 WCF client to SOAP 1.2 WCF service Ping example Following is an example command for the Ping sample: WSWindowsClient.exe -p 9082 –f /WSSampleSei/PingService12 -m “ping test SOAP 12” -s ping Because this operation is a one-way MEP, there is no service response.

SOAP 1.2 WCF client to SOAP 1.2 WCF service Echo example Following is an example command for the Echo sample: WSWindowsClient.exe -p 9082 -f /WSSampleSei/EchoService12 -m “echo test SOAP 12” -s echo The service response to the client request is SOAP12==>>echo test SOAP 12. The service prepends SOAP12==>> to the testMessage echo test.SOAP 12. You should also see the echo test SOAP 12 message in the service window.

SOAP 1.2 WCF client to SOAP 1.2 WCF service Async example Following is an example command for the Async sample: WSWindowsClient.exe -p 9082 –f /WSSampleSei/EchoService12 -m “async test SOAP 12” -s async The service response to the client request is SOAP12==>>async test SOAP 12. The service prepends SOAP12==>> to the testMessage async test.SOAP 12. You should also see the “async test SOAP 12” message in the service window.

Test SOAP 1.2 Feature Pack for Web Services SEI client to WCF SOAP 1.2 services The following example screen captures are similar to those for the Feature Pack for Web Services SEI client to WCF SOAP 1.1 services. However, in these examples, you select the SOAP 1.2 check box. SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Ping example To demonstrate the SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Ping MEP, do the following, as shown in Figure 25:

1. Select One-Way Ping for Message Typo. 2. Enter a Message String. In this example, we use Ping test WAS to WCF SOAP

12. 3. Specify http://localhost:9082 for the Service URI. 4. Check Use SOAP 1.2. 5. Click Send Message.

Figure 25. SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Ping example

Figure 26 shows the output of the Ping request in the WCF services window.

Figure 26. WCF service output from the Ping request

SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Echo example To demonstrate the SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Echo MEP, do the following, as shown in Figure 27:

1. Select Synchronous Echo as the Message Type. 2. Enter a Message String. In this example, we use Echo test WAS to WCF SOAP

12. 3. Specify http://localhost:9082 for the Service URI. 4. Check Use SOAP 1.2. 5. Click Send Message.

Figure 27. SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Echo

Figure 28 shows the output of the Echo request and response in the WCF services window. You can also see your input string.

Figure 28. WCF service output from the Echo request

SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Async example To demonstrate the SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Async MEP, do the following, as shown in Figure 25:

1. Select Asynchronous Echo with Sync Communication for Message Type. 2. Enter a Message String. In this example, we use Async Echo test WAS to

WCF SOAP 12. 3. Specify http://localhost:9082 for the Service URI. 4. Check Use SOAP 1.2. 5. Click Send Message.

Figure 29. SOAP 1.2 Feature Pack for Web Services client to SOAP 1.2 WCF service Async example

Figure 30 shows the output of the Async request and response. You can also see your input string in the output.

Figure 30. WCF service output from the Async Echo request

Test SOAP 1.2 WCF client to Feature Pack for Web Services SOAP 1.2 services The screen captures for the following examples are similar to the WCF client to Feature Pack for Web Services SOAP 1.1 services, so they are not repeated here. However, in these examples, the WCF points to SOAP 1.2 services. In all of these examples, it’s important that you use the Feature Pack for Web Services port and the correct endpoints, which are /WSSampleSei/PingService12 for the Ping sample and /WSSampleSei/EchoService12 for the Echo and Async samples.

SOAP 1.2 WCF client to SOAP 1.2 Feature Pack for Web Services service Ping example Following is an example command for the Ping sample to demonstrate interoperability from a SOAP 1.2 WCF client to a SOAP 1.2 Feature Pack for Web Services service: WSWindowsClient.exe -p 9081 –f /WSSampleSei/PingService12 -m “ping test WCF to WAS SOAP 12” -s ping Figure 31 shows the proper usage of the WCF client request to a WAS service along with the successful results for Ping using SOAP 1.2.

Figure 31. WCF Client usage example for Ping using SOAP 1.2 to WAS service

SOAP 1.2 WCF client to SOAP 1.2 Feature Pack for Web Services service Echo example Following is an example command for the Echo sample to demonstrate interoperability from a SOAP 1.2 WCF client to a SOAP 1.2 Feature Pack for Web Services service: WSWindowsClient.exe -p 9081 –f /WSSampleSei/EchoService12 -m “echo test WCF to WAS SOAP 12” -s echo The service response to the client request is SOAP12==>>echo test WCF to WAS SOAP 12. The service prepends SOAP12==>> to the testMessage echo test.WCF to WAS SOAP 12.

SOAP 1.2 WCF client to SOAP 1.2 Feature pack for Web Services service Async example Following is an example command for the Async sample to demonstrate interoperability from a SOAP 1.2 WCF client to a SOAP 1.2 Feature Pack for Web Services service. WSWindowsClient.exe -p 9081 –f /WSSampleSei/EchoService12 -m “async test WCF to WAS SOAP 12” -s async The service response to the client request is SOAP12==>>async test WCF to WAS SOAP 12. The service prepends SOAP12==>> to the testMessage async test.WCF to WAS SOAP 12.

Configure WS-Addressing In this section, you’ll learn how to apply the WS-Addressing policy set to the SEI samples and configure the customBinding to use WS-Addressing for the WCF samples.

Apply the WS-Addressing policy set to the samples Complete the following steps to apply the WS-Addressing policy set to the samples: 1. Start the Integrated Solution Console (ISC) by doing one of the following:

• From the Start menu, click n Start => Programs => IBM WebSphere => Application Server v6.1 => Profiles => AppSvr01 => Administrative Console.

• In a browser, go to http://<hostname>:9061/ibm/console. Depending on your installation of the AppSrvxx profile, the console port could be different. 9061 is the default console port for AppSrv02.

2. Enter your application server administrative user ID and, if required, your password, and click Log in, as shown in Figure 32.

Figure 32. Log in to ISC

3. In the left pane, expand Applications.

Figure 33. Expand Applications in ISC

4. Select Enterprise Applications, as shown in Figure 34.

Figure 34. Select Enterprise Applications

5. Check WSSampleServicesSei, as shown in Figure 35. Figure 35. Check WSSampleServicesSEI

6. Select Service provider policy sets and bindings, as shown in Figure 36. Figure 36. Select Service provider policy sets and bindings

7. Check WSSampleServicesSei.

Figure 37. Check WSSampleServicesSei

8. Click Attach to display a list of available policy sets to attach, and select the

WSAddressing default policy set, as shown in Figure 38.

Figure 38. Click Attach

. 9. The following screen displays. Click Save to save your changes to the master

configuration.

Figure 39. Save your configuration changes

10. On the Enterprise Applications page, check WSSampleClientSei, as shown in Figure 40.

Figure 40. Check WSSampleClientSEI

11. Select Service client policy sets and bindings, as shown in Figure 41.

Figure 41. Select Service client policy sets and bindings

12. Check WSSampleClientSei.

Figure 42. Check WSSampleClientSEI

13. Click Attach to display a list of available policy sets to attach, and select the

WSAddressing default policy set from the list, as shown in Figure 43.

Figure 43. Select WSAddressing default policy

14. The following screen displays. Click Save to save your changes to the master

configuration. Figure 44. Save your configuration changes

15. From the Enterprise Applications page, check WSSampleServicesSei and WSSampleClientSei, then click Stop and then Start to restart the applications.

Figure 45. Stop and restart the applications

16. After the applications are successfully restarted, log off ISC.

Configure WS-Addressing using WCF bindings Configuring WS-Addressing in WCF is similar to configuring SOAP 1.1 or SOAP 1.2. Follow the same steps outlined in Configure the SOAP version in WCF on configuring textMessageEncoding for SOAP 1.2 . You can change textMessageEncoding to either SOAP11WSAddressing10 or SOAP12WSAddressing10 for both the EchoSOAP(customBinding) sample and the PingSOAP(customBinding) sample based on your SOAP requirements. Figure 46 shows the changes to textMessageEncoding for the EchoSOAP(customBinding):

Figure 46. Changes to textMessageEncoding for the EchoSOAP(customBinding)

After making the changes to both EchoSOAP(customBinding) and PingSOAP(customBinding) to specify either SOAP11WSAddressing10 or SOAP12WSAddressing10 for the MessageVersion, select File => Save to save the changes to WSWindowsService.exe.config. Repeat these steps for the WSWindowsClient.exe.config file. Once the client and service configurations are completed, restart the WCF services based on the SOAP version chosen.

Test WS-Addressing configuration Depending on whether you configured WCF for SOAP11WSAddressing10 or SOAP12WSAddressing10, you can now run either the complete SOAP 1.1 or SOAP 1.2 interoperability test as described previously.

Configure asynchronous over-the-wire behavior In previous sections, we have performed only the two-way MEP with either blocking or non-blocking programming model with synchronous over-the-wire behavior. This section describes how to configure asynchronous over-the-wire behavior in JAX-WS and how to configure WCF for asynchronous over-the-wire behavior.

Configure asynchronous over-the-wire behavior in a Feature Pack for Web Services client In order to configure over-the-wire asynchronous behavior, you need to set the com.ibm.websphere.webservices.use.async.mep only in the Web services client code. The service responds based on the WS-Addressing information in the client request. Following is a sample code snippet showing how to set this property: EchoService12PortProxy echo = new EchoService12PortProxy(); echo._getDescriptor().setEndpoint(endpointURL); //if (wireasync) Configure over-the-wire async if specified

{ BindingProvider bp = (BindingProvider) (echo._getDescriptor() .getProxy()); bp.getRequestContext().put("com.ibm.websphere.webservices.use.async.mep", Boolean.TRUE); }

Configure asynchronous over-the-wire behavior in WCF client or service By default, you can use WsDualHttpBinding to configure a Microsoft client or service for asynchronous over-the-wire behavior. WsDualHttpBinding requires configuration of reliable messaging (WS-RM). Additionally, WsDualHttpBinding only supports SOAP 1.2. Therefore, it is not a good choice for basic asynchronous over-the-wire Web services that don’t require reliable messaging or SOAP 1.1. You can also configure this behavior using customBinding. As shown in this article, the minimum stack elements required for basic Web services are <httpTransport> and <textMessageEncoding>. The <textMessageEncoding> configuration includes SOAP 1.1 or SOAP 1.2 and SOAP 1.1 or SOAP 1.2 with WS-Addressing. To configure asynchronous over-the-wire behavior, you must configure <textMessageEncoding> for SOAP 1.1 or SOAP 1.2 with WS-Addressing. Additionally, you must add <compositeDuplex> and <oneWay> stack elements to the customBinding. The <oneWay> element must be directly underneath <compositeDuplex>. The asynchronous over-the-wire communications applies only to the two-way EchoSOAP service and client, so you should not use the following steps for the PingSOAP service or client. It’s important to note that once a WCF service is configured for

compositeDuplex, the service always expects to reply on a separate HTTP channel. As a result, any two-way synchronous message exchanges will not work correctly. The WCF service will accept the request; however, no response will be sent on the back channel. No error occurs in this scenario when no response is sent. Only asynchronous over-the-wire messages work for this configuration. In contrast, a Feature Pack for Web Services service responds based on the WS-Addressing information in the request message; therefore, no special configuration is required on the Feature Pack for Web Services service side. Now we’ll configure textMessageEncoding for either SOAP11WSAddressing10 or SOAP12WSAddressing10 based on your SOAP requirements.

1. In the left-hand pane under Bindings, select EchoSOAP(customBinding), as shown in Figure 47.

Figure 47. Select EchoSOAP(customBinding)

2. In the right pane, click Add, as shown in Figure 48.

Figure 48. Click Add

3. Select compositeDuplex, then click Add, as shown in Figure 49.

Figure 49. Add compositeDuplex

4. In the right pane, click Add, as shown in Figure 50.

Figure 50. Click Add

5. Select oneWay, and click Add, as shown in Figure 51.

Figure 51. Add oneWay

6. Select File => Save to save the changes to WSWindowsService.exe.config to the master configuration.

7. Repeat these steps for the WSWindowsClient.exe.config file. When you’re done,

restart the WCF service with the new configuration changes using SOAP 1.2 start WCF service example

Test async over-the-wire interoperability Now that you’ve successfully finished configuring asynchronous over-the-wire behavior in WCF, you can run interoperability tests for async over-the-wire behavior for Application Server and WCF.

Test async over-the-wire Application Server to Application Server interoperability Complete the following steps to use the Async sample to verify over-the-wire interoperability from the WebSphere Application Server to WebSphere Application Server.

1. Select Asynchronous Echo with Async Communication for Message Type. 2. Enter a Message String. In this example, we use WAS to WAS Async Echo.

3. Specify http://localhost:9081 for the Service URI. 4. Check Use SOAP 1.2. 5. Click Send Message. 6. Start the WCF service and verify WCF to WCF communication.

Figure 52. Test async over-the-wire Application Server to Application Server interoperability with Async sample

Following is an example of a command to run the over-the-wire interoperability tests using the Async sample: WSWindowsClient.exe -p 9082 –f /WSSampleSei/EchoService12 -m “WCF to WCF async over-the-wire test” -s async Figure 53 shows an example of the proper usage of the WCF client request to a WCF service configure for the async over-the-wire behavior and indicates successful completion. Figure 53. WCF client to WCF service usage for async over-the-wire

Figure 54 shows the output from the async request and response in the WCF services window. You can also see your input string in the output.

Figure 54. WCF service output from WCF client request

Test Application Server to WCF interoperability Do the following to use of the Async sample to verify over-the-wire interoperability from the application server to WCF.

1. Select Asynchronous Echo with Async Communication for Message Type. 2. Enter a Message String. In this example, we use WAS to WCF Async Echo. 3. Specify http://localhost:9082 for the Service URI. 4. Check Use SOAP 1.2. 5. Click Send Message.

Figure 55. Test Application Server to WCF asynch over-the-wire interoperability with the Async sample

Figure 56 shows the output from the Async request and response in the WCF services window. You can also see your input string in the output.

Figure 56. Output of the Async request and response

Following is an example command to run the over-the-wire interoperability tests using the Async sample from WCF to Application Server: WSWindowsClient.exe -p 9081 –f /WSSampleSei/EchoService12 -m “WAS to WCF async over-the-wire test” -s async Figure 57 shows the proper usage of the WCF client configured for the Async over-the-wire request to a WebSphere service and indicates successful completion.

Figure 57. WCF client Async over-the-wire request to WAS service

You have now successfully completed the asynchronous over-the-wire interoperability tests.

Summary In this article, you learned how to use the simple message exchange patterns to test over-the-wire basic interoperability between JAX-WS Web services deployed on WebSphere Application Server and Windows Communication Foundation Web services. By applying the correct programming techniques, policy sets, and WCF bindings, you can easily achieve interoperability between the two different programming models.

Resources

Specifications • WSDL 1.1 • SOAP 1.1 • SOAP 1.2 Primer • SOAP 1.2 Specification • WS-Addressing • JAX-WS

Feature Pack for Web Services and developerWorks articles • Feature Pack for Web Services Information center

• Asynchronous operations and Web services, Part 1: A primer on asynchronous transactions (developerWorks 2002): This article explains why web services architects need to understand how asynchronous operations work. It will help you begin to adapt your own services for an asynchronous environment.

• Asynchronous operations and Web services, Part 2 (developerWorks 2002): Learn

about concrete blueprints that will help you build your own asynchronous Web services. These practical patterns can be used for handling responses to Web service requests as separate transactions.

Windows Communication Foundation Web Services Protocols Interoperability Guide: This topic provides a list of Web Services Protocols implemented by WCF. Web Services Protocols Supported by System-Provided Interoperability Bindings: This topic lists specifications that are supported by system-provided interoperable bindings.

About the authors Charles Le Vay is a senior software architect responsible for Web service interoperability for WebSphere Application Server. He represents IBM on the Web Service Interoperability Organization (WS-I) Reliable Secure Profile (RSP) Working Group. As an interoperability architect, Charles ensures IBM products meet industry standard interoperability criteria. He is responsible for identifying and detailing best practices for Web services interoperability. Prior to this position, Charles specialized in mobile application development, wireless technology, and extending enterprise applications securely to mobile devices. Before joining IBM, Charles developed advanced submarine sonar systems for the Navy and specialized in signal processing and underwater acoustics. He is a graduate of Duke University with a degree in physics. Tom Link is an advisory software engineer responsible for the JAX-WS samples for WebSphere Application Server. His current focus is the interoperability of the WebSphere Application Server with other Web services frameworks. Tom has worked on IBM software for over 20 years. Prior to his current position, he specialized in PalmOS mobile application development, and has also developed IBM tools for software support, including IBM FaxRouter/2, IBM DB2 Content Manager, and IBM Machine Translation.