January 2006 - ogsa-wg - lists.ogf.org

Last call for Application Contents Service Specification 1.0
by Keisuke Fukui 08 Mar '06

08 Mar '06

Folks in ogsa-wg, cddlm-wg and acs-wg, We, acs-wg, has come to completion of the ACS Specification 1.0 after discussions and reviews. This is the last call for comments before submission to the GGF Editor for publication. If you have comments, please get them to me by 9 am Japan time on Monday November 7. If there are no significant comments I plan to submit the document on Monday afternoon. Below is the link for the document: https://forge.gridforum.org/projects/acs-wg/document/draft-ggf-acs-spec-1.0… Regards, Keisuke Fukui ACS-WG co-chair

1 1

Survey for GGF16, GGF17, and interim F2F in April
by Hiro Kishimoto 01 Feb '06

01 Feb '06

Hi all, and sorry for the cross-posting. As you already know, OGSA-WG is planning to have F2F meetings back-to-back with GGF16 (Athens) and GGF17 (Tokyo). We are also planning to have interim F2F meeting in April (venue TBD). Please let us know your plan for attendance and preference by answering the following on-line survey. http://www.zoomerang.com/survey.zgi?p=WEB224YECBCXZY OGSA-WG will discuss meeting plans at the upcoming weekly call on Monday, Jan. 30th, 4-6pm CST. And hard deadline for this survey is Sunday, Feb. 5th. Thanks, -- Hiro Kishimoto

1 2

FINAL CALL Document: OGSA Basic Security Profile 1.0 - Secure Channel v017
by Takuya Mori 31 Jan '06

31 Jan '06

The final call document for the OGSA Basic Security Profile 1.0 - Secure Channel is available for download at the link below. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Please review and positive acknowledge with an email to the mailing list with your vote (yes or no) for submission from the workgroup to the GGF Editor. Please vote (email) by Monday, February 6 COB (EDT). If your vote is 'no' please include precise comments so that we may address any substantive issues you may have prior to submission. Thanks, Takuya

1 0

FINAL CALL Document: OGSA Basic Security Profile 1.0 - Core v005
by Takuya Mori 31 Jan '06

31 Jan '06

The final call document for the OGSA Basic Security Profile 1.0 - Core is available for download at the link below. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Please review and positive acknowledge with an email to the mailing list with your vote (yes or no) for submission from the workgroup to the GGF Editor. Please vote (email) by Monday, February 6 COB (EDT). If your vote is 'no' please include precise comments so that we may address any substantive issues you may have prior to submission. Thanks, Takuya

1 0

Non-normative text update for section 1.2 of the OGSA WSRF Basic Profile
by Hiro Kishimoto 30 Jan '06

30 Jan '06

Hi all, We've agreed on this revised text at today's call. ---- Hiro Kishimoto 1.2 Relationships to Other Profiles This Profile extends the WS-I Basic Profile 1.1 [WS-I BP 1.1]. As mentioned in section 1.1 of the WS-I Basic Profile 1.1, there are several profiled bindings which should be used in combination with a profile. It is expected that combined claims of conformance with binding-specific profiles will be the norm. All requirements of WS-I BP 1.1 except for section 5 "Service Publication and Discovery" pertain to this Profile. There may be additional profiles in the future that will include discovery functions. This Profile mandates composition with an OGSA Basic Security profile as described in section 8. Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-580-3477 (8280 3477) Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

1 0

Non-normative text update for section 1.2 of the OGSA WSRF Basic Profile
by Maguire_Tom＠emc.com 30 Jan '06

30 Jan '06

1.2 Relationships to Other Profiles This Profile extends the WS-I Basic Profile 1.1 [WS-I BP 1.1]. All requirements except for section 5 "Service Publication and Discovery" specified in WS-I BP 1.1 pertain to this Profile. There may be additional profiles in the future that will include discovery functions. This Profile mandates composition with an OGSA Basic Security profile as described in Section 8. Additionally, as mentioned in section 1.1 of the WS-I Basic Profile 1.1, there are several profiled bindings which should be used in combination with a profile. It is expected that combined claims of conformance with binding specific profiles will be the norm. Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-580-3477 (8280 3477) Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

1 0

Proposed agenda for Jan. 30th call
by Hiro Kishimoto 30 Jan '06

