...Because that's how long it took me to find and fix a bug in the [not so] new WebSphere V6.1 product.

Let me present some background before I start to rant! Starting V6.0, WAS has a concept of Service Integration BUS (or SIBUS). You can use this to forward an xml/soap message from a receiving queue to web service. You can also put mediations on the request and return paths to inspect/manipulate the message. This eliminates the need to parse an incoming xml message while giving a lot of flexibility in other areas. Actually, you can do a lot more with SIBUS but let me just rant for today.

WAS represents the message in Service Data Object (SDO) format because it's much easier to work with objects when you are inspecting or manipulating the message or its path. You have to install an SDO repository - a database where your wsdl and other service information is stored so that WAS can create SDO object structure – for this to work. When you create an SIBUS web service using the admin console, WAS 6.1 'should' put the service information - especially wsdl file in the SDO database using wsdl location as the primary key. So, MyService.wsdl will be stored using http://localhost:<port>/<context_root>/services/MyService/wsdl/MyService.wsdl as the key. This happens automatically when you create the SIBUS service through admin console. When you use the service, you specify a so called format string to identify the wsdl (the key of the SDO repository) the incoming soap message belongs to. Specifying the format string will give you complete SDO structure including service name, parameters, header, attachment and body in object form so that you can manipulate anything you want. You can even change the message route!

So far so good. My problem started when I successfully defined the service but couldn't retrieve it as SDO. Surprisingly, no error was reported but message simply didn't forward to my web service from the receiving queue. Upon close inspection of log files in ffdc log directory, I got a message similar to 'wsdl could not be located.' And upon closer inspection (and of course a lot time wasting), I found an ObjectNotFoundException on SDO repository. Obviously, I was using wrong key (format string) to retrieve my data. Now, according to WAS 6.1 info center, format string should be defined in the following format:

SOAP:<wsdl_location><other_parameters>

And that is exactly what I was using. This led me to reinstalling SDO repository, recreating server profile, redeploying ear files and web services and a lot more not to mention, lost sleep and eating/drinking unhealthy stuff while desperately trying to figure out what was going on.

Finally, I decided to try WAS 6.0 supported format of format string:

SOAP:dest:<bus_name>,<other_parameters>

Correctly, I got an incorrect format string error because there was a validation component watching the format string I was passing. As it turns out while the validation component was watching the format string correctly, IBM WAS developers were NOT watching the key they used to create a record in the SDO repository for an SIBUS web service.

When you create a web service in SIBUS, WAS 6.1 uses WRONG KEY to insert the record in the repository. It uses "SOAP:dest…" format. So there is a record in the repository for your web service but you can never retrieve it because of the validation component! If you use the WAS 6.1 recommended format, "SOAP:<wsdl_location>…" you will never get any results back because the data wasn't inserted with that key in the first place. In other words, creating a web service within SIBUS will NOT work correctly in WAS 6.1.

It took me 3 days to figure it out. Finally, I ended up writing some jacl script to fix this issue (I will share the scripts in near future). What is ironic is, "SOAP:dest:…" format is not even mentioned in WAS 6.0 OR WAS 6.1 info center. I found this format from an article on developerworks at http://www-128.ibm.com/developerworks/websphere/techjournal/0509_reinitz/0509_reinitz.html. Info center always mentioned "SOAP:<wsdl_location>," which makes sense because every web service within a bus will have unique wsdl location so location should be used to store objects in SDO repository.

The lesson learned? If you are using WAS 6.0, use "SOAP:dest…" format to specify format string. And if you are using WAS 6.1, good luck using web services in SIBUS environment! Well... just use the jacl script I will share soon to change the SDO repository to make the correct format string work.