The Bio-jETI Framework - User-Level Workflow Design: A Bioinformatics Perspective - page 52

Apparently, none of these services defines any entries for the FORBID and
KILL sets. This is in fact representative for all application domains considered
in this topic, which primarily work on self-contained data processing services
that simply consume and produce data, so that no further behavioral aspects
of the individual services have to be taken into account.
In addition to the input/output characterization in terms of symbolic type
names, a PROPHETS service interface description comprises technical infor-
mation like the reference to the SIB that implements the service, the SIB
branch to which the interface description applies, and a mapping from sym-
bolic types to the corresponding concrete SIB parameters (to enable auto-
matic parameter configuration). Furthermore, it is possible to provide default
values for SIB parameters that are not included in the semantic interface de-
scriptions of the domain model, and which are consequently not be configured
by the synthesis plugin automatically. However, with appropriate default val-
ues provided, executable workflows can be obtained also in these cases.
Note that the current implementation of the synthesis framework only
considers sets of data types for input/output characterization of the services
in the domain, and does not distinguish between concrete instances in terms
of the services' actual parameters. That is, even if several parameters of the
same type are involved, the corresponding sets contains the type exactly once,
and thus the synthesis framework is not able to tell the individual instances
apart. This can cause ambiguities, especially with respect to inserting and
instantiating services that have more than one parameter of a particular type.
For instance, consider an image processing service that combines two (or
more) pictures of the same format, say jpg , into one. The USE set of this
service only comprises the type jpg . Consequently, the synthesis regards this
serviceasexecutableassoonasone jpg data item is available, although
actually one (or more) additional instances of this type are required. Similarly,
when transferring a synthesis solution (which is given as a sequence of states
that are constituted by the sets of available data types and connected by
services that consume and produce these types) into a concrete SLG, the
instantiation of the involved SIBs can face ambiguities. As an example, the
availability of a particular data type at a state does not tell whether it refers
to one or more instances of this type, and in the latter case, to which. That
is, if the type jpg is available, but more than one of the (input) parameters
of the respective SIB are of this type, then it is not clear how the parameters
have to be instantiated. As another example, the occurrence of a data type
in several states of the synthesis solution alone does not reveal whether it
refers to the same or to different instances of the type. That is, a jpg at two
different states may refer to exactly the same image, or to different ones.
Currently, PROPHETS applies a simple heuristics for the parameter in-
stantiation, which basically aims at establishing short-distance data flow con-
nections, that is, data items are rather passed between subsequent SIBs than
across longer service sequences. In case of remaining ambiguities, simply the
first possibility that is encountered is used. Fortunately, this strategy has