Repository: incubator-taverna-plugin-component Updated Branches: refs/heads/master bb94976c9 -> aaa2befc1
GitHub uses README.md instead of index.md Project: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/commit/aaa2befc Tree: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/tree/aaa2befc Diff: http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/diff/aaa2befc Branch: refs/heads/master Commit: aaa2befc1721e644312ef7adfbd52ed56c6b3862 Parents: bb94976 Author: Stian Soiland-Reyes <[email protected]> Authored: Fri Jun 29 10:01:37 2018 +0100 Committer: Stian Soiland-Reyes <[email protected]> Committed: Fri Jun 29 10:01:37 2018 +0100 ---------------------------------------------------------------------- README.md | 2 +- doc/README.md | 162 +++++++++++++++++++++++++++++++++++++++++++++++++++++ doc/index.md | 162 ----------------------------------------------------- 3 files changed, 163 insertions(+), 163 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/blob/aaa2befc/README.md ---------------------------------------------------------------------- diff --git a/README.md b/README.md index bbee7db..d0849b3 100644 --- a/README.md +++ b/README.md @@ -21,7 +21,7 @@ Plugins for [Apache Taverna](http://taverna.incubator.apache.org/) for supporting components. -[Taverna Workflow Components](doc/index.md) are a system for creating shareable, +[Taverna Workflow Components](doc/) are a system for creating shareable, reusable, encapsulated sub-workflows that perform clearly defined tasks while abstracting the details of how those tasks are performed. http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/blob/aaa2befc/doc/README.md ---------------------------------------------------------------------- diff --git a/doc/README.md b/doc/README.md new file mode 100644 index 0000000..92d6247 --- /dev/null +++ b/doc/README.md @@ -0,0 +1,162 @@ +# Workflow Components + +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +## Overview +Taverna Workflow Components are a system for creating shareable, reusable, + encapsulated sub-workflows that perform clearly defined tasks while abstracting + the details of how those tasks are performed. +They are an integrated feature of Taverna since Workbench 2.5.0 and Server 2.5.4. + +Taverna's system of service components was developed as part of the BioVeL and SCAPE projects. They consist of tools for the creation, management and use of workflow components, + along with a repository for the storage and sharing of those components. +Workflow components within a given component family will work together cleanly, + for example, by adhering to a tidy type system and being well described. + +## Requirements + +A set of minimal functional requirements for service component management has been developed. These requirements are + based upon previous component-related work carried out as part of the e-Lico project as well as an examination of the needs of BioVeL and SCAPE. + +The requirements include: + + - The ability to create components + - The specification of the characteristics that are necessary for a set of components to + âplayâ together â called a âcomponent profileâ + - Creating a component so it complies with a given profile + - Checking that a component complies with a given profile + - Publishing a component + - Discovering a component + - Including a component in a workflow + - Executing the component within a workflow run + +<img class="aligncenter" title="The Model of Components" src="img/registry.png" alt="" + width="433" height="251" /> + +## Workflows +### Example workflow with components + +This is an example workflow that includes components, with internal ports hidden for simplicity: + +<img class="alignnone" title="Componentized Workflow" src="img/component_b_1.png" alt="" + width="679" height="294" /> + +Without components, using the same view, it would instead look like this: + +[<img class="aligncenter" title="Un-componentized Workflow" src="img/component_c.png" alt="" width="245" height="526" />](http://www.taverna.org.uk/pages/wp-content/uploads/2013/05/component_c.png) + +### Including a component in a workflow + +A component can be added into a Taverna workflow in the same way as an ordinary service: + by dragging it from the service panel of the workbench into the workflow design view. + *Although it may be realized internally as a workflow, + a user sees it as a âblack boxâ and cannot (normally) edit the componentâs workflow.* + +<img class="aligncenter" src="img/arch3.png" alt="" width="500" height="401" /> + +It is intended that there will be consistency checks to ensure components are only plugged + together in a sensible manner, and for the discovery of (and connection to) suitable components + based upon existing workflow structure. + +### Executing a component in a workflow run + +When a component is invoked during a workflow run, the underlying workflow is called with the + corresponding data. +The results of the workflow are used as the output data for the component invocation. +*The user sees the component invocation as a âblack boxâ and cannot see details of + what happens inside.* + +>If you publish a workflow containing a component, you *must* make sure the + component is publicly readable in a globally-accessible component registry; + myExperiment is such a suitable registry. + +## Components +### Component creation + +It was decided that the majority of the information necessary for a component will be specified + as a Taverna workflow. +This allows complex internal component functionality and removes the need for extensive new + software to design components. + +<img class="aligncenter" src="img/arch1.png" alt="" width="340" height="433" /> + +### Component profile + +A specification of the format for the component profile has been agreed. +The format is in XML and an XML schema (xsd) has been created. +An example [component profile](http://www.myexperiment.org/files/905/versions/1/download/Characterisation%20Component.xml) + is available. +Components that share a profile will be collected together into component families. +A [component profile editor](/documentation/components/component-profile-editor) + is being developed. + +<p style="text-align: center;"> +<img class="aligncenter" src="img/arch2.png" alt="" width="359" height="412" /> +</p> + +The SCAPE project has an + [extended discussion of component profiles](https://github.com/openpreserve/scape-component-profiles) + available. + +### Component creation against a profile + +In order to conform to a component profile, it can be necessary to make semantic annotations + parts of the corresponding workflow. +For example, the annotation of the type of format in which data is output by a port or + a service with the task it performs. + +The component profile specifies the ontologies that will be used for the components within the + family, the correspondence between object classes within a workflow + (input port, service etc.) and the concepts within the ontologies. + +### Checking a component against a profile + +Although the components will be modified using a chosen profile, + it is unlikely that the components can be assured as being âcorrect by constructionâ. +For this reason, a separate + [component validator](/documentation/components/component-validator) + is being implemented. +The component validator is included within + [myExperiment](http://www.myexperiment.org). + +### Publishing a component + +Since components are realized as âextensionsâ to Taverna workflows, + it was decided that rather than using a separate component repository, + the extensive capabilities of myExperiment would be used. +Thus a component is currently published and shared on myExperiment as (a pack containing) + a workflow. +The components themselves are items within a pack corresponding to the component family. + +To facilitate the development of components, a workflow can also be saved to the userâs local + machine. + +When a user publishes a component either to myExperiment or to their local file system, + their service panel is updated to reflect the new component. + +### Discovering a component + +Since component families are realized as packs on myExperiment + (or by analogous structures in the userâs file system), + we use the existing Taverna code to talk to the myExperiment REST interface to give users + access to families of components. +Users can then see the discovered families of components via the Taverna Workbench service + panel, and the components within those families. +A component can then be added to a workflow. http://git-wip-us.apache.org/repos/asf/incubator-taverna-plugin-component/blob/aaa2befc/doc/index.md ---------------------------------------------------------------------- diff --git a/doc/index.md b/doc/index.md deleted file mode 100644 index 92d6247..0000000 --- a/doc/index.md +++ /dev/null @@ -1,162 +0,0 @@ -# Workflow Components - -<!-- - Licensed to the Apache Software Foundation (ASF) under one - or more contributor license agreements. See the NOTICE file - distributed with this work for additional information - regarding copyright ownership. The ASF licenses this file - to you under the Apache License, Version 2.0 (the - "License"); you may not use this file except in compliance - with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, - software distributed under the License is distributed on an - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, either express or implied. See the License for the - specific language governing permissions and limitations - under the License. ---> - -## Overview -Taverna Workflow Components are a system for creating shareable, reusable, - encapsulated sub-workflows that perform clearly defined tasks while abstracting - the details of how those tasks are performed. -They are an integrated feature of Taverna since Workbench 2.5.0 and Server 2.5.4. - -Taverna's system of service components was developed as part of the BioVeL and SCAPE projects. They consist of tools for the creation, management and use of workflow components, - along with a repository for the storage and sharing of those components. -Workflow components within a given component family will work together cleanly, - for example, by adhering to a tidy type system and being well described. - -## Requirements - -A set of minimal functional requirements for service component management has been developed. These requirements are - based upon previous component-related work carried out as part of the e-Lico project as well as an examination of the needs of BioVeL and SCAPE. - -The requirements include: - - - The ability to create components - - The specification of the characteristics that are necessary for a set of components to - âplayâ together â called a âcomponent profileâ - - Creating a component so it complies with a given profile - - Checking that a component complies with a given profile - - Publishing a component - - Discovering a component - - Including a component in a workflow - - Executing the component within a workflow run - -<img class="aligncenter" title="The Model of Components" src="img/registry.png" alt="" - width="433" height="251" /> - -## Workflows -### Example workflow with components - -This is an example workflow that includes components, with internal ports hidden for simplicity: - -<img class="alignnone" title="Componentized Workflow" src="img/component_b_1.png" alt="" - width="679" height="294" /> - -Without components, using the same view, it would instead look like this: - -[<img class="aligncenter" title="Un-componentized Workflow" src="img/component_c.png" alt="" width="245" height="526" />](http://www.taverna.org.uk/pages/wp-content/uploads/2013/05/component_c.png) - -### Including a component in a workflow - -A component can be added into a Taverna workflow in the same way as an ordinary service: - by dragging it from the service panel of the workbench into the workflow design view. - *Although it may be realized internally as a workflow, - a user sees it as a âblack boxâ and cannot (normally) edit the componentâs workflow.* - -<img class="aligncenter" src="img/arch3.png" alt="" width="500" height="401" /> - -It is intended that there will be consistency checks to ensure components are only plugged - together in a sensible manner, and for the discovery of (and connection to) suitable components - based upon existing workflow structure. - -### Executing a component in a workflow run - -When a component is invoked during a workflow run, the underlying workflow is called with the - corresponding data. -The results of the workflow are used as the output data for the component invocation. -*The user sees the component invocation as a âblack boxâ and cannot see details of - what happens inside.* - ->If you publish a workflow containing a component, you *must* make sure the - component is publicly readable in a globally-accessible component registry; - myExperiment is such a suitable registry. - -## Components -### Component creation - -It was decided that the majority of the information necessary for a component will be specified - as a Taverna workflow. -This allows complex internal component functionality and removes the need for extensive new - software to design components. - -<img class="aligncenter" src="img/arch1.png" alt="" width="340" height="433" /> - -### Component profile - -A specification of the format for the component profile has been agreed. -The format is in XML and an XML schema (xsd) has been created. -An example [component profile](http://www.myexperiment.org/files/905/versions/1/download/Characterisation%20Component.xml) - is available. -Components that share a profile will be collected together into component families. -A [component profile editor](/documentation/components/component-profile-editor) - is being developed. - -<p style="text-align: center;"> -<img class="aligncenter" src="img/arch2.png" alt="" width="359" height="412" /> -</p> - -The SCAPE project has an - [extended discussion of component profiles](https://github.com/openpreserve/scape-component-profiles) - available. - -### Component creation against a profile - -In order to conform to a component profile, it can be necessary to make semantic annotations - parts of the corresponding workflow. -For example, the annotation of the type of format in which data is output by a port or - a service with the task it performs. - -The component profile specifies the ontologies that will be used for the components within the - family, the correspondence between object classes within a workflow - (input port, service etc.) and the concepts within the ontologies. - -### Checking a component against a profile - -Although the components will be modified using a chosen profile, - it is unlikely that the components can be assured as being âcorrect by constructionâ. -For this reason, a separate - [component validator](/documentation/components/component-validator) - is being implemented. -The component validator is included within - [myExperiment](http://www.myexperiment.org). - -### Publishing a component - -Since components are realized as âextensionsâ to Taverna workflows, - it was decided that rather than using a separate component repository, - the extensive capabilities of myExperiment would be used. -Thus a component is currently published and shared on myExperiment as (a pack containing) - a workflow. -The components themselves are items within a pack corresponding to the component family. - -To facilitate the development of components, a workflow can also be saved to the userâs local - machine. - -When a user publishes a component either to myExperiment or to their local file system, - their service panel is updated to reflect the new component. - -### Discovering a component - -Since component families are realized as packs on myExperiment - (or by analogous structures in the userâs file system), - we use the existing Taverna code to talk to the myExperiment REST interface to give users - access to families of components. -Users can then see the discovered families of components via the Taverna Workbench service - panel, and the components within those families. -A component can then be added to a workflow.
