The Generic Application Service: Overview

The Generic Application Factory (GFac) creates an instance of an application service by first instantiating a Generic Application Service and "configuring" it with its ServiceMap document. All the application services created by GFac have some common features. These are the features of the Generic Application Service and are listed below.

1. The application services are secure. They support two security mechanisms
   1. Transport Level Security (TLS): X509 certificates are used for authentication. All authenticated users are allowed access to all operations on the service i.e. no fine grained authorization is used to decide which user has access to what operations on the service. We will call this "service level" authorization.
   2. Message signature with authorization tokens: Authentication is using X509 certificates and authorization is using XPOLA, which uses SAML tokens for authorization. Authorization tokens are used to decide which user has access to what operations on the service. We call this "operation level" authorization.
2. The application services do not attempt to deploy any application. So the command-line application that the application service "wraps" has to be pre-deployed and must be ready-to-run on some host. The deployment of the application is usually done by the application provider.
3. The deployment of the application is described in an XML document called the "ApplicationDeploymentDescription" document and has to be registered with a well known Registry service so that it can be retrieved later by the application service to run the application. The "ApplicationDeploymentDescription" document apart from other details, contains the name of the host on which the application is deployed, the path to the application on that host and the environmental variables that are needed to run the application on that host.
4. The application services can run their applications as batch jobs using schedulers like PBS, LSF, Condor and SGE through the use of GRAM. Schedulers like SLURM are also supported by built-in adapters in the application services.
5. The application services can stage the input data files before running the application and the output data files after running the application.
6. The application services can send notifications about their status and the status of their applications to a well known Notification service using WS-Eventing and WS-Notification. Interested clients can subscribe to the Notification service to get these notifications.
7. The application services automatically generate a graphical user interface in the form of a HTML page. The graphical user interface describes all the operations that the user can invoke, allows the user to choose an operation, specify its input parameters and invoke the operation on the application service.
8. The application services provide soft-state lifetime management. They renew their WSDL's with a well known Registry service.
9. The application services have built-in "shutdown" and "kill" operations that can be invoked to shutdown or kill the service. The shutdown operation unregisters the WSDL from the Registry service, waits for all the jobs (application instances) started by the service to finish and then stops the service. The kill operation unregisters the WSDL from the Registry service, kills all running jobs and stops the service.
10. The application services support both synchronous and asynchronous modes of invocation through the use of WS-Addressing.
11. Each application service instance can support upto 250 concurrent clients using synchronous request-response model for invocation.
12. The application services generate Abstract WSDLs that contain metadata about the service and their input and output parameters. Abstract WSDLs can be used by workflow composers to compose workflows from application services.

[ << ] [ < ] [ Home ] [ > ] [ >> ]