Hi, 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. Dawid Donal K. Fellows napisał(a):
Steven Newhouse wrote:
The other thing is that from my observation so far the ReferenceParameters contains only job id and that's all, no other information is there.
That is required by the BES specification. Other services and systems are free to use the ReferenceParameter system to provide other information and do...
You may have identified a need for an optional human readable identifier...
As I understand the currents of opinion within the OGSA-WG, the idea is that the EPRs out of a BES will actually be WS-Names, and that the abstract name parts of each WS-Name will be the human-readable part that you are looking for. This isn't officially recommended yet though, mostly due to unpleasant politics and the fact that nobody's written the profile yet[*]. (I can't remember if such a profiling is on the current work roster or not; it might not be if people decide they need a few more things first to make a good profile.)
I suggest that if you're dealing with non-names, you should generate some magic names yourself in your portal and maintain a mapping from those to EPRs. You could even do some clever stuff so that the portal acts as the naming service for the dumb BES instances. That's the sort of thing that people developing portals for this sort of thing have had to do in the past anyway.
Donal. [* Correct me if I'm wrong! ]