airavata-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r827905 - in /websites/staging/airavata/trunk/content: ./ airavata/architecture/registry.html airavata/architecture/workflow.html
Date Fri, 03 Aug 2012 19:50:38 GMT
Author: buildbot
Date: Fri Aug  3 19:50:38 2012
New Revision: 827905

Log:
Staging update by buildbot for airavata

Modified:
    websites/staging/airavata/trunk/content/   (props changed)
    websites/staging/airavata/trunk/content/airavata/architecture/registry.html
    websites/staging/airavata/trunk/content/airavata/architecture/workflow.html

Propchange: websites/staging/airavata/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Aug  3 19:50:38 2012
@@ -1 +1 @@
-1369180
+1369184

Modified: websites/staging/airavata/trunk/content/airavata/architecture/registry.html
==============================================================================
--- websites/staging/airavata/trunk/content/airavata/architecture/registry.html (original)
+++ websites/staging/airavata/trunk/content/airavata/architecture/registry.html Fri Aug  3
19:50:38 2012
@@ -106,29 +106,34 @@
 
   <div id="content">
     <h1 class="title">Information and Data Registry</h1>
-    <p>Airavata provides capabilities for an integrated workflow and data management
system. The information and data has to be persisted into a registry 
-service. To adhere to the philosophies of Airavata for layering over existing stable third
party components, Airavata usage is consolidated into a 
-thick-client API. This API allows the pluggability of the infrastructure and avoids locks
in into any specific registry architectures. 
-This follwing figure summerizes the use of the registry.</p>
+    <p>Airavata provides capabilities for an integrated workflow and data management
system. The information and data has to
+be persisted into a registry service. To adhere to the philosophies of Airavata for layering
over existing stable third
+party components, Airavata usage is consolidated into a thick-client API. This API allows
the pluggability of the
+infrastructure and avoids locks in into any specific registry architectures. This following
figure summarizes the use
+of the registry.</p>
 <p><img alt="Airavata Registry Usage" src="/airavata/architecture/airavata-registry.png"
title="Airavata Registry Usage" /></p>
 <h2 id="jcr-specification">JCR Specification:</h2>
-<p>The Content Repository for Java Technology specification, developed under the Java
Community Process JSR-170, 
-aims to standardize Java API to repositiries. The specification provides a unified API under
the javax.jcr namespace that allows you to
-access any specification-compliant repository implementation in a vendor-neutral manner.
A major advantage of JSR-170 is that it is not 
-tied to any particular underlying architecture. The back-end data storage for a JSR-170 implementation,
for instance, may be a filesystem, 
-a WebDAV repository, an XML-backed system, or even an SQL database. Furthermore, the export
and import facilities of JSR-170 allow an integrator
-to switch seamlessly between content back ends and JCR implementations. Finally, the JCR
provides a straightforward interface that can be layered 
-on top of a wide variety of existing content repositories, while simultaneously standardizing
complex functionality such as versioning, 
-access control, and searching. There are open source implementations of JSR-170 such as Apache
Jackrabbit, Alfresco and WSO2 Registry.</p>
+<p>The Content Repository for Java Technology specification, developed under the Java
Community Process JSR-170, aims to
+standardize Java API to repositories. The specification provides a unified API under the
javax.jcr namespace that allows
+you to access any specification-compliant repository implementation in a vendor-neutral manner.
A major advantage of
+JSR-170 is that it is not tied to any particular underlying architecture. The back-end data
storage for a JSR-170
+implementation, for instance, may be a filesystem, a WebDAV repository, an XML-backed system,
or even an SQL database.
+Furthermore, the export and import facilities of JSR-170 allow an integrator to switch seamlessly
between content
+back ends and JCR implementations. Finally, the JCR provides a straightforward interface
that can be layered on top of
+a wide variety of existing content repositories, while simultaneously standardizing complex
functionality such as
+versioning, access control, and searching. There are open source implementations of JSR-170
such as Apache Jackrabbit,
+Alfresco and WSO2 Registry.</p>
 <h2 id="airavata-registry-api">Airavata Registry API</h2>
-<p>When implementing registry functionality to store data and retrieve data we did
not want to have locking for any custom API's to content 
-repository implementations. Airavata tried to integrate with existing repositories without
having to re-invent the wheel. 
-JCR-2.0 specification and the JSR-170 implementation is plugged in to Apache Airavata system.
The Airavata specific API layers over 
-the generic JCR API and is integrated with Apache Jackrabbit implementation. The API is modularized
as a common component reused by XBaya and 
-GFac components to store and retrieve data. In addition to the service information, the registry
is used to catalog workflow consumed inputs
-and generated output data. The registry is also used to advertise and retrieve persistent
service information. The use of the registry for 
-GFac service registration allows for late service binding and supporting large number of
applications provided by the inherent load balance 
-capabilities. For more up to date information and samples on Airavata API, refer <a href="https://cwiki.apache.org/confluence/display/AIRAVATA/Client+API+Overview">Client
API Overview</a>.</p>
+<p>When implementing registry functionality to store data and retrieve data we did
not want to have locking for any custom
+API's to content repository implementations. Airavata tried to integrate with existing repositories
without having to
+re-invent the wheel. JCR-2.0 specification and the JSR-170 implementation is plugged in to
Apache Airavata system. The
+Airavata specific API layers over the generic JCR API and is integrated with Apache Jackrabbit
implementation. The API
+is modularized as a common component reused by XBaya and GFac components to store and retrieve
data. In addition to the
+service information, the registry is used to catalog workflow consumed inputs and generated
output data. The registry
+is also used to advertise and retrieve persistent service information. The use of the registry
for GFac service
+registration allows for late service binding and supporting large number of applications
provided by the inherent
+load balance capabilities. For more up to date information and samples on Airavata API, refer
+<a href="https://cwiki.apache.org/confluence/display/AIRAVATA/Client+API+Overview">Client
API Overview</a>.</p>
   </div>
 
   <!--<div id="rightnav">

