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.
- The application services are secure. They support two security
- 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.
- 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"
- 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.
- 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.
- 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
- The application services can stage the input data files before running
the application and the output data files after running the application.
- 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.
- 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.
- The application services provide
soft-state lifetime management. They renew their WSDL's with a well known
- 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.
- The application services support both synchronous and asynchronous
modes of invocation through the use of WS-Addressing.
- Each application service instance can support upto 250 concurrent
clients using synchronous request-response model for invocation.
- 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 ] [ > ] [