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