I’ve spent most of this weekend trying to build a simple JADE agent that will invoke a web service and return the results. I finally succeeded this morning, after a fashion. And it was not pretty.

I began trying a simple stock quote service, as I thought this would be useful and easy to incorporate into several demonstration workflows. I was able to find some public services available, so I set to work. I decided to use WSDL2Java utility to generate an interface I could easily call. The utility worked simply enough, although the code it generates is less than intuitive. Searching through several forums and tutorials weren’t much help; its interface is apparently sufficiently quirky that Axis2 didn’t much like it. Most other stock quote services are subscription-only, and I’m not going to be using this enough to make that worth my while.

So I decided to switch to a weather service; that’s always a good standby for a workflow. and the National Oceanic and Atmospheric Administration (NOAA) has a publicly available weather service I for a class project several years ago. It’s the National Digital Forecast Database (NDFD), and it makes all manner of weather information available.

After 8 or 10 different attempts to generate code from the WSDL, using both the Axis2 utility, the MyEclipse utility of the same name, and a couple of others, I found myself in the same state as I was with the stock quote service. The one major difference is that there is some chatter on various web sites and forums discussing the NDFD service, and apparently it’s not very well-behaved when code is generated from it. The general opinion of the user community seems to be that it’s a poorly designed service; I’m not enough of a programmer to offer a meaningful opinion.

I did finally get the NDFD service to work. It’s not pretty, but it works. I’m manually generating the SOAP request, building the message, and submitting it to the service. And as painful as that sounds, it’s no worse than dealing with the mess that is Axis2. I’m sure the authors mean well, but they seem focused on service providers and not consumers. Surely there must be a more straightforward way to write code for invoking a web service. It’s no wonder web service adoption has been much less rapid than originally anticipated.

I am working on the development of a descriptive framework that is usable for all services, including electronic and business services. Electronic services can be described (however imperfectly) using the Web Services Description Language (WSDL). while not perfect, WSDL does have the advantage of being widely adopted for SOAP-based web services. When carefully assembled, web services can be chained together into an executable workflow to perform some useful task.

There no analogous way to assemble a workflow from business services.  While a business process can be described using BPMN, there is no way to automatically screen business service providers to determine whether they are suitable for performing a particular task within a given workflow. What is lacking is a WSDL for business services.

We need a machine-processable description of the services offered by a business. This description should include the tasks performed by the service (i.g., its effects), the inputs required to engage the service, the outputs that will be produced by the service, and any preconditions that must be satisfied before engaging the service. To the maximum extent practical, this description should be compatible with existing WSDLs — there is no logical reason electronic services cannot be combined with other services to form a complete workflow, so the descriptions of both services types should be compatible.

I’ve spent some time lately working on just such a service description, and over the weekend I turned my notes into a detailed class model that I exported into an XML schema. Next i need to do a detailed comparison with the WSDL schema to ensure I have accounted for all elements of the WSDL. After making any necessary refinements I will try some practical applications to see how it handles.

As best I can determine, nothing of this type has been developed to date. I had planned to call it a “Business Service Definition Language,” but I discovered that name was already taken by several researchers from the University of Wollongong who have published an interesting paper on the subject. Luckily for me, their research is in a different direction from mine even though they arrived at the same terminology. Universal Service Description Language is already taken. I considered General or Generic Service Description Language, but those seem too… generic.

So for now, it’s back to thinking of an appropriate name for my creation.