For those already working with WebSphere Integration Developer, WebSphere ESB, or WebSphere Process Server, or those considering using them, you might be interested to know that version 7.0 has just been announced and is scheduled to be available around the end of Q4 2009.

Please look at the official announcement for more information, but some of the new things I think are particularly interesting are:

• Service Federation Management between WebSphere Services Registry and Repository and WebSphere ESB.
• More pattern-based development.
• Exploitation of WebSphere Application Server V7.
• Improved Service Gateway scenario support.
• Event sequencing support in WebSphere ESB.

I was recently asked to review the new book WebSphere Application Server 7.0 Administration Guide by Steve Robinson. First impressions are good; the book looks professional and comprehensive. Steve starts from the basics, installing WebSphere Application Server from scratch. He walks through some administration tasks that I might expect an experienced system administrator or developer to be able to do without trouble (details on un-taring a file, for example), and a little more information at various points would be welcome: for example, although Chapter 1 describes creation of a profile, it doesn’t really explain what a profile is or why it would be needed, referring only to an “application server definition”.

Nevertheless, taken as a whole, the book is generally thorough, and certainly covers the basics for someone with little WebSphere Application Server expertise or exposure. Steve looks at administrative security, scripting, messaging via the System Integration Bus, and so on. As the title implies, the book doesn’t talk much about application development, but that’s fine. There’s nothing here you wouldn’t find elsewhere, but Steve does a good job of collecting it all together, and presenting WebSphere administration topics in a coherent and logical manner.

It’s a good book for WebSphere Application Server administrators who are just getting started – and it would also be useful for those learning to administrate products that use it as a base, such as WebSphere Enterprise Service Bus or WebSphere Process Server.

A little bit of a deviation from our usual WebSphere content here, but: if you’re using Lotus Connections in your organisation, you might want a way to backup the bookmarks you save to Dogear locally. Maybe there’s a lot of valuable content in there that you need should it go offline for a few hours, for example. I’m just paranoid, and I always like to have personal backups of anything important to me – which my bookmarks sure are.

So I wrote a quick and dirty Python script that backs up your bookmarks by connecting via the Dogear API and saving them to an XBEL file. It doesn’t support all fields – in particular, in doesn’t currently back up tags, only the title and the URL.

Feel free to take and adapt to your needs (as with all material on this site, this is not supported by IBM in any way and there are no guarantees that this will even work for you). Feedback appreciated as always.

You’ll need to pass in three command-line arguments to the script: hopefully the code is self-explanatory.

#!/usr/bin/python

import urllib2
import feedparser
import base64

from urllib import quote
from optparse import OptionParser

parser = OptionParser()

parser.add_option("-u", "--username", dest="username")
parser.add_option("-p", "--password", dest="password")
parser.add_option("-s", "--servername", dest="servername")

(options, args) = parser.parse_args()

print "<?xml version=\"1.0\"?>"
print "<xbel version=\"1.0\">"

PAGESIZE = 50
url = "https://" + options.servername + "/dogear/atom?email=" + quote(options.username) + "&access=all&ps=" + str(PAGESIZE)

entrieslength = PAGESIZE
currentpage = 1

base64string = base64.encodestring('%s:%s' % (options.username, options.password))[:-1]
authheader = "Basic %s" % base64string

while entrieslength >= PAGESIZE:
 req = urllib2.Request(url + "&page=" + str(currentpage))
 req.add_header("Authorization", authheader)
 data = urllib2.urlopen(req).read()
 feed = feedparser.parse(data)
 entrieslength = len(feed.entries)
 for entry in feed.entries:
  print "\t<bookmark href=\"" + entry.link + "\">"
  print "\t\t<title>" + entry.title.encode('utf-8') + "</title>"
  print "\t</bookmark>"
 currentpage = currentpage + 1

print "</xbel>"

I attended a presentation last week by one of the developers of Health Center, a new monitoring and diagnostic tool IBM has made available for debugging Java Virtual Machines as they are executing. It’s available for any application that runs on an (IBM-based) JVM, but of particular interest to me is WebSphere ESB and Process Server.

I won’t repeat the installation instructions, which you can find here, but there are one or two gotchas you should be aware of:

• At the time of writing, Java versions shipped with WebSphere ESB and Process Server (version 6.2.x) are sufficiently old that they don’t yet include the Health Center agent, so you will need to install this manually as described in the “Enabling an application for monitoring” link when you set up a connection in Health Center. Be careful to extract files into exactly the right directory.
• I also suggest you then follow the instructions labelled “Configuring WAS to enable monitoring” in the Health Center Infocenter. If you are using the embedded Integrated Test Environment servers inside WebSphere Integration Developer, I suggest the topic “Configuring WAS test environment in RAD to enable monitoring”. Although the product names are different, the principles are essentially the same.
• Be aware that (at the time of writing) Java 5 SR8 is used by WebSphere ESB and Process Server, so you’ll need to use the more complex form of JVM boot parameters as described in the help. This also means that it’s not yet recommended that use Health Center in production, although it will be useful in development, particularly when you’re focusing on performance, stability, or capacity issues. Hopefully this situation should change in later versions of WebSphere ESB and Process Server.

To give you a taster, once you’ve managed to connect, you’ll see some very cool screens, like this one that allows you to do trivial method profiling:

(sort by ‘Tree’ is particularly useful, as this includes time taken by methods that a given method has called).

