December 2004 - cddlm-wg

XML-CDL ver 1.0 final(?) draft
by Jun Tatemura 03 Jan '05

03 Jan '05

Dear team, Please find the attached XML-CDL ver 1.0, (hopefully final, but please check it...) which has incorporated feedback from Stuart and Steve. Thank you very much! Happy Holidays, Jun Tatemura NEC Laboratories America,

2 1

RE: [cddlm] XML-CDL ver 1.0 final(?) draft
by Milojicic, Dejan S 25 Dec '04

25 Dec '04

Dear CDDLM members, We need volunteers who will review the document in a thorough manner. Please let me know who is willing to do so. I would prefer to receive the review wihin next couple of weeks. Our plan is to submit the document to the GGF editor well ahead of the GGF in Korea. This is an important accomplishmet for the CDDLM group. Congratulations to Jun for this milestone! Best regards, Dejan. -----Original Message----- From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Jun Tatemura Sent: Thursday, December 09, 2004 7:05 PM To: 'cddlm-wg(a)ggf.org' Subject: [cddlm] XML-CDL ver 1.0 final(?) draft Dear team, Please find the attached XML-CDL ver 1.0, (hopefully final, but please check it...) which has incorporated feedback from Stuart and Steve. Thank you very much! Happy Holidays, Jun Tatemura NEC Laboratories America,

2 1

RE: [cddlm] SF-based language spec, dilemma whether to go with a recommendations or common practice document track
by Milojicic, Dejan S 14 Dec '04

14 Dec '04

