Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 83 to 83 | ||||||||
0.0.1 Credentials RenewalThe User can store a long-lived certificate that can be used by the WMS in order to renew the lifetime of a standard user certificate proxy (usually valid only for 12 hours). Long-running jobs may run into this limit and fail due to expioration of user proxy. WMProxy can automatically request the registration for renewing the proxy certificate sent by the user. This is done through the attribute "MyProxyServer" inside the submitting JDL. When a Proxy Renewal Registration is requested for a certain Job, the WMProxy registers it to the proxy renewal. From that moment on, credentials for such jobs are granted by renewed certificate credentials. Actually all jobs that uses the same credentials links to only one renewed certificate. | ||||||||
Added: | ||||||||
> > | 0.1 Provided FunctionalityThe operations provided by WMProxy are listed below: Version:
0.2 Job SubmissionIn this section we describe the sequence of WMProxy operations and the corresponding actions that need to be performed to accomplish job submission to the WMS, i.e. the delivery of the user’s job request in the WM request queue. Job submission requires both, a description of the job to be executed, and a description of the needed resources. These descriptions are provided with a high-level language called JDL. The actual submission is done by calling in sequence the two service operations jobRegister and jobStart When a jobRegister request arrives to the WMProxy, if the client has the rights to proceed, a job identifier is generated and a set of specific attributes needed by the WMS for handling the request appropriately are inserted in the job description. The requesting user is then mapped to a local user by means of LCMAP so that the job local directories and files can be created with appropriate ownership and permissions. When all the aforementioned steps have been successfully completed, the job with the generated job identifier and the enriched JDL description is registered to the LB and from that point on is uniquely identified and can be followed-up throughout the whole system with its identifier. Afterwards, the job is registered for proxy renewal (if requested) and the job handle is returned to the user. In case the JDL description provided by the user represents a compound request (see next section), i.e., a set of jobs, a tree of identifiers is returned. This tree contains the job identifier of the single jobs composing the group, and a job identifier to identify and manage the entire group. The completion of the WMProxy job registration phase is the sign that the job has been taken into account within the Grid environment and is ready to be actually submitted to Grid resources. This further step is triggered by the invocation of the jobStart operation. During the start operation the provided job identifier is used to check if the corresponding job has the pre-requisites for being started, i.e., it has been previously registered by the same WMProxy service and it has not already been started. Only if both conditions are met or previous job start attempts have failed for some reason the job processing is carried on by further manipulating the job description, decompressing, extracting, locating sandbox files in the appropriate areas and lastly writing the request into the WM requests queue. Compound jobs start requires additional steps to be performed before passing the request to WM. These are the registration to LB of all sub-jobs composing the request and the creation of the job reserved area on the file system for all of them. All auxiliary actions needed for the job to run successfully on the remote resource can be performed in the phase between job registration and job start. Relevant examples could be the preparation of the input files needed by the job at run time including both the job input sandbox files and the data stored on Storage Elements (SE) and registered onto Grid Catalogs. In particular the job input sandbox files can be either located on accessible external file server or have to "travel" together with the job from the client machine to the resource where the job is going to run. In the latter case the needed files have to be uploaded by the user to the WMS node so that they can be then managed by the WMS and made available to the job. WMProxy provides the URI of the files destination location through specific operations. Supported file transfer protocols are gsiFTP and HTTPS. The split of the job submission process into the two well distinct phases, job registration and job start, realizes a sort of two-phase commit: with the former operation the job enters the system remaining registered for a configurable period of time; with the latter one, the job can utilize the system. This gives the user full control over single submission phases; in case of failure single operations can be performed again separately. Moreover it allows performing preparatory activities when the job has already entered the system and moving specific time-consuming processing after the operation response has been provided to the client.![]() 0.3 Service InterfaceThe WMProxy service exposes operation through a WSDL interface: http://web.infn.it/gLiteWMS/index.php/techdoc/howtosandguides![]()
| |||||||
-- FabioCapannini - 2011-11-04 | ||||||||
Line: 90 to 167 | ||||||||
Added: | ||||||||
> > | ||||||||
| ||||||||
Added: | ||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 40 to 40 | ||||||||
| ||||||||
Changed: | ||||||||
< < | re | |||||||
> > | 0.1 ArchitectureTo adhere to the SOA model, WMProxy has been designed and implemented as a Simple Object Access Protocol (SOAP) Web service. The interface is described through the Web Service Description Language (WSDL). The WSDL file was written following the Web Services Interoperability Basic Profile (WS-I Basic Profile). This profile defines a set of Web Services specifications that promote interoperability. The WMProxy service runs in an Apache container extended with Fast CGI and Grid Site modules.
![]() 0.2 Security, AuthN & AuthZMessage exchange between client and server is performed with SOAP/HTTPS. Authentication of the requesting user is done through the X.509 proxy certificate signed by a trusted Certification Authority (CA), which guarantees that the exposed public key is really owned by the user. The authentication process is handled by the Apache HTTP server by means of the SSL and Grid Site modules. The authenticated request together with information about the checked credential (e.g. expiration time, VOMS extensions), are then passed to WMProxy within the CGI environment. WMProxy does not need to directly manipulate Grid credentials in this phase. Authorization is implemented through the Grid Access Control List (GACL) library, which is provided by Grid Site for manipulating Access Control List (ACL) files. Authorization can be either Fully Qualified Attribute Name (FQAN) (coarse-grained) or Distinguished Name (DN) based (fine-grained) according to the type of proxy presented by the client. There are two authorization steps that are performed for an incoming request within the WMProxy:
0.3 Credentials Delegation0.3.1 Delegation ProcessThe delegation is the process used to transfer rights and privileges to another party. Since the WMProxy and the WMS when providing some services need to interact with other services, operating on behalf of the user, a delegation process is needed to transfer client proxy credentials to the server host. The delegation service is provided through a port type whose description is imported into the WMProxy WSDL file from the gLite common delegation WSDL file. Delegated credentials are uniquely identified by the association of the delegation identifier, provided by user, and the user’s DN within the credentials. Multiple delegations of the same proxy credential are allowed with different delegation identifiers; however, it is recommended to do it once at the beginning of the working session and reuse the same delegation identifier, as delegation process is generally time-consuming. The WMProxy holds a cache of the delegated proxies, which is purged periodically from the expired credentials; upon a submission request the service performs a mapping between the incoming job and a proxy in its cache according to the requesting user DN and the specified delegation identifier. From that point on, each operation performed for that job is done using the credential associated to it in this way.![]() 0.3.2 Credentials RenewalThe User can store a long-lived certificate that can be used by the WMS in order to renew the lifetime of a standard user certificate proxy (usually valid only for 12 hours). Long-running jobs may run into this limit and fail due to expioration of user proxy. WMProxy can automatically request the registration for renewing the proxy certificate sent by the user. This is done through the attribute "MyProxyServer" inside the submitting JDL. When a Proxy Renewal Registration is requested for a certain Job, the WMProxy registers it to the proxy renewal. From that moment on, credentials for such jobs are granted by renewed certificate credentials. Actually all jobs that uses the same credentials links to only one renewed certificate. | |||||||
-- FabioCapannini - 2011-11-04 | ||||||||
Added: | ||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 17 to 17 | ||||||||
0.1 Client configurationC++ WMProxy client commands![]() | ||||||||
Changed: | ||||||||
< < |
1 For each supported Virtual Organisation a directory must be created, with the following name:
/etc/glite-wms/<vo name-lowercase> | |||||||
> > |
| |||||||
(e.g. for dteam /etc/glite-wms/dteam) | ||||||||
Changed: | ||||||||
< < |
/etc/vo_template/glite_wmsui.conf.templateThis file should be copied with the name "glite_wmsui.conf" in each directory created in step 1)
/etc/vo_template/glite_wms.confThis file should be copied with the name "glite_wms.conf" in each directory created in step 1) | |||||||
> > |
| |||||||
-- FabioCapannini - 2011-11-04 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 6 to 6 | ||||||||
0.1 About WMProxy | ||||||||
Changed: | ||||||||
< < | WMProxy is a new component to access the EMI Workload Management System (WMS). | |||||||
> > | WMProxy is a new component to access the EMI Workload Management System (WMS). | |||||||
The need of such a component, besides adhering to the emerging design methodology called Service Oriented Architecture (SOA), is to improve the performance of existing similar components, to handle more efficiently a large number of requests for job submission and control and also to provide additional features. | ||||||||
Line: 14 to 14 | ||||||||
Since the European Middleware Initiative (EMI) Middleware is a composition of Grid services provided by different vendors and/or operated by different organizations, the Web services technology is a powerful means to achieve service interoperability and allow easier compliance with emerging standards such as Open Grid Services Architecture (OGSA) and Web Services Resource Framework (WSRF). | ||||||||
Added: | ||||||||
> > | 0.1 Client configurationC++ WMProxy client commands![]() /etc/glite-wms/<vo name-lowercase> (e.g. for dteam /etc/glite-wms/dteam)
/etc/vo_template/glite_wmsui.conf.templateThis file should be copied with the name "glite_wmsui.conf" in each directory created in step 1)
/etc/vo_template/glite_wms.confThis file should be copied with the name "glite_wms.conf" in each directory created in step 1) | |||||||
-- FabioCapannini - 2011-11-04 \ No newline at end of file |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
1 WMProxy Service1.1 About WMProxyWMProxy is a new component to access the EMI Workload Management System (WMS). The need of such a component, besides adhering to the emerging design methodology called Service Oriented Architecture (SOA), is to improve the performance of existing similar components, to handle more efficiently a large number of requests for job submission and control and also to provide additional features. The WMProxy is implemented as a Web service. The Web is considered a successful technology mostly because of its simplicity and ubiquity. A Web service allows us to take advantage of the benefits of the Web, not only to provide information, but also to offer services to a greater community of possible users. Since the European Middleware Initiative (EMI) Middleware is a composition of Grid services provided by different vendors and/or operated by different organizations, the Web services technology is a powerful means to achieve service interoperability and allow easier compliance with emerging standards such as Open Grid Services Architecture (OGSA) and Web Services Resource Framework (WSRF). -- FabioCapannini - 2011-11-04 |