Hi all, I have a question about BES : We implemented a plugin to our portal solution which let us run jobs to any BES service (compatible with first version of this standard). So our solution should work well with any service which conforms to this standard. But we met some small problems although. For our perspective we need to extract the job identifier - and here we had to write suitable part of code for different BES services - why? becuase ActivityIdentifier is a type of wsa:EndpointReferenceType and here lies the problem. Every BES service use different tactics here. For example when I tried BES service build upon LSF (platform.com) the job id was added simply to the Address which is simply url with parameter containing job ID. Other services always uses ReferenceParameters which can be any xml data which is characteristic to the target underlying system. So for every new BES service built on different middleware, job managament service I had to write something like let say transition code which extracts for me job id from different xml data. This way actually I don't know if some new service will work well with my plugin. This is a little confusing for me why in some common interface (let me say that about BES) can have different job id notation. It is always some string by the way which looks a little different for every underlying system. So why it couldn't be also one xml schema concerning job id? Regards, Dawid Szejnfeld, PSNC
Hi,
maybe some example what I meant so far:
The case is when I get ActivityIdentifier from BES service which is as
the BES schema says:
Hi all,
I have a question about BES :
We implemented a plugin to our portal solution which let us run jobs to any BES service (compatible with first version of this standard). So our solution should work well with any service which conforms to this standard.
But we met some small problems although.
For our perspective we need to extract the job identifier - and here we had to write suitable part of code for different BES services - why? becuase ActivityIdentifier is a type of wsa:EndpointReferenceType and here lies the problem. Every BES service use different tactics here. For example when I tried BES service build upon LSF (platform.com) the job id was added simply to the Address which is simply url with parameter containing job ID. Other services always uses ReferenceParameters which can be any xml data which is characteristic to the target underlying system. So for every new BES service built on different middleware, job managament service I had to write something like let say transition code which extracts for me job id from different xml data. This way actually I don't know if some new service will work well with my plugin.
This is a little confusing for me why in some common interface (let me say that about BES) can have different job id notation. It is always some string by the way which looks a little different for every underlying system. So why it couldn't be also one xml schema concerning job id?
Regards, Dawid Szejnfeld, PSNC
On Mar 15, 2007, at 7:33 AM, dejw wrote:
Hi,
maybe some example what I meant so far:
The case is when I get ActivityIdentifier from BES service which is as the BES schema says:
and wsa:EndpointReferenceType is:
So as you can see I can have always Address so uri of target service, and its ok here. But the problem is with 'ReferenceParameters'. The definition of this is:
So it can contain any xml blob. And many BES services have their own xml here inside it. So I as a programmer have to parse these xml's and get the job id which is always some string and that's all. So I think this xml is useless here unless it is common for every service.
The endpoint reference type is a web services standard way of describing how to contact a web service, potentially including references to some state managed by the service via the ReferenceParameters (these are similar in concept to http cookies). The ReferenceParameters are to be considered an opaque data block to service clients. There is no guarantee that any sort of meaningful local identifier will be present in the EPR. It is meant to be used by the Web Service hosting system to address Web Service operation requests to the particular stateful resource associated with the created activity.
Now I have to now what "type" of underlying system I have i.e. crown, unicore, gridsam etc. and then I have to built a little different ActivityIdentifier to get job status for example. It's a little strange.
The EndpointReferenceType can be sent in the body of the GetActivityStatus operation directly. Why do you think you need to know about the contents of the EPR? joe
On Mar 15, 2007, at 7:33 AM, dejw wrote:
Hi,
maybe some example what I meant so far:
The case is when I get ActivityIdentifier from BES service which is as the BES schema says:
and wsa:EndpointReferenceType is:
So as you can see I can have always Address so uri of target service, and its ok here. But the problem is with 'ReferenceParameters'. The definition of this is:
So it can contain any xml blob. And many BES services have their own xml here inside it. So I as a programmer have to parse these xml's and get the job id which is always some string and that's all. So I think this xml is useless here unless it is common for every service.
The endpoint reference type is a web services standard way of describing how to contact a web service, potentially including references to some state managed by the service via the ReferenceParameters (these are similar in concept to http cookies). The ReferenceParameters are to be considered an opaque data block to service clients.
There is no guarantee that any sort of meaningful local identifier will be present in the EPR. It is meant to be used by the Web Service hosting system to address Web Service operation requests to the particular stateful resource associated with the created activity.
Now I have to now what "type" of underlying system I have i.e. crown, unicore, gridsam etc. and then I have to built a little different ActivityIdentifier to get job status for example. It's a little strange.
The EndpointReferenceType can be sent in the body of the GetActivityStatus operation directly. Why do you think you need to know about the contents of the EPR? In our portal solution we need job id to present it in our web pages with job statuses and other information, we have also plugins for other non-BES services and we need job ids to get all informations about jobs. 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. So I don't know if job id is something which should be hidden for BES services? The other thing it is easier later to debug some problems - user knows job id and he can also directly contact administrator of the target system and get known about source of the
Hi, Joseph Bester napisał(a): problem, he can give exact job id which let do it much easier. So I think there are scenarios where the client must know job id and has to parse ReferenceParameters to get this job id as it is often in case of BES services. Other case I had that there was noting in ReferenceParameters and the job id was added to the uri which was in the Address element of the EndpointReferenceType. So finally I had common interface to different job management systems - BES - and this is very good, but what is not so comfortable - I have to test evey new BES service I want to use and write another part of code to get job id and later to create ActivityIdentifier where ReferenceParameters is a little different if it was used. Dawid
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... Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, University of Southampton, Highfield, Southampton, SO17 1BJ, UK
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! ]
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! ]
Hi all, I would suggest the following WRT the current discussion. Regardless whether the issued EPRs are WS-Names or not. If desired (e.g for debugging), the batch sub system's job id would be best placed in the EPR metadata section as the ReferenceParameeters are certainly meant opaque to anybody else except the issuer and the addressed service instance itself. A human-readable job id, e.g. user-issued in a portal, is probably best stuffed into the EndpointIdentifier in a WS-Name - if this is not abailable, then a RNS service would be a natural fit to map human-readable names to job EPRs. Cheers, Michel dejw wrote:
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):
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
Steven Newhouse wrote: 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! ]
-- ogsa-bes-wg mailing list ogsa-bes-wg@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
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.
Donal K. Fellows wrote:
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.
Alright - but this might be something interesting to implement/explore when composing the OGSA-BES interface with an SLA interface. For example: The service offers in its generic SLA to pass through the job id, for a small fee, for example .99 USD. The user reads this SLA, decides he accepts it, and, along with the job submission, passes *his* SLA describing the acceptance of the fee and details how to debit his credit card. Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
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, 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. 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. 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.
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
-- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834
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
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@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
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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
On Mar 19, 2007, at 7:20 AM, 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.
This might occur, for example, if data staging is to be done before the submission. The CreateActivity operation may return the EPR to the Activity while the staging is in progress, prior to a submission to a queuing system (and thus before any local job id exists). joe
I definitely was in favour of using WS-Names in order to achieve this goal,
since my service is definitely (in a later poster's email) "old style", and
uses integer job identifiers. :-)
I don't recall the reasons why people didn't want to use WS-Names. Maybe it
was that some didn't want them mandated. I agree that maybe we should
profile this. Perhaps we can address this in the HPC Profile sessions at
OGF20?
-- Chris
On 18/3/07 11:43, "Donal K. Fellows"
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! ]
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
Hi, I think it could be a good idea to have such human readable id of the job which conforms to the real job id got from the job management system standing behind BES service. (anyway I have to get it always from ReferenceParameters if it is there) Dawid Steven Newhouse napisał(a):
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...
Steven
participants (6)
-
Christopher Smith -
dejw -
Donal K. Fellows -
Joseph Bester -
Michel Drescher -
Steven Newhouse