Hi Greg, Thanks for the follow email. I would suggest that we focus the discussion on whether there is a need for a user-friendly (SF-based) in addition to the machine-friendly (XML-based CDL) language for deployment and configuration mgmt rather than whether there is a plan at the moment for a new reference implementation or not. The fact that there is no plan at the moment does not mean that there will not be another reference implementation in the future. Thanks, Dejan. PS Your original email bounced from the CDDLM mailing list because you are not a member, but I include it below. -----Original Message----- From: Gregory Newby [mailto:newby@arsc.edu] Sent: Monday, December 13, 2004 12:11 PM To: Hiro Kishimoto Cc: Milojicic, Dejan S; cddlm-wg(a)ggf.org Subject: Re: [cddlm] SF-based language spec, dilemma whether to go with a recommendations or common practice document track I've suggested this be added to the next GFSG conference call, to gather feedback. I understand the reasoning on both sides. The one factor that might be critical is that the 2nd reference implementation is a requirement for publication as a recommendation (at least, it seems to be under GFD.1). If there are no practical plans for a 2nd reference implementation, that might provide a solid practical reason for going with another category. I hope we'll have more info/feedback from GFSG after tomorrow's call (Tuesday), though it's possible the discussion won't happen until next Tuesday. -- Greg On Sun, Dec 12, 2004 at 04:38:17AM +0900, Hiro Kishimoto wrote: > Hi Dejan, Greg, > > I appreciate your efforts to choose most appropriate category for this > document. I feel regret that "community practice" is not applicable > for the SF-based language spec. > > Dejan: I understand your dilemma, but may I re-state my biggest > concern for this issue? I believe that interoperability of CDDLM > services among multiple implementations should achieved by XML-CDL > language. > > >From the GGF11 session minutes; > > Note that the SF CDL is intended to be more user-friendly / > >user-tractable, while the XML CDL is more standardised, is the > >interop format (i.e. we can translate from various front ends into > >the XML form), but is less user-friendly to use directly. > > Expecting or encouraging the second implementation of SF-CDL > is bad idea, IMHO. For wider adoption of the CDL, implementation of > XML-CDL should be promoted. > > Thus, the CDDLM-WG should publish XML-CDL language spec as > recommendation and SF-CDL language spec NOT as recommendation. > Otherwise, you will mislead the community by sending confused message. > > On the contrary, are there any issues if SF-CDL language spec becomes > informational document? I see no formality problems on informational > document because it is stable, open, and has clear IPR. > > Thanks, > ---- > Hiro Kishimoto > > > > -----Original Message----- > > From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] On > > Behalf Of Milojicic, Dejan S > > Sent: Thursday, December 09, 2004 5:29 AM > > To: cddlm-wg(a)ggf.org > > Cc: Hiro Kishimoto > > Subject: [cddlm] SF-based language spec, dilemma whether to go with > > a recommendations or common practice document track > > > > Hi, > > > > I had an extensive discussion with Greg Newby yesterday morning on > > various topics, but most of the time we spent discussing the > > recommendation that Hiro brought up: "Why is SmartFrog-based > > language specification submitted as a recommendation track?" To be > > even more specific, Hiro recommended that it be resubmitted as a > > "Community Practice" because there will not be two reference > > implementations as a result of the standardization process. I > > checked with two other main drivers (Softricity and NEC) and neither > > indeed planned to pursue a reference implementation of the > > SmartFrog-based language at the time. I also checked with technical > > area directors and their recommendation was not to go with community > > practices because that track is applicable to something that is as > > commonly used as FTP and they have not considered SF to be that > > wide-spread. With all this information on my mind I approached Greg > > to discuss whether we should change submission to experimental or > > even informational track. > > > > Our discussion was quite productive. I updated Greg that SmartFrog > > is in fact in active use by a number of universities, HP, and other > > parties; that it has been open-sourced; and that the submitted spec > > is the most formal specification of the SF language (goes well > > beyond the reference manual published for the language, system, and > > component model). Then we discussed the issue of the target type. At > > the moment the document has reached the point of the recommendation > > track and formally we can take it any way we want. The reasons for > > sticking with the recommendation track are the following: > > > > a) At the moment it is not clear that there will or will not be > > another reference implementation and one already exists. Two other > > partners claimed that they will not create one, but it is possible > > that other parties may create one. We would need to come up with > > another independently implemented SF-language parser that would > > create the same output as the existing one. > > > > b) If the XML-based language interoperates with the SF-based > > language, that would be another proof point (this would require two > > other reference implementations of the XML-based language specs, > > though, but this is also open or the discussion). > > > > c) If after the process, there are no other reference > > implementations, we can still downgrade the document. However, Greg > > and I estimated the value of proceeding the recommendations track at > > the moment. > > > > I welcome comments to this discussion by email or by phone (650 > > 236-2906 office, 650 468-3929 cell). > > > > Hiro, I appreciate your thoughtful suggestion. It was a good > > observation and it took us some time to truly understand all the > > implications. I hope that the final outcome works for you. If not, > > I'd be glad to continue discussion until we find a solution that > > will work for everyone. As you can see from the Greg's note below, > > we also agreed to provide some additional front-matter to the > > document. Finally, I will submit this email to Source Forge to > > capture this discussion. I recommend that any follow-ups also be > > submitted there. > > > > Thanks, > > > > Dejan. > > > > Greg's GridForge input is available at > > https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=827&gr > > oup_ > > id=90 and also copied below: > > > > Comment By: Greg Newby (2004-12-08 11:35:03) Per a telephone > > conversation with Dejan, I now agree this should be recommendation > > track. The authors are essentially providing a CDDLM specification > > which, at the same time, is the most formal specification for > > SmartFrog. There is already one reference implementation, and we > > anticipate there will be more by the end of the GGF's recommendation > > review timeline. > > > > Some additional front matter will be added to provide further > > background on SmartFrog, as well as the nature of existing > > reference implementations and the relationship to CDDLM (as an > > application area for SmartFrog). > > > > > > > !DSPAM:41bb770f215203616814886!

2 1

RE: [cddlm] SF-based language spec, dilemma whether to go with a recommendations or common practice document track
by Milojicic, Dejan S 11 Dec '04

11 Dec '04

