Meaning and Behaviour in Grid Oriented Components

An End-to-end Workflow Pipeline for Large-scale Grid Computing

“…These include the implemented functional interfaces, behavioral description (e.g., performance characteristics), resource dependencies and runtime requirements. While multiple components might exhibit the same functional interface, they can be independently implemented yielding different behavior [45]. An application therefore consists of a number of components linked together in a manner which performs the overall task required by the e-Scientist.…”

“…We advocate the collection and use of higher level annotation information on components and the workflow languages used to describe the use of these components. In previous work (Mayer [45]) we proposed the annotation of components in terms on Meaning, Behavior and implementation. We see that as an integral part in the development of techniques for efficiently executing abstract workflows defined by users.…”

“…Using static information about the components, this Service accepts as input an application's workflow specified by the user in an appropriate high-level, componentbased language and produces a pre-optimised workflow that is expected to execute more efficiently in the Grid than the original one would. Each component defined at the level of meaning (e.g., linear solver) that participates in the workflow may have multiple behaviors (e.g., pull data in, push data out) each of which has multiple implementations (e.g., Cholesky implemented in C) for different input parameters (such as matrix type for numerical method components) and also for different execution platform architectures (e.g., linux vs MS Windows) [45]. The mapping of component to implementation takes place at the runtime, pre-scheduling phase (see Section 5.3).…”

“…Abstract Workflow. The goal description is mapped down onto an abstract workflow which describes the workflow in terms of its meaning [45]. Thus the workflow contains information about what each component will do rather than how it will achieve it, along with information about how these components are interconnected.…”

Collective Interfaces for Distributed Components

“…They use messages or invocations, and most rely on intermediate components. ICENI [16] proposes a range of dispatch modes, including scatter, gather, dispatch and reduce, but they are only applicable to arrays and require XML data. Several CCA frameworks [6] propose collective communications in order to provide efficient and modular code coupling, usually using intermediate components, and also through group method invocations.…”