Biomedical Engineering Reference
In-Depth Information
language [1], XML process definition language from the workflow management
coalition [4], and Microsoft and IBM's business process execution language for web
services (BPEL4WS) [10], which is a combination of Microsoft's XLANG [57] and
IBM's WSFL [39]. Although developed for web services, these workflow languages
support the basic requirements of sequential and parallel execution of tasks, looping,
and conditional control constructs.
There have been many efforts aimed at building workflows based on web services.
For example, both Huang's SWFL [31] and Addis et al.'s SCUFL [6] (the workflow
component of myGrid [27]) make use of WSFL as a basis to construct their languages,
whereas most recently, Wang's Triana Workflow utilized BPEL4WS [43]. It must,
however, be remembered that these standards are constantly evolving, and, with the
introduction of new web services-oriented languages, it is difficult to foretell the exact
standard that will be accepted by the community in future.
There are however a few drawbacks to the services-oriented workflow solutions.
For one, these require deployment of the services, that is, installation and publication
of applications. As a result, services are less mobile (in the sense that they run only
where they have been installed) and the extra overhead can be an obstacle for the
development of new applications. Furthermore, services-oriented solutions, such as
the GridRPC and DSM approaches, require re-engineering of legacy applications.
There are also security issues that need to be considered while implementing web
services because the WSFL approach to workflow composition does not provide the
security features of a Grid certificate authentication provided by Globus. Hence, there
is a possible cause for concern on abuse and misuse from unauthorized users. Although
Amin's GridAnt [9] and Biven's GALE [15] do make an effort to address these issues
with the implementation of Grid security features, their present descriptive languages
are only able to express simple directed acyclic graphs (DAGs).
The use of grid services also raises similar problems to that of web services. Users
would need to first enable their application as a Grid service before they can enact
the workflow. Changing standards, with the coming introduction of the open grid
service architecture (OGSA) [26], would mean that a workflow built using a solution
as Huang's GSiB, which deploys an application as a grid service, would not be a valid
composition.
Legacy systems are also a potential problem as such most such applications are not
or cannot be readily and easily made available as a web or grid service. Web services
though developed to enable enterprises to give access to their legacy applications
through the web, do not presently allow for multiple types of applications invocation,
for example, MPI, java, PVM, and C
/
C
++
to name a few. Web services are essentially
only able to make web service calls.
There are also nonservices-oriented workflow languages such as DAGMan [17],
GridANT [9], GALE [15], and APST [14]. However, these languages only support
workflows with acyclic dependencies and thus cannot handle iterative loops, and as
such are not generic programming languages.
In summary, standards for web services-oriented workflow languages are con-
stantly evolving. They are not semantically suited for data-driven workflows. Addi-
tionally, security issues pose concerns for safe grid operations. Furthermore, most
Search WWH ::
Custom Search