Hi Hiro, Thanks for your feedback. Maybe we should talk by phone to more effectively resolve the issue. I am in the office right now (650 236-2906), if you provide your phone number, I'd be glad to call you. I think that that there is a benefit in promoting both as standards and I do not see that they impact each other if both are standards. One is more appropriate as human-oriented, the other one as machine oriented. We are very close to completing the XML-based CDL, it is the next one in queue. Having SF-based as a standard will by no mean influence wider-spread use of XML-based language as a standard. Is this your main concern? Let's talk some more so that we can close on it. Thanks Dejan. > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Saturday, December 11, 2004 11:38 AM > To: Milojicic, Dejan S; cddlm-wg(a)ggf.org > Cc: 'Gregory Newby' > Subject: RE: [cddlm] SF-based language spec, dilemma whether > to go with a recommendations or common practice document track > > Hi Dejan, Greg, > > I appreciate your efforts to choose most appropriate category > for this document. I feel regret that "community practice" is > not applicable for the SF-based language spec. > > Dejan: I understand your dilemma, but may I re-state my > biggest concern for this issue? I believe that > interoperability of CDDLM services among multiple > implementations should achieved by XML-CDL language. > > From the GGF11 session minutes; > > Note that the SF CDL is intended to be more user-friendly / > > user-tractable, while the XML CDL is more standardised, is > the interop > > format (i.e. we can translate from various front ends into the XML > > form), but is less user-friendly to use directly. > > Expecting or encouraging the second implementation of SF-CDL > is bad idea, IMHO. For wider adoption of the CDL, > implementation of XML-CDL should be promoted. > > Thus, the CDDLM-WG should publish XML-CDL language spec as > recommendation and SF-CDL language spec NOT as recommendation. > Otherwise, you will mislead the community by sending confused message. > > On the contrary, are there any issues if SF-CDL language spec > becomes informational document? I see no formality problems > on informational document because it is stable, open, and has > clear IPR. > > Thanks, > ---- > Hiro Kishimoto > > > > -----Original Message----- > > From: owner-cddlm-wg(a)ggf.org > [mailto:owner-cddlm-wg@ggf.org] On Behalf > > Of Milojicic, Dejan S > > Sent: Thursday, December 09, 2004 5:29 AM > > To: cddlm-wg(a)ggf.org > > Cc: Hiro Kishimoto > > Subject: [cddlm] SF-based language spec, dilemma whether to > go with a > > recommendations or common practice document track > > > > Hi, > > > > I had an extensive discussion with Greg Newby yesterday morning on > > various topics, but most of the time we spent discussing the > > recommendation that Hiro brought up: "Why is > SmartFrog-based language > > specification submitted as a recommendation track?" To be even more > > specific, Hiro recommended that it be resubmitted as a "Community > > Practice" because there will not be two reference > implementations as a > > result of the standardization process. I checked with two > other main > > drivers (Softricity and NEC) and neither indeed planned to pursue a > > reference implementation of the SmartFrog-based language at > the time. > > I also checked with technical area directors and their > recommendation > > was not to go with community practices because that track is > > applicable to something that is as commonly used as FTP and > they have > > not considered SF to be that wide-spread. With all this > information on > > my mind I approached Greg to discuss whether we should change > > submission to experimental or even informational track. > > > > Our discussion was quite productive. I updated Greg that > SmartFrog is > > in fact in active use by a number of universities, HP, and other > > parties; that it has been open-sourced; and that the > submitted spec is > > the most formal specification of the SF language (goes well > beyond the > > reference manual published for the language, system, and component > > model). Then we discussed the issue of the target type. At > the moment > > the document has reached the point of the recommendation track and > > formally we can take it any way we want. The reasons for > sticking with > > the recommendation track are the following: > > > > a) At the moment it is not clear that there will or will not be > > another reference implementation and one already exists. Two other > > partners claimed that they will not create one, but it is possible > > that other parties may create one. We would need to come up with > > another independently implemented SF-language parser that > would create > > the same output as the existing one. > > > > b) If the XML-based language interoperates with the > SF-based language, > > that would be another proof point (this would require two other > > reference implementations of the XML-based language specs, > though, but > > this is also open or the discussion). > > > > c) If after the process, there are no other reference > implementations, > > we can still downgrade the document. However, Greg and I > estimated the > > value of proceeding the recommendations track at the moment. > > > > I welcome comments to this discussion by email or by phone (650 > > 236-2906 office, 650 468-3929 cell). > > > > Hiro, I appreciate your thoughtful suggestion. It was a good > > observation and it took us some time to truly understand all the > > implications. I hope that the final outcome works for you. > If not, I'd > > be glad to continue discussion until we find a solution > that will work > > for everyone. As you can see from the Greg's note below, we also > > agreed to provide some additional front-matter to the document. > > Finally, I will submit this email to Source Forge to capture this > > discussion. I recommend that any follow-ups also be submitted there. > > > > Thanks, > > > > Dejan. > > > > Greg's GridForge input is available at > > > https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=827&grou > > p_ > > id=90 and also copied below: > > > > Comment By: Greg Newby (2004-12-08 11:35:03) Per a telephone > > conversation with Dejan, I now agree this should be recommendation > > track. The authors are essentially providing a CDDLM specification > > which, at the same time, is the most formal specification > for SmartFrog. > > There is already one reference implementation, and we > anticipate there > > will be more by the end of the GGF's recommendation review timeline. > > > > Some additional front matter will be added to provide further > > background on SmartFrog, as well as the nature of existing > reference > > implementations and the relationship to CDDLM (as an > application area > > for SmartFrog). > > > > >

