I was in Atlanta this week for webMethods Integration World 2005, at which GXS sponsored a number of events. GXS also held its Customer SIG (Special Interest Group), but I’ll blog that separately.

webMethods core messages are very consistent with last year’s IW, and in this case that is good. They have continued to integrate the suite, and if their company motto is not “BAM everywhere”, it could be! The highlights of the product roadmap are that the integration of the acquired products are making substantial progress (BAM can be used easily with Modeler, a number of products are now making use of portal), JMS performance has been dramatically improved from 6.1 to 6.5 (3X for guaranteed, 12X for volatile), and the tools now support a “non-developer” view called analyst.

A big announcement was a partnership around business rules with Fair Isaac (see thewebMethods’ Press Release here).

I’ve spent much of today trying to tie up loose ends in anticipation of attending webMethods Integration World in Atlanta next week. Part of this involves interacting with alot of websites and webforms (both internal and external to my company), and I realize just how addicted I’ve become to Roboform (if you have not tried it, check it out here).

Roboform is a program that manages passwords and fills out forms (and lots of other stuff). I bought it for two reasons:

This is a good article from a few months back by Dave Chapelle (who authored O’Reilly’s JMS and ESB books). I met Dave during some work we were doing with Sonic Software — and he is a true visionary.

ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked @ SOA WEB SERVICES JOURNAL

ESB stands for Enterprise Service Bus. Sonic (and Dave) practically invented the ESB category, although they have strong competition from other innovators (like Cape Clear, and — of course — open source). The emphasis is on a lightweight container model that can be effectively managed from the ESB infrastructure.

In practice, this proves challenging with legacy applications, often requiring extensive administrative integration to facilitate the management of the “service” from the ESB. As a for instance, most people know GXS for its VAN (value added network). In order to implement our Trading Grid vision, we had to create an interface to manage VAN mailboxes (create, list, extract, etc). This required constructing an API, and then wrapping it as a service that could be invoked from outside.

Piece of cake, right? Well, not exactly… GXS is fortunate to have a contemporary, open-systems based EDI service, so at least we don’t have to automate CICS transactions to add a mailbox, but it is not so contemporary that we have a friendly XML web services interface either. In order to provide that to our partners, we had to wrap a stream protocol (like ftp, but the commands are different) into an API, and then put a services interface on it.

Couldn’t we just “auto-magically” expose the API as a set of services? Sure — but it would not be a great idea, because of that evil word granularity. API work is a lot like wiring or plumbing a house, not so easy to alter later, so you want to handle every possible case you can think of, and offer a fine degree of control to the future user of the API. The service interface is more like the electrical outlets and switches. API’s that are too “coarse” mean you often have to rip open the wall, services that are too fine-grained “electrocute”. The core problem is that an API is supposed to be powerful, while a service interface should be highly usable.

So what does that have to do with ESB? Well, the emphasis on lightweight infrastructure often means you don’t have the toolset you need to integrate. As a result, I think more highly of using technologies with a strong EAI capability (like webMethods) as an ESB than Dave does (though it worries me, because he is smarter than I am….)