From: Miloš Mulač Date: Fri, 12 Aug 2005 10:42:31 +0000 (+0000) Subject: removed to jp.ws-interface X-Git-Tag: gridsite-core_R_1_1_11~73 X-Git-Url: http://scientific.zcu.cz/git/?a=commitdiff_plain;h=affcee10b355d2d8209d30627664f7dfac30df4d;p=jra1mw.git removed to jp.ws-interface --- diff --git a/org.glite.jp.index/project/JobProvenanceIS.wsdl b/org.glite.jp.index/project/JobProvenanceIS.wsdl deleted file mode 100644 index 26f97a4..0000000 --- a/org.glite.jp.index/project/JobProvenanceIS.wsdl +++ /dev/null @@ -1,531 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Register job with JP primary storage. -Job registration in LB is propagated to JP immediately so that JP is aware of the job, -despite no furhter information is available in it. - -Input: JobId - -Output: N/A - -Faults: GenericJPFault - - - - - - - Initiate upload of of sandbox/dump of job life log from LB. -WM component responsible for job sandbox management and LB server call JP to declare -intention to upload intput/output sandbox and job life log. - -Input: - -uclass: type of the upload - INPUT_SANDBOX, OUTPUT_SANDBOX, JOB_LOG - -commitTimeout: upper limit on time for which JP waits for committing this upload transaction - -contentType: MIME type of the uploaded file - -Output: - -destination: URL where the client should upload the file - -commitBefore: acutual time when the upload transaction times out - -Faults: GenericJPFault - - -Initiate upload of of sandbox/dump of job life log from LB. - - - - - - Confirm upload. -Should be called after a file upload initiaded with StartUpload is finished. - -Input: - -destination: Upload destination URL (to match with the original request) - -Output: - -Faults: GenericJPFault - - - - - - - Record a value of user tag. -JP tags are either standalone or override values of their LB counterparts. -However, JP tag values are still distinguishable those inherited from LB. -JP tags may be either strings or blobs. - -Input: - -jobid: - -tag: structure containing name, timestamp, optional sequence number to order tag values -without relying on timestamps, and string or blob value. - -Output: N/A - -Faults: GenericJPFault - - - - - - - Start feeding JP index server. -Called by the index server to start batch feed, and optionally also subscribe for incremental feed. - -JP index server subscribes with JP primary storage using a query -containing conditions on primary metadata and a list of queryable attributes -of the index server (i.e. data which should be sent to the index server). - -When a matching job record is created or modified within the primary storage -the job record data are sent to the subscribed index server. - -The subscription is soft-state, it expires after certain time unless refreshed by the client explicitely. - -In the batch mode the query has the same form -with additional flag asking for all matching records (i.e.\ not only -arriving afterwards). - -Input: - -destination: where to send the job record data - -attributes: which job record attributes should be sent to the requesting index server - -conditions: list of query conditions. Each conditions has the form Attribute Operator Value, -where Attribute is any of job record attributes and Operator is one of EQUAL, UNEQUAL, LESS, GREATER, WITHIN. - -continuous: flag determining that the query is incremental (not batch) - -Output: - -feedId: unique Id of the feed request, to be used in refresh, cancelation etc. - -expires: when the feed times out. Must be refreshed before this time. - -Faults: GenericJPFault - - - - - - - Extend batch feed subscription (used by index server) - -Input: feedId returned previously by FeedIndex - -Output: the same as for FeedIndex - -Faults: GenericJPFault - - - - - - - Retrieve job record URL's when jobid is known -Used either to bypass JP index server query for this specific case, or after the index server query to -retrieve actual job record. - -Input: jobid - -Output: - -jobLog, inputSandbox, outputSandbox, tags: URL's to components of the job record. - -Faults: GenericJPFault - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Job Provenance Primary Storage service - - - - - - - - - - - - - - - - - - - - - - Store or update information on jobs within the JP index server. -Called directly by the primary storage, used for both batch and incremental feed. - -Input: - -data: list of job record updates. Each contains jobid, list of JP attribute values and user tag values. - -feedDone: flag indicating end of batch feed. (In order to avoid potential problems with buffer allocation -the huge dataset of batch feed is split into reasonable chunks and delivered with more UpdateJobs calls.) - -Output: N/A - -Faults: GenericJPFault - - - - - - - - - Retrieve pointers to job records of jobs matching a query. -Input: conditions - list of lists of query conditions. - Elements of the inner lists refer to a single job attribute, the conditions are or-ed. - Elements of the outer list may refer to different job attributes, they are and-ed. - -Output: - -jobs: list of JobId, PSContact (URL of the primary storage which manges this job) pairs - -Faults: GenericJPFault - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Job Provenance Index service - - - - - - -