1 0

SF-based language spec, dilemma whether to go with a recommendations or common practice document track
by Milojicic, Dejan S 11 Dec '04

11 Dec '04

Hi, I had an extensive discussion with Greg Newby yesterday morning on various topics, but most of the time we spent discussing the recommendation that Hiro brought up: "Why is SmartFrog-based language specification submitted as a recommendation track?" To be even more specific, Hiro recommended that it be resubmitted as a "Community Practice" because there will not be two reference implementations as a result of the standardization process. I checked with two other main drivers (Softricity and NEC) and neither indeed planned to pursue a reference implementation of the SmartFrog-based language at the time. I also checked with technical area directors and their recommendation was not to go with community practices because that track is applicable to something that is as commonly used as FTP and they have not considered SF to be that wide-spread. With all this information on my mind I approached Greg to discuss whether we should change submission to experimental or even informational track. Our discussion was quite productive. I updated Greg that SmartFrog is in fact in active use by a number of universities, HP, and other parties; that it has been open-sourced; and that the submitted spec is the most formal specification of the SF language (goes well beyond the reference manual published for the language, system, and component model). Then we discussed the issue of the target type. At the moment the document has reached the point of the recommendation track and formally we can take it any way we want. The reasons for sticking with the recommendation track are the following: a) At the moment it is not clear that there will or will not be another reference implementation and one already exists. Two other partners claimed that they will not create one, but it is possible that other parties may create one. We would need to come up with another independently implemented SF-language parser that would create the same output as the existing one. b) If the XML-based language interoperates with the SF-based language, that would be another proof point (this would require two other reference implementations of the XML-based language specs, though, but this is also open or the discussion). c) If after the process, there are no other reference implementations, we can still downgrade the document. However, Greg and I estimated the value of proceeding the recommendations track at the moment. I welcome comments to this discussion by email or by phone (650 236-2906 office, 650 468-3929 cell). Hiro, I appreciate your thoughtful suggestion. It was a good observation and it took us some time to truly understand all the implications. I hope that the final outcome works for you. If not, I'd be glad to continue discussion until we find a solution that will work for everyone. As you can see from the Greg's note below, we also agreed to provide some additional front-matter to the document. Finally, I will submit this email to Source Forge to capture this discussion. I recommend that any follow-ups also be submitted there. Thanks, Dejan. Greg's GridForge input is available at https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=827&group_ id=90 and also copied below: Comment By: Greg Newby (2004-12-08 11:35:03) Per a telephone conversation with Dejan, I now agree this should be recommendation track. The authors are essentially providing a CDDLM specification which, at the same time, is the most formal specification for SmartFrog. There is already one reference implementation, and we anticipate there will be more by the end of the GGF's recommendation review timeline. Some additional front matter will be added to provide further background on SmartFrog, as well as the nature of existing reference implementations and the relationship to CDDLM (as an application area for SmartFrog).

2 1

FW: gf-chairs GGF13 News
by Milojicic, Dejan S 08 Dec '04

