My doctoral research is focused in improving the user of web services and attempting to make it possible for end users (i.e., non-programmers) to modify the capabilities of their applications by adding new web services or composing existing web services into new workflows at run time. A major promise of web services has been that they will enable just that — users will be able to find new web services as they are published and add them to their applications without recompiling.

Previous efforts in this arena have focused on one of two main approaches: using purpose-built frameworks that channel all web service development to conform to specific standards that foster interoperability; or requiring developers to generate significant amounts of semantic metadata that is then appended to the web service description.

My approach is based on the belief that web service interface descriptions (generally in the form of Web Service Description Language (WSDL) documents) contain within them an implicit ontology, and that it is possible to tease out that ontology and match it to similar ontologies in other WSDL documents. Put another way, I believe that the structure and content of the WDSL interface description reflects the developer’s understanding of the information, and thereby the structure and relationship of the different input and output elements.

Parsing out this sort of information is traditionally the province of artificial intelligence researchers, but I am hopeful that by using a multitude of simple, task-specific agents, I can predict parameter matches with sufficient fidelity to enable me to state with some degree of accuracy that the outputs of Service A can be matched to the inputs of Service B, and that A and B can therefore be composed into a viable workflow.

I am using an agent-based framework (the Java Agent Development Framework) to develop a proof of concept application. So far, I am making slow but (hopefully) steady progress. I have a basic agent set that will parse a WSDL document into its operations, the input and output messages for each operation, and the individual parameters for each operation. All of these are stuck into a database for ease of access when I need them. I’ll fill in more details as I have time.

I seem to be unable to maintain a dissertation log*, which is a recommended practice for anyone working on their doctoral dissertation. At least, I can’t maintain one in the form of a paper document or a word processor file.

So I have resorted to maintaining one here, in public, where anyone and everyone can see whether I am maintaining it. Perhaps the potential shame of being called out for not updating it will be enough to keep me at it. I can only hope.

*In the process of proofreading I realized that the document is normally called a “dissertation journal,” but I guess old habits die hard. Those of us in the sea services maintain “logs” of our doings. On reflection, I like the sound of it better than “journal.”