30 Jan '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Jan. 30th Monday from 4pm to 6pm (CST). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0130 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if available) OGSA WSRF BP 1.0 status (Tom) IBM RSM academic/SDOs license program update (Jay) Agenda bashing 2) Basic Security Profiles status review (20 min) Takuya has uploaded revised "secure channel" draft to GridForge https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… He will also upload revised "core" draft before the call. Please read these drafts before the call and discuss if they are ready for final call. 3) F2F meeting minutes approval and action item review (30 min) Andreas has uploaded almost all materials and minutes: https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… aka http://tinyurl.com/cyrvk 4) GGF16, GGF17, April F2F meeting plan (30 min) Hiro will lunch zoomerang survey of these meetings. Update for GGF16 OGSA-WG sessions and B2B F2F meeting. 5) EMS discussion (30 min) Continuing discussion on EMS composite roadmap document. Darren has uploaded updated composite roadmap draft (v0.7) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… CDDLM-WG joint-call (Feb. 1) prep 6) Wrap up (10 min) AOB <NEXT CALL> Feb. 1 (Wed): CDDLM joint call Feb. 6 (Mon): Arch 1.5 final text review, GGF16 prep Feb. 8 (Wed): Info model, EMS design team GGF16 prep GGF16 (Athens): Feb. 13-16 -- Hiro Kishimoto

2 2

RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Subramaniam, Ravi 30 Jan '06

30 Jan '06