08 Dec '04

Hi Team, Any ideas on who will be or will not be attending. Please let me know as soon as you know. Thanks, Dejan. ________________________________ From: owner-gf-chairs(a)ggf.org [mailto:owner-gf-chairs@ggf.org] On Behalf Of Stacey Giannese Sent: Wednesday, December 08, 2004 7:43 AM To: gf-chairs(a)ggf.org Cc: office(a)ggf.org Subject: gf-chairs GGF13 News Importance: High GGF Chairs- It's that time again for me to find out which of your groups plan on attending GGF13 in Korea and which ones do not. Leaders in the Asia-Pacific region have estimated that we can expect around 500 participants just from their region. Many of these will be newcomers while others will be veterans in grid computing, both from research and from industry. In either case, Seoul is a great opportunity for your group to extend its influence and its participation. Furthermore, GGF leadership is planning to communicate several of the outcomes of the strategic activities that are being completed during the 4th quarter. It will be a meeting you do not want to miss! GGF leadership also realizes that for some of you, traveling to Seoul is a huge commitment of time and resource for both you and your group members. This is one of many challenges of being a Global community. The secretariat is developing a FAQ sheet that will not only supply you with costs of attending (airfare, lodging, registration fees, etc.) but will also give a snapshot of some of the activities you can expect during the event. We hope you can use this information to educate your group members on the value of participating in GGF13. GGF needs your strong leadership in helping get your group volunteers to be part of what Seoul will have to offer your group. Please take some time today to initiate with your group concerning participation in the Seoul meeting. I would like to have some idea of which groups are planning to meet in Seoul (and which may not) before the end of the year, so please respond promptly. Keep an eye on ggf.org next week for additional information about the event, including the opening of advanced registration. Please send me email back with the name of your group and if you plan on holding a working session or not at GGF13. Thank you, Stacey Giannese Manager of Community Activities Global Grid Forum (Phone) 630-252-6444 (Cell) 708-935-2951 (Fax) 630-252-4466

1 0

Deployment API draft
by Steve Loughran 07 Dec '04

07 Dec '04

This is an early draft of the deployment API; feedback welcome Feedback on the formatting (esp. those 4 column tables) not needed, as I know of them. This doc is actually autogenerated from docbook, so if openjade cant handle the tables, we can switch to something else. I'm also planning on auto-including the accompanying XML schemas and constants files through the wonders of XSL. I worry about how to do a design that is fault tolerant without requiring that every node supports inbound WSRF calls and then instianting the application EPR on the same node as the app itself. The design I have allows the application EPR to be instantiated on a separate server, which leaves you with the problem "how do you rebind to the app if the front end server you are using goes belly up". I note that Globus4 has the same design, but haven't seen how they solve the fault tolerance problem. For the curious, the underlying issue is that a wsa:EPR contains the URL of the endpoint for the SOAP call. If the server goes away, the EPR is invalid. WSRF hints that WS-Policy can enable renewal, but doesnt cover it. Maybe they looked at the CORBA oid tracking documents and got scared off. I 36 hours from going off on holiday/vacation till January 2. No laptop; no email. This deployment API is in SCM on the deployment.sf.net project; if people send me their sourceforge usernames before 2004-12-08Z1800 I will give them access to the repository to add this, the XSD/WSDL for the other specs, etc, etc. -Steve -steve

1 0

FW: [sched-chairs] GGF Sched Area - Chairs Telecon Notes, 7 Dec 2004
by Milojicic, Dejan S 07 Dec '04

07 Dec '04

