Lessons Learned - User-Level Workflow Design: A Bioinformatics Perspective - page 147

As detailed in the introduction (Section 1.1.1), services are basically read-
ily executable “nuggets of functionality” that are ready for use in complex
applications. More specifically, services as understood in the scope of this
work are clearly defined units of functionality that abstract from the inter-
faces of the underlying implementations in order to provide the functionality
at an application-specific, less technical, and hence user-accessible level. Ide-
ally, the specification and design of services is approached in a top-down and
use-case-oriented fashion, identifying the requirements from the user's or ap-
plication's perspective. A frequent problem with existing services, however,
is that they are usually conceived from a programmers' perspective, which
often differs considerably from that of the user: While programmers tend to
think in technical details of the concrete service interface implementations,
users typically think in the pieces of functionality required for their appli-
cations. As a consequence, service interfaces are often convenient to use for
application programmers, but not for users of workflow environments, who
want to work on a more abstract level.
In fact, many existing tools and services provide useful functionality, but
are not directly adequate for use in workflow applications due to inappropri-
ate interfaces. Thus, turning them into adequate SIB libraries may require
additional service conception efforts. More precisely, either a service of ad-
equate granularity is directly usable, or the SIB developer can combine dif-
ferent small steps into an adequate larger one, or also split a large step into
adequate smaller ones. The following explains and illustrates these three prin-
cipal possibilities in greater detail. Subsequently it is discussed that the same
principles also apply for the data types that are associated with the services.
Directly Using Services
Ideally, the workflow building blocks for a particular application scenario can
directly be derived from existing services. As already sketched above, how-
ever, existing services are often simply not conceived for use in user-oriented
workflow environments like Bio-jETI, and are thus not directly usable.
Interestingly, it has often been possible to use “classical” command line
tools more or less directly, while for many “modern” (esp. Web Service) re-
mote interfaces straightforward integration did not result in user-level SIBs.
In fact, command line tools are typically designed to execute particular, well-
defined tasks, and usually all inputs and configuration options can be pro-
vided upon invocation, so that their execution runs completely autonomous
(“headless”). Furthermore, command line tools typically work on files, which
are per se more user-level than the programming language entities (such as
Java objects) that are required for the communication with, e.g., Web Service
APIs. Accordingly, jETI services, which are designed to provide convenient
(remote) access to file-based command line tools, are inherently closer to the
user level than web services.