Modified: websites/staging/airavata/trunk/content/airavata/architecture/workflow.html
==============================================================================
--- websites/staging/airavata/trunk/content/airavata/architecture/workflow.html (original)
+++ websites/staging/airavata/trunk/content/airavata/architecture/workflow.html Fri Aug  3
19:50:38 2012
@@ -107,35 +107,42 @@
   <div id="content">
     <h1 class="title">Airavata Workflow Suite</h1>
     <p>Airavata XBaya workflow system provides a programming model that allows the
scientist to program experiments using 
-service-oriented architecture that would abstract the complexities of the underlying middleware.

-Airavata XBaya provides interfaces for composition, execution and monitoring of the workflows
as illustrated in the following Figure. 
-Airavata XBaya consist of convenient GUI interface for workflow composition, workflow enactment

-engine/interface for workflow enactment and workflow monitoring module. </p>
+service-oriented architecture that would abstract the complexities of the underlying middleware.
Airavata XBaya provides
+interfaces for composition, execution and monitoring of the workflows as illustrated in the
following Figure. Airavata
+XBaya consist of convenient GUI interface for workflow composition, workflow enactment engine/interface
for workflow
+enactment and workflow monitoring module.</p>
 <p><img alt="Airavata Workflow Suite" src="/airavata/architecture/workflow-suite.png"
title="Airavata Workflow Suite" /></p>
 <h2 id="workflow-composition">Workflow Composition</h2>
-<p>Airavata XBaya by design decouples composition and monitoring from the orchestration
of the workflow although it does provide an embedded workflow 
-enactment engine integrated with the workbench. As a scientific workflow suite XBaya is often
expected to run long running computations thus it 
-often delegates the workflow execution to a persistent orchestration engine and XBaya workbench
can monitor the progress of the workflow asynchronously. The workbench provides a convenient
drag and drop GUI for SOA based service composition along with other functionalities like
service discovery, registry lookup and workflow experiment management.</p>
+<p>Airavata XBaya by design decouples composition and monitoring from the orchestration
of the workflow although it does
+provide an embedded workflow enactment engine integrated with the workbench. As a scientific
workflow suite XBaya is
+often expected to run long running computations thus it often delegates the workflow execution
to a persistent
+orchestration engine and XBaya workbench can monitor the progress of the workflow asynchronously.
The workbench provides
+a convenient drag and drop GUI for SOA based service composition along with other functionalities
like service
+discovery, registry lookup and workflow experiment management.</p>
 <h2 id="workflow-orchestration">Workflow orchestration</h2>
-<p>XBaya provides a unique pluggable architecture for selecting the orchestration engine.
When a user composes a workflow using XBaya workbench 
-it builds an abstract Directed Acyclic Graph (DAG) which is independent of any workflow runtime.
There are pluggable compiler modules that are 
-capable of producing workflow execution scripts for target runtimes. The above Figure illustrated
how the DAG can compiled into different runtimes. 
-Currently XBaya supports BPEL 2.0 and Apache ODE; SCUFL and Taverna; DAGMAN and Pegasus;
Jython scripts and XBaya Interpreter Service.</p>
-<p>Each of these workflow runtimes have their own strengths, for example, Apache ODE
is a robust SOA based workflow orchestration engine well suited 
-for long running applications. Pegasus workflow system is well suited for parametric sweeps
whereas XBaya Interpreter engine is strong in dynamic 
-and user interactive workflow execution. It is also capable of generating a Jython script
that can be executed in any Jython runtime independent 
-of any of the workflow infrastructure.</p>
+<p>XBaya provides a unique pluggable architecture for selecting the orchestration engine.
When a user composes a workflow
+using XBaya workbench it builds an abstract Directed Acyclic Graph (DAG) which is independent
of any workflow runtime.
+There are pluggable compiler modules that are capable of producing workflow execution scripts
for target runtimes. The
+above Figure illustrated how the DAG can compiled into different runtimes. Currently XBaya
supports BPEL 2.0 and Apache
+ODE; SCUFL and Taverna; DAGMAN and Pegasus; Jython scripts and XBaya Interpreter Service.</p>
+<p>Each of these workflow runtimes have their own strengths, for example, Apache ODE
is a robust SOA based workflow
+orchestration engine well suited for long running applications. Pegasus workflow system is
well suited for parametric
+sweeps whereas XBaya Interpreter engine is strong in dynamic and user interactive workflow
execution. It is also capable
+of generating a Jython script that can be executed in any Jython runtime independent of any
of the workflow
+infrastructure.</p>
 <h2 id="workflow-interpreter">Workflow interpreter</h2>
 <p>XBaya provides a inbuilt workflow enactment engine that provides extremely dynamic
