[OGSA-BES-WG] BES question

[Michel Drescher]

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 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/930f3670/attachment.pgp