[OGSA-BES-WG] BES question

[Michel Drescher]

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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20070319/7952ac10/attachment-0001.pgp