and interactive workflow execution. 
-As the name suggests the workflow interpreter provides an interpreted workflow execution
framework rather than the compiled workflow execution 
-environments. In this context the interpreted workflow means at that execution framework
executed tasks in the XBaya DAG as and when the tasks 
-become runnable. Once the user composes the workflow and launches the workflow the workflow
interpreter will start executing the workflow DAG. 
-Topological sort of the DAG provides execution ordering of the tasks which allow the identification
of the initial ready task set and incrementally 
-adding new tasks to the ready list as previous tasks finish execution. What is unique about
this type of execution model is it allows the user 
-to pause the execution of the workflow as necessary and update the DAG’s execution states
or even the DAG itself and resume execution and the 
-changes are immediately picked up by the workflow interpreter.</p>
-<p>Workflow interpreter can be used as an embedded workflow enactment engine within
XBaya GUI or as an interpreter service that may run as a persistent 
-service. The functionality provided by the workflow interpreter allows fine gain control
over the workflow execution which translates into following 
+As the name suggests the workflow interpreter provides an interpreted workflow execution
framework rather than the
+compiled workflow execution environments. In this context the interpreted workflow means
at that execution framework
+executed tasks in the XBaya DAG as and when the tasks become runnable. Once the user composes
the workflow and launches
+the workflow the workflow interpreter will start executing the workflow DAG. Topological
sort of the DAG provides
+execution ordering of the tasks which allow the identification of the initial ready task
set and incrementally adding
+new tasks to the ready list as previous tasks finish execution. What is unique about this
type of execution model is it
+allows the user to pause the execution of the workflow as necessary and update the DAG’s
execution states or even the
+DAG itself and resume execution and the changes are immediately picked up by the workflow
interpreter.</p>
+<p>Workflow interpreter can be used as an embedded workflow enactment engine within
XBaya GUI or as an interpreter service
+that may run as a persistent service. The functionality provided by the workflow interpreter
allows fine gain control
+over the workflow execution which translates into following
 functionalities.
 <em> Static workflow interactions
 </em> Dynamic change workflow inputs, workflow rerun.
@@ -147,16 +154,19 @@ functionalities.
 </em> Dynamic addition of activities to the DAG.
 * Dynamic remove or replace of activity to the DAG.</p>
 <h2 id="workflow-monitoring">Workflow monitoring:</h2>
-<p>XBaya workbench allows the user to monitor the progress of the workflow in real-time.
Monitoring includes the services which are currently executing, 
-those that are done. It also provides state of the job submissions to the batch job queues
and status of the data transfer. Workflow monitoring in 
-XBaya workbench work in two modes; synchronous mode and asynchronous mode. The synchronous
mode only applies when XBaya interpreter runs embedded in 
-the workbench. This allows the execution engine to be aware of which task are ready, running,
finished and waiting and thus accordingly update the 
-DAG execution state. But when the workflow execution is delegated to a persistant service
like Apache ODE serve or XBaya interpreter service, 
-it is necessary to have asynchronous monitoring. This is achieved using the WS-Eventing based
notification messages published by different components 
-of the workflow  system. If a user launches a workflow instance a unique topic will be associated
with that instance and all the workflow components
-like workflow engine, Factory service will publish status notification about the workflow
to the event bus using the topic assigned to the workflow 
-instance. This asynchronous monitoring is truly asynchronous where the user can launch the
workflow, start monitoring, loose internet connectivity and
-once reconnected the XBaya workbench will bring back the monitoring to the current execution
state of the workflow.</p>
+<p>XBaya workbench allows the user to monitor the progress of the workflow in real-time.
Monitoring includes the services
+which are currently executing, those that are done. It also provides state of the job submissions
to the batch job
+queues and status of the data transfer. Workflow monitoring in XBaya workbench work in two
modes; synchronous mode and
+asynchronous mode. The synchronous mode only applies when XBaya interpreter runs embedded
in the workbench. This allows
+the execution engine to be aware of which task are ready, running, finished and waiting and
thus accordingly update the
+DAG execution state. But when the workflow execution is delegated to a persistent service
like Apache ODE serve or XBaya
+interpreter service, it is necessary to have asynchronous monitoring. This is achieved using
the WS-Eventing based
+notification messages published by different components of the workflow  system. If a user
launches a workflow instance
+a unique topic will be associated with that instance and all the workflow components like
workflow engine, Factory
+service will publish status notification about the workflow to the event bus using the topic
assigned to the workflow
+instance. This asynchronous monitoring is truly asynchronous where the user can launch the
workflow, start monitoring,
+loose internet connectivity and once reconnected the XBaya workbench will bring back the
monitoring to the current
+execution state of the workflow.</p>
   </div>
 
   <!--<div id="rightnav">



Mime
View raw message