-----Original Message----- From: owner-sched-chairs(a)ggf.org [mailto:owner-sched-chairs@ggf.org] On Behalf Of Bill Nitzberg Sent: Tuesday, December 07, 2004 8:18 AM To: sched-chairs(a)ggf.org Subject: [sched-chairs] GGF Sched Area - Chairs Telecon Notes, 7 Dec 2004 GGF Sched Area - Chairs Telecon Notes, 7 Dec 2004 ================================================== Attendees (with '*'s): ---------------------- *Bill Nitzberg, Area Director *Stephen Pickles, Area Director Hrabri Rajic, DRMAA-WG Andreas Haas, DRMAA-WG Wolfgang Ziegler, GRAAP-WG Jim Pruyne, GRAAP-WG Volker Sander, GRAAP-WG Jon MacLaren, GESA-WG Steven Newhouse, GESA-WG Steven Newhouse, RUS-WG Bill Horn, RUS-WG Rebekah Metz, UR-WG *Stephen McGough, JSDL-WG *Ali Anjomshoaa, JSDL-WG Darren Pulsipher, JSDL-WG *Dejan Milojicic, CDDLM-WG Takashi Kojo, CDDLM-WG +Ramin Yahyapour, GSA-RG +Uwe Schwiegelshohn, GSA-RG Jarek Nabrzyski, GSA-RG Ewa Deelman, WFM-RG Jim Blythe, WFM-RG Miron Livny, WRM-RG ('+' == could not attend, but emailed status report) Notes ----- Upcoming GGFs: GGF13 14-17 Mar 2005 Seoul, Korea GGF14 ~Jun 2005 Chicago, USA (Tentative) GGF15 ~Oct 2005 (Tentative) Status ------ CDDLM-WG -- Dejan attended meeting with companies who are planning a new Standard in this general area--this effort is still in it's early stages. Hoping to have 2 documents formally completed in the next week, and submitting the 3rd real soon. DRMAA-WG -- nobody on call... GESA-WG -- (hibernating...) GRAAP-WG -- nobody on call... GSA-RG -- Emailed status: No not change since the last telecom; Preparing the first draft document to be sent around on the list. JSDL-WG -- Making good progress on hammering out the document; intent is to have it in public review during the next GGF. RUS-WG -- Although the chairs have not reported anything in quite some time, and there is no activity on the email list; John Ainsworth at Manchester has been working on an implementation of something RUS-like. UR-WG -- nobody on call... WFM-RG -- nobody on call... Upcoming Telecons ----------------- Every other Tuesday (skipping holiday weeks) 8a US Pacific (see www.worldtime.com to convert) Usually very short (less than 15 minutes long) Dial-in: 1-800-387-6159 & 1-303-248-0173 Conference ID: 7144404 Upcoming Telecons / or status reports due before: 21 Dec 2004 4 Jan 2004 18 Jan 2004 1 Feb 2004 15 Feb 2004 1 Mar 2004 If you can't make a telecon, please send us a note. If no chairs from your group will make a telecon, please also send a status update to everyone on the list (sched-chairs(a)gridforum.org) As always, please keep things moving forward --- if you need help setting up a separate mailing list or teleconference calls for your group, etc., don't hesitate to ask us. Thanks all! - bill & Stephen GGF SRM Area Directors

1 0

Policy object decision matrix
by Stuart Schaefer 02 Dec '04

02 Dec '04

Team, Enclosed is the policy object document with a matrix for making a decision. I have filled in the matrix with my impressions from testing. Ideally, we will make a decision as a group based on recommendations and consensus on these factors. If you agree or disagree with the assessments please modify the columns below and send me your feedback or lets discuss on the list. My current recommendation to the team is to implement a BPEL like syntax with some similar constructs, but not support the whole BPEL namespace. In doing this, the keywords will be the same, but will be a part of the CDDLM namespaces. Additionally, I would support policy objects instead of compound objects, as BPEL does not require a strict parent-child hierarchy. Thanks, Stuart

1 0

proposed changes to deploy api
by Steve Loughran 02 Dec '04

02 Dec '04

Hi all, this is my proposed rework of the deploy API. I will revise it one more time (with more detail on the operations), but this is the plan. If you want more detail, imagine the operations of the GGF12 deployment API have been split and the app identifier is now the "application endpoint reference". Some new features -app 'ID' is required to be very unique -can listen to a portal EPR for events of new apps being created. Once an app is created, you can listen to its own lifecycle events. I have left WS-Notification as a SHOULD, though I think it ought to be a MUST. I dont like its complexity, and think implementations may want to not support it, but it would also be nice if everything did. comments welcome, esp in the next few days. -steve

1 0