airavata-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hes...@apache.org
Subject svn commit: r1369180 - in /incubator/airavata/site/trunk/content/airavata/architecture: airavata-stakeholders.mdtext gfac.mdtext overview.mdtext
Date Fri, 03 Aug 2012 19:40:38 GMT
Author: heshan
Date: Fri Aug  3 19:40:38 2012
New Revision: 1369180

URL: http://svn.apache.org/viewvc?rev=1369180&view=rev
Log:
Fixed typos.

Modified:
    incubator/airavata/site/trunk/content/airavata/architecture/airavata-stakeholders.mdtext
    incubator/airavata/site/trunk/content/airavata/architecture/gfac.mdtext
    incubator/airavata/site/trunk/content/airavata/architecture/overview.mdtext

Modified: incubator/airavata/site/trunk/content/airavata/architecture/airavata-stakeholders.mdtext
URL: http://svn.apache.org/viewvc/incubator/airavata/site/trunk/content/airavata/architecture/airavata-stakeholders.mdtext?rev=1369180&r1=1369179&r2=1369180&view=diff
==============================================================================
--- incubator/airavata/site/trunk/content/airavata/architecture/airavata-stakeholders.mdtext
(original)
+++ incubator/airavata/site/trunk/content/airavata/architecture/airavata-stakeholders.mdtext
Fri Aug  3 19:40:38 2012
@@ -18,8 +18,10 @@ Notice:    Licensed to the Apache Softwa
 
 ![Airavata Stakeholders](/airavata/architecture/user1.png "Airavata Stakeholders")
 
-Airavata is a framework which enables a user to build Science Gateways. It is used to compose,
manage, execute and monitor distributed applications and workflows on computational resources.
These computational resources can range from local resources to computational grids and clouds.
Therefore,  various users with different backgrounds either contribute or use Airavata in
their  applications. From the Airavata standpoint, three
-main users can be identified.
+Airavata is a framework which enables a user to build Science Gateways. It is used to compose,
manage, execute and
+monitor distributed applications and workflows on computational resources. These computational
resources can range
+from local resources to computational grids and clouds. Therefore,  various users with different
backgrounds either
+contribute or use Airavata in their  applications. From the Airavata standpoint, three main
users can be identified.
 
 * End Users
 * Gateway Developers
@@ -31,15 +33,21 @@ Now let's focus on each user and how the
 
 ![End Users](/airavata/architecture/user2.png "End Users")
 
-End User is the one who will have a model code to do some scientific application. Sometimes
this End User can be a Research Scientist. He/She writes scripts to wrap the applications
up and by executing those scripts, they run the scientific workflows in Super Computers. This
can be called a scientific experiment. Now the Scientist might have a requirement to call
multiple of these applications together and compose a workflow. That's where the Gateway Developer
comes into the picture.
+End User is the one who will have a model code to do some scientific application. Sometimes
this End User can be a
+Research Scientist. He/She writes scripts to wrap the applications up and by executing those
scripts, they run the
+scientific workflows in Super Computers. This can be called a scientific experiment. Now
the Scientist might have a
+requirement to call multiple of these applications together and compose a workflow. That's
where the Gateway Developer
+comes into the picture.
 
 ## Gateway Developers ##
 
 ![Gateway Developers](/airavata/architecture/user3.png "Gateway Developers")
 
-The Research Scientist is the one who comes up with requirement of bundling scienitific applications
together and composing as a workflow.
+The Research Scientist is the one who comes up with requirement of bundling scientific applications
together and
+composing as a workflow.
 
-The job of the Gateway Developer is to use Airavata and wrap the above mentioned model code
and scripts together. Then, scientific workflows are created out these.
+The job of the Gateway Developer is to use Airavata and wrap the above mentioned model code
and scripts together.
+Then, scientific workflows are created out these.
 
 Above diagram depicts how Gateway Developer fits into the picture.
 
@@ -47,4 +55,5 @@ Above diagram depicts how Gateway Develo
 
 ![Core Developers](/airavata/architecture/user4.png "Core Developers")
 
-Core Deveoper is the one who develops and contributes to Airavata framework codebase. The
Gateway Developers use the software developed by the Core Developers to create science gateways.
+Core Developer is the one who develops and contributes to Airavata framework code-base. The
Gateway Developers use
+the software developed by the Core Developers to create science gateways.

Modified: incubator/airavata/site/trunk/content/airavata/architecture/gfac.mdtext
URL: http://svn.apache.org/viewvc/incubator/airavata/site/trunk/content/airavata/architecture/gfac.mdtext?rev=1369180&r1=1369179&r2=1369180&view=diff
==============================================================================
--- incubator/airavata/site/trunk/content/airavata/architecture/gfac.mdtext (original)
+++ incubator/airavata/site/trunk/content/airavata/architecture/gfac.mdtext Fri Aug  3 19:40:38
2012
@@ -19,28 +19,30 @@ Notice:    Licensed to the Apache Softwa
 Airavata Generic Application Service Factory (GFac) facilitates users to create Web Services
