draft ESI 0.7 OGSA WSRF BP rendering

newer
Re: [ogsa-wg] More comments: HPC...

older
Wednesday Meeting details April...

Michel Drescher

28 Apr 2006 28 Apr '06

2:36 p.m.

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

Attachments:

esi-faults.xsd (application/octet-stream — 1.1 KB)
esi-jobfactory.xsd (application/octet-stream — 7.1 KB)
esi-messages.wsdl (application/octet-stream — 2.1 KB)
esi-porttypes.wsdl (application/octet-stream — 2.4 KB)

Show replies by date

Peter G Lane

28 Apr 28 Apr

3:19 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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): . . . 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

Michel Drescher

3:39 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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):

. . .

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

Peter G Lane

4:30 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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):

. . .

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 Drescher

4:38 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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):

. . .

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 G Lane

5:15 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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):

. . .

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

Andrew Grimshaw

4:54 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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

4:55 p.m.

New subject: [ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

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.

6735

Age (days ago)

6735

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Andrew Grimshaw
Ian Foster
Michel Drescher
Peter G Lane

draft ESI 0.7 OGSA WSRF BP rendering

tags

participants (4)