Archive for the ‘Java’ Category

Calling Java One-Way, with or without Exception Handling, in BizTalk

November 20, 2007 Leave a comment

A co-worker, Richard Seroter, created a post earlier this year talking about BizTalk calling a .NET web service enabling/disabling the OneWay tag. Inevitably the situation came up at work where there was a need to call a Java web service through a One-Way SOAP send port yet the service wanted to be able to throw exceptions back to BizTalk in the event one occurred (this isn’t a true asynchronous call, yet something people often yearn for). So, I looked into things and here’s what I found…

By the way, the Java web service I referred to earlier was built using NetBeans 5.5, so I downloaded NetBeans to reproduce the scenario. Once installed, I created a new project of type Web->Web Application. If you are trying this yourself, in the New Project wizard, be sure to use a JDK of 1.5 or higher in order to get some of the built-in web services funcationality (mine defaulted to 1.4 for some reason).

After doing this, I right-clicked on the newly-created project and chose New->Web Service. After stepping through the wizard, I had something like this:

package MyPackage;

import javax.jws.WebService;

public class NewWebService {


I proceeded to add a method that looks like this:

public void ProcessNewSomething(String myString){

I then right-clicked on my project and chose Deploy Project. After figuring out what port Tomcat had chosen, I was then able to browse the WSDL. Next, I used TCP Trace to start monitoring traffic. I then started XML Spy to call the web service and sent through a SOAP message:

What’s happening here is that the web service is being called synchronously, despite the fact that the method is void and returns nothing. This is the desired behavior for BizTalk when called synchronously. But what about when a One-Way SOAP message is sent through? There are two options here. As Richard points out in his posting, the OneWay flag can be set to true or false. If true on the side of the web service proxy (interface object), then the Java side to match it would look like this:

public void ProcessNewSomething(String myString){

In this example, the addition of the tags @WebMethod() and @Oneway indicate an asynchronous call. The web traffic now looks like this:

Here we see that the only response is the “202 Accepted”. This is a true asynchronous call, but if an exception is thrown in the Java code, it won’t go back to the caller, which in our case is BizTalk (in fact it won’t even compile if you try this). So, if you’d like to make a mostly-asynchronous call, i.e. asynchronous except the added ability to catch exceptions, you can leave out the @Oneway attribute on the Java side, and similarly set the OneWay=false flag on the proxy (interface object) on the .NET side, and you can have BizTalk queue up messages that couldn’t be processed because of an exception in the Java code.

In conclusion, the tricky, and sometimes confusing thing to be sure of, is that the sending proxy (interface object) and receiver, whether it be Java or .NET, are both set to communicate the same way, either asynchronously or synchronously. If out-of-sync with each other, you’ll have trouble, which will most likely present itself in the form of suspended messages due to some sort of delivery failure in BizTalk.