wrapping commandline
 applications. The generated application service WSDL interface provides input and outputs
of the 
 wrapped application. GFac provides a generic framework to wrap an application as a service
interface in Java. 
-This service layers separates the invocation from the communication layer supporting multiple
protocol likes SOAP, REST, or JSON. 
-Thus GFac can generate a SOAP, REST or native Java interface to any command line application.
Currently, Apache Airavata focuses on the 
-Axis2 and core java implementations, but is well architected to incorporate the GFac-Core
into any service frameworks. 
+This service layers separates the invocation from the communication layer supporting multiple
protocol likes SOAP, REST,
+or JSON. Thus GFac can generate a SOAP, REST or native Java interface to any command line
application. Currently, Apache
+Airavata focuses on the Axis2 and core java implementations, but is well architected to incorporate
the GFac-Core into
+any service frameworks.
 
-The application provider first describes the input, outputs, deployment information, temporary
working directories, remote access mechanisms for 
-file transfers and job submissions and registers the information with a registry service.
Once applications are registered, GFac Distributed 
-Application Management handles the file staging, Job submission, and security protocols associated
with executions. 
-Furthermore, the service acts as the extensible runtime around which extensions like sharing,
auditing and resource scheduling are implemented.
+The application provider first describes the input, outputs, deployment information, temporary
working directories,
+remote access mechanisms for file transfers and job submissions and registers the information
with a registry service.
+Once applications are registered, GFac Distributed Application Management handles the file
staging, Job submission,
+and security protocols associated with executions. Furthermore, the service acts as the extensible
runtime around which
+extensions like sharing, auditing and resource scheduling are implemented.
 
-During execution, the application schedule is determined and the input data files specified
by input parameters are staged to computational host 
-and the underlying application is executed using a job submission mechanisms. Currently,
Grid, Cloud, SSH and Local submissions are supported. 
-Subsequently, the framework monitors the status of remote application, and publishes frequent
activity information to the event bus. 
-Once the invocation is complete, the application service tries to determine the results of
the application invocation by searching the standard output 
-for user-defined patterns or by listed a pre-specified location for generated data products.
The application service runtime is implemented using a 
-processing pipeline based on the Chain of Responsibility pattern, where the pipeline can
be altered by inserting interceptors. 
-The resulting architecture is highly flexible and extensible, and provides the ideal architectural
basis for a system that supports wide range of 
-requirements. 
+During execution, the application schedule is determined and the input data files specified
by input parameters are
+staged to computational host and the underlying application is executed using a job submission
mechanisms. Currently,
+Grid, Cloud, SSH and Local submissions are supported. Subsequently, the framework monitors
the status of remote
+application, and publishes frequent activity information to the event bus. Once the invocation
is complete, the
+application service tries to determine the results of the application invocation by searching
the standard output for
+user-defined patterns or by listed a pre-specified location for generated data products.
The application service
+runtime is implemented using a processing pipeline based on the Chain of Responsibility pattern,
where the pipeline
+can be altered by inserting interceptors. The resulting architecture is highly flexible and
extensible, and provides
+the ideal architectural basis for a system that supports wide range of requirements.
 
 Some of the features of the toolkit include:
-* Inherent application life time management and the architecture allows to have large number
of 
-services registered and used.
-* The Application service performs data staging supporting multiple protocols including http,
scp, 
-GridFTP and S3.
+* Inherent application life time management and the architecture allows to have large number
of services registered
+and used.
+* The Application service performs data staging supporting multiple protocols including http,
scp, GridFTP and S3.
 * The generated services are instrumented with detailed execution activity.
-* The toolkit supports job submissions to Local, Grid and Cloud computing resourcces.
\ No newline at end of file
+* The toolkit supports job submissions to Local, Grid and Cloud computing resources.
\ No newline at end of file

Modified: incubator/airavata/site/trunk/content/airavata/architecture/overview.mdtext
URL: http://svn.apache.org/viewvc/incubator/airavata/site/trunk/content/airavata/architecture/overview.mdtext?rev=1369180&r1=1369179&r2=1369180&view=diff
==============================================================================
--- incubator/airavata/site/trunk/content/airavata/architecture/overview.mdtext (original)
+++ incubator/airavata/site/trunk/content/airavata/architecture/overview.mdtext Fri Aug  3
19:40:38 2012
@@ -16,27 +16,26 @@ Notice:    Licensed to the Apache Softwa
            specific language governing permissions and limitations
            under the License.
 
-Apache Airavata is a software toolkit with features to compose, manage, execute, and monitor
small
-to large scale applications and workflows on computational resources ranging from local clusters
to 
-national grids and computing clouds. 
-
-Airavata builds on general concepts of service oriented computing, distributed messaging,
and 
-workflow composition and orchestration. The services primarly communicate using SOAP messages.

-In addition to the basic Web services specifications like SOAP and WSDL, the Web services
also 
-support WS-Addressing and WS-Messaging. WS-Addressing is used to provide an asynchronous

-communication mechanism for the services to communicate. All the communication channels are
secured 
-using https as the transport layer.
-
-Airavata features Dynamic Service Binding where in a proxy service accepts an input message
intended
-to a target application Web service instance invoked by a workflow engine. The proxy service
binds 
-an appropriate running Web service instance by looking up in XRegistry. When no Web service

-instances are available, a new instance of the GFac service is created.
+Apache Airavata is a software toolkit with features to compose, manage, execute, and monitor
small to large scale
+applications and workflows on computational resources ranging from local clusters to national
grids and computing
+clouds.
+
+Airavata builds on general concepts of service oriented computing, distributed messaging,
and workflow composition and
+orchestration. The services primarily communicate using SOAP messages. In addition to the
basic Web services
+specifications like SOAP and WSDL, the Web services also support WS-Addressing and WS-Messaging.
WS-Addressing is used
+to provide an asynchronous communication mechanism for the services to communicate. All the
communication channels are
+secured using https as the transport layer.
+
+Airavata features Dynamic Service Binding where in a proxy service accepts an input message
intended to a target
+application Web service instance invoked by a workflow engine. The proxy service binds an
appropriate running
+Web service instance by looking up in XRegistry. When no Web service instances are available,
a new instance of the
+GFac service is created.
 
 Airavata's primary goal is to support long running applications and workflows on distributed
computational resources. 
-The architecture is designed to be modular, componentized 
-software framework as illustrated in the following Figure. The goal of the Airavata framework
is minimalist 
-architectural design (i.e., a thin layer), a conceptually simple to understand architecture;
and easier to install, 
-maintain and use. Its salient feature includes using components by themselves or as an integrated
solution.
+The architecture is designed to be modular, componentized software framework as illustrated
in the following Figure.
+The goal of the Airavata framework is minimalist architectural design (i.e., a thin layer),
a conceptually simple to
+understand architecture; and easier to install, maintain and use. Its salient feature includes
using components by
+themselves or as an integrated solution.
 
 ![Airavata Overview](/airavata/architecture/airavata.png "Airavata Overview")
 
@@ -44,20 +43,20 @@ maintain and use. Its salient feature in
 * desktop tools and browser-based web interface components for managing applications, workflows
and generated data. 
 * sophisticated server-side tools for registering and managing scientific applications on
computational resources. 
 * graphical user interfaces to construct, execute, control, manage and reuse of scientific
workflows.
-* interfacing and interoperability with with various external (third party) data, workflow
and provenance management tools.
+* interfacing and interoperability with with various external (third party) data, workflow
and provenance management
+tools.
 
 ## Airavata Components
-* XBaya Workflow Suite - includes a GUI for workflow composition and monitoring. The workflows
can be 
-interpreted at each step providing dynamic interactive capabilities. The composed workflow
can be 
-exported to various workflow languages like BPEL, SCUFL, Condor DAG, Jython and Java. 
-The defacto workflow enacting engine used is Airavata Workflow Engine. In the future, it
will be Apache ODE.
-* GFac - an application wrapper service that can be used to wrap command line-driven science

-applications and make them into robust, network- accessible services. This component is build
on 
-Axis2 web service stack. 
-and constructed workflows.
-* WS-Messenger - a publish-subscribe based message broker implemented on top of Apache
Axis2 web 
-services stack. It implements the WS-Eventing and WS-Notifications specifications and incorporates

-a message box component that facilities communications with clients behind firewalls and
overcomes 
-network glitches. As an example, the workflow execution engine sends out events in various
stages,
-including start, end, failure, successful invocation, of its workflow execution.
-* Registry-API: A thick client registry API for Airavata to put and get documents. Current
JCR implementation is supported by Jack-Rabbit.
\ No newline at end of file
+* XBaya Workflow Suite - includes a GUI for workflow composition and monitoring. The workflows
can be interpreted at
+each step providing dynamic interactive capabilities. The composed workflow can be exported
to various workflow
+languages like BPEL, SCUFL, Condor DAG, Jython and Java. The defacto workflow enacting engine
used is Airavata Workflow
+Engine. In the future, it will be Apache ODE.
+* GFac - an application wrapper service that can be used to wrap command line-driven science
applications and make them
+into robust, network- accessible services. This component is build on Axis2 web service stack
and constructed workflows.
+* WS-Messenger - a publish-subscribe based message broker implemented on top of Apache
Axis2 web services stack. It
+implements the WS-Eventing and WS-Notifications specifications and incorporates a message
box component that facilities
+communications with clients behind firewalls and overcomes network glitches. As an example,
the workflow execution
+engine sends out events in various stages, including start, end, failure, successful invocation,
of its workflow
+execution.
+* Registry-API: A thick client registry API for Airavata to put and get documents. Current
JCR implementation is
+supported by Jack-Rabbit.
\ No newline at end of file



Mime
View raw message