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