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

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;

@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:

@WebMethod()
@Oneway
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.

Terminal Services and the BizTalk Administration Console

One of the problems at work we faced a while back as our BizTalk developer pool grew, was an increased need to allow users to simultaneously work on the same BizTalk Server. Some of the time users need to deploy new things on the server, but the grand majority of the time they simply needed to resume suspended messages, kill messages, etc. (we all know how this goes, right?).

Until this time, our current process involved having each user use a Remote Desktop Connection to connect to the server, do whatever administration they needed, and then, if we were lucky, they’d log off. We only had two Terminal Service licenses (the default for remote administration), so of course now and again, people didn’t log off, or at least didn’t do so properly and then we’d have a problem on our hands. Emails would go out trying to figure out who was accessing the server so that the next poor guy or gal could start their work. As a response, we did a few things to help.

First, we modified the Terminal Services configuration to end disconnected sessions quickly and we closed sessions that had been idle for an hour.

Of course this helped a great deal, but it wasn’t enough – we actually had a real need to have several users logged in at once. So then we heard about the “secret” third terminal service connection.

Basically, the secret third terminal service connection is the console. By adding the “/console” appendage to the otherwise ordinary Remote Desktop Connection command, e.g. %SystemRoot%\system32\mstsc.exe /console, you can get a third person in on the box. As a note, you probably want to avoid using “/console” unless you need to get on the box, as it will force the previous console user out. Nonetheless, you now have 3 remote users! In this image you see I have successfully logged in thrice; the green user indicates the console (or so I presume):

This last approach is a little bit of a hack, but nonetheless nice to know. Now, here’s the real exciting part for BizTalk administrators…

As I mentioned, most of our developers were logging into the various servers to simply resume orchestrations, kill messages, and so forth. This is when a fellow teammate, Richard Seroter, looked into better utilizing the Microsoft MMC capabilities. This approach doesn’t require the users to log into any of the various servers to do their administration tasks. Rather, from a single console, all BizTalk Servers the user has access to can be managed. Similarly, assuming the user has access to the event logs of the particular server, the event logs of each server would also be available.

To get started, install BizTalk Server with just the minimum number of components (may not even be necessary if your using your own pc for BizTalk development). In my setup I added the additional software component of Enterprise Single Sign-On Administration Module.

Next, download the Microsoft Management Console for your OS. Mine is XP, so I found it here. Then, you can either modify an existing msc file (why didn’t MS choose mmc?) or create a new one. To modify, throw in the /a to the mmc command, e.g. mmc /a whatever.msc. To create a new one, just run the command ‘mmc.exe’. Next, choose File->Add/Remove Snap-Ins.

In the screen above I am setting up administration for any number of BT servers (I’ll later setup 2) and 2 Event Log viewers (one for each remote server). After pressing OK you will then need to add a BizTalk Server group, which I won’t go into here…

So what’s the final result? The ability to monitor two (or more) servers from a single console without having to log into any of the servers. This has saved me a lot of hassle. Now our developers only login to the various servers when they need to deploy a new msi file. Consequently our terminal services use has declined dramatically.

Oh, one more thing to note, if you use any other adapters, e.g. Siebel, Oracle, etc., you will need to install the basics of the adapters on the machine with the MMC as well. Good luck!