Conclusion - User-Level Workflow Design: A Bioinformatics Perspective - page 185

Synthesis Performance
As detailed in Section 7.1.2, the performance of the synthesis algorithm suffers
from the state explosion problem [324]: the size of the synthesis universe,
and thus the time required for the (breadth-first) search of solutions in the
universe, grows exponentially with the number of services in the domain
model. Section 7.1.2 also shows, however, that despite state explosion, there
is potential for improving the performance of the synthesis' search, as, for
instance, constraints can not only reduce the number of solutions effectively,
but also size of the search space.
At the downside, applying lots of constraints impacts the performance of
the construction of the formula automaton from the constraints, which is done
prior to the actual search. Although this step is usually faster and hence not
crucial for the overall execution time of the synthesis, there is clear potential
for improvement that should be exploited.
Domain Modeling
One central issue of all automatic workflow composition approaches is that
considerable effort is required to set up adequate domain models. The quality
of the obtained solutions crucially depends on the quality of the available in-
formation about the services of the domain. Merely syntactic information (as
provided by most programming language APIs or standard web service inter-
faces) is not su cient. Proper semantic descriptions of services and data types
are required to obtain meaningful results. For instance, assume a web service
that returns a job ID, and another service that consumes a nucleotide se-
quence. From a programming language point of view, both would be classified
as character sequences (strings) and would thus be assumed to match. While
this is syntactically correct, submitting a job ID to a sequence analysis service
would of course not lead to the desired results, so a more precise, semantic
interface description is required. Furthermore, adequate domain modeling re-
quires to incorporate as much domain knowledge as possible, far beyond the
mere technical aspects of the different types and services in order to enable
ecient working with large, heterogeneous and hence manually intractable
service collections.
While it is easy to see that the domain modeling is the key of making
information technology available to users, as it can enable them to express
their problems in their own language terms, finding or defining semantically
appropriate service and type descriptions is indeed a dicult task [190], and
it is not clear where the manifold ingredients for a good domain model should
ideally come from. Basic domain-specific vocabulary can be provided by on-
tologies like EDAM (cf. Section 3.3.1), but refinements or additions may
be necessary to cover the terminology of specific applications. Service an-
notations should ideally come directly from their providers (cf. [127]), but
as the services themselves can be automatically imported or retrieved from