Reusable Java and WCF Service Test Clients

I needed a reusable method to recursively test a WCF service host I had written from both the Java and .NET worlds. I wanted to be able to submit the test harness with service WSDL and pass in test parameters. 

Being familiar with Microsoft technology, I knew exactly where I could find a reusable WCF client test harness (located at %installDir%:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WCFTestClient.exe). However when it came to locating a reusable test client in the Java world, I was stumped. A colleague at work directed me to download Eclipse for Java development but I easily ended up spending a few evenings learning to use the GUI and Java language specifics. Time pressures outside my work schedule did not allow me to code from scratch a generic Java test harness for the future.

By chance, I happened to stumble on Eclipse’s Web Services Explorer :). The Web Services Explorer was exactly what I was after!!!

It was now possible for me to seamlessly test services built from both Java and .NET environments without having to write a single line of code. The below screenshots display both the Eclipse Java EE Web Services Explorer tool and Microsoft’s WCF Test Client tool.

Eclipse Java Web Services Explorer

 

Microsoft WCF Test Client

User Impersonation in WCF

In some integration scenarios, impersonation is required, where a WCF service is required to assume the caller’s identity. Though this usually happens for a single call, the impersonation token could be retained for future use by the WCF servce. The reason impersonation is most relevant to integration scenarios is because all WCF service code running under the priviledges of the caller ensures that only resources and data available to the caller are made available.

I found this to be partcularly useful while integrating middle layers of various heterogeneous systems. I did not have to add additional integration code to ensure that application-level authorization was being implemented because I could be assured that the impersonated thread would be denied access if relevant permissions to resources have not been authorized in the target system.

Inline code to support impersonation in WCF is as shown below:

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public int AddNumbers(int i, int j)
{
    return (i + j);
}

To implement impersonation on all Operations, a behavior could be configured as shown below: 

<behaviors>
    <serviceBehaviors>
        <behavior name=“ServiceBehavior“>
            <serviceAuthorization principalPermissionMode=“UseWindowsGroups“
                                  impersonateCallerForAllOperations=“true“>
            </serviceAuthorization>
        </behavior>
    </serviceBehaviors>
</behaviors>

Summary of default WCF Bindings

A binding in WCF is one of the most important concepts behind the WCF architecture itself. Developers can create their own bindings if the below default WCF bindings do not suit a purpose by extending CustomBinding.

First a definition of what a binding controls. A WCF binding controls the following:

1. Transport (HTTP, MSMQ, Named Pipes, TCP)
2. Channel (one-way, duplex, request-reply)
3. Encoding (XML, binary, MTOM, JSON)
4. Supported WS-* protocols

I found the below matrix extremely helpful when determining which implementation of default binding to use when determining a solution architecture.

Binding	Configuration	Security	Default Session	Transactions	Duplex
basicHttpBinding	Basic Profile 1.1	None	No	-	-
wsHttpBinding	WS	Message	Optional	Yes	-
wsDualHttpBinding	WS	Message	Yes	Yes	Yes
wsFederationHttpBinding	WS-Federation	Message	Yes	Yes	No
netTcpBinding	.NET	Transport	Optional	Yes	Yes
netNamedPipeBinding	.NET	Transport	Yes	Yes	Yes
netMsmqBinding	.NET	Transport	Yes	Yes	No
netPeerTcpBinding	Peer	Transport	-	-	Yes
msmqIntegrationBinding	MSMQ	Transport	Yes	Yes	-

The above information has been condensed from Microsoft MSDN for ease of reference.