Hi, I totally agree Dawid Michel Drescher napisał(a):
Hi,
dejw wrote:
Hi,
yes sure I agree with all of this and I am aware of this. I tested also some service where the unique data (which wasn't in fact the real job id) was added to the uri as a parameter and ReferenceParameters wasn't used. Generally all is clear to me. I wonder only if the job id couldn't be available though? I can accept that I had to store EPRs and so on, I understand the goal of using this and so on. I don't want to undermine this and I understand this is part of specification. Sometimes it could be easier to debug some situations faster if user knows job id and then the portal supervisor doesn't have to be involved. (but of course it depends how "help desk" is organised). In our case we always relied on job ids and there wasn't problem with this. But ok I can accept all of this as it is with BES spec.
The fact that the BES spec remains silent on this particular issue does not stop people to implement it. But *if* an implementation of the BES spec supports this then it better had done it in a "non'hacky" way, i.e. properly profiling the use of WS-Addressing EPRs so that clients can pick up that piece of information in an interoperable way. That's the reason why I advocated for putting that into the EPR metadata, and publish *how* this is done, i.e. publishing schema and stuff.
Cheers, Michel
Dawid
Michel Drescher napisaďż˝(a):
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