Another handy view is this one, which allows you to watch your heap and JVM pause times over time (drag a box over a particular area to restrict all statistics to that period):

The best part of Health Center is that all data is updated in real time (and can be saved away and reloaded later), so you can (for example) watch your heap grow and shrink, your garbage collection happen, and so on. Overhead is generally minimal and since it uses a client/server architecture, is minimally invasive.

You can find out a lot more information on the Health Center website and the Java troubleshooting team’s blog.

Thanks to Toby Corbin for the original presentation and Dave Nice for assistance with Health Center.

Since version 6.1, WebSphere Integration Developer has come with the ability to create test projects containing test suites and programmatic emulators, allowing developers to create repeatable automated tests for their modules. Projects can contain any number of suites, test cases and variations to cover all the behaviours of the module.

One scenario often overlooked in user-defined test suites is the one where the partner reference returns a modelled fault.

For example:

Fortunately, it is possible to return a fault using a programmatic emulator. In this example we will use Java, but the same behaviour can be accomplished using a visual snippet.

First create the payload for the fault. If the payload is a String or other Java type, you can simply create it and assign it to a variable. If the object is a business object then locate the BOFactory and create it as you would any other SDO DataObject

BOFactory boFactory =
  (BOFactory) ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOFactory");

DataObject reservationFault =
  boFactory.create("http://LB_Example","ReservationFault");

Once you have the object set any attributes that are required.

reservationFault.setString("faultCode", "100");

Next create a Java ServiceBusinessException. The exception has four constructor methods, and we want the one that accepts a String and an Object. The string will be name of the fault being returned, and the object will be the payload created above.

Finally, you throw (not return) the ServiceBusinessException

ServiceBusinessException sbe =
  new ServiceBusinessException(reservationFault,"unknownEventFault");

throw sbe;

For completeness, here is the same code represented visually.

This tip comes from Arancha Ocana Diaz-Ufano, who did all the hard work to figure it out!

In WebSphere ESB, there are many ways of changing the endpoint of a SOAP message outbound from a mediation flow, and the normal way is to use the dynamic endpoint support.  To be clear, this is recommended way.

However, there is another technique, and that’s to use a JAX-WS handler (assuming you’re using a JAX-WS Web Services binding) on the outbound message. This might be useful if, for example, you absolutely cannot modify a mediation flow that’s been given to you, you cannot modify the endpoint at administration time (for example, from the administration console), or you want to do the override in a generic fashion across a large number of mediation flows.

The key is knowing the magic incantation to put in your JAX-WS handler. And here it is:

mySOAPMessageContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://myhost:9080/MyEndPoint");

Thanks again to Arancha for allowing us to publish this tip.

I’m pleased to say that my colleague David George has agreed to join the SOA Tips ‘n’ Tricks team. He’s a WebSphere Process Server consultant, and will be blogging about it, WebSphere Integration Developer, and other related subjects. Like myself, David is part of IBM Software Services and works with IBM customers on a regular basis, so has a wealth of experience to share.

As always, please remember that the postings on this blog are our own and don’t necessarily represent IBM’s positions, strategies or opinions.

Sorry that there haven’t been many posts here recently. To whet your appetite, I’m currently preparing a series of articles with a working title of ‘Mediation Flow Creation Guidelines’, which will aim to provide some guidance on well-worn ways to develop mediation flows efficiently.

In the meantime, I’d just like to mention a new book coming out soon called WebSphere Application Server 7 Internals. I’ve been lucky enough to take a look at some preview chapters, and I have to say the content is set to be excellent; Colin has done a great job of explaining many of the more detailed and nitty-gritty topics involved in WebSphere Application Server, which underpins several IBM products, including the one I specialise in, WebSphere ESB. I’m sure it’s set to be a handy tome.

If you’re creating a mediation flow in WebSphere ESB and Process Server 6.2, it’s now even easier to do ‘lazy’ (drop-and-forget) logging for debugging purposes (Note: I’m calling it ‘lazy’ deliberately. I am not suggesting you should do this in a production system – it’s for quick-and-dirty testing).

Simply drop a Message Logger primitive onto the mediation flow, and change the type from ‘Database’ to ‘Custom’:

The default handler, formatter, and filter classes shown will be used to do the logging. This means that files named MessageLogN.log will appear in your system’s temporary folder (on Windows, for example, this is normally C:\Documents and Settings\YourUsername\Local Settings\Temp). These will contain lines like this:

3/9/09 3:08 PM,EBC7634C-011F-4000-E000-02BCC0A80A8A,MessageLogger1,LogTest,<?xml version="1.0" encoding="UTF-8"?>
<body xsi:type="i1:operation1RequestMsg" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:i1="wsdl.http://LogTest/i1" xmlns:i1_1="http://LogTest/i1">
  <i1_1:operation1>
    <input1>some data</input1>
  </i1_1:operation1>
</body>
,6

The six fields you see in the comma-delimited line are:

1. Timestamp
2. Service Message Object message ID
3. Mediation primitive name
4. Module name
5. Actual message itself – i.e. the Service Message Object serialized as XML.
6. Service Message Object version

This can be really handy for quickly instrumenting a mediation flow.

If you want to get more sophisticated, you can override the handler, formatter, and filter classes with your own, and in any production system, you’d probably want to do that. This document from the Java documentation explains more.