Architectures for Dynamic Service Composition

Call for involvement
John Collins and Wolfgang Ketter

The MinneTAC group at the University of Minnesota and at Erasmus University in Rotterdam is embarking on a spinoff project, looking into applying some of the architectural ideas from the MinneTAC agent to a web-service environment. The application vision is what we call Ontology-Driven Decision Support (ODDS). A very high-level view of this idea is shown here:

The idea is that we have a dynamic environment, where decision makers must monitor and control their own processes, as well as make decisions about interactions with entities in the outside world, such as customers, suppliers, partners, etc. There are a variety of "service modules", in various categories shown here as Data acquisition, Analysis and modeling, and Presentation tools. Some of these are externally-available tools (think Google Maps), and some are internal. We assume that all of them are configured as Web Services, but with a restricted API that makes them appear to be dataflow components - each takes some inputs, does some processing of some sort, and produces outputs.

Individual services are described with Semantic Web standards, such as RDF/OWL, both in terms of the types of data they consume and produce, but also in terms of the transformations they perform and in many cases the business meanings of their inputs and outputs. This allows, for example, the automatic labeling of graphical presentations. Also, it should eventually allow pro-active composition of service networks that can generate specific business information, such as summaries, trends, distributions, etc.

For more background on this work, see our working paper on decision support using dynamic networks.

Research directions

We are looking for students who are interested in furthering this work in a variety of ways, such as

Ontology-driven composition
Given a set of services that are described in terms of our ontology, how do we compose them to produce useful results?
Representation, construction, and maintenance of ad hoc service networks
Service networks are graphs (probably, but not necessarily acylic graphs) of dataflow services that satisfy constraints defined by their formal descriptions, and that produce well-defined business results. These are not static structures -- any given service might be participating in multiple such graphs at any given time. How do we lash them together at runtime, given that we know what the graph should look like?
Service discovery
How do we find services? This is probably not a UDDI problem. Do we need some sort of directory service? How simple could it be? How does it hook into the ontology?
Data caching and validity
In a dynamic network, how do we know which results are still valid and which need to be re-computed? This could be a critical performance issue.
Mixed forward and backward chaining
We envision two kinds of activity in such a service network. First is query behavior, in which a service is queried for a result. This would result in synchronous "backward-chaining" behavior, in which the queried service must query other services for its inputs. The other is event-driven data acquisition behavior, in which aspects of the environment are monitored, looking for patterns, alarms, etc. These may then trigger other activities that do logging and data reduction in an asynchronous "forward-chaining" way.
Security model
Services and data may be restricted inside or across organizations. How do we combine the ability to freely compose services with necessary security restrictions? Should security issues be represented in our ontology?
Test support
Semantic descriptions can presumably be used to generate test cases. Can we prove it with code?