Hi, let me try answer this, too: dejw wrote:
Hi,
this is interesting - so something else is sent which identifies directly the executed job? something like job id?
So far we had worked with various job submission services let me say - and always we got job id,
Were these submission services WS and WS-Addressing based? If not, then these systems are "old style" (*cough* *cough*) and the job id is the only handle you get back.
the case is how to check later the job status for example? The unique pair we used always was: uri of the target system + job id got form there after job submission.
This makes me guess you actually usedd WS and WS-Addressing based job submission services.
In the case you mentioned there is some other information (not job id) which finally is unique and identifies submitted job in the given service? if yes then we can treat it as something like job id.
I guess you got the semantics of EPRs mixed up*. An EPR's [address] and [reference parameter]s are opaque to at least the user. Reading and trying to understand them is unwanted by the specification, though not explicitly stated. These both form a unique identification for a Web Service (particularly for stateful Web Services). Even though the [address] is of tye xsd:anyURI, and even more though most implementations stuff *URL*s in it** it can hold any type of information that fits the uniqueness requirements, including URIs (e.g. "urn:foo.completely-opaque-information.Y29tcGxpY2F0ZWQ="). Hence target system generated job ids are not at all guaranteed being any parseable part of a job's EPR *unless* it is made so by proper means (e.g. EPR Metadata, etc.). Cheers, Michel * Which is, I may say, fairly common, still. ** This, I believe, is a requirement for RESTful Web Services.
Dawid
Donal K. Fellows napisa�(a):
dejw wrote:
I agree, this is some solution (magic names) but I have to dig into EPRs as it is good for a user to know real job id - later any debug action could be done directly between user and supervisor of the target BES service and target job management service (it was checked by us in practise). If user doesn't know the real job id then the portal admin has to be involved to get it somehow in some critical situations let's say. So finally I have to get it anyway. I know of at least one implementation that won't tell you the job identifier, no matter how you look in the EPR. You *can't* rely on it being there.
Donal.
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834