draft ESI 0.7 OGSA WSRF BP rendering
Folks, I took a shot and hacked a WSDL that is OGSA WSRF Basic Profile compliant (I hope). It is fairly incomplete with respect to a) the operations, messages and faults taken from WSRF- ResourceProperties, WSRF-ResourceLifetime and WS-Notification specifications. b) the ManagedJob interface completely missing as this in a constant flux at the moment (and will probably merge eventually with the existing BES specification) The documents differ from the draft specification in that the resource properties that define the (POSIX) limits of a Job Factory retain the "Limit" suffix to avoid a naming conflict of the per ManagedJob limit "VirtualMemory" with the capability resource property "VirtualMemory". As I am either not allowed or not capable otherwise to add documents to GridForge, would please one of the project admins do so for me. Cheers, Michel
Great start! Just a couple of comments: 1) I'd prefer something like "ManagedJobFactoryResourcePropeties" instead of "JobFactoryRPDocument". That way everything is spelled out and it's named after the full port type name. 2) I think the unnamed complexType under the "JobFactoryRPDocument" element should be named. Following my preference from #2, this is what I would like to see (or something similar): <xsd:element name="ManagedJobFactoryResourceProperties" type="tns:ManagedJobFactoryResourcePropertiesType"/> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType"> . . . </xsd:complexType> This is primarily motivated by implementation concerns, but it's not like working around broken tooling. I just don't like leaving class names up to the tooling. Specifying a name explicitly usually dictates what it will be seen as in the API. In addition, it mandates that any reuse of the element be done via a ref (like Subscribe). 3) The port type name is specified as "JobFactoryPortType" instead of "ManagedJobFactoryPortType" from the spec. If this was something decided upon in the last call I apologize. Peter On Fri, 2006-04-28 at 15:36 +0100, Michel Drescher wrote:
Folks,
I took a shot and hacked a WSDL that is OGSA WSRF Basic Profile compliant (I hope).
It is fairly incomplete with respect to a) the operations, messages and faults taken from WSRF- ResourceProperties, WSRF-ResourceLifetime and WS-Notification specifications. b) the ManagedJob interface completely missing as this in a constant flux at the moment (and will probably merge eventually with the existing BES specification)
The documents differ from the draft specification in that the resource properties that define the (POSIX) limits of a Job Factory retain the "Limit" suffix to avoid a naming conflict of the per ManagedJob limit "VirtualMemory" with the capability resource property "VirtualMemory".
As I am either not allowed or not capable otherwise to add documents to GridForge, would please one of the project admins do so for me.
Cheers, Michel
Hi Peter, I'm referring to spec v0.7 in my inline comments: On 28 Apr 2006, at 16:19, Peter G Lane wrote:
Great start! Just a couple of comments:
1) I'd prefer something like "ManagedJobFactoryResourcePropeties" instead of "JobFactoryRPDocument". That way everything is spelled out and it's named after the full port type name.
Referring to 3) below, I would suggest "JobFactoryResourcePropertiesDocument" (or "JobFactoryResourcePropertyDocument"?), reconciling your and my suggestions.
2) I think the unnamed complexType under the "JobFactoryRPDocument" element should be named. Following my preference from #2, this is what I would like to see (or something similar):
<xsd:element name="ManagedJobFactoryResourceProperties" type="tns:ManagedJobFactoryResourcePropertiesType"/> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType"> . . . </xsd:complexType>
This is primarily motivated by implementation concerns, but it's not like working around broken tooling. I just don't like leaving class names up to the tooling. Specifying a name explicitly usually dictates what it will be seen as in the API. In addition, it mandates that any reuse of the element be done via a ref (like Subscribe).
Agreed, according to the notes from 1).
3) The port type name is specified as "JobFactoryPortType" instead of "ManagedJobFactoryPortType" from the spec. If this was something decided upon in the last call I apologize.
I took it directly from the section headings (section 4) and not from the UML picture in figure 1 (page 5) I guess pictures get easier out of sync with draft specifications in much flux, so I preferred the section headings. Also, I think "ManagedJobFactory" could be misinterpreted as a JobFactory that is managed which would lead to the wrong assumptions. But I am probably nitpicking here. The point is that I have no trouble changing it, if necessary. I attached the updated versions below. Cheers, Michel
On Fri, 2006-04-28 at 16:39 +0100, Michel Drescher wrote:
Hi Peter,
I'm referring to spec v0.7 in my inline comments:
On 28 Apr 2006, at 16:19, Peter G Lane wrote:
Great start! Just a couple of comments:
1) I'd prefer something like "ManagedJobFactoryResourcePropeties" instead of "JobFactoryRPDocument". That way everything is spelled out and it's named after the full port type name.
Referring to 3) below, I would suggest "JobFactoryResourcePropertiesDocument" (or "JobFactoryResourcePropertyDocument"?), reconciling your and my suggestions.
"JobFactoryResourcePropertiesDocument" is fine with me.
2) I think the unnamed complexType under the "JobFactoryRPDocument" element should be named. Following my preference from #2, this is what I would like to see (or something similar):
<xsd:element name="ManagedJobFactoryResourceProperties" type="tns:ManagedJobFactoryResourcePropertiesType"/> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType"> . . . </xsd:complexType>
This is primarily motivated by implementation concerns, but it's not like working around broken tooling. I just don't like leaving class names up to the tooling. Specifying a name explicitly usually dictates what it will be seen as in the API. In addition, it mandates that any reuse of the element be done via a ref (like Subscribe).
Agreed, according to the notes from 1).
3) The port type name is specified as "JobFactoryPortType" instead of "ManagedJobFactoryPortType" from the spec. If this was something decided upon in the last call I apologize.
I think we might be talking about different documents. I'm attaching what Ian posted to GT's gram-dev mailing list. He didn't send a UML diagram with it, so my comments are also straight from the text. Could you attach or post a link to the document you all are using. Thanks. Peter
I took it directly from the section headings (section 4) and not from the UML picture in figure 1 (page 5) I guess pictures get easier out of sync with draft specifications in much flux, so I preferred the section headings. Also, I think "ManagedJobFactory" could be misinterpreted as a JobFactory that is managed which would lead to the wrong assumptions. But I am probably nitpicking here. The point is that I have no trouble changing it, if necessary.
I attached the updated versions below.
Cheers, Michel
Peter, I used the attached document. Cheers, Michel On 28 Apr 2006, at 17:30, Peter G Lane wrote:
On Fri, 2006-04-28 at 16:39 +0100, Michel Drescher wrote:
Hi Peter,
I'm referring to spec v0.7 in my inline comments:
On 28 Apr 2006, at 16:19, Peter G Lane wrote:
Great start! Just a couple of comments:
1) I'd prefer something like "ManagedJobFactoryResourcePropeties" instead of "JobFactoryRPDocument". That way everything is spelled out and it's named after the full port type name.
Referring to 3) below, I would suggest "JobFactoryResourcePropertiesDocument" (or "JobFactoryResourcePropertyDocument"?), reconciling your and my suggestions.
"JobFactoryResourcePropertiesDocument" is fine with me.
2) I think the unnamed complexType under the "JobFactoryRPDocument" element should be named. Following my preference from #2, this is what I would like to see (or something similar):
<xsd:element name="ManagedJobFactoryResourceProperties" type="tns:ManagedJobFactoryResourcePropertiesType"/> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType"> . . . </xsd:complexType>
This is primarily motivated by implementation concerns, but it's not like working around broken tooling. I just don't like leaving class names up to the tooling. Specifying a name explicitly usually dictates what it will be seen as in the API. In addition, it mandates that any reuse of the element be done via a ref (like Subscribe).
Agreed, according to the notes from 1).
3) The port type name is specified as "JobFactoryPortType" instead of "ManagedJobFactoryPortType" from the spec. If this was something decided upon in the last call I apologize.
I think we might be talking about different documents. I'm attaching what Ian posted to GT's gram-dev mailing list. He didn't send a UML diagram with it, so my comments are also straight from the text. Could you attach or post a link to the document you all are using. Thanks.
Peter
I took it directly from the section headings (section 4) and not from the UML picture in figure 1 (page 5) I guess pictures get easier out of sync with draft specifications in much flux, so I preferred the section headings. Also, I think "ManagedJobFactory" could be misinterpreted as a JobFactory that is managed which would lead to the wrong assumptions. But I am probably nitpicking here. The point is that I have no trouble changing it, if necessary.
I attached the updated versions below.
Cheers, Michel
Ok, these are basically the same. I believe I understand now what you meant by the UML document--the embedded diagram. It seems that the document in general is a little inconsistent about whether it uses "ManagedJob" (i.e. CreateManagedJob) or just "Job" (i.e. "Job Factory Interface"). IMHO this needs to be reconciled. Either use "Job Factory Interface" and "CreateJob", for example, or "Managed Job Factory Interface" and "CreateManagedJob". Anyway, that's all. Ian has a bunch of spec comments from me already, so I won't go into anything else about the spec right now. Peter On Fri, 2006-04-28 at 17:38 +0100, Michel Drescher wrote:
Peter,
I used the attached document.
Cheers, Michel
On 28 Apr 2006, at 17:30, Peter G Lane wrote:
On Fri, 2006-04-28 at 16:39 +0100, Michel Drescher wrote:
Hi Peter,
I'm referring to spec v0.7 in my inline comments:
On 28 Apr 2006, at 16:19, Peter G Lane wrote:
Great start! Just a couple of comments:
1) I'd prefer something like "ManagedJobFactoryResourcePropeties" instead of "JobFactoryRPDocument". That way everything is spelled out and it's named after the full port type name.
Referring to 3) below, I would suggest "JobFactoryResourcePropertiesDocument" (or "JobFactoryResourcePropertyDocument"?), reconciling your and my suggestions.
"JobFactoryResourcePropertiesDocument" is fine with me.
2) I think the unnamed complexType under the "JobFactoryRPDocument" element should be named. Following my preference from #2, this is what I would like to see (or something similar):
<xsd:element name="ManagedJobFactoryResourceProperties" type="tns:ManagedJobFactoryResourcePropertiesType"/> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType"> . . . </xsd:complexType>
This is primarily motivated by implementation concerns, but it's not like working around broken tooling. I just don't like leaving class names up to the tooling. Specifying a name explicitly usually dictates what it will be seen as in the API. In addition, it mandates that any reuse of the element be done via a ref (like Subscribe).
Agreed, according to the notes from 1).
3) The port type name is specified as "JobFactoryPortType" instead of "ManagedJobFactoryPortType" from the spec. If this was something decided upon in the last call I apologize.
I think we might be talking about different documents. I'm attaching what Ian posted to GT's gram-dev mailing list. He didn't send a UML diagram with it, so my comments are also straight from the text. Could you attach or post a link to the document you all are using. Thanks.
Peter
I took it directly from the section headings (section 4) and not from the UML picture in figure 1 (page 5) I guess pictures get easier out of sync with draft specifications in much flux, so I preferred the section headings. Also, I think "ManagedJobFactory" could be misinterpreted as a JobFactory that is managed which would lead to the wrong assumptions. But I am probably nitpicking here. The point is that I have no trouble changing it, if necessary.
I attached the updated versions below.
Cheers, Michel
Michel, Does it make sense to do a rendering of the ESI document when it was intended (based on what we've been told) to inform the BES discussion - and that we are in fact in the process of updated BES to accommodate the ESI issues? A
-----Original Message----- From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Michel Drescher Sent: Friday, April 28, 2006 10:36 AM To: ogsa-bes-wg@ggf.org Subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering
Folks,
I took a shot and hacked a WSDL that is OGSA WSRF Basic Profile compliant (I hope).
It is fairly incomplete with respect to a) the operations, messages and faults taken from WSRF- ResourceProperties, WSRF-ResourceLifetime and WS-Notification specifications. b) the ManagedJob interface completely missing as this in a constant flux at the moment (and will probably merge eventually with the existing BES specification)
The documents differ from the draft specification in that the resource properties that define the (POSIX) limits of a Job Factory retain the "Limit" suffix to avoid a naming conflict of the per ManagedJob limit "VirtualMemory" with the capability resource property "VirtualMemory".
As I am either not allowed or not capable otherwise to add documents to GridForge, would please one of the project admins do so for me.
Cheers, Michel
Andrew: I was eager to see this, as input to the BES updating process that we have agreed to. Ian. At 12:54 PM 4/28/2006 -0400, Andrew Grimshaw wrote:
Michel, Does it make sense to do a rendering of the ESI document when it was intended (based on what we've been told) to inform the BES discussion - and that we are in fact in the process of updated BES to accommodate the ESI issues? A
-----Original Message----- From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Michel Drescher Sent: Friday, April 28, 2006 10:36 AM To: ogsa-bes-wg@ggf.org Subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering
Folks,
I took a shot and hacked a WSDL that is OGSA WSRF Basic Profile compliant (I hope).
It is fairly incomplete with respect to a) the operations, messages and faults taken from WSRF- ResourceProperties, WSRF-ResourceLifetime and WS-Notification specifications. b) the ManagedJob interface completely missing as this in a constant flux at the moment (and will probably merge eventually with the existing BES specification)
The documents differ from the draft specification in that the resource properties that define the (POSIX) limits of a Job Factory retain the "Limit" suffix to avoid a naming conflict of the per ManagedJob limit "VirtualMemory" with the capability resource property "VirtualMemory".
As I am either not allowed or not capable otherwise to add documents to GridForge, would please one of the project admins do so for me.
Cheers, Michel
_______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org.
participants (4)
-
Andrew Grimshaw -
Ian Foster -
Michel Drescher -
Peter G Lane