R ESULTS FOR UNCOATED AND COATED M ETAL N ANOPARTICLES

Workflow definitions

From the research perspective, a Workflow is the "process of combining data and processes into a config-urable, structured set of steps that implement semi-automated computational solutions of a scientific problem" [Wikipedia, Kepler].

The Workflow Management Coalition (WfMC) defines workflow as "The automation of a business pro-cess, in whole or part, during which documents, information or tasks are passed from one participant to

89 The current version of the technical guidance for INSPIRE Discovery Services is available under

http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical%20Guidance%20Discovery%20Services%20v2.0.p df (August 2009)

90 http://www.wfmc.org/

91 The Workflow Reference Model - 10 years on:

http://www.futstrat.com/books/downloads/Ref_Model_10_years_on_Hollingsworth.pdf

another for action, according to a set of procedural rules". In other words, a workflow consists of all the steps that should be executed in order to deliver an output or to achieve a goal. These steps (tasks) can have a variety of complexity and are usually connected in a non-linear way, forming a directed acyclic graph (DAG). A Workflow Management System defines, manages, and executes workflows through the execution of software that is driven by a computer representation of the workflow logic. The description of a workflow includes the definition of different tasks, their interconnection structure, and their depend-encies and relative order. This description of the operational aspects of a workflow can be expressed in textual (e.g. XML) or graphical form (e.g. as a graph in Business Process Modelling Notation [BPMN] or Petri nets).

In the context of Grids, a workflow is postulated as "The automation of the processes, which involves the orchestration of a set of Grid services, agents and actors that must be combined together to solve a prob-lem or to define a new service".

In the context of OGC, workflows are produced through "service chaining", which can be performed in a number of ways:

• Orchestration of a service chain including one or more Web Processing Services (WPS) using a BPEL engine.

• A WPS process can be designed to call a sequence of web services including other WPS process-es, thus acting as the service-chaining engine.

• Simple service chains can be encoded as part of the execute query. Such cascading service chains can be executed even via the GET interface.

Workflow components

For LifeWatch a Workflow will be defined as: an identifiable and thus reusable sequence of services, including the related resources and agents, where:

• Services are the basic functional components of the infrastructure, defined by interfaces,

• Resources are all elements to be used by the service such as information, information models (see Section1), or other services, which are used internally and are not explicitly visible for the work-flow and,

• Agents are the actors involved in the workflow having particular roles and responsibilities (e.g.

observer, creator, consumer, etc.) and may be a human or another service.

The principal components and their interactions are depicted in Figure 19.

Figure 19: Workflow components

Service

Agent Resource

Consumes, generates, transforms

Access, ownership, permissions

Roles

The WfRM defines two major phases for workflows: (1) a build phase, where the workflow is defined in terms of a textual or graphical language, and (2) a run phase where the workflow is enacted according to its definition by a workflow execution (enactment) component or a workflow engine. The capabilities required for these phases leads to a functional decomposition of workflow management into the following elements:

• Workflow composition: user environments, usually graphical, where the user can define a work-flow (phase 1)

• Workflow definition: representation languages that are used to express workflows (phase 1)

• Workflow compilation: Translation or compilation of a workflow so that it could be enacted (phase 2)

• Workflow enactment: execution of a workflow and runtime support (phase 2)

To support the ability to work with workflows, LifeWatch will provide separated workflow management capabilities that can be used independently in support of each of these elements.

The nature of workflow can be very varied. Depending on the duration of execution, results can be deliv-ered quasi immediately or a notification mechanism may be needed to inform the user how to retrieve the results, when the workflow finished. The number of entities (actors, services and resources) and the way they are organised involved can also vary significantly. Different workflow categories can be derived according to the different aspects.

Workflow patterns

This aspect reflects options for the allocation of workflows to components, according to different priori-ties for different applications. According to the design pattern for service chaining defined by OGC, LifeWatch introduces three types of workflow representing different infrastructure components holding the workflow definition and users’ perspectives on workflow [cf. OpenGIS Service architecture]:

• User-defined (transparent) chaining: The human supervises and controls the workflow execution.

The user knows how services can be combined, is able to discover available services matching his/her goals, guarantees that inputs and outputs of the services chained are compatible, provide sufficient resources to run the services, and controls execution. Calling services sequentially us-ing a terminal with line wise commands is, for instance, an example of transparent chainus-ing. A portal with predetermined interactions by a user that result in calling different services sequential-ly, where the output of one service determines which services may be called next, may be consid-ered as a transparent chaining (though the user may not be aware of services being called).This pattern is also known as client-coordinated service chaining.

• Workflow-managed (translucent) chaining: The user calls a workflow management service (En-actment service) that controls execution of the chain but is aware of the structure of the workflow and the individual services chained. A key distinction to transparent chaining is that all of the workflow is defined before execution. While executing, the user’s role is mostly one of observing the progression of execution of the individual services but the user may be asked to interact, for instance, in order to provide specific parameters. The enactment service handles the details of ex-ecution, for instance, of distributed computing. Depending on intermediate results the user may interfere, for instance, to abort execution due to lack of convergence of computation. The typical scenario is that the user has edited a workflow using a Workflow Editor Service or that a user re-trieves a workflow from a repository and then calls an Enactment Service.

• Opaque chaining: The workflow has been deployed as a service, which performs an aggregation and management of the related services. The user has no awareness of the individual services and relatively little control over the workflow. This type is often hidden behind portal functionality or complex processing services. A portal with predetermined interactions by a user that result in calling different services sequentially, where the output of one service determines which services

may be called next, may be considered as an opaque chaining since the user is not aware of the underlying workflow. This pattern is also known as aggregate service or static chaining.

Figure 20 shows collaboration diagrams for the three patterns.

Figure 20: Workflow patterns: a) transparent workflow; b) translucent workflow; c) opaque workflow

Execution models

• In data-driven workflows, information is streamed from one agent to the next. An activity is initi-ated by the arrival of data. Often, data-flow based workflows have no explicit control instance for the whole process.

• In control-driven workflows, the connections between agents represent transfer of control from one task to another. This typically includes control-structures such as sequences, conditionals, and iterations.

• Hybrid models combine data-driven workflows with discrete control elements.

Workflow representation

This aspect is concerned with the structure of workflows. The following structure of increasing complexi-ty:

• In a linear sequence: simple sequence of tasks to be performed in a specified linear order;

• As an acyclic graph: some workflow tasks depend upon the completion of several other tasks which may be executed concurrently;

• As a cyclic graph: the cycles represent some form of explicit or implicit loop or iteration control mechanism. Services are "connected" with each other and communicate via messages or se-quence of transactions; and,

• As a workflow hierarchy: is used to model very complex workflows, which can be separated into individual graphs. The workflow hierarchy represents a workflow of workflows, where the con-trol instance is not necessarily aware of the sequences defined within a workflow part.