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?