Hi Charles, Thanks for the clarification on the decision. I am not sure why one would have to have policy in the domain of EPS only. As far as I know, policy can be in multiple domains and partitioned at multiple levels and/or hierarchically. This suggests to me that one may partition policy in the CSG domain, EPS domain or any such domain as one chooses. One would expect that these policy frameworks be consistent but I don't see why they need to be concentrated in one place. Second, I don't understand the motivation behind the "redo much of the work". I don't see why this would be the case. It has less to do with the types of services rather than the limitations of implementation. In the case one cannot determine an algorithm that can have distributed decision/processing or if there is some sticky performance metric then one can design a software component that provides both services but leverages the "tight implementation composition" in realizing that algorithm. This again brings me back to the point of software component versus services. Thanks! Ravi -----Original Message----- From: Spitz, Charles F [mailto:Charles.Spitz@ca.com] Sent: Friday, January 27, 2006 1:26 PM To: Subramaniam, Ravi Cc: Andreas Savva; Donal K. Fellows; ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Hi Ravi, The discussion at the F2F regarding the CSG and EPS was along the lines that the EPS needed more information than just a list of handles from the CSG, and would most likely redo much of the work that the CSG had done in putting together the candidate list. In your example below, you're suggesting that the CSG could use "policy, requirements and resource properties and profiles" to generate candidate sets. The sense of the F2F discussion was that policy, etc. is thought to be more in the domain of the EPS. Hence the question about why CSG needs to be a separate service. Thanks, -chuck spitz -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Subramaniam, Ravi Sent: Friday, January 27, 2006 1:56 PM To: Donal K. Fellows; ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Hi, Unfortunately, I missed most if not all of the EMS sessions at the F2F because of alternate commitments that I could not reschedule. This is the first I have seen on the suggestion to remove CSG. I would strongly suggest against dropping the requirement for CSG. When view from the narrow view of HPC the function of EPS and CSG has been traditionally been the scheduler. There is value in this service beyond the execution of jobs when we consider the larger picture of systems management. There are opportunities to build candidate sets using combinations of policy, requirements and resource properties and profiles that go beyond the need for scheduling jobs. Such candidate sets. I also agree with Donal and, based on his reference to Dave, with Dave that this is an important concept and, therefore, by extrapolation a service. This brings me to the larger topics (I don't often speak up in email so please permit me to use my soap box): 1. What is OGSA defining: standard software components or services? The granularity and the separation of concerns that is represented in the concept of SOA does not preclude that services may be combined into a single software component as part of implementation decisions. I see an increased march in OGSA towards the implementation (i.e. software components) view rather than a services view since we had the GFSG direction on being more normative. 2. We are increasing driving toward siloed "implementation" rather than using this opportunity of such a WG to build an architecture that unifies concepts that are more horizontal and integrated. EMS is becoming more HPC, we have little discussion with data. We don't seem to be asking questions like why should BES be worried about data staging when the data team can provide more general schemes for data management whether in a execution container context or otherwise. There are issues that are better and much more simply handled with benefits like late binding by workflows but we seem to ignore that in our current activity. I am *not* finding fault but trying to raise the discussion to finding the "compositional" nature of services and not biasing our thinking with fitting a particular notion of an implementation. 3. Taking too many shortcuts (in the name of progress) will fritter away the unique opportunity that is OGSA and we will be walking the path towards failure like CORBA and DCE before us (both of which had noble goals but focused, from my understanding, more on the software components as defined should interact as opposed to what are the key functional elements and how should these interact/interoperate and be composed). Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Friday, January 27, 2006 4:26 AM To: ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Thanks to Andreas for the notification. Andreas Savva wrote: > Even though there were no RSS-WG representatives at the F2F the EMS > design team also discussed EPS and CSG as part of the EMS Roadmap > session. Two *suggestions* came out of that session and should be > discussed at a future joint call or perhaps during a joint session at > GGF16. I think they fit in the agenda that Donal proposed below. > >>From the minutes: > - Separation of EPS and CSG is not clearly required - suggest to RSS to > remove CSG and let them make the call. And clearly define the added > value of CSG. > - EPS returns an ordered (by policy) list of (Activity Execution > Candidates: <JSDL doc; EPR or path of BES container; rank (optional, > numeric, extensible), CDL, EPR to deployment service, ...>. > > Folder url: > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor y_id=1149&filtertype=basic I think I favour keeping the CSG as an abstract concept; it looks like it will be useful for places in the Data architecture (e.g. it's possibly an abstraction of other things like replica catalogs. Many thanks to Dave Berry for starting me thinking about these things; it helped a lot with understanding the difference between a CSG and an EPS.) It will also be the level at which we describe how to map things down to stuff like WSRF or WS-Transfer, since it stops us from worrying about how to actually splat things over the wire in a portable way (i.e. there are multiple ways of doing it, but writing connectors from one to another isn't hard). Looking at the other issue, that of the Activity Execution Candidates, I rather like much of what is suggested. I'd modify it a bit though: AEC < JSDL BES-EPR QoS Terms < Price Start Time Range[*] End Time Range etc. (extensible) > CDL (I don't know what this will look like, but having it is not a problem at all; probably easier to not require though, since as long as we have extensibility it can go in trivially anyway.) etc. (extensible) > Just putting the score in isn't so helpful (there's no reasonable possibility of examining the provenance of the value) especially since different parties that see the AEC might want to apply different objective functions. In a reverse to things I've said in the past, I don't think we should require the AEC to be implemented as a WS-Agreement template (though one could be contained within it via extensibility) since that imposes some very strong restrictions on how the job is subsequently handled. There probably ought to be provision for the signing of the AEC, since that enables the receiving party to know the identity of the party legally responsible for honouring what will be the basis for a contract. Pricing model must itself be extensible, but lots of useful cases are easily handled through "fixed amount plus <consumption level>*rate". Looking more at https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/ en/1 I see that there are some thoughts on EPS and things more complex than an atomic job. That would require some kind of composite activity description language, the definition of which is outside the scope of the RSS WG. (In many respects, it doesn't alter all that much anyway. It's just a more complex replacement for the JSDL chunk.) Similarly for scheduling parameters or parametric things (well, certainly for sched parms; I don't understand the parametric world quite so well). Anything else I've missed? Donal. [* Or should this be an expression of estimated delay from submission to execution commencement? Sometimes things are best one way, sometimes another. StartTime is good for reservation, StartDelay is good for immediate-execution or conventional batch queues. ]

4 6

Material from F2F meeting (1/16-20) now on gridforge
by Andreas Savva 27 Jan '06

27 Jan '06

All the material I collected during last week's F2F as well as draft minutes are now on gridforge in folder https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… aka http://tinyurl.com/cyrvk If there is anything missing please upload it to this folder or send it to me. Thanks to all volunteer minute takers. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic
by Spitz, Charles F 27 Jan '06

27 Jan '06

Hi Ravi, The discussion at the F2F regarding the CSG and EPS was along the lines that the EPS needed more information than just a list of handles from the CSG, and would most likely redo much of the work that the CSG had done in putting together the candidate list. In your example below, you're suggesting that the CSG could use "policy, requirements and resource properties and profiles" to generate candidate sets. The sense of the F2F discussion was that policy, etc. is thought to be more in the domain of the EPS. Hence the question about why CSG needs to be a separate service. Thanks, -chuck spitz -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Subramaniam, Ravi Sent: Friday, January 27, 2006 1:56 PM To: Donal K. Fellows; ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: RE: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Hi, Unfortunately, I missed most if not all of the EMS sessions at the F2F because of alternate commitments that I could not reschedule. This is the first I have seen on the suggestion to remove CSG. I would strongly suggest against dropping the requirement for CSG. When view from the narrow view of HPC the function of EPS and CSG has been traditionally been the scheduler. There is value in this service beyond the execution of jobs when we consider the larger picture of systems management. There are opportunities to build candidate sets using combinations of policy, requirements and resource properties and profiles that go beyond the need for scheduling jobs. Such candidate sets. I also agree with Donal and, based on his reference to Dave, with Dave that this is an important concept and, therefore, by extrapolation a service. This brings me to the larger topics (I don't often speak up in email so please permit me to use my soap box): 1. What is OGSA defining: standard software components or services? The granularity and the separation of concerns that is represented in the concept of SOA does not preclude that services may be combined into a single software component as part of implementation decisions. I see an increased march in OGSA towards the implementation (i.e. software components) view rather than a services view since we had the GFSG direction on being more normative. 2. We are increasing driving toward siloed "implementation" rather than using this opportunity of such a WG to build an architecture that unifies concepts that are more horizontal and integrated. EMS is becoming more HPC, we have little discussion with data. We don't seem to be asking questions like why should BES be worried about data staging when the data team can provide more general schemes for data management whether in a execution container context or otherwise. There are issues that are better and much more simply handled with benefits like late binding by workflows but we seem to ignore that in our current activity. I am *not* finding fault but trying to raise the discussion to finding the "compositional" nature of services and not biasing our thinking with fitting a particular notion of an implementation. 3. Taking too many shortcuts (in the name of progress) will fritter away the unique opportunity that is OGSA and we will be walking the path towards failure like CORBA and DCE before us (both of which had noble goals but focused, from my understanding, more on the software components as defined should interact as opposed to what are the key functional elements and how should these interact/interoperate and be composed). Thanks! Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Friday, January 27, 2006 4:26 AM To: ogsa-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org Cc: Andreas Savva Subject: [ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic Thanks to Andreas for the notification. Andreas Savva wrote: > Even though there were no RSS-WG representatives at the F2F the EMS > design team also discussed EPS and CSG as part of the EMS Roadmap > session. Two *suggestions* came out of that session and should be > discussed at a future joint call or perhaps during a joint session at > GGF16. I think they fit in the agenda that Donal proposed below. > >>From the minutes: > - Separation of EPS and CSG is not clearly required - suggest to RSS to > remove CSG and let them make the call. And clearly define the added > value of CSG. > - EPS returns an ordered (by policy) list of (Activity Execution > Candidates: <JSDL doc; EPR or path of BES container; rank (optional, > numeric, extensible), CDL, EPR to deployment service, ...>. > > Folder url: > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&categor y_id=1149&filtertype=basic I think I favour keeping the CSG as an abstract concept; it looks like it will be useful for places in the Data architecture (e.g. it's possibly an abstraction of other things like replica catalogs. Many thanks to Dave Berry for starting me thinking about these things; it helped a lot with understanding the difference between a CSG and an EPS.) It will also be the level at which we describe how to map things down to stuff like WSRF or WS-Transfer, since it stops us from worrying about how to actually splat things over the wire in a portable way (i.e. there are multiple ways of doing it, but writing connectors from one to another isn't hard). Looking at the other issue, that of the Activity Execution Candidates, I rather like much of what is suggested. I'd modify it a bit though: AEC < JSDL BES-EPR QoS Terms < Price Start Time Range[*] End Time Range etc. (extensible) > CDL (I don't know what this will look like, but having it is not a problem at all; probably easier to not require though, since as long as we have extensibility it can go in trivially anyway.) etc. (extensible) > Just putting the score in isn't so helpful (there's no reasonable possibility of examining the provenance of the value) especially since different parties that see the AEC might want to apply different objective functions. In a reverse to things I've said in the past, I don't think we should require the AEC to be implemented as a WS-Agreement template (though one could be contained within it via extensibility) since that imposes some very strong restrictions on how the job is subsequently handled. There probably ought to be provision for the signing of the AEC, since that enables the receiving party to know the identity of the party legally responsible for honouring what will be the basis for a contract. Pricing model must itself be extensible, but lots of useful cases are easily handled through "fixed amount plus <consumption level>*rate". Looking more at https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/ en/1 I see that there are some thoughts on EPS and things more complex than an atomic job. That would require some kind of composite activity description language, the definition of which is outside the scope of the RSS WG. (In many respects, it doesn't alter all that much anyway. It's just a more complex replacement for the JSDL chunk.) Similarly for scheduling parameters or parametric things (well, certainly for sched parms; I don't understand the parametric world quite so well). Anything else I've missed? Donal. [* Or should this be an expression of estimated delay from submission to execution commencement? Sometimes things are best one way, sometimes another. StartTime is good for reservation, StartDelay is good for immediate-execution or conventional batch queues. ]

1 0