Group items tagged

The standard GRIA client does not know about the sample service or the resources it creates

The Java interfaces which define the interaction between the service and the client go in a single jar which is used by each of them.

A data stager is a container for a single file (or zip file)

although GRIA does not require them to be located on the same machine

This guide describes the GRIA Workflow Deployer Application software which works in conjunction with the GRIA Workflow Application package, and enables the automatic conversion of a user-supplied XScufl workflow into a GRIA application, which is then automatically deployed onto a GRIA Job Service. XScufl workflows may be created using Taverna or g-Eclipse.

UsernameIdentityProviderA new key-pair is generated and given a certificate signed by another Identity. This is for use in portals where users only have usernames and passwords rather then key-pairs.

UsernameIdentityProviderA new key-pair is generated and given a certificate signed by another Identity. This is for use in portals where users only have usernames and passwords rather then key-pairs.

KrbIdentityProvider An Identity is fetched from a Kerberos service. This allows users with a Kerberos or Active Directory login to get an Identity automatically.

The GRIA Workflow Application v0.2 software includes tools for deploying and running XScufl workflows as GRIA applications. XScufl workflows may be created using Taverna or g-Eclipse. A command line deployment tool generates GRIA application wrapper scripts and other requisite files from an XScufl workflow. Running the deployment tool generates a new application that can be deployed to the GRIA Job service in the usual way using the Job Service Administration web pages.

Management View The management view displays resources under the resource which they are managed by. This relationship is a parent-child relationship and this can be seen in the resources endpoint reference, right click a resource and select View EPR there is a managingresource element which tells us the endpoint of the managing resource. If a resource is unmanaged then it appears under the Management Resources node otherwise it appears under its managing resource.

Management View The management view displays resources under the resource which they are managed by. This relationship is a parent-child relationship and this can be seen in the resources endpoint reference, right click a resource and select View EPR there is a managingresource element which tells us the endpoint of the managing resource. If a resource is unmanaged then it appears under the Management Resources node otherwise it appears under its managing resource.

For Linux, the first line of the script (eg. #!/usr/bin/python) is used to determine which interpreter to use. The filename extension can be anything (eg. startJob.py, startJob.sh).

The application wrapper scripts are deployed along with the applications - either on a shared file system or individually on each compute node. Their function is to provide a uniform interface to the Job Service for starting, monitoring and stopping applications.

The GRIA API is used to create and manage the GRIA resources representing databases, roles and subscriptions

This allows you to access managed Basic Application Services on griademo2. You can now use the client to store data and run jobs, much as you did before, but managed by the SLA that you proposed and billing to the trade account that you have just opened:

The GRIA Workflow Application software includes tools for deploying and running Taverna workflows as GRIA applications. A command line deployment tool generates GRIA application wrapper scripts and other requisite files from a Taverna workflow. Running the deployment tool generates a new application that can be deployed to the GRIA Job service in the usual way using the Job Service Administration web pages.

Use nested workflows (sub workflows)

Monitor execution

Manage jobs and results

Managed Services The SLA service is of no use if it does not manage any functional services. There are five conditions that must be met in order for a functional service to be managed: At the functional service: The SLA service must be in the functional service's list of "Trusted Management Services". The SLA service's CA certificate must be a trusted CA in the functional service's key-store. The SLA service must be in the "management-services" group of the functional service. At the SLA service: The functional service's CA certificate must be a trusted CA in the SLA service's key-store. The functional service must be in the "sla-managed-services" group of the SLA service. If the functional services that require managing are hosted on the same machine as the SLA service (and therefore share the same certificate) then steps 2-5 are not necessary, otherwise see below for more detail.

Advanced usage Input arrays An application might require arrays of inputs, whose exact sizes are specified by the user when creating the job. This is supported by GRIA using the minOccurs, maxOccurs and defaultSize attributes on DataStager elements. For example, if your application took between 2 and 8 images as input, you might use the following XML: <DataStager type="input" name="inputImage" minOccurs="2" maxOccurs="8" defaultSize="2"> <Description>Input image</Description> <MimeType>image</MimeType></DataStager> You can use the defaultSize attribute to support older clients that do not know how to specify the desired size of arrays.

Advanced usage Input arrays An application might require arrays of inputs, whose exact sizes are specified by the user when creating the job. This is supported by GRIA using the minOccurs, maxOccurs and defaultSize attributes on DataStager elements. For example, if your application took between 2 and 8 images as input, you might use the following XML: <DataStager type="input" name="inputImage" minOccurs="2" maxOccurs="8" defaultSize="2"> <Description>Input image</Description> <MimeType>image</MimeType></DataStager> You can use the defaultSize attribute to support older clients that do not know how to specify the desired size of arrays.

Advanced usage Input arrays An application might require arrays of inputs, whose exact sizes are specified by the user when creating the job. This is supported by GRIA using the minOccurs, maxOccurs and defaultSize attributes on DataStager elements. For example, if your application took between 2 and 8 images as input, you might use the following XML: <DataStager type="input" name="inputImage" minOccurs="2" maxOccurs="8" defaultSize="2"> <Description>Input image</Description> <MimeType>image</MimeType></DataStager> You can use the defaultSize attribute to support older clients that do not know how to specify the desired size of arrays.

Running a Groovy script   This is the easiest way to access the Java API. To try it out, create a script named test.groovy containing: println "Starting Groovy script!" def jobService = serviceFactory.createServiceProxy("https://host:8443/gria-basic-app-services/services/JobService?wsdl") println "Getting ID..." def id = jobService.getServiceProviderID() println "Job service identity: " + id Replace host with the address of your GRIA job service. The script is run by passing it as an argument to the normal gridcli command. For example: $ gridcli test.groovy Starting Groovy script! Getting ID... Job service identity: <subject> <subject> will appear at the identity of your job service. The configured keystore and active plugins are the same as when running the GRIA client normally.