[OGSA-BES-WG] BES question

[dejw]

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 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/72e5c7ed/attachment.htm