[OGSA-BES-WG] BES question

[dejw]

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.

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 at ogf.org
>>   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
>>
>>     
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20070319/6ae20ea8/attachment.html