- ogsa-wg - lists.ogf.org

paper available: "Alternative Software Stacks for OGSA-based Grids"
by Marty Humphrey 27 Apr '05

27 Apr '05

Hi, We have just written what I hope will be a productive contribution to the efforts of this group. It's essentially our experiences implementing WS-Transfer and using a publicly-available WS-Eventing, and comparing it to WSRF and WSRF.NET. As we all know, it's a difficult/controversial subject, but we're hoping we can help the community with a concrete implementation and evaluation. Title: Alternative Software Stacks for OGSA-based Grids Abstract: The Open Grid Services Architecture (OGSA) has been a major step forward for Grid Computing, but its de facto reliance on the Web Services Resource Framework (WSRF) and WS-Notification have left some in the community questioning if the Grid software and protocols have become too complex. In this paper, we consider the feasibility of an "alternative" software stack, based on WS-Transfer and WS-Eventing. We compare and evaluate WSRF/WS-Notification vs. WS-Transfer/WS-Eventing, first via a "hello world" service and then via a more complete Grid scenario for remote execution called "Grid-in-a-Box". By qualitatively and quantitatively evaluating each approach, we find that subtle differences exist (e.g., the naming of resources, the creation of resources) but they are overwhelmingly equivalent in their functionality and implied performance. Overall, this paper uniquely shows that there could be alternative software stacks for OGSA-based Grids. Full info: M. Humphrey, G. Wasson, Y. Kiryakov, S-M. Park, D. Del Vecchio, N. Beekwilder, and J. Gray. Alternative Software Stacks for OGSA-based Grids. University of Virginia Department of Computer Science Tech Report CS-2005-06. April 2005. Available: http://www.cs.virginia.edu/~humphrey/papers/AlternativeSoftwareStacksOGSA.pd f We look forward to any comments and discussion! Regards, Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

1 0

Teleconference minutes - 25 April 2005
by Andreas Savva 27 Apr '05

27 Apr '05

Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050425/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 25 April 2005 =================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Dave Berry (NeSC) [first 15 minutes] Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * April 20 minutes approved with no changes * May F2F update - Choosing the same hotel is a good idea to make it more convenient to meet off-hours. Internet connectiviy may not be an issue since it should be ok during the day at IC. - The Rydges hotel on Gloucester Rd was one choice. Andrew will follow up. Action: Andrew to mail out the hotel recommendation * EMS related work - How to follow up with the people (Germany, Naregi, etc) who volunteered to do RSS (CSG) work. It is not clear if anyone from the OGSA-WG has the time to commit to follow up on this effort at the moment. Some of them are coming to the May F2F but it may be a good idea to talk to them in advance. Action: Hiro and Andrew to coordinate and arrange a call with the people who volunteered to start up the RSS group. Preferably arrange it this week and in any case before the F2F. * Profile definition document review (v1.5) - Tracker exists but no issues registered yet. Action: Tom to check and upload any unresolved issues. - No comments on the "Status" or "Abstract" sections ** Section 1 (On a side-note it was mentioned that the DMTF has decided to use ISO terminology rather than RFC 2119. The downside is that there is more variation in the use of words. For example, many different flavors of MUST.) ** Section 2 - [2.1] - Delete 'similar to' as it does not add anything. - 'claim attachment mechanism' : Does WS-I have 'many' such mechanisms and if so which is being referred to here? - Tom confirmed that there is only 1 such document (WSDL 1.1 claims, UDDI claims, ...). Action: Tom to provide a proper reference to the WS-I claims document. ** Section 3.2 *** Status - 'consortium of one or more': Does 'one' make sense in this context? The idea is not to preclude specs coming from one company. This statement does need to be revised for clarity, however. - Is 'consortium' the right word here? And should a consortium category be listed or not? Examples of consortia: DAT collaborative, EGA, etc. Consensus that it is worth leaving in 'consortium' and making the distinction that a specification from one company would mean a 'draft' categorization. Proposal that to make things clearer examples should be added for each category defined. In the order given in the document the following examples were mentioned for each category: - WS-Security - WSDL 1.1 - WSRF, WSN - EGA or perhaps SNIA specs: SMIS, EGA reference models etc - Evolving standard comment in document: Agree with it; Delete. *** Adoption levels - Need to point out that 'Adoption' levels are 'additive': the next level builds on top of the lower level definition; no exceptions. - Consensus that definitions are to some extent subjective (e.g., what defines a community?) and that there is no way to get over this subjectivity completely. The classification is intended as a guideline and the actual decision will be done by a group of people (so judgement calls and consensus will be needed). Agreed to leave definition as is. - 'Ubiquitous' statement: - 'but' is really an 'and'. - Reached rough consensus on what is 'ubiquitous' (e.g., html, http, tcp/ip) but not sure how to wordsmith the definition to bring out the desired meaning. Action: Tom will follow up on ubiquitous definition on the list. ** Section 3.4: Restrictions Agreed to leave intentionally vague. Tom will review text again. ** Section 4: Profile type distinction - The decision on profile document type depends on the state of the referenced specs. It is not clear whether the evaluation of the state of the referenced specs should be made strictly at submission time or whether there should be more 'freedom'; i.e., allow a profile to enter the recommendation track based on the expectation that the referenced specs will be at the right state when publication time comes. The consensus on the call was to add wording that the criteria should be satisfied at submission time. This decision was made on the assumption that the GGF process does not permit revisions of a 'proposed recommendation' document and that since a change in the referenced specs would result in such a revision the document would be invalidated anyway. The only concern here is that of extra serialization and backtracking for what may be only minor changes. - There seems to be no problem with submitting a document on one track and also (perhaps partially overlapping) re-submitting it on another. (A document could also be withdrawn from one track in this case). The motivating use case here is a profile being submitted on the information track but due to rapid changes in the states of the specification it uses becoming eligible for the recommendation track. In this case the process would start again; switching tracks without restarting the process does not look like good practice. - Agreed to drop 'evolving' from proposed recommendation - Agreed to delete existing comments on informational profiles - Tom will look at other options for putting profile documents in a 'lighter' publication track without going through the requirements of the recommendation track. (Community, experimental were mentioned.) * JSDL introduction Overview of parts of JSDL relative to draft 16. (Draft 17 is out and there is work to produce draft 18) Same presentation as that given to the DMTF Utility WG Focus is describing requirements at submission. But submission API and results of submission are out of scope. Also no elements that describe post-submission concepts, e.g., job id generated by submission system. This is done simply for scoping purposes. Spec provides a number of extensibility points and other information (e.g., job id) can be added. Normative extensions for the known gaps may be produced at a later time. [Slide 6] JSDL version 1.0 only attempts to cover a part of what is needed. More work, possibly by other groups is expected to cover this area. For example, scheduling, workflow, etc. Abstract-refined-incarnated/grounded: This model is supported but not required by JSDL. Submitter can write a document at the desired level. (EMS big-picture implies this kind of refinement too so JSDL is aligned with that approach.) Data staging is a common requirement (not 'fundamental' as the slide mentions). The copy and completion semantics are built in but it may not be necessary to copy over existing files (overwrite or not). Some more refined cases may be covered using the filesystem attribute. It was not clear how RNS work could be used here. Need more discussion offline. JSDL examples slides: - slide 11: an example of adding a job id extension element - slide 12: user section has been deleted in the latest pre-draft. - slide 13: Application and its extensibility (POSIXApplication) - Why not define as application types and draw out commonalities? - Application types were defined in an earlier draft. One problem is that there was not that much commonality between the different types: e.g., a posix application versus a WS invocation or a SQL call. Common parts seemed to be just name and version. - slide 16: Resource definition does not offer sufficient abstraction. (Also the order that is used to present the elements in the slide is problematical.) - The starting point (and main use cases) is existing DRMs. More generalization may be needed but it is also necessary to make sure the existing systems and use cases are covered. - It is possible to completely ignore the jsdl sub-resource elements (all are optional) and use a different resource description if that is more appropriate and if another standard comes along. - <exact> and <lowerboundedrange> are part of a rangevalue definition. - slide 17: In certain cases, values are also defined in addition to elements: Processor architectures and OS types are such examples. The values are based on CIM defined ones. - slide 18: the source or target urls also define the protocol that should be used for the transfer, e.g., http, rsync, and so on. How far along is the group? The goal is to submit the spec to the GGF Editor before GGF14.

1 0

OGSA Roadmap doc v5 uploaded
by Treadwell, Jem 26 Apr '05

26 Apr '05

Hi, I've uploaded v5 of the OGSA Roadmap document for review at Wednesday's meeting - you can find it at: http://tinyurl.com/ccsza. These are mostly my usual nitpick editing changes, and there are a lot of them, so given that the document is quite short it's probably easiest to read it with a fresh eye than try to follow the changes. 1) Although the changes are significant, I didn't intentionally change any substance, except as noted below - just reworded things in some places. 2) In 2.2, OGSA Profiles, there seemed to be a problem with the flow - it went back mid-section and described again what OGSA Profiles are, but in a different way. So I reorganized it to what I believe is a logical flow, by moving paragraphs and, in some cases, parts of sentences around (e.g. the first sentence was moved from the middle of the section). Other than one para (the one that begins "In addition...") I don't believe I changed the wording much in this section - the changes are all just cut and paste, and I haven't deleted anything. 3) In 2.4, OGSA Branding, I had some problems with the original wording, and reworded it to what I *think* it was intended to say. I may have got this wrong, so it will need careful review! But I'm aware that Hiro was passing this section to the GFSG, so we may want to reject these changes and leave it as is until we have agreement. I've also reviewed the Tracker items that Hiro had set to "fixed," and closed all but one of them. - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

Proposed agenda for April 27th call
by Hiro Kishimoto 26 Apr '05

26 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 27th Wednesday from 5pm to 7pm (CDT). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0427 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 Agenda bashing 2) OGSA roadmap document review (60 min) Jem is now working on the document. Tracker for the roadmap. https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… Spec schedule template proposal. https://forge.gridforum.org/projects/ogsa-wg/document/spec-schedule-templat… 1 3) Wrap up (10 min) AOB May 2 (5-7pm CDT) Profile definition discussion May 4 (5-7pm CDT) <TBD> See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

spec schedule template for roadmap document
by Hiro Kishimoto 26 Apr '05

26 Apr '05

Hi all, Attached is a proposed schedule template for (1) OGSA informational document, (2) OGSA normative interface, (3) OGSA profile, and (4) OGSA informational profile. Thank you Andreas and Mark for reviewing early draft of this template. Please have a look and give your feedback at this Wednesday call. Thanks, ---- Hiro Kishimoto

1 0

OGSA-D mailing list (for new Data Architecture working group)
by Hiro Kishimoto 26 Apr '05

26 Apr '05

Hi all, Dave Berry's email bounced since it includes word "sub scribe" ---- Hiro Kishimoto Subject: OGSA-D mailing list (for new Data Architecture working group) Date: Mon, 25 Apr 2005 18:02:10 +0100 From: "Dave Berry" <daveb(a)nesc.ac.uk> To: "ogsa-wg" <ogsa-wg(a)gridforum.org> Dear all, The OGSA-D working group has been approved and a new mailing list has been created. To sub-scribe to the list, please email majordomo(a)ggf.org with the following line in the TEXT of the message (without double quotes): "subscribe ogsa-d-wg" Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

OGSA-BES charter
by Andrew Grimshaw 25 Apr '05

25 Apr '05

All, The attached was sent to the GFSG for approval on Sunday. It is the document we discussed last Thursday. An agenda for this Thursday's call will follow tomorrow. Andrew

1 0

Data: forthcoming telcons & proposed agenda for this week
by Dave Berry 25 Apr '05

25 Apr '05

Dear all, OGSA-D telcons will take place on Wednesdays, starting on this Wednesday 27th April, at 8:00am PDT / 11:00am EDT / 4:00pm BST / 5:00pm CEST. We intend these calls to include technical discussions. PIN for all calls: 632 065 UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 The following is a provisional list of topics by week until the F2F meeting on May 26th. There are probably also issues that cut across these topics, which we will track and address. Apr 27 - Replication May 4 - Data access May 11 - Data storage May 18 - Document review & plan for F2F Here is a provisional agenda for this week. 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval of last design team call (attached) Agenda bashing 2) Action report (5 min) - Dave to mail contributors re common section structure. [Done] - Dave to add version number to header and accept current changes. [Done] - Dave to ask NextGrid/InfoD about transfer to non-service endpoints. [Done] - Allen to get in touch with Steve Crumb about setting up the WG. [Done] - Dave to mail F2F meeting info to relevant people who aren't on the OGSA WG mailing list. [Done] - Dave to propose a presentation of data area work to the main OGSA F2F. [Done] - Dave to ping Malcolm regarding data transfer discussions at the F2F. [Done] - Dave to mail contributors to see which weeks they can attend, with an eye to setting agendas. [Done] 3) WG plans (10 min) Use of trackers Topics for future meetings. 4) F2F planning (10 min) - Date: May 26th. Place: London. - Discussion of agenda. 5) Technical content (25 min) - Update from contributors - Discussion of issues arising 6) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Consultants to Resource Selection Services-WG wanted
by Mathias Dalheimer 25 Apr '05

25 Apr '05

Hi! I am currently working on the charter for the OGSA-RSS group. This group will deal with the Resource Selection Services as specified by the OGSA-WG. I am looking for people from OGSA that are interested in the Resource Selection Services. Since OGSA and OGSA-RSS are closely related, I would appreciate if someone can commit himself to act as a consultant. We've set up a wiki for our charter discussion: http://h63759.serverkompetenz.net:8668//space/Documents/charter I will also participate in the May F2F meeting in London on Sunday and Monday. In case of any questions, please send me an email. Regards, Mathias -- ______________________________________________________________________ Dipl.-Wirtsch. Ing. (Inform.) Mathias Dalheimer Fraunhofer Institut fuer Techno- und Wirtschaftsmathematik (ITWM) Europaallee 10 67657 Kaiserslautern, Germany Phone +49(0)631/303-1827 | mailto:dalheimer@itwm.fraunhofer.de Fax +49(0)631/303-1877 | ______________________________________________________________________

1 0

SAGA use cases and strawman API
by Christopher Smith 22 Apr '05

22 Apr '05

Hey all, In case you missed these announcements. -- Chris

1 0

Proposed agenda for April 25th call
by Hiro Kishimoto 22 Apr '05

22 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 25th Monday from 5pm to 7pm (CDT). 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: 0425 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 (April 20th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050420 May F2F meeting update (if any) Agenda bashing 2) OGSA profile definition review (60 min) The latest draft (v1.5) https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profil… plate/en/4 3) JSDL overview presentation (30 min) The latest JSDL spec: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… JSDL Introduction presentation: https://forge.gridforum.org/projects/jsdl-wg/document/JSDL-Introduction/en/ 4) Wrap up (10 min) AOB April 27 (noon-2pm CDT) Basic Profile April 27 (5-7pm CDT) Roadmap discussion First week of the May is Japanese holidays (Golden Week). See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule I've attached update schedule as of Today. ---- Hiro Kishimoto

1 0

Reminder: OGSA-BES first teleconference
by Andrew Grimshaw 21 Apr '05

21 Apr '05

All, The first BES teleconference is scheduled for this Thursday, April 21,(US) at 10 AM eastern. The dial in number (thanks IBM) is: Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net <http://ogsa.glance.net/> Session key: 0421 The agenda is: Agenda bashing Charter finalization: Scope issues: 1) Legacy only or include "service instantiation" 2) Definition of "job" interface - or leave it to another WG Approval of modification "to communicate and interact regularly with the OGSA-WG". Discussion of future telecon's, e.g., End first agenda Because of the importance of JSDL to our discussions I have included links to the relevant information. JSDL Specification draft information. https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/en / Also here's the link to the JSDL Introduction presentation: https://forge.gridforum.org/projects/jsdl-wg/document/JSDL-Introduction/en/ Issues for discussion in the following telecon's 1) Agreement or not agreement 2) WSRF or WSRF-neutral 3) Metadata/attributes of containers 4) Interface of the service container 5) Interactions with JSDL - terms and semantics of terms 6) I/O specifications and JSDL terms 7) Service containers as manageable entities Please send us your thoughts on other topics. Andrew Grimshaw Darren Pulsipher Steven Newhouse _____ From: Andrew Grimshaw [mailto:grimshaw@cs.virginia.edu] Sent: Tuesday, April 19, 2005 4:09 PM To: 'ogsa-wg(a)ggf.org'; 'OGSA-BES-bof(a)ggf.org' Subject: OGSA-BES first teleconference All, The first BES teleconference is scheduled for this Thursday, April 21,(US) at 10 AM eastern. The dial in number (thanks IBM) is: Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 The agenda is: Agenda bashing Charter finalization: Scope issues: 3) Legacy only or include "service instantiation" 4) Definition of "job" interface - or leave it to another WG Discussion of future telecon's, e.g., End first agenda Issues for discussion in the following telecon's 8) Agreement or not agreement 9) WSRF or WSRF-neutral 10) Metadata/attributes of containers 11) Interface of the service container 12) Interactions with JSDL - terms and semantics of terms 13) I/O specifications and JSDL terms 14) Service containers as manageable entities Please send us your thoughts on other topics. Andrew Grimshaw Darren Pulsipher Steven Newhouse

3 2

JSDL spec link
by Andreas Savva 21 Apr '05

21 Apr '05

During today's call I was asked to send out the url to the current JSDL spec. This will (always) get you the latest snapshot: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… Also here's the link to the JSDL Introduction presentation that we'll be using for next Monday's call: https://forge.gridforum.org/projects/jsdl-wg/document/JSDL-Introduction/en/ -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Teleconference minutes - 20 April 2005
by Andreas Savva 21 Apr '05

21 Apr '05

Minutes attached. As gridforge is not responding these are not uploaded yet. -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 20 April 2005 =================================== * Participants Pete Ziu (Northrop Grumman) Jay Unger (IBM) Jem Treadwell (HP) Andreas Savva (Fujitsu) Mark Morgan (UVa) Tom Maguire (IBM) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * Minutes of April 18 approved with no changes * May F2F update - Waiting for room reservation at IC - Many people have already said that they will be attending - More than 13 for the main meeting (Mon & Tue) - More than 11 for the Data (Thu) - Any hotel suggestions? The url sent last week has a lot of information (too many choices) - Andrew stayed at the "John Howard Hotel" last time. It was nice but there was no network connectivity. - Arranging to stay in the same hotel sounds like a good idea but there was no proposal on how to go about arranging it. - Arriving at Heathrow vs Gatwick: Probably no big difference. Heathrow might be more convenient (Heathrow Express). * Basic Profile update - Calls have been very productive; very good progress. - Many but not all artifacts fixed/closed. - Trying to close the rest this week or perhaps early next week. - Planning one more teleconf next week, same day, at the 1-3pm timeslot - There are 11 artifacts resolved: revisions not completed yet. - There are some 'Pending' state issues that need discussion. Have to get specific people on the call to make sure a proper discussion is done. - Remaining are 'fixed'; need people to check them and close them. - How to check 'fixed' better? - Ask people who will review doc to check? - From the BP team's perspective, 'fixed' may be good enough. The OGSA-WG will have to check the document anyway before going through with the submission. It might be a good place to do the 'Closed' transition then. Action: Tom, to help reviewers confirm changes, will cross-link each issue to the specific requirement statement using the 'Category' field. - Overall the document is in good state for GGF14 submission. Action: Tom to send a copy of the BP draft to Marty Humphrey and ask him to review it. * BES BoF update - Scheduled the first call tomorrow morning. Mail has been sent to both the BES BoF list and OGSA-WG list. - There is a revised agenda based on received feedback - Charter bashing is main topic (Is a Naming call being planned? Not yet. Andrew is in the process of contacting the people he has in mind for co-chairs. There is no GFSG tracker artifact for this proposed WG but GGF (Steve C) is aware of it.) * Roadmap document review - Hiro has submitted the issues from the last review (19 in total) Action: Andreas to set up Roadmap tracker in the same way as the BP tracker (same values for status) >(Done) - Jem volunteered to review the document afterwards and verify that the actions are done. - Reviewed by tracker item - "4.3 EM profile" comment: Agree with comment on the section title. Current contents are consistent. - For each section describing a Profile we should include a list of what the "Profile Template" document requires of each profile. The list will offer an indication on what the status of each profile is likely to be. - Agreed to add such a sub-section to each profile section in the Roadmap. - See "Appendix A" of the Profile Template for an example. - Does it address Dave's comment 1374? Probably but need to check. Action: Jay to make a better representation of the table in Appendix A of the Profile Template document. Action: Tom to update the Profile Template with the new version of the table. Action: Hiro to include a sub-section with such a table for each profile in the Roadmap document. - Section 4.3: Statement starting "If appropriate implementation ..." does not add anything. The real issue is the need for standards on resource modelling and resource access. And how resources are modelled in OGSA. This requirement should be stated to clarify why WSDM and WS-CIM are mentioned as possible candidates here. - (The above point triggered a long BES-related side-discussion and how things should tie together. WSRF vs other mechanisms, JSDL, does BES need to care about the resource modelling and how much does, etc. Andrew will do a short write-up to clarify the issues for this section and for BES and send it out for comment.) Action: Andreas will send out the URL to the latest JSDL specification and to a JSDL Introduction presentation. Action: Hiro will schedule the JSDL introduction presentation for next Monday's call (to start after the first hour mark). - Title revision: moved 'version 1.0' for clarity. - Section 1: forward reference to 'profiles' fixed. - Mark Linesch's comment on section 2.0: Decided to bring back old text and add the new text as extra explanation. - Footnote: deleted as obsolete. - Title of section 2: revised. - Conformance testing or tools: Not clear if GGF should be doing this. Something to discuss in the future perhaps; leave out for now. - "OGSA branding" controlled by GFSG: This section will be updated with the GFSG statement when it becomes available. Hiro has sent a draft of this section as a separate document to the GFSG. GGF is planning to obtain a TM and Service mark for OGSA. - Branding at different levels: WG and Document names - Compilant software and who can claim OGSA implementations - Decided to leave the text as a placeholder for now (might need some revision to change the tone) - Adjourned; the review to continue next week. * Next week calls - Monday: Profile template - Wednesday: Roadmap document

1 0

OGSA-WG May F2F meeting inquiry
by Hiro Kishimoto 21 Apr '05

21 Apr '05

Hi all, We've agreed to have May OGSA-WG F2F as follows; Date: May 23 (Mon) and 24 (Tue) for general meeting May 22 (Sun) for optional BES-WG meeting May 26 (Thu) for optional OGSA-data WG and ByteIO-WG meeting Venue: Imperial College London Please let me know your availability once again through the follow URL: http://www.zoomerang.com/members/survey-management.zgi?ID=L22BTBVPACJ4# or http://tinyurl.com/9y5po Thanks in advance. ---- Hiro Kishimoto

1 3

[ogsa-wg | Basic Profile - 1392] Referenced spec status and adoption table
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1392 Submitted by: Tom Maguire Submitted date: 2005-04-20 16:04:03 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1392&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1392&group_id…) Summary: Referenced spec status and adoption table Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1392 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Tom Maguire Last Modified: 2005-04-20 16:04:03 Submitted By: Tom Maguire Submit Date: 2005-04-20 16:04:03 Assigned To: Tom Maguire File(s): <None> Description: as per profile template. add table to appendix. View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Minutes of OGSA BP telecon -- April 20, 2005
by Srinivasan, Latha 20 Apr '05

20 Apr '05

Hi, I've uploaded the minutes of the OGSA BP call held today, to GridForge. -Latha

1 0

[AI:1368][AI:1369] additional descriptions for the keyinfo exchange
by Takuya Mori 20 Apr '05

20 Apr '05

Dear all, The following is my draft for the additional descriptions for the keyinfo exchange. This is for the action item 1368 and 1369 of the basic profile tracker. Regard, Takuya ---- 8.1.6 Message Level Security Section 8.1.5 defines the usage of XML Encryption as part of the SOAP message security. This profile specifies how the key information for the XML Enryption is exchanged. R0813 When using Message Level Security, the ENDPOINTREFERENCE SHOULD include xxx:KeyInfo element as defined in Appendix A. R0814 When using XML Encryption as part of Message Level Security, the RECEIVER SHOULD provide the key info for encrypting incoming messages to the SENDER prior to the message sending by the SENDER. (More specifically, - the instance should provide the encryption key as part of its endpoint reference resolution and - the consumer should provide the encryption key as part of the endpoint reference in the request message.) R0814 When using XML Encryption as part of Message Level Security, the SENDER SHOULD use the key specified by xxx:KeyInfo element in the endpoint reference of the receiver.

1 0

NOTE TIME CHANGE OGSA Basic Profile Telecon Agenda 4/20
by Tom Maguire 20 Apr '05

20 Apr '05

The following is a proposed agenda for OGSA-WG telecon on April 20th Wednesday from 1pm to 2pm (CDT) 2PM-3PM (EDT). The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0420 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (5 min) Note taker assignment Roll call Agenda bashing 2) Basic Profile discussion (50 min) Review updated doc and trackers 3) Wrap up (5 min) AOB See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

Revised roadmap document
by Hiro Kishimoto 20 Apr '05

20 Apr '05

Hi all, Revised roadmap document has been uploaded to GridForge. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-roadma… 4 Let's discuss it at the OGSA call tomorrow. ---- Hiro Kishimoto

1 0

[ogsa-wg | Roadmap - 1390] service description documents section
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1390 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:36:20 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1390&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1390&group_id…) Summary: service description documents section Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1390 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:36:20 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:36:20 Assigned To: Hiro Kishimoto File(s): <None> Description: Add a section on service description documents. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1389] security consideration (section 9)
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1389 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:35:23 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1389&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1389&group_id…) Summary: security consideration (section 9) Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1389 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:35:23 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:35:23 Assigned To: Hiro Kishimoto File(s): <None> Description: If there is a security profile add some text here about it. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1388] OSS project (section 8)
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1388 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:34:38 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1388&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1388&group_id…) Summary: OSS project (section 8) Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1388 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:34:38 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:34:38 Assigned To: Hiro Kishimoto File(s): <None> Description: Similar to the comment for Section 7. Must be more concrete on what each project is doing, e.g., implementing which OGSA profiles or contributing how to OGSA. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1387] SDOs collaboration (section 7)
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1387 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:33:46 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1387&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1387&group_id…) Summary: SDOs collaboration (section 7) Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1387 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:33:46 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:33:46 Assigned To: Hiro Kishimoto File(s): <None> Description: Need to be more specific about what is being done to achieve this. In other words, be more concrete about the SDO effort and what OGSA-WG is doing. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1386] Interface schedule (section 5)
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1386 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:31:29 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1386&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1386&group_id…) Summary: Interface schedule (section 5) Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1386 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:31:29 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:31:29 Assigned To: Hiro Kishimoto File(s): <None> Description: Describes the schedule: revise sentence in section 1 (top of p4) for consistency. - Maybe add a short description of each document in addition to the schedule View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1385] OGSA branding
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1385 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:29:00 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1385&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1385&group_id…) Summary: OGSA branding Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1385 Category: <None> Group: <None> Status: Open Priority: 2 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:29:00 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:29:00 Assigned To: Hiro Kishimoto File(s): <None> Description: Sec. 4.3.: OGSA-WG can not be writing this section. It is the responsibility of the GFSG to set these rules. It could be writen as a suggestion but it would not fit in a Roadmap. Ideally this text should be a separate (policy) document that is authored by the GFSG and referred to by this document. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1384] conformance text
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1384 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:27:55 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1384&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1384&group_id…) Summary: conformance text Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1384 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:27:55 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:27:55 Assigned To: Hiro Kishimoto File(s): <None> Description: There was a proposal to add to text on whether conformance can be partial or not and what is recommended. Consensus on the call was that it does not seem right to have this text here. Might be in the Profile template document. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1383] Delete 'though' in the last sentence.
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1383 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:25:08 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1383&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1383&group_id…) Summary: Delete 'though' in the last sentence. Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1383 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:25:08 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:25:08 Assigned To: Hiro Kishimoto File(s): <None> Description: section 2, last paragraph View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1382] title for session 2
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1382 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:23:37 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1382&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1382&group_id…) Summary: title for session 2 Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1382 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:23:37 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:23:37 Assigned To: Hiro Kishimoto File(s): <None> Description: titles are not balanced. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1381] page 4 footnote
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1381 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:21:32 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1381&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1381&group_id…) Summary: page 4 footnote Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1381 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:21:32 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:21:32 Assigned To: Hiro Kishimoto File(s): <None> Description: "Architectural process" footnote is misleading since the definition is in the text. Delete footnote. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1380] We distinguish...
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1380 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:20:02 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1380&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1380&group_id…) Summary: We distinguish... Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1380 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:20:02 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:20:02 Assigned To: Hiro Kishimoto File(s): <None> Description: section 2 Mark Linesch: I view all 3 areas of the conceptual model as critical to maintaining coherence around OGSA and grid standards. If we have great (1) Concepts and Fundamentals but cannot utilize the Profiles to achieve interoperable OGSA-Compliant Software we are not closing the loop. (i.e. reducing barriers to customer adoption and accelerating industry investment) View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1379] term profile
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1379 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:16:35 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1379&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1379&group_id…) Summary: term profile Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1379 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:16:35 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:16:35 Assigned To: Hiro Kishimoto File(s): <None> Description: Top of p4: Introduces the term 'profile' but there is no definition. Either rewrite to remove this term or define what a profile is. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1378] Title format
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1378 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:15:27 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1378&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1378&group_id…) Summary: Title format Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1378 Category: <None> Group: <None> Status: Open Priority: 4 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:15:27 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:15:27 Assigned To: Hiro Kishimoto File(s): <None> Description: Proposal to change the formatting of the title. It gives the impression of being a roadmap for OGSA 1.0 which is not correct. It is version 1.0 of the Roadmap. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1377] WS-CIM
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1377 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:04:02 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1377&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1377&group_id…) Summary: WS-CIM Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1377 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:04:02 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:04:02 Assigned To: Hiro Kishimoto File(s): <None> Description: section 6.3 OGSA basic EM profile We need more investigation before decide to adopt WS-CIM for future OGSA spec. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1376] Postpone Basic EM profile
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1376 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:02:57 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1376&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1376&group_id…) Summary: Postpone Basic EM profile Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1376 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:02:57 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:02:57 Assigned To: Hiro Kishimoto File(s): <None> Description: Session 6.3 Hiro: We agree to postpone this until later half of 2005 View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1375] BP is just a web services profile without WS-RSN
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1375 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 21:01:08 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1375&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1375&group_id…) Summary: BP is just a web services profile without WS-RSN Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1375 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 21:01:08 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 21:01:08 Assigned To: Andrew Grimshaw File(s): <None> Description: Andrew Grimshaw: That without WS-RSN there is nothing OGSA at all about the basic profile. It is really just a web services profile. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1374] the degree of profile adoption
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1374 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 20:59:35 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1374&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1374&group_id…) Summary: the degree of profile adoption Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1374 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 20:59:35 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 20:59:35 Assigned To: David Snelling File(s): <None> Description: Section 4.2, the 5th bullet. David Snelling: OGSA and GGF have provided some leadership in Grid, and this turns OGSA, and to some extent GGF, into a watch and see what happens organization. The community might prefer to offer some leadership. I would however, highlight in the profiles (normatively if possible) the degree of adoption at the time of publication. View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1373] "OGSA Requirements" is the wrong title
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1373 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 20:56:22 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1373&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1373&group_id…) Summary: "OGSA Requirements" is the wrong title Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1373 Category: <None> Group: <None> Status: Open Priority: 2 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 20:56:22 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 20:56:22 Assigned To: Hiro Kishimoto File(s): <None> Description: Section 2, the first paragraph Dave Snelling: I think "OGSA Requirements" is the wrong title, just as "Architecture" isn't right either. Something like a "OGSA Concepts and Fundamentals" View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Roadmap - 1372] "OGSA Roadmap" or "OGSA Directions"?
by Sourceforge Tracker Monitor 20 Apr '05

20 Apr '05

A new artifact has been added: 1372 Submitted by: Hiro Kishimoto Submitted date: 2005-04-20 20:54:25 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1372&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=789&aid=1372&group_id…) Summary: "OGSA Roadmap" or "OGSA Directions"? Project: Open Grid Services Architecture Tracker: Roadmap Artifact ID: 1372 Category: <None> Group: <None> Status: Open Priority: 3 Last Modified By: Hiro Kishimoto Last Modified: 2005-04-20 20:54:25 Submitted By: Hiro Kishimoto Submit Date: 2005-04-20 20:54:25 Assigned To: Hiro Kishimoto File(s): <None> Description: Mark Linesch: Is this an "OGSA Roadmap" or is this "OGSA Directions". I am thinking there might be confusion between the term roadmap utilized here versus what the GFSG has committed to produce "GGF Standards Roadmap". View the Roadmap : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

OGSA-BES first teleconference
by Andrew Grimshaw 20 Apr '05

20 Apr '05

All, The first BES teleconference is scheduled for this Thursday, April 21,(US) at 10 AM eastern. The dial in number (thanks IBM) is: Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 The agenda is: Agenda bashing Charter finalization: Scope issues: 1) Legacy only or include "service instantiation" 2) Definition of "job" interface - or leave it to another WG Discussion of future telecon's, e.g., End first agenda Issues for discussion in the following telecon's 1) Agreement or not agreement 2) WSRF or WSRF-neutral 3) Metadata/attributes of containers 4) Interface of the service container 5) Interactions with JSDL - terms and semantics of terms 6) I/O specifications and JSDL terms 7) Service containers as manageable entities Please send us your thoughts on other topics. Andrew Grimshaw Darren Pulsipher Steven Newhouse

4 3

OGSA-ByteIO WG and OGSA-data WG are formally approved
by Hiro Kishimoto 20 Apr '05

20 Apr '05

Congratulations! GFSG has formally approved OGSA-ByteIO WG and OGSA-data WG. Data Area Directors, Malcolm and David, help WG co-chairs to set-up their mailing lists and GridForge project pages shortly. I'd like to express our appreciation for your endeavor to make this happen and let's collaborate closer and drive OGSA development forward. ---- Hiro Kishimoto

1 0

Proposed agenda for April 20th call
by Hiro Kishimoto 19 Apr '05

19 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 20th Wednesday from 5pm to 7pm (CDT). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0420 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 (April 18th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050418 Agenda bashing 2) OGSA May F2F meeting update (if any) 3) OGSA Basic Profile document status (20 min) Tom will report on completion of BP development. Thank you very much BP team for your great efforts. 4) OGSA roadmap document review (60 min) New draft will be available before the call. 5) Wrap up (10 min) AOB April 25 (5-7pm CDT) Profile definition discussion April 27 (5-7pm CDT) Roadmap discussion May 2 (5-7pm CDT) <TBD> May 4 (5-7pm CDT) <TBD> See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

Data: proposed agenda for Wednesday 20th April
by Dave Berry 19 Apr '05

19 Apr '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday April 20th, which will be at the usual time of 7.30am PDT / 10.30am EDT / 3.30pm BST / 4.30pm CEST UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) - http://tinyurl.com/8wsn5 Agenda bashing 2) Action report (5 min) - Allen to discuss replication & InfoD with Cecille. - Dave to find consensus on meeting date. - Dave to mail contributors re common section structure. - Dave to add version number to header and accept current changes. - Dave to ask NextGrid/InfoD about transfer to non-service endpoints. 3) F2F planning (10 min) - Date: May 26th. Place: London. - Initial discussion of agenda. 4) Technical content (25 min) - Update from contributors - Discussion of issues arising 5) Architecture document structure (10 min) Comments on the structure of the architecture document. 6) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: OGSA May F2F meeting venue
by Hiro Kishimoto 19 Apr '05

19 Apr '05

Hi all, The following is the May F2F information by Steve McGough. I got his email before the Monday call but overlooked. Sorry Steve. > The actual room at Imperial is in flux at the moment as we are having > renevation work done to our new office space. Once I've got an exact > room I shall provide full information on it and how to get there. I've > attached the pdf I sent out for the JSDL f2f to give you an idea of what > to expect. > > As for accomodation: > Hotels can be booked through the university conference office > http://www.imperialcollege-conferencelink.com/ > > They list hotels by walking distance from the campus and quality. They > apparently arrange discount on prices. > > To get to the list of hotels click the South Kensington link at the top > and then select Hotel Directory. > > The Campus is South Kensington. I'm sure you can figure out the other > options. Thanks, ---- Hiro Kishimoto

1 0

CFP: NYC WISE'05 Industry Track
by Gagnon, Stephane 19 Apr '05

19 Apr '05

C A L L F O R P A P E R S ===================================================================== WISE 2005 Industry Track http://elab.njit.edu/wise 6th International Conference on Web Information Systems Engineering November 20-22 2005, New York City, New York http://www.cs.txstate.edu/wise05 ===================================================================== Sponsored by: - Telcordia - IBM - NJIT Supported by: - Object Management Group (OMG) - Integration Consotrium (IC) --------------------------------------------------------------------- The goals of the WISE 2005 Industry Program are to foster exchanges between practitioners and the academics, to promote novel solutions to today's business challenges, to provide practitioners in the field an early opportunity to evaluate leading-edge research, and to identify new issues and directions for future research and development work. We invite submissions on all topics related to web engineering including technologies, methodologies, and applications. Papers can take the form of detailed case studies, technical white papers, new methodologies, new standard specifications, benchmarking models, or any other contributions demonstrating innovative web engineering technologies, methods, and applications. Topics of particular interest include but are not limited to those identified in the conference CFP, as well as those listed below: 1. Technologies: a. Development of new web services standards b. Use of business process automation technologies c. Use of semantic web and grid computing d. Innovative solutions for performance optimization e. Benchmarking of leading runtime environments 2. Methodologies: a. Web engineering with a Model Driven Architecture b. Requirements engineering for web applications c. Software design reusing legacy systems and data d. Quality focus and use of Test Driven Development e. Benchmarking of leading web engineering tools 3. Applications: a. Case studies of major web engineering projects b. Implementation of a Service Oriented Architecture c. Outsourcing and use of Business Services Networks d. Analysis of industry-specific trends and challenges e. Benchmarking models in selecting web IT vendors ---------- Deadlines: ---------- Abstracts due June 10, 2005 Papers due June 17, 2005 Decision notification Aug. 12, 2005 Camera-ready copies due Sept. 16, 2005 ------------------------- Guidelines and Submission: -------------------------- All industrial papers will be peer-reviewed and published in the regular conference proceedings. For easy identification, industrial papers should have as their title "Industry Track: rest of title". Please follow the guidelines of Lecture Notes in Computer Science (LNCS) published by Springer: http://www.springeronline.com/sgw/cda/frontpage/ 0,11855,5-164-2-72376-0,00.html. Please submit your paper online in PDF format: http://elab.njit.edu/wisesubmit For more information, please contact the Industrial Program Chair. ------------------------- Industrial Program Chair: ------------------------- Jen-Yao Chung, IBM T. J. Watson Research (jychung(a)us.ibm.com) ------------------------------- Industrial Program Vice Chairs: ------------------------------- Stephane Gagnon, NJIT (gagnon(a)njit.edu) Shu-Ping Chang, IBM Research (spchang(a)us.ibm.com) ------------------ Program Committee: ------------------ TBA

1 0

draft-ogsa-profile-template-v1.5 document updated for review
by Tom Maguire 19 Apr '05

19 Apr '05

http://forge.gridforum.org/ projects/ogsa-wg/document/draft-ggf-ogsa-profile-template/en/4 New rev of doc addresses AIs from 4/6 telecon. Please review and comment. Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

draft-ogsa-profile-template-v1.5 (current comments and what I believe are the resolutions)
by Tom Maguire 19 Apr '05

19 Apr '05

Ian Foster: Is this rewording correct? I wasn’t sure of the meaning: It seemed to say that no Profile could ever make reference to an extension, which seemed unnecessarily restrictive, and also is contradicted by the next paragraph. <trm>Section deleted per AI to remove copyrighted material</trm> Ian Foster: This is unclear to me. What are “other profiles”? <trm>Section deleted per AI to remove copyrighted material</trm> Ian Foster: I’m not sure what this is saying. Of course it’s true, but how does this relate to profile conformance? <trm>Section deleted per AI to remove copyrighted material</trm> Dave Snelling: This definition is critical as it distinguishes profile types below. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: It has been suggested that we don't need this category. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Tom Maguire: Needs work The paragraph in question: In some cases, specifications allow multiple interpretations of aspects of the specification. Where this variability in interpretation is likely to effect interoperability, the profile should restrict the interpretation. The nature of these restrictions may range from a simple clarification of meaning in a specification to the inclusion of "mini" specifications for missing content in the referenced specification. Note that if such a "mini" specification becomes significant in size or relevance outside the given profile, it should be spun out as a separate normative specification and referenced externally. <trm>We are in practice doing this for KeyInfo exchange in Basic Profile. The question remains do we need to provide additional guidance on when to spin-off</trm> Dave Snelling: The names of these profile types follow the GGF document type and process models. We could use just two types, informational and normative, and allow the GGF process only to distinguish the later two. We would still need our own guide-lines, however. There has also been a suggestion for other names. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: There is concern that this non-normative form of profile <informational> may undervalue the others. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: There was some surprise that there were no restrictions on either the status value or the adoption value. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: Can other WGs create OGSA Profiles? <trm>Other WGs can create OGSA profiles but they must be approved by the OGSA WG. Have we clarified this process?</trm> Dave Snelling: As interoperable implies at least two implementations, it would exclude key specifications that the OGSA WG may want to encourage implementers to address. Do we need another category or a refined definition of interoperable? Discuss on a call. <trm>Discussed. I believe we have agreed to the set of profile types defined in the document.</trm> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

Teleconference minutes - 18 April 2005
by Andreas Savva 18 Apr '05

18 Apr '05

Minutes attached. Gridforge https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050418/en/1 OGSA Teleconference - 18 April 2005 =================================== * Participants Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jay Unger (IBM) Apologies: Dave Snelling Minutes: Andreas Savva * April 11 & 13 approved with no changes - Is there a complete schedule of all OGSA teleconferences? No, just for the regular calls (Mon, Wed). Hiro will look into providing a more complete schedule. - OGSA BES teleconference time, day and logistics? There was an announcement on the time/day on the ogsa-wg list by Andrew on March 31. - Probably the first call will be this week. Andrew is expected to send out an email announcing it. Assume a duration of one hour for now. - Tom to offer his teleconference number for the BES call. (Done) * May F2F update - Why is there a gap between the first part of the F2F and the Data? - EGEE meeting conflict. There was an announcement by Dave B on the list. - The meeting room at IC is not fixed yet. OGSA F2F typically have around 15 people attending so a largish room is probably needed. (The Access Grid room maybe too small.) - Hotels nearby and information about IC? - Nothing about arranging a group booking at the moment. - The main University site is http://www.ic.ac.uk and includes information on how to get to the South Kensington campus. - From Heathrow the Heathrow Express going to Paddington (and then the underground), or the Piccadilly line are convenient. - The nearest underground station is South Kensington. - Andreas will forward some information he has about Hotels from the November JSDL F2F. (Done) * Profile Template - Reviewed minutes April 6; the last review of this document. - There are not a lot of issues open on this document. - There is no updated version yet. Tom will do a minor revision and post a new version on gridforge. - Requesting people to review this document. It should be fairly easy to move it forward. [There is a tracker 'Profile template' already created for this document.] * EMS area BES represents a small subset of the EM area. What is the next step and how is the overall EM area discussion being addressed? Can Ravi commit time to lead the discussion? - Jay is trying to get people from within IBM engaged in this effort. - There is some interest in another portion of EM (CGS) from people in Germany. - Arrange time at the F2F to discuss how to move forward. [EM topic is already on the agenda.] * Next call - Basic profile and Roadmap document review

1 0

May F2F: Hotels near Imperial College
by Andreas Savva 18 Apr '05

18 Apr '05

While Dave B and Hiro sort out the room reservation at IC for the May F2F here's some preliminary information on hotels in the area: >Hotels can be booked through the university conference office >http://www.imperialcollege-conferencelink.com/ > >They list hotels by walking distance from the campus and quality. They >apparently arrange discount on prices. > >To get to the list of hotels click the South Kensington link at the top >and then select Hotel Directory. > >The Campus is South Kensington. > >(The closest Marriot is the Kensington one on Cromwell road.) > and >Here are some useful links on accommodation close to Imperial. > >General location and nearby interests >http://www.upmystreet.com/overview/?l1=SW72AZ > >Hotels nearby >http://www.upmystreet.com/nrs/?l1=SW72AZ&cat=1231 > > >

1 0

OGSA-BES DRAFT charter and F2F
by Andrew Grimshaw 18 Apr '05

18 Apr '05

All, Attached is the draft BES charter. Please comment in the next several days so we can get this off to the GFSG. A few other administrative things. 1) We are planning a face-to-face in conjunction with the OGSA F2F in London at the end of May. The OGSA F2F is May 23-24. We will have the BES F2F the day before - on Sunday the 22. 2) The proposed weekly teleconference time is 10 AM Eastern (US) on Thursdays (NOT including today.) It is not an ideal time for the folks in Asia. Midnight in Japan, and 10 PM in Thailand. We are working on finding a conference call number and will post in advance. Any ideas are appreciated. Andrew

2 2

Teleconference minutes - April 13, 2005
by Andreas Savva 18 Apr '05

18 Apr '05

Minutes attached. Gridforge url: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050413/en/1 Mark has also uploaded the April 11 minutes: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050411/en/1 -- Andreas Savva OGSA Teleconference - 13 April 2005 =================================== * Participants Jem Treadwell (HP) Andreas Savva (Fujitsu) Kazushige Saga (NII) Mark Morgan (UVa) Hiro Kishimoto (Fujitsu) Soonwook Hwang (NII) Dave Berry (NeSC) Mike Behrens (R2AD, LLC) * No teleconference minutes available for approval * F2F update There is an EGEE meeting coinciding with OGSA F2F so some people have conflicts. This especially affects the Data team. The current thinking is to leave a day between the main F2F and the Data one; details not decided yet. The venue (LeSC) is still ok. Jem is still not sure he can make it. Andrew has said that he is not planning a naming discusion. Hiro to drop it from the agenda. BES-WG is still set to have a meeting on Sunday. * Roadmap document review - Agreed that "roadmap" is correct for now and will re-check after reviewing for content. - Proposal to change the formatting of the title. It gives the impression of being a roadmap for OGSA 1.0 which is not correct. It is version 1.0 of the Roadmap. - Top of p4: Introduces the term 'profile' but there is no definition. Either rewrite to remove this term or define what a profile is. ** Section 2 - OGSA 1.0 is called 'OGSA Requirements' but the name does not look right. To sidestep the problem of what to call it just use the published document's title. - "We distinguish..." rewrite to address the existing comment, e.g., "There are three critical areas...." - "Architectural process" footnote is misleading since the definition is in the text. Delete footnote. - Agreed to revisit section titles again offline. - Delete 'though' in the last sentence. ** Section 3 - Second paragraph last sentence: delete since it does not add anything to the text. - There was a proposal to add to text on whether conformance can be partial or not and what is recommended. Consensus on the call was that it does not seem right to have this text here. Might be in the Profile template document. - Some typos to be corrected. Jem to send revisions to Hiro. ** Section 4 - David S comment: Hiro to ask Dave S to rewrite the sentence. - Sec. 4.3.: OGSA-WG can not be writing this section. It is the responsibility of the GFSG to set these rules. It could be writen as a suggestion but it would not fit in a Roadmap. Ideally this text should be a separate (policy) document that is authored by the GFSG and referred to by this document. ** Section 5 - Describes the schedule: revise sentence in section 1 (top of p4) for consistency. - Maybe add a short description of each document in addition to the schedule - Question on whether to add all related specifications or just the ones that will be used in the profiles? Consenus was for all specifications. - But maybe provide different level of detail. For example, only provide additional explanation for specifications that are used in profiles. ** Section 6 - There is still no consensus on a Basic EM profile or its content. The text comes from the Dec'04 F2F. - WSDM has been published. - Acceptance into 2.0? WSDM and WS-CIM should be on separate list since they fall in a different category. - Add a security profile. ** Section 7 - Need to be more specific about what is being done to achieve this. In other words, be more concrete about the SDO effort and what OGSA-WG is doing. ** Section 8 - Similar to the comment for Section 7. Must be more concrete on what each project is doing, e.g., implementing which OGSA profiles or contributing how to OGSA. ** Section 9 (security) - If there is a security profile add some text here about it. ** Additional - Add a section on service description documents. - Dave S is listed as an author at the front but not at the back. Hiro to add Dave's details in the back section. - Add Glossary document in the References. - Andreas to create a tracker for this document. * Teleconference schedule Next Monday: Review of profile template Next Wednesday: Review of Roadmap document

1 0

Javadocs for SimpleAuthorizationDecisionStatement
by Sandeep Kumar Singh 18 Apr '05

18 Apr '05

Dear All, I tried searching for javadocs for SimpleAuthorizationDecisionStatement, but could not find it. Can anyone tell me where can I find the same? Regards, Sandeep

2 1

Proposed agenda for April 18th call
by Hiro Kishimoto 18 Apr '05

18 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 18th Monday from 5pm to 7pm (CDT). 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: 0418 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 (April 11th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050411/en/1 Agenda bashing 2) OGSA May F2F meeting update (20 min) Date: May 22 (Sun) for BES-WG meeting May 23 (Mon) and 24 (Tue) for general meeting May 26 (Thu) for OGSA-D WG and ByteIO-WG meeting Venue: Imperial College London Host: Dave Berry (daveb(a)nesc.ac.uk) Accommodation: TBA 3) OGSA profile definition review (60 min) New draft will be available before the call. 4) Wrap up (10 min) AOB April 20 (noon-2pm CDT) Basic Profile April 20 (5-7pm CDT) BP reporting and Roadmap discussion April 25 (5-7pm CDT) <TBD> April 27 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

RE: [ogsa-wg] OGSA F2F Dates: May 25th or May 26th?
by Dave Berry 16 Apr '05

16 Apr '05

All, >From the responses I've received, there is a clear advantage to holding the OGSA Data meeting on Thursday 26th, even though it is less convenient for those of us who will also be attending the main OGSA WG meeting on the Monday and Tuesday. I will contact IC to book a room for the Thursday. I look forward to seeing you there! Best wishes, Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Dave Berry Sent: 13 April 2005 17:07 To: ogsa-wg Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; Stephen Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; Mark M. Morgan Subject: [ogsa-wg] OGSA F2F Dates: May 25th or May 26th? All, Although we agreed a date of May 25th for the OGSA Data F2F, following immediately after the OGSA F2F on the 23rd and 24th, it turns out that some people, both Europeans and Americans, will be attending an EGEE design meeting on those dates. This raises the question of whether more people could attend if we move the OGSA Data F2F to the 26th. Please could interested people mail me and tell me for each date whether you will or will not be able to attend an OGSA Data F2F in London? May 25th Yes (Preferred) / Yes (Possible) / No May 26th Yes (Preferred) / Yes (Possible) / No I want to make a decision this week, because people need to book flights. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

ICSOC 2005
by Ian Foster 15 Apr '05

15 Apr '05

Dear All: I enclose a call for papers for ICSOC, which may be of interest to some of you. Regards -- Ian.

2 2

OGSA Evolution Policy Statement Draft 2
by David Snelling 15 Apr '05

15 Apr '05

Folks, Following a weeks time for comments, I have received very little but valuable feedback. I have clarified the definition of the Infrastructure Level, which several people noted was not as clear as it could be. Further comments welcome. It is not yet frozen. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

2 2

ByteIO: Agenda on Tuesday 19th
by Dave Berry 14 Apr '05

14 Apr '05

Dear All, The nascent ByteIO working group will meet on Tuesday 19th at 7am PDT / 9am CDT / 10am EDT / 3pm BST / 4pm CEST / 11pm Japan. Agenda ------ Continue technical discussion Start discussing use cases - binary file - DAIS query - sensor PLEASE NOTE CHANGE IN PIN NUMBER UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 369 786 Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Minutes from OGSA-WG Basic Profile discussion -- April 13, 2005
by Srinivasan, Latha 14 Apr '05

14 Apr '05

Hi, Here are the meeting minutes from today's BP discussion. I've also uploaded the notes to GridForge/MeetingMinutes. -Latha

1 0

Notes from ByteIO Telcon
by Hiro Kishimoto 13 Apr '05

13 Apr '05

Neil's email bounced. ---- Hiro Kishimoto From: "neil p chue hong" <N.ChueHong(a)epcc.ed.ac.uk> To: "'ogsa-wg'" <ogsa-wg(a)gridforum.org> Subject: Notes from ByteIO Telcon Date: Wed, 13 Apr 2005 10:17:31 +0100 These are the notes from the telcon postponed from last week. Minutes from the ByteIO Telcon on 12/4/05 ----------------------------------------- Attending: Mark Morgan (MM) Neil Chue Hong (NCH) Dave Berry (DB) Agenda - Charter Discussion - Telcon times - Kicking off technical discussion Date of next Telcon: 19/4/05 at 14:00 UTC (09:00 CDT / 10:00 EDT / 15:00 BST / 16:00 CEST) *** Note change in time *** Charter Discussion ------------------ The co-chairs and Dave Berry had put out the charter for comment, separately the OGSA-WG solicited comments on the ByteIO charter. In particular, one set of comments from Olegario Hernandez were addressed: - concern over whether the writers have properly considered the writing operations in scope (this stemmed from confusion within the initial version of scope as compared with the focus) - the scope does not clearly say what is included We discussed the charter, reworded the purpose, and tightened the scope to make it consistent. We feel we have now given adequate time for comment, received comments and addressed them where necessary. AGREED to submit revised charter, DB has done this. Telcon ------ Agreed to change telcon time to an hour earlier, to avoid clash with DAIS WG telcons. The new time is Tuesdays at 14:00 UTC / 09:00 CDT / 15:00 BST, starting from next week. [NCH] will advertise new time and distribute minutes [DB] will book a new telcon slot Starting Tech ------------- NCH circulated a paper on experiments done in Edinburgh comparing SOAP Base64, SwA and DIME, and sockets. Mark had also done some experiments, which confirm these results. The problem with using SwA is that in the next Microsoft WSE 3.0 release, it is likely that DIME will go out and MTOM will go in. So we lose compatibility in this release. We can also disregard raw sockets as a default as it's just not going to play nice with any web services normal setup. NCH will check on the progress of MTOM implementations in Java. There appear to be some commits into Apache on MTOM in JAXRPC 2.0 / JAXB. WebDAV can be wrapped by a simple web service, this might be a possibility, MM will look into this in more detail. Agenda for next week -------------------- Continue technical discussion Start discussing use cases - binary file - DAIS query - sensor [MM] Write a paragraph or two describing a binary file use case. [NCH] Send mail to Mario Antonioletti at DAIS to procure an existing use case from DAIS to contribute. [DB] Send mail to NEC to see if they can provide a sensor use case -- << NOTE ROOM CHANGE, OTHER DETAILS REMAIN CONSTANT >> Neil P Chue Hong | T: [+44] (0)131 650 5957 Project Manager, EPCC | F: [+44] (0)131 650 6555 Rm 2409, JCMB, Mayfield Rd. | E: N.ChueHong(a)epcc.ed.ac.uk Edinburgh, EH9 3JZ, UK | W: http://www.epcc.ed.ac.uk "A film is like a battleground. It's love, hate, action, violence, death - in a word, emotion." - Sam Fuller

1 0

[ogsa-wg | Basic Profile - 1369] Section 8.1.6 additional MESSAGE and INSTANCE reqts
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1369 Submitted by: Tom Maguire Submitted date: 2005-04-13 15:45:47 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1369&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1369&group_id…) Summary: Section 8.1.6 additional MESSAGE and INSTANCE reqts Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1369 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 15:45:47 Submitted By: Tom Maguire Submit Date: 2005-04-13 15:45:47 Assigned To: &lt;None&gt; File(s): <None> Description: Need testable MESSAGE and INSTANCE normative reqts View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1368] Section 8.1.6 MLS needs description
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1368 Submitted by: Tom Maguire Submitted date: 2005-04-13 15:44:12 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1368&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1368&group_id…) Summary: Section 8.1.6 MLS needs description Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1368 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 15:44:12 Submitted By: Tom Maguire Submit Date: 2005-04-13 15:44:12 Assigned To: &lt;None&gt; File(s): <None> Description: Need good decription of MLS issue View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1367] Appendix A KeyInfoElement; why not ds:KeyInfoElement
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1367 Submitted by: Tom Maguire Submitted date: 2005-04-13 15:37:49 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1367&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1367&group_id…) Summary: Appendix A KeyInfoElement; why not ds:KeyInfoElement Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1367 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 15:37:49 Submitted By: Tom Maguire Submit Date: 2005-04-13 15:37:49 Assigned To: &lt;None&gt; File(s): <None> Description: Why create a new element and not use the digsig element for key info View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1365] section 6.1 BaseNotification refers to ServiceGroup
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1365 Submitted by: Tom Maguire Submitted date: 2005-04-13 15:12:12 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1365&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1365&group_id…) Summary: section 6.1 BaseNotification refers to ServiceGroup Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1365 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 15:12:12 Submitted By: Tom Maguire Submit Date: 2005-04-13 15:12:12 Assigned To: &lt;None&gt; File(s): <None> Description: description is wrong View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1364] Remove section 5.3 Destroy pending notification
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1364 Submitted by: Tom Maguire Submitted date: 2005-04-13 15:10:27 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1364&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1364&group_id…) Summary: Remove section 5.3 Destroy pending notification Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1364 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 15:10:27 Submitted By: Tom Maguire Submit Date: 2005-04-13 15:10:27 Assigned To: &lt;None&gt; File(s): <None> Description: no normative spec for defining that View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1363] Section 5.2 Should we have Resource Destruction notification
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1363 Submitted by: Tom Maguire Submitted date: 2005-04-13 15:08:55 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1363&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1363&group_id…) Summary: Section 5.2 Should we have Resource Destruction notification Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1363 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 15:08:55 Submitted By: Tom Maguire Submit Date: 2005-04-13 15:08:55 Assigned To: &lt;None&gt; File(s): <None> Description: Should the BP place ANY reqts on destroy notification View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1362] Remove section 3.1.2 Policy statement
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1362 Submitted by: Tom Maguire Submitted date: 2005-04-13 14:44:48 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1362&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1362&group_id…) Summary: Remove section 3.1.2 Policy statement Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1362 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 14:44:48 Submitted By: Tom Maguire Submit Date: 2005-04-13 14:44:48 Assigned To: &lt;None&gt; File(s): <None> Description: Does not apply anymore. View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1361] section 1.3 notational conventions need to be a ref to WS-I BP 1.1
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1361 Submitted by: Tom Maguire Submitted date: 2005-04-13 14:36:09 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1361&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1361&group_id…) Summary: section 1.3 notational conventions need to be a ref to WS-I BP 1.1 Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1361 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 14:36:09 Submitted By: Tom Maguire Submit Date: 2005-04-13 14:36:09 Assigned To: &lt;None&gt; File(s): <None> Description: reduce and ref WS-I BP 1.1 View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1360] Section 1.1 BaseFault and BaseNotification Description
by Sourceforge Tracker Monitor 13 Apr '05

13 Apr '05

A new artifact has been added: 1360 Submitted by: Tom Maguire Submitted date: 2005-04-13 14:34:24 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1360&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1360&group_id…) Summary: Section 1.1 BaseFault and BaseNotification Description Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1360 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-04-13 14:34:24 Submitted By: Tom Maguire Submit Date: 2005-04-13 14:34:24 Assigned To: &lt;None&gt; File(s): <None> Description: Add descriptive text on BaseFaults and Notificaitons regarding issues addressed. View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

OGSA Basic Profile Telecon Agenda 4/13
by Tom Maguire 13 Apr '05

13 Apr '05

The following is a proposed agenda for OGSA-WG telecon on April 13th Wednesday from noon to 2pm (CDT) 1PM-3PM (EDT). The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0413 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 Agenda bashing 2) Approve minutes from 4/6 https://forge.gridforum.org/ projects/ogsa-wg/document/minutes-20050406-OGSA-BP/en/1 See AI below for update of minutes 3) Review AIs Kick lazy scum leader for not getting agenda out 4) Security discussion (60 min) Review updated doc and trackers 5) Basic Profile discussion (50 min) Review updated doc and trackers 6) Wrap up (10 min) AOB See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

OGSA F2F Dates: May 25th or May 26th?
by Dave Berry 13 Apr '05

13 Apr '05

All, Although we agreed a date of May 25th for the OGSA Data F2F, following immediately after the OGSA F2F on the 23rd and 24th, it turns out that some people, both Europeans and Americans, will be attending an EGEE design meeting on those dates. This raises the question of whether more people could attend if we move the OGSA Data F2F to the 26th. Please could interested people mail me and tell me for each date whether you will or will not be able to attend an OGSA Data F2F in London? May 25th Yes (Preferred) / Yes (Possible) / No May 26th Yes (Preferred) / Yes (Possible) / No I want to make a decision this week, because people need to book flights. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

OGSA Basic Profile Telecon Agenda 4/6
by Tom Maguire 13 Apr '05

13 Apr '05

The following is a proposed agenda for OGSA-WG telecon on April 6th Wednesday from noon to 2pm (CDT) 1PM-3PM (EDT). The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0406 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 Agenda bashing 2) Approve minutes from 3/30 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050330-OGSA… See AI below for update of minutes 3) Review AIs Action 1321: Frank & Sam to come up with text and schema for 1321 Action 1320: DaveS update text (text not captured need update of minutes) Action: 1298 should be closed no action (see minutes) Action 1231-1233: TomM to pull back 1231-33 into the document with empty body resolve message. Action 1317: TomM to make this a SHOULD with follow-on MUSTs (if implemented) Action 1262: TomM to remove from profile doc. 4) Security discussion (60 min) 1322: Use of Proxy Certificates 1323: Communication of assertions 5) Basic Profile discussion (50 min) 1211: What must a service satisfy before it can be called an "OGSA service?" 1314: Relationship to WS-I Basic Security Profile 1.0 6) Wrap up (10 min) AOB See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

4 6

Proposed agenda for April 13th call
by Hiro Kishimoto 13 Apr '05

13 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 13th Wednesday from 5pm to 7pm (CDT). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0413 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 May F2F meeting update (if any) Agenda bashing 2) OGSA roadmap document review (60 min) New draft will be available before the call. 3) Wrap up (10 min) AOB April 18 (5-7pm CDT) Profile template discussion April 20 (noon-2pm CDT) Basic Profile April 20 (5-7pm CDT) Roadmap discussion April 25 (5-7pm CDT) <TBD> April 27 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 1

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Savas Parastatidis 12 Apr '05

12 Apr '05

Dear Ian, I don't think that the approach I proposed forces the user to do more than they would have to do anyway if EPRs were used. It is still the case that someone has to manage the EPRs to the resources in WSRF. This is similar to what happens in the real world. The online bookstore will ask for my credit card number (a URI), or the book store will as for an ISBN (another URI) or multiple ISBNs if I want to buy multiple books. The banking service will ask for my bank account number (another URI perhaps). Also, there is no reason why a "kill all my jobs" message couldn't also be supported. But please note that this message is now addressed to the service (the container of resources) and not, as in the case of WSRF, to a specific resource. This is no different from what I am advocating. Also... to Steve's point about partial failure. If one wishes atomic transaction semantics, I don't see the difference from the two approaches... Atomic Msg -> resource 1 Msg -> resource 2 Msg -> resource 3 End Atomic Vs Msg Atomic Resource 1 Resource 2 Resource 3 End Atomic In fact, I would argue that the latter is better because: 1. It uses fewer messages (and, Steve, I am not assuming only HTTP and the optimisations that may be supported) 2. I can more easily deal with the failures in an application specific-manner since my atomic TX semantics do not span multiple msgs. (Anyway... who wants to do atomic TXs over the Web anyway? :-) Regards, -- Savas Parastatidis http://savas.parastatidis.name ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Tuesday, April 05, 2005 2:22 PM To: Steve Loughran; Savas Parastatidis Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions Steve's note raises a key point for me: do we really want to force the user (as Savas seems to be advocating) to keep track of jobs running at a remote site? I'd rather send a request "kill all my jobs" or "kill all my jobs that have run for more than a day" to the factory than carefully keep track of all jobs that I have active, and how long they have been running, so that I can send the big document (or stream) discussed below. Ian. At 02:10 PM 4/5/2005 +0100, Steve Loughran wrote: Savas Parastatidis wrote: Dear all, I think something needs to be clarified with regards to handling multiple jobs with one message. The beauty of document-oriented interactions is that you can do things like... <job-details-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> </job-details-request> Or <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> </job-suspend-request> The schema for the above document can allow anything from 0 to N number of <job-id> elements. the trouble with any bulk operation is you have to handle partial failure. You need either atomic operations (not long lived transactions over HTTP Savas, I wouldn't be that daft), or a way of indicating that only a bit went wrong Hence the 207 Multi-Status response in WebDav, the "something failed, look in the message". WebDav is still single instance (here a RESTy URL), but you can set >1 property and so have partial failure. SOAP just has SOAPFault and extensions; no explicit multiple failure response. WS-RF-ResourceProperties has a similar problem with SetResourceProperties, but a different failure model in which any failure to set can result in a WS-BaseFault, indicating which failed, but providing no apparent information on which worked. It seems to me that if you want to bulk stuff, you do need ways of (a) handling partial failure and (b) declaring what happens on partial failure. For the curions, WebDav's failure mode on file operations (MOVE, COPY) is explicitly declared to be that of failed file operations of Win98 on a FAT32 filesystem [1,2] Alternatively, you dont go for bulk operations, neither on a multiple jobs, or on multiple properties of a job (remember, WS-RF doesn't declare atomic/transacted property operations, so all you do here is increase the window of instability, a window that already exists). Instead you just stream a series of operations over the same HTTP1.1 connection -assuming that everything is accessible at the same far-end host, and get a series of (potentially out of order, we are talking HTTP1.1) responses. This could be efficient, and you could do better handling of failure. But you do need a SOAP stack that can keep an HTTP1.1 channel open for multiple requests. Axis doesnt, even if you get httpclient to do the HTTP work; I don't know about .NET/WSE. You also need developers to model the communication correctly. Manipulating JAXRPC proxies as if they represent remote objects is *clearly* the wrong way to do it. You'd almost want to model a queue of requests waiting to be POSTed, a queue you can fill up then push out. Something like this, in your Java-era language of choice :- //different queues for SOAP, REST Queue q=new Soap12RequestQueue(); q.add(new StatePut(job1.uri,Job.LIFECYCLE,Job.SUSPENDED)); //let the queue reorder stuff if it wants to q.add(new StatePut(job2.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_OPTIMAL); q.add(new StatePut(job3.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_LAST); q.setEventHandler(this); q.nonBlockingSubmit(); No, there is no code behind this example, and I am avoiding any hints as to what the even handler would look like. I think the key point is that once you embrace remote operations as async actions, then you can model the manipulations differently. Note also that I am representing job suspension not as an explicit suspend() operation, but as a request to put a job into the suspended state. This API could work with our friend REST just as easily as with WS-RF... Anyway Savas, to conclude: do you have any evidence that a single document is suboptimal compared to a sequences of requests over an open HTTP/1.1 connection? That is, assuming we ignore the SHOULD in the HTTP1.1 specification " Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods" [3] -Steve [1] WebDav http://www.ietf.org/rfc/rfc2518.txt S8.9.2 "after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible." [2] http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html [3] RFC2616 HTTP1.1 _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

3 2

Proposed agenda for April 11th call
by Hiro Kishimoto 11 Apr '05

11 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 11th Monday from 5pm to 7pm (CDT). 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: 0411 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 - http://tinyurl.com/5fxfd/minutes-20050406/en/1 May F2F meeting update (if any) Agenda bashing 2) profile policy statement discussion (30 min) This is time boxed discussion. Since the OGSA is GGF's flagship architecture, the GFSG has been working on a policy surrounding the creation of profiles for OGSA. David Snelling, our Area Director, has done a FIRST DRAFT ("The OGSA Evolution Policy Statement"). Please read this draft and give your feedback. David and I will bring your feedback to GFSG to improve the policy statement. https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-evolution-policy… ement/en/1 3) Fellow WGs status report (60 min) - OGSA-ByteIO WG - OGSA-Data WG - OGSA-BES WG - OGSA-naming WG 4) Wrap up (10 min) AOB April 13 (noon-2pm CDT) Basic Profile April 13 (5-7pm CDT) Roadmap discussion April 18 (5-7pm CDT) Profile template discussion April 20 (noon-2pm CDT) Basic Profile April 20 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

2 1

Virtualization: How do we specify notifications?
by Dave Berry 08 Apr '05

08 Apr '05

Dear OGSA WG, In the object-oriented world, components such as Java Beans or ActiveX controls are typically defined by a set of properties, a set of methods and a set of events. In the service-oriented world we have a similar requirement, dealing with interoperable messages rather than a language API. What is the best way to specify the notifications that a service or interface can send? The OGSA document describes a virtualization as a "common set of abstract interfaces available for a set of similar resources, thereby hiding differences in their properties and operations". To this we somehow have to add the notifications that can be generated, as these are an essential part of virtualization. Are the notifications part of an interface? Are they actually specified in any of the metadata for a service? The OGSA document defines an interface as follows: "In a service-oriented architecture, a specification of the operations that a service offers its clients". Should this be extended to include properties and/or notifications? This is a live issue for the Data Architecture document. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

2 1

OGSA Basic Profile minutes posted
by Treadwell, Jem 08 Apr '05

08 Apr '05

Hi, the minutes of this week's Basic Profile telecon are now posted at http://tinyurl.com/6c3rv. Please let me know if you see any errors or omissions - thanks! - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

Data: Proposed agenda for Wednesday 13th April
by Dave Berry 08 Apr '05

08 Apr '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday April 13th, which will be at the usual time of 7.30am PDT / 10.30am EDT / 3.30pm BST / 4.30pm CEST UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) - http://tinyurl.com/5y324 Agenda bashing 2) Action report (5 min) - Dave to send charter to GFSG [done]. - Dave to consult re F2F meeting [see next section]. - Dave to remind contributers of schedule [done]. 3) F2F planning (10 min) The main OGSA WG meeting will be May 23-24 with a data day planned on May 25. May 25 overlaps with an EGEE meeting - is there another day that suits everybody? 4) Replication (25 min) Update from Anne and Allen on the replication section and a discussion of remaining issues. 5) Architecture document structure (10 min) Comments on the structure of the architecture document. 6) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

OGSA ByteIO telcon, April 12th
by Dave Berry 08 Apr '05

08 Apr '05

Dear all, I've booked a telcon for the nascent ByteIO group. This will be next Tuesday at 8AM Pacific, 11AM Eastern, 4PM UK and midnight in Japan. We will start the technical discussion, focussing on the protocol for transferring the bytes. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Mark McKeown 07 Apr '05

07 Apr '05

Hi Paul, Moving the question from can I suspend multiple jobs by sending a single message to a resource (either REST or WS-Resource) to weither this is a good thing. There is a balance between simplicity and efficiency - using a single message intoduces more complexities, as Steve Loughran illustrated, but is potentially more efficient than sending mutliple messages. Remembering that "Early optimisation is the root of all evil" (Knuth) - is adding support for suspending mutiple jobs using a single message an example of early optimisation? I would imagine that this should be a straight forward question since there is already considerable experience in using computational grids. Are users demanding the ability to suspend mutliple jobs using a single message? Is it for improved efficiency reasons? From my experience no, but others on this list will have considerably more experience. Could this be a case of "worse is better", simplicity is more important than efficiency? Perhaps there are other reasons for using a single message to interact with multiple jobs? cheers Mark > Ian, > > > > I agree that this is good progress. So let's bank that and see if we can > we can agree on one more thing, and then I'll ask a question. > > > > Considering your list of abilities (a, b & c) below, do we agree that in > terms of expressiveness, the ordering is: > > > > c>b>a > > > > i.e. using approach c, a client can request operations on: > > a) single jobs: "where (jobid = urn:guid:364)" > > b) sets of jobs: "where (jobid = urn:guid:364) or (jobid = > urn:guid:401)" > > > > If there is agreement on this, then we could move on to discussing why > it is felt necessary to provide more than just c for the job submission > service. > > > > Regards > > Paul > > > > Ian wrote... > > >Savas: > > > > > >It seems that we are in agreement, then, that we want the ability to: > > > > > >a) Request operations on individual jobs identified by some sort of > "jobid" > > > > > >b) Request operations on sets of jobs identified by a user-supplied > list of "jobids" > > > > > >c) Request operations on sets of jobs identified by more abstract > criteria > > > > > >We also agree that (as I expressed in the email that started this > discussion) such >requests can be expressed in a few different ways, > with somewhat different >characteristics. > > > > > >That's progress I hope. > > > > > >Ian. > > > > ________________________________ > > From: Ian Foster [mailto:foster@mcs.anl.gov] > Sent: 05 April 2005 17:59 > To: Savas Parastatidis; Steve Loughran > Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; > dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; > grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; > mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry; Paul Watson > Subject: RE: [ogsa-wg] RE: Modeling State: Technical Questions > > > > [I'm feeling increasingly bad about sending email to all of the people > CCed here, who may not be interested in these issues at all but got > addressed by Tony long ago...] > > Savas: > > It seems that we are in agreement, then, that we want the ability to: > > a) Request operations on individual jobs identified by some sort of > "jobid" > > b) Request operations on sets of jobs identified by a user-supplied list > of "jobids" > > c) Request operations on sets of jobs identified by more abstract > criteria > > We also agree that (as I expressed in the email that started this > discussion) such requests can be expressed in a few different ways, with > somewhat different characteristics. > > That's progress I hope. > > Ian. > > At 02:44 PM 4/5/2005 +0100, Savas Parastatidis wrote: > > > > > Dear Ian, > > > > I dont think that the approach I proposed forces the user to do more > than they would have to do anyway if EPRs were used. It is still the > case that someone has to manage the EPRs to the resources in WSRF. This > is similar to what happens in the real world. The online bookstore will > ask for my credit card number (a URI), or the book store will as for an > ISBN (another URI) or multiple ISBNs if I want to buy multiple books. > The banking service will ask for my bank account number (another URI > perhaps). > > > > Also, there is no reason why a kill all my jobsmessage couldnt also be > supported. But please note that this message is now addressed to the > service (the container of resources) and not, as in the case of WSRF, to > a specific resource. This is no different from what I am advocating. > > > > Also& to Steves point about partial failure. If one wishes atomic > transaction semantics, I dont see the difference from the two > approaches& > > > > Atomic > > Msg -> resource 1 > > Msg -> resource 2 > > Msg -> resource 3 > > End Atomic > > > > Vs > > > > Msg > > Atomic > > Resource 1 > > Resource 2 > > Resource 3 > > End Atomic > > > > In fact, I would argue that the latter is better because: > > > > 1. It uses fewer messages (and, Steve, I am not assuming only HTTP and > the optimisations that may be supported) > > > > 2. I can more easily deal with the failures in an application > specific-manner since my atomic TX semantics do not span multiple msgs. > > > > (Anyway& who wants to do atomic TXs over the Web anyway? :-) > > > > Regards, > > -- > Savas Parastatidis > http://savas.parastatidis.name > > > > > From: Ian Foster [mailto:foster@mcs.anl.gov] > Sent: Tuesday, April 05, 2005 2:22 PM > To: Steve Loughran; Savas Parastatidis > Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; > dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; > grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; > mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry > Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions > > > > Steve's note raises a key point for me: do we really want to force the > user (as Savas seems to be advocating) to keep track of jobs running at > a remote site? > > I'd rather send a request "kill all my jobs" or "kill all my jobs that > have run for more than a day" to the factory than carefully keep track > of all jobs that I have active, and how long they have been running, so > that I can send the big document (or stream) discussed below. > > Ian. > > > At 02:10 PM 4/5/2005 +0100, Steve Loughran wrote: > > Savas Parastatidis wrote: > > Dear all, > I think something needs to be clarified with regards to handling > multiple jobs with one message. The beauty of document-oriented > interactions is that you can do things like... > <job-details-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> > </job-details-request> > Or > <job-suspend-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> > </job-suspend-request> > The schema for the above document can allow anything from 0 to N number > of <job-id> elements. > > > the trouble with any bulk operation is you have to handle partial > failure. You need either atomic operations (not long lived transactions > over HTTP Savas, I wouldn't be that daft), or a way of indicating that > only a bit went wrong > > Hence the 207 Multi-Status response in WebDav, the "something failed, > look in the message". WebDav is still single instance (here a RESTy > URL), but you can set >1 property and so have partial failure. > > SOAP just has SOAPFault and extensions; no explicit multiple failure > response. WS-RF-ResourceProperties has a similar problem with > SetResourceProperties, but a different failure model in which any > failure to set can result in a WS-BaseFault, indicating which failed, > but providing no apparent information on which worked. > > It seems to me that if you want to bulk stuff, you do need ways of (a) > handling partial failure and (b) declaring what happens on partial > failure. For the curions, WebDav's failure mode on file operations > (MOVE, COPY) is explicitly declared to be that of failed file operations > of Win98 on a FAT32 filesystem [1,2] > > Alternatively, you dont go for bulk operations, neither on a multiple > jobs, or on multiple properties of a job (remember, WS-RF doesn't > declare atomic/transacted property operations, so all you do here is > increase the window of instability, a window that already exists). > Instead you just stream a series of operations over the same HTTP1.1 > connection -assuming that everything is accessible at the same far-end > host, and get a series of (potentially out of order, we are talking > HTTP1.1) responses. > > This could be efficient, and you could do better handling of failure. > But you do need a SOAP stack that can keep an HTTP1.1 channel open for > multiple requests. Axis doesnt, even if you get httpclient to do the > HTTP work; I don't know about .NET/WSE. You also need developers to > model the communication correctly. Manipulating JAXRPC proxies as if > they represent remote objects is *clearly* the wrong way to do it. You'd > almost want to model a queue of requests waiting to be POSTed, a queue > you can fill up then push out. Something like this, in your Java-era > language of choice :- > > //different queues for SOAP, REST > Queue q=new Soap12RequestQueue(); > > q.add(new StatePut(job1.uri,Job.LIFECYCLE,Job.SUSPENDED)); > //let the queue reorder stuff if it wants to > q.add(new > StatePut(job2.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_OPTIMAL); > q.add(new > StatePut(job3.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_LAST); > > q.setEventHandler(this); > q.nonBlockingSubmit(); > > No, there is no code behind this example, and I am avoiding any hints as > to what the even handler would look like. I think the key point is that > once you embrace remote operations as async actions, then you can model > the manipulations differently. Note also that I am representing job > suspension not as an explicit suspend() operation, but as a request to > put a job into the suspended state. This API could work with our friend > REST just as easily as with WS-RF... > > Anyway Savas, to conclude: do you have any evidence that a single > document is suboptimal compared to a sequences of requests over an open > HTTP/1.1 connection? That is, assuming we ignore the SHOULD in the > HTTP1.1 specification " Clients SHOULD NOT pipeline requests using > non-idempotent methods or non-idempotent sequences of methods" [3] > > -Steve > > > [1] WebDav http://www.ietf.org/rfc/rfc2518.txt S8.9.2 > > "after encountering an error moving a non-collection > resource as part of an infinite depth move, the server SHOULD try to > finish as much of the original move operation as possible." > > [2] > http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html > > [3] RFC2616 HTTP1.1 > > _______________________________________________________________ > Ian Foster www.mcs.anl.gov/~foster > Math & Computer Science Div. Dept of Computer Science > Argonne National Laboratory The University of Chicago > Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. > Tel: 630 252 4619 Fax: 630 252 1997 > Globus Alliance, www.globus.org <http://www.globus.org/> > > _______________________________________________________________ > Ian Foster www.mcs.anl.gov/~foster > Math & Computer Science Div. Dept of Computer Science > Argonne National Laboratory The University of Chicago > Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. > Tel: 630 252 4619 Fax: 630 252 1997 > Globus Alliance, www.globus.org <http://www.globus.org/> > >

7 6

ByteIO charter: ready for GFSG?
by Dave Berry 07 Apr '05

07 Apr '05

Dear all, I'd like, if possible, to send the draft charter for the OGSA ByteIO group to the GFSG before their next meeting on Tuesday. See the attachment for a version that I've updated in the light of comments received. Please send any comments to the co-chairs and me by Sunday. If there are no unresolved issues I'll submit it to the GFSG on Monday, for discussion at their meeting on Tuesday. They will then make it open for comment for another 7 days. If there are unresolved issues, we can discuss them on next Tuesday's telcon (details to follow). Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

New tracker (for Profile template document)
by Andreas Savva 07 Apr '05

07 Apr '05

>From the Apr 6 minutes: > Action: Andreas to create a tracker for the template document I have created a new tracker for issues relating to the OGSA profile template document.(http://tinyurl.com/5fxfd/draft-ggf-ogsa-profile-template/en/) The new tracker is called "Profile template" https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… and is set to send mail to the list on new artifact submissions only. The status fields are set up in the same way as for the Basic Profile Tracker. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

DRAFT OGSA Evolution Policy Statement (call for review)
by Hiro Kishimoto 07 Apr '05

07 Apr '05

Hi all, Since the OGSA is GGF's flagship architecture, the GFSG has been working on a policy surrounding the creation of profiles for OGSA. David Snelling, our Area Director, has done a FIRST DRAFT ("The OGSA Evolution Policy Statement"). At the OGSA call today, attendants reviewed and discussed on this first draft (see meeting minutes also) and agreed to send it out to the mailing list to open discussion. Please read this draft and give your feedback. David and I will bring your feedback to GFSG to improve the policy statement. Thanks, ---- Hiro Kishimoto

1 0

Teleconference minutes - 6 April 2005
by Andreas Savva 07 Apr '05

07 Apr '05

Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050406/en/1 aka http://tinyurl.com/5fxfd/minutes-20050406/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 6 April 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Dave Berry (NeSC) Ian Foster (ANL) Soonwook Hwang (NII) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Kazushige Saga (NII) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ravi Subramaniam (Intel) Jem Treadwell (HP) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * Teleconference minutes April 4 Minutes approved with changes Corrections: (Mark) - May F2F: EMS was confirmed for Monday - Allen's name is mispelled * Byte IO charter During an earlier review it was proposed that since the OGSA Basic Profile 1.0 is not yet published the charter should mention that the WG will start work with a draft version of the Profile and move to the final version later on. To minimize synchronization work it was suggested to pick a draft version to work from and only when the WG's specification gets close to publication synchronize with a later or final version of the BP. There is no BoF ML set up yet. So it was agreed to mail a final draft charter to the ogsa-wg-ml and other interested parties and ask for comments. There is no problem with not setting up a call specifically to discuss the draft charter. Once that is done, incorporate any feedback and submit a final version of the charter to the AD. Since the GFSG call is on Tuesday it is important to get this to the AD fairly soon. (It was also suggested that important emails from the Byte IO WG should also be sent to ogsa-wg-ml as part of liaison work. Obviously there is no need to cross-post everything.) * OGSA evolution policy statement This is a new document written by Dave S for the GGF (GFSG). "Drawer statement": A (M.Linesch) term describing documents that may not be completely public (but not secret) and are used for reference when needed (kept in a drawer). The intention is, however, to send this document out to the ogsa-wg-ml for more comments. OGSA is high profile especially after GGF's adoption of OGSA as a "flagship architecture." There are some concerns raised with OGSA adopting one specific approach. This document tries address those concerns based on the consensus of the December OGSA F2F. Three levels of interoperability - At infrastructure layer (based on WS standards) - (OGSA version 1.0 (aka GFD.30) definition of infrastructure also includes WSRF and WSDM. This definition is inconsistent with the definition in this document. Needs clarification.) - At the highest level based on GFD.30 - (From a technical perspective it is not really meaningful to talk about interoperability at this level) - At the middle level based on profile definitions - Consistency between GFD.30 and profiles is mentioned but is this a vacuous statement at the moment? - Consistency is a work in progress. - There is a plan/desire to produce more detailed architectural documents per capability - Concerns that the way this document is written any profile can be ogsa so resulting in a tower of babel. - Is it possible that profiles can be inconsistent with each other? - Inconclusive discussion on the consensus of the Dec or Feb meeting. - From a technical point of view it is not meaningful to allow inconsistent profiles (so this statement seems to be politically motivated) - Technical vs branding issues - Who controls the OGSA name/brand and who can state that a profile is part of ogsa - If the OGSA 'brand' is important then it should not be 'diluted' by allowing anything to be OGSA. - E.g., is it possible to issue BP and then state that all other profiles should be consistent/build on top of this profile? - And a stronger statement could be that the higher profiles are unique for individual GFD.30 features/components - Might also need to work from top down to articulate the architecture further (something that could be done later) - Is there such a thing as a middle level profile (?architectural profile?) and what does it mean for interoperability - Profiles are concrete and talk about specific conformance targets so such a profile is not possible - Even though potentially this document allows for a tower of babel situation logistically it would be difficult to find the people to define the profiles/specifications currently being worked on. (So it seems like a small risk.) - Proposal for defining a process/policy by which only certain documents can use the OGSA name: - At the moment once a WG is formed it is accountable to the GFSG only; there is no formal mechanism for one WG to affect another except by individual member participation. - So some extra layer to allow OGSA-WG to 'control' such documents from other WGs would be needed. - The current process allows for feedback to documents during the public comment period and that could be the place to raise objections to inappropriate usage of the OGSA term. Action: - Send the document out to the list and continue this discussion there. (Hiro) - Dave S will feedback this discussion back to the GFSG * OGSA Profile definition (profile template) review - Existing issue with copyright affected text (text copied from WS-I basic profile): - Hiro has confirmed that it is not allowed to copy-paste this text. Even if GGF becomes a WS-I associate member, membership only provides early access to WS-I materials. Action: Delete the copyrighted text from the OGSA basic profile and template documents. (Dave S and Tom) - Reference the WS-I document instead - The status and adoption levels are the main contributions of the template document: - It is expected that profiles categorize specs used in this way - Level of adoption: for a profile it affects the transition from proposed recommendation to recommendation. Action: Make this kind of information for each referenced spec a required appendix for profiles and include an example in this document. (Dave S) - "Security considerations" is typically the last section in GGF documents. Action: Fix order of the "Profile type distinction" section and the "Security considerations" section. (Dave S) - Section 5.1: Should the term "informational profile" be changed to the more commonly used "candidate profile" - Dave S prefers "informational" but maybe "candidate" is already well established. No change for now. - Section 5.3: - It is incorrect to include "evolving standard" as an allowed status here. - "Published recommendation" should be "Grid recommendation" Action: Dave S to update the document with the above corrections - Section 5.2: - It was proposed to also delete 'Evolving standard' from this section. - A proposed recommendation becomes a recommendation after implementation and an experience report so the standards it is based on should not be 'evolving'. - The downside is that a lot of referred work may be in progress making this requirement too restrictive - No decision reached. Need to revisit in order to clarify which 'milestones' are being assumed. E.g., is it acceptable to use evolving specs up to submission but make sure they are updated before submission or not. - The adoption levels of section 5.2 and 5.3 should probably be the other way round. Dave S to correct. - Agreed that this document should be submitted as an information document by GGF14 Action: Andreas to create a tracker for the template document * AOB - Next call (Monday) is new WG status call - It is not clear if there is a Naming BoF list. - A BES BoF list seems to be setup (OGSA-BES-bof(a)ggf.org)

1 0

Re: [ogsa-wg] RE: Modeling State: Technical Questions
by Steve Loughran 06 Apr '05

06 Apr '05

I have this theory, it's #2 of my "silly but possibly valid theories":- Any technology other than an RDBMS that implements a SELECT statement is inherently over-complex I would cite SLPv2 and that EJB query language [1] as two examples to back up my claim, with UDDI lurking nearby. I also note that it is badly escaped SQL select statements that are a primary attack point into custom HTTP apps, and even more often, custom SOAP endpoints [2]. There is something about the "let's do a SELECT" operation that gets people excited, but you soon end up with something that is hard to implement, test and interop test against, or you have to hand it off to a real DB underneath. Yes, bits of XPath fall in to this category too. If we are going to have select statements, at least be rigorous about requiring quotes around strings, for security reasons: “where (jobid = 'urn:guid:364') or (jobid = 'urn:guid:401')” -steve [1] http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBQL5.html [2] http://ws.apache.org/axis/java/security.html Paul Watson wrote: > > > Ian, > > > > I agree that this is good progress. So let’s bank that and see if we can > we can agree on one more thing, and then I’ll ask a question. > > > > Considering your list of abilities (a, b & c) below, do we agree that in > terms of expressiveness, the ordering is: > > > > c>b>a > > > > i.e. using approach c, a client can request operations on: > > a) single jobs: “where (jobid = urn:guid:364)” > > b) sets of jobs: “where (jobid = urn:guid:364) or (jobid = urn:guid:401)” > > > > If there is agreement on this, then we could move on to discussing why > it is felt necessary to provide more than just c for the job submission > service. > > > > Regards > > Paul > > > > Ian wrote… > >>Savas: > >> > >>It seems that we are in agreement, then, that we want the ability to: > >> > >>a) Request operations on individual jobs identified by some sort of "jobid" > >> > >>b) Request operations on sets of jobs identified by a user-supplied list > of "jobids" > >> > >>c) Request operations on sets of jobs identified by more abstract criteria > >> > >>We also agree that (as I expressed in the email that started this > discussion) such >requests can be expressed in a few different ways, > with somewhat different >characteristics. > >> > >>That's progress I hope. > >> > >>Ian. > > > > * From: * Ian Foster [mailto:foster@mcs.anl.gov] > *Sent:* 05 April 2005 17:59 > *To:* Savas Parastatidis; Steve Loughran > *Cc:* Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; > ogsa-wg; dave.pearson(a)oracle.com; gray(a)microsoft.com; > humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; aherbert(a)microsoft.com; > gcf(a)indiana.edu ; mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave > Berry; Paul Watson > *Subject:* RE: [ogsa-wg] RE: Modeling State : Technical Questions > > > > [I'm feeling increasingly bad about sending email to all of the people > CCed here, who may not be interested in these issues at all but got > addressed by Tony long ago...] > > Savas: > > It seems that we are in agreement, then, that we want the ability to: > > a) Request operations on individual jobs identified by some sort of "jobid" > > b) Request operations on sets of jobs identified by a user-supplied list > of "jobids" > > c) Request operations on sets of jobs identified by more abstract criteria

2 1

London F2F for data, May 25th - who's coming
by Dave Berry 06 Apr '05

06 Apr '05

All, We are holding a F2F meeting for OGSA data on May 25th, following the main OGSA WG F2F on May 23rd-24th. Most of the day will be on the Data Architecture document - we plan to have a significant revision ready at least a week beforehand. There will also be a session on ByteIO as well, either as a parallel session or for part of the time. Please can you let me know if you can attend this day? It would be great to have some of the main OGSA WG people there as well. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

[ogsa-wg | Basic Profile - 1355] Basic Discovery Properties
by Sourceforge Tracker Monitor 06 Apr '05

06 Apr '05

A new artifact has been added: 1355 Submitted by: David Snelling Submitted date: 2005-04-06 10:39:21 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1355&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1355&group_id…) Summary: Basic Discovery Properties Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1355 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: David Snelling Last Modified: 2005-04-06 10:39:21 Submitted By: David Snelling Submit Date: 2005-04-06 10:39:21 Assigned To: &lt;None&gt; File(s): <None> Description: In addition to the ResourcePropertyNames RP, we should also require other basic discovery mechanisms. FinalResourceInterface - QName of the most derived portType of the resource 0..1 ResourceInterface - QName of a portTypes mixed into the FinalResourceInterface 0..n ResourceEndPointReference - An EPR to this Resource 0..n View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Minutes of April 4th Telecon
by Hiro Kishimoto 06 Apr '05

06 Apr '05

Hi all, As you may already know, Mark has uploaded his excellent minutes on the GridForge. Have a look and approve it at the call tomorrow. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050404/en/1 Many thanks Mark! ---- Hiro Kishimoto

1 0

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Hiro Kishimoto 06 Apr '05

06 Apr '05

Paul's email bounced. ---- Hiro Kishimoto Subject: RE: [ogsa-wg] RE: Modeling State: Technical Questions Date: Tue, 5 Apr 2005 20:20:09 +0100 From: "Paul Watson" <Paul.Watson(a)newcastle.ac.uk> To: "Ian Foster" <foster(a)mcs.anl.gov>, "Savas Parastatidis" <Savas.Parastatidis(a)newcastle.ac.uk>, "Steve Loughran" <steve_loughran(a)hpl.hp.com> Ian, I agree that this is good progress. So let's bank that and see if we can we can agree on one more thing, and then I'll ask a question. Considering your list of abilities (a, b & c) below, do we agree that in terms of expressiveness, the ordering is: c>b>a i.e. using approach c, a client can request operations on: a) single jobs: "where (jobid =3D urn:guid:364)" b) sets of jobs: "where (jobid =3D urn:guid:364) or (jobid =3D urn:guid:401)" If there is agreement on this, then we could move on to discussing why it is felt necessary to provide more than just c for the job submission service. Regards Paul Ian wrote... >Savas: > >It seems that we are in agreement, then, that we want the ability to: > >a) Request operations on individual jobs identified by some sort of "jobid" > >b) Request operations on sets of jobs identified by a user-supplied list of "jobids" > >c) Request operations on sets of jobs identified by more abstract criteria > >We also agree that (as I expressed in the email that started this discussion) such >requests can be expressed in a few different ways, with somewhat different >characteristics. > >That's progress I hope. > >Ian. ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 05 April 2005 17:59 To: Savas Parastatidis; Steve Loughran Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch@hp. com; Frank Siebenlist; Tony Hey; Dave Berry; Paul Watson Subject: RE: [ogsa-wg] RE: Modeling State: Technical Questions [I'm feeling increasingly bad about sending email to all of the people CCed here, who may not be interested in these issues at all but got addressed by Tony long ago...] Savas: It seems that we are in agreement, then, that we want the ability to: a) Request operations on individual jobs identified by some sort of "jobid" b) Request operations on sets of jobs identified by a user-supplied list of "jobids" c) Request operations on sets of jobs identified by more abstract criteria We also agree that (as I expressed in the email that started this discussion) such requests can be expressed in a few different ways, with somewhat different characteristics. That's progress I hope. Ian. At 02:44 PM 4/5/2005 +0100, Savas Parastatidis wrote: Dear Ian, I dont think that the approach I proposed forces the user to do more than they would have to do anyway if EPRs were used. It is still the case that someone has to manage the EPRs to the resources in WSRF. This is similar to what happens in the real world. The online bookstore will ask for my credit card number (a URI), or the book store will as for an ISBN (another URI) or multiple ISBNs if I want to buy multiple books. The banking service will ask for my bank account number (another URI perhaps). Also, there is no reason why a kill all my jobsmessage couldnt also be supported. But please note that this message is now addressed to the service (the container of resources) and not, as in the case of WSRF, to a specific resource. This is no different from what I am advocating. Also& to Steves point about partial failure. If one wishes atomic transaction semantics, I dont see the difference from the two approaches& Atomic Msg -> resource 1 Msg -> resource 2 Msg -> resource 3 End Atomic Vs Msg Atomic Resource 1 Resource 2 Resource 3 End Atomic In fact, I would argue that the latter is better because: 1. It uses fewer messages (and, Steve, I am not assuming only HTTP and the optimisations that may be supported) 2. I can more easily deal with the failures in an application specific-manner since my atomic TX semantics do not span multiple msgs. (Anyway& who wants to do atomic TXs over the Web anyway? :-) Regards, -- Savas Parastatidis http://savas.parastatidis.name From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Tuesday, April 05, 2005 2:22 PM To: Steve Loughran; Savas Parastatidis Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch@hp. com; Frank Siebenlist; Tony Hey; Dave Berry Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions Steve's note raises a key point for me: do we really want to force the user (as Savas seems to be advocating) to keep track of jobs running at a remote site? I'd rather send a request "kill all my jobs" or "kill all my jobs that have run for more than a day" to the factory than carefully keep track of all jobs that I have active, and how long they have been running, so that I can send the big document (or stream) discussed below. Ian. At 02:10 PM 4/5/2005 +0100, Steve Loughran wrote: Savas Parastatidis wrote: Dear all, I think something needs to be clarified with regards to handling multiple jobs with one message. The beauty of document-oriented interactions is that you can do things like... <job-details-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> </job-details-request> Or <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> </job-suspend-request> The schema for the above document can allow anything from 0 to N number of <job-id> elements. the trouble with any bulk operation is you have to handle partial failure. You need either atomic operations (not long lived transactions over HTTP Savas, I wouldn't be that daft), or a way of indicating that only a bit went wrong Hence the 207 Multi-Status response in WebDav, the "something failed, look in the message". WebDav is still single instance (here a RESTy URL), but you can set >1 property and so have partial failure. SOAP just has SOAPFault and extensions; no explicit multiple failure response. WS-RF-ResourceProperties has a similar problem with SetResourceProperties, but a different failure model in which any failure to set can result in a WS-BaseFault, indicating which failed, but providing no apparent information on which worked. It seems to me that if you want to bulk stuff, you do need ways of (a) handling partial failure and (b) declaring what happens on partial failure. For the curions, WebDav's failure mode on file operations (MOVE, COPY) is explicitly declared to be that of failed file operations of Win98 on a FAT32 filesystem [1,2] Alternatively, you dont go for bulk operations, neither on a multiple jobs, or on multiple properties of a job (remember, WS-RF doesn't declare atomic/transacted property operations, so all you do here is increase the window of instability, a window that already exists). Instead you just stream a series of operations over the same HTTP1.1 connection -assuming that everything is accessible at the same far-end host, and get a series of (potentially out of order, we are talking HTTP1.1) responses. This could be efficient, and you could do better handling of failure. But you do need a SOAP stack that can keep an HTTP1.1 channel open for multiple requests. Axis doesnt, even if you get httpclient to do the HTTP work; I don't know about .NET/WSE. You also need developers to model the communication correctly. Manipulating JAXRPC proxies as if they represent remote objects is *clearly* the wrong way to do it. You'd almost want to model a queue of requests waiting to be POSTed, a queue you can fill up then push out. Something like this, in your Java-era language of choice :- //different queues for SOAP, REST Queue q=3Dnew Soap12RequestQueue(); q.add(new StatePut(job1.uri,Job.LIFECYCLE,Job.SUSPENDED)); //let the queue reorder stuff if it wants to q.add(new StatePut(job2.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_OPTIMAL); q.add(new StatePut(job3.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_LAST); q.setEventHandler(this); q.nonBlockingSubmit(); No, there is no code behind this example, and I am avoiding any hints as to what the even handler would look like. I think the key point is that once you embrace remote operations as async actions, then you can model the manipulations differently. Note also that I am representing job suspension not as an explicit suspend() operation, but as a request to put a job into the suspended state. This API could work with our friend REST just as easily as with WS-RF... Anyway Savas, to conclude: do you have any evidence that a single document is suboptimal compared to a sequences of requests over an open HTTP/1.1 connection? That is, assuming we ignore the SHOULD in the HTTP1.1 specification " Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods" [3] -Steve [1] WebDav http://www.ietf.org/rfc/rfc2518.txt S8.9.2 "after encountering an error moving a non-collection resource as part of an infinite depth move, the server SHOULD try to finish as much of the original move operation as possible." [2] http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html [3] RFC2616 HTTP1.1 _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/> _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

1 0

EM resource modeling (GLUE vs CIM)
by Fred Maciel 05 Apr '05

05 Apr '05

Hi all, > As soon as you start trying to organize or decompose this space according > to conceptual interface rather than implementation, you run headlong > into the community modeling tar-pit. The problem is, in OGSA we are just starting to tackle this, starting by execution management. Welcome to the tar pit! :-) We are starting by comparing GLUE, JSDL, and CIM (including JSIM). This should help defining a resource model for the container and other entities. BTW, here goes a request. Some people had already done a comparison of CIM and GLUE long ago, but we don't know who still have the files with the results. Do you have these files, or know anybody who participated in this work who might have them? Thanks in advance, Fred Maciel.

1 0

Data: restructured "straw man" document
by Dave Berry 05 Apr '05

05 Apr '05

Dear all, I have uploaded a new version of the data architecture "straw man" -- see http://tinyurl.com/5de69. This version has a simpler structure. I've drastically shortened the overview section and now each capability has its own section. This should make it easy to contribute sections, e.g. on data access, replication, etc. I think it also makes the document easier to read. Please take a look and let me know of any comments. Reminder: we are having a short telcon tomorrow, starting at 7.45am PDT / 10.45am EDT / 3.45pm BST / 4.45 pm CEST. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Ian Foster 05 Apr '05

05 Apr '05

Savas: I think your email misses the point of the current discussion. Of course, as you point out, if I have a handle of some sort for a job (a WS-Addressing EPR, as in WSRF/WS-Transfer, or a job-id, as you advocate below), then I can include several of these in a request to the job factory asking for some operation to be performed on them all. I don't believe that anyone's debating that. But that's not the topic of the recent thread. What Mark and Karl are discussing is how you would express more abstract requests such as "kill all jobs that have consumed more than one hour's CPU time." This is a question of query languages, I presume, not modeling of job ids. Ian. At 01:10 PM 4/5/2005 +0100, Savas Parastatidis wrote: >Dear all, > >I think something needs to be clarified with regards to handling >multiple jobs with one message. The beauty of document-oriented >interactions is that you can do things like... > ><job-details-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> ></job-details-request> > >Or > ><job-suspend-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> ></job-suspend-request> > >The schema for the above document can allow anything from 0 to N number >of <job-id> elements. > >What WS-RF and WS-Transfer and REST are doing is require that each >message be directed to only one resource. As a result, when it comes to >defining groups of resources, additional resources (representing >collections) have to be created. Populating and managing the collections >require additional messages. > >The WS-RF/Ws-Transfer/REST model is a special case of the >document-oriented model I described above... > > ><job-suspend-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> ></job-suspend-request> > >In the WS-RF/WS-Transfer case the job ID will have to be part of the >wsa:To (wsa -> WS-Addressing) header. In REST, it is the URI on which >the operations are called (if we are using HTTP and the HTTP verbs, then >the URI usually has the 'http' prefix). > >An example, of a WS-Addresing EPR... > ><my:MyEndpointReference> > <wsa:Address> urn:ogsa:job:guid:bla-bla-bla-002</wsa:Address> ></my:MyEndpointReference> > >Please note that the address doesn't have to carry transport/transfer >specific semantics (i.e. it doesn't have to be an 'http' URI). The above >would require a registry look up if that's necessary or perhaps a P2P >network that will know how to direct the message to its destination >based only on the above information. The sender of the message may never >actually see the transport-specific address of the receiving service. > >This means that a SOAP msg like the one bellow will have to be sent... > ><soap:Envelope> > <soap:Header> > <wsa:To>urn:ogsa:job:guid:bla-bla-bla-002</wsa:To> > </soap:Header> > <soap:Body> > <job:job-suspend-request /> > </soap:Body> ></soap:Envelope> > >Well... it turns out that this can by the special case of a message that >looks like this... > ><soap:Envelope> > <soap:Header> > <wsa:To>urn:ogsa:job:service:Newcastle-Job-Service</wsa:To> >  > </soap:Header> > <soap:Body> > <job:job-suspend-request> > <job:job-id>urn:ogsa:job:guid:bla-bla-bla-002</job:job-id> > <job:job-id>urn:ogsa:job:guid:bla-bla-bla-003</job:job-id> > <job:job-id>urn:ogsa:job:guid:bla-bla-bla-004</job:job-id> > </job:job-suspend-request> > </soap:Body> ></soap:Envelope> > >What WS-RF and WS-Transfer seem to be doing is to expose to the wire the >programming abstraction that most of us are used to (i.e. calling >methods on an object). As a result, systems based on a special case are >designed rather than the more general case. It's been our argument all >along that this may not be the most efficient way of designing systems >in general (perhaps in certain application domains the WS-RF/WS-Transfer >approach may be appropriate) but I am prepared to be corrected on this >:-) > >Best regards, >-- >Savas Parastatidis >http://savas.parastatidis.name > _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

2 1

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Ian Foster 05 Apr '05

05 Apr '05

[I'm feeling increasingly bad about sending email to all of the people CCed here, who may not be interested in these issues at all but got addressed by Tony long ago...] Savas: It seems that we are in agreement, then, that we want the ability to: a) Request operations on individual jobs identified by some sort of "jobid" b) Request operations on sets of jobs identified by a user-supplied list of "jobids" c) Request operations on sets of jobs identified by more abstract criteria We also agree that (as I expressed in the email that started this discussion) such requests can be expressed in a few different ways, with somewhat different characteristics. That's progress I hope. Ian. At 02:44 PM 4/5/2005 +0100, Savas Parastatidis wrote: >Dear Ian, > > > >I dont think that the approach I proposed forces the user to do more than >they would have to do anyway if EPRs were used. It is still the case that >someone has to manage the EPRs to the resources in WSRF. This is similar >to what happens in the real world. The online bookstore will ask for my >credit card number (a URI), or the book store will as for an ISBN (another >URI) or multiple ISBNs if I want to buy multiple books. The banking >service will ask for my bank account number (another URI perhaps). > > > >Also, there is no reason why a kill all my jobsmessage couldnt also be >supported. But please note that this message is now addressed to the >service (the container of resources) and not, as in the case of WSRF, to a >specific resource. This is no different from what I am advocating. > > > >Also& to Steves point about partial failure. If one wishes atomic >transaction semantics, I dont see the difference from the two approaches& > > > >Atomic > > Msg -> resource 1 > > Msg -> resource 2 > > Msg -> resource 3 > >End Atomic > > > >Vs > > > >Msg > > Atomic > > Resource 1 > > Resource 2 > > Resource 3 > > End Atomic > > > >In fact, I would argue that the latter is better because: > > > >1. It uses fewer messages (and, Steve, I am not assuming only HTTP and the >optimisations that may be supported) > > > >2. I can more easily deal with the failures in an application >specific-manner since my atomic TX semantics do not span multiple msgs. > > > >(Anyway& who wants to do atomic TXs over the Web anyway? :-) > > > >Regards, > >-- >Savas Parastatidis ><http://savas.parastatidis.name>http://savas.parastatidis.name > > >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Tuesday, April 05, 2005 2:22 PM >To: Steve Loughran; Savas Parastatidis >Cc: Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; >dave.pearson(a)oracle.com; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; >grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; >mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry >Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions > > > >Steve's note raises a key point for me: do we really want to force the >user (as Savas seems to be advocating) to keep track of jobs running at a >remote site? > >I'd rather send a request "kill all my jobs" or "kill all my jobs that >have run for more than a day" to the factory than carefully keep track of >all jobs that I have active, and how long they have been running, so that >I can send the big document (or stream) discussed below. > >Ian. > > >At 02:10 PM 4/5/2005 +0100, Steve Loughran wrote: > >Savas Parastatidis wrote: > >Dear all, >I think something needs to be clarified with regards to handling >multiple jobs with one message. The beauty of document-oriented >interactions is that you can do things like... ><job-details-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> ></job-details-request> >Or ><job-suspend-request> > <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> > <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> ></job-suspend-request> >The schema for the above document can allow anything from 0 to N number >of <job-id> elements. > > >the trouble with any bulk operation is you have to handle partial failure. >You need either atomic operations (not long lived transactions over HTTP >Savas, I wouldn't be that daft), or a way of indicating that only a bit >went wrong > >Hence the 207 Multi-Status response in WebDav, the "something failed, look >in the message". WebDav is still single instance (here a RESTy URL), but >you can set >1 property and so have partial failure. > >SOAP just has SOAPFault and extensions; no explicit multiple failure >response. WS-RF-ResourceProperties has a similar problem with >SetResourceProperties, but a different failure model in which any failure >to set can result in a WS-BaseFault, indicating which failed, but >providing no apparent information on which worked. > >It seems to me that if you want to bulk stuff, you do need ways of (a) >handling partial failure and (b) declaring what happens on partial >failure. For the curions, WebDav's failure mode on file operations (MOVE, >COPY) is explicitly declared to be that of failed file operations of Win98 >on a FAT32 filesystem [1,2] > >Alternatively, you dont go for bulk operations, neither on a multiple >jobs, or on multiple properties of a job (remember, WS-RF doesn't declare >atomic/transacted property operations, so all you do here is increase the >window of instability, a window that already exists). Instead you just >stream a series of operations over the same HTTP1.1 connection -assuming >that everything is accessible at the same far-end host, and get a series >of (potentially out of order, we are talking HTTP1.1) responses. > >This could be efficient, and you could do better handling of failure. But >you do need a SOAP stack that can keep an HTTP1.1 channel open for >multiple requests. Axis doesnt, even if you get httpclient to do the HTTP >work; I don't know about .NET/WSE. You also need developers to model the >communication correctly. Manipulating JAXRPC proxies as if they represent >remote objects is *clearly* the wrong way to do it. You'd almost want to >model a queue of requests waiting to be POSTed, a queue you can fill up >then push out. Something like this, in your Java-era language of choice :- > >//different queues for SOAP, REST >Queue q=new Soap12RequestQueue(); > >q.add(new StatePut(job1.uri,Job.LIFECYCLE,Job.SUSPENDED)); >//let the queue reorder stuff if it wants to >q.add(new >StatePut(job2.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_OPTIMAL); >q.add(new StatePut(job3.uri,Job.LIFECYCLE,Job.SUSPENDED),Queue.POSITION_LAST); > >q.setEventHandler(this); >q.nonBlockingSubmit(); > >No, there is no code behind this example, and I am avoiding any hints as >to what the even handler would look like. I think the key point is that >once you embrace remote operations as async actions, then you can model >the manipulations differently. Note also that I am representing job >suspension not as an explicit suspend() operation, but as a request to put >a job into the suspended state. This API could work with our friend REST >just as easily as with WS-RF... > >Anyway Savas, to conclude: do you have any evidence that a single document >is suboptimal compared to a sequences of requests over an open HTTP/1.1 >connection? That is, assuming we ignore the SHOULD in the HTTP1.1 >specification " Clients SHOULD NOT pipeline requests using non-idempotent >methods or non-idempotent sequences of methods" [3] > >-Steve > > >[1] WebDav http://www.ietf.org/rfc/rfc2518.txt S8.9.2 > >"after encountering an error moving a non-collection > resource as part of an infinite depth move, the server SHOULD try to > finish as much of the original move operation as possible." > >[2] http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html > >[3] RFC2616 HTTP1.1 > >_______________________________________________________________ >Ian Foster www.mcs.anl.gov/~foster >Math & Computer Science Div. Dept of Computer Science >Argonne National Laboratory The University of Chicago >Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. >Tel: 630 252 4619 Fax: 630 252 1997 > Globus Alliance, www.globus.org _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

1 0

RE: [ogsa-wg] Telcon for OGSA ByteIO WG charter
by Dave Berry 05 Apr '05

05 Apr '05

Sorry about this... We are postponing to next week. Dave. > -----Original Message----- > From: Dave Berry > Sent: 05 April 2005 16:28 > To: Dave Berry; ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen > Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke > (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; > Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; > Stephen Langella; Shannon Hastings; Manuel Pereira; Ted > Anderson; Leo Luan; Mark M. Morgan > Subject: RE: [ogsa-wg] Telcon for OGSA ByteIO WG charter > > There was a mixup with the telcon booking - it's sorted now. > If you were trying to call in, please try again. > > Dave > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > > Behalf Of Dave Berry > > Sent: 01 April 2005 11:42 > > To: ogsa-wg > > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen > > Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke > > (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; > > Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; > > Stephen Langella; Shannon Hastings; Manuel Pereira; Ted > > Anderson; Leo Luan; Mark M. Morgan > > Subject: [ogsa-wg] Telcon for OGSA ByteIO WG charter > > > > Dear all, > > > > The ByteIO group plans on having it's first telecon next > > Tuesday at 11AM > > Eastern (8AM Pacific, 4PM UK and midnight in Japan). Our > > agenda for that > > telecon includes the group's first discussion of the > charter. Please > > see the attachments. > > > > > > UK Dial In: 0845 245 0224 > > US Dial In: 1866 838 0046 > > International Dial In: +44 1452 542309 > > > > PIN Number: 632 065 > > > > Best wishes, > > > > > > Dave Berry > > Research Manager, National e-Science Centre > > 15 South College St., Edinburgh > > Tel: +44 131 6514039 > > >

1 0

RE: [ogsa-wg] Telcon for OGSA ByteIO WG charter
by Dave Berry 05 Apr '05

05 Apr '05

There was a mixup with the telcon booking - it's sorted now. If you were trying to call in, please try again. Dave > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Dave Berry > Sent: 01 April 2005 11:42 > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen > Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke > (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; > Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; > Stephen Langella; Shannon Hastings; Manuel Pereira; Ted > Anderson; Leo Luan; Mark M. Morgan > Subject: [ogsa-wg] Telcon for OGSA ByteIO WG charter > > Dear all, > > The ByteIO group plans on having it's first telecon next > Tuesday at 11AM > Eastern (8AM Pacific, 4PM UK and midnight in Japan). Our > agenda for that > telecon includes the group's first discussion of the charter. Please > see the attachments. > > > UK Dial In: 0845 245 0224 > US Dial In: 1866 838 0046 > International Dial In: +44 1452 542309 > > PIN Number: 632 065 > > Best wishes, > > > Dave Berry > Research Manager, National e-Science Centre > 15 South College St., Edinburgh > Tel: +44 131 6514039 >

1 0

RE: Telcon for OGSA ByteIO WG charter
by Allen Luniewski 05 Apr '05

05 Apr '05

I am getting the same message. Allen "Mark Morgan" <mmm2a(a)cs.virginia.edu> 04/05/2005 08:01 AM To "'Dave Berry'" <daveb(a)nesc.ac.uk>, "'ogsa-wg'" <ogsa-wg(a)gridforum.org> cc "'Dave Pearson'" <Dave.Pearson(a)oracle.com>, "'Mario Antonioletti'" <mario(a)epcc.ed.ac.uk>, "'Martin Westhead'" <M.Westhead(a)epcc.ed.ac.uk>, <gtr(a)ast.cam.ac.uk>, <chappella(a)battelle.org>, <arun(a)sdsc.edu>, Jane Xu/San Jose/IBM@IBMUS, <o.tatebe(a)aist.go.jp>, <Yves.Denneulin(a)imag.fr>, <ppadala(a)cise.ufl.edu>, <ivm(a)fnal.gov>, <jalameda(a)ncsa.uiuc.edu>, <annc(a)isi.edu>, Cecile Madsen/Santa Teresa/IBM@IBMUS, <allcock(a)mcs.anl.gov>, "'Allen Luniewski'" <luniew(a)almaden.ibm.com>, "'Malcolm Atkinson'" <mpa(a)nesc.ac.uk>, Susan Malaika/Santa Teresa/IBM@IBMUS, "'Peter Clarke \(UCL\)'" <clarke(a)hep.ucl.ac.uk>, David E Martin/Chicago/IBM@IBMUS, "'Peter Kunszt'" <pkunszt(a)mail.cern.ch>, <Ian.Bird(a)cern.ch>, <Erwin.Laure(a)cern.ch>, <Gavin.Mccance(a)cern.ch>, "'Scott Oster'" <oster(a)bmi.osu.edu>, "'Stephen Langella'" <langella(a)bmi.osu.edu>, "'Shannon Hastings'" <hastings(a)bmi.osu.edu>, Manuel Pereira/Almaden/IBM@IBMUS, Ted Anderson/Almaden/IBM@IBMUS, "'Leo Luan'" <luan(a)almaden.ibm.com> Subject RE: Telcon for OGSA ByteIO WG charter I'm getting a message indicating that this passcode is not recognized. Is anyone else having any luck? -Mark > -----Original Message----- > From: Dave Berry [mailto:daveb@nesc.ac.uk] > Sent: Friday, April 01, 2005 5:42 AM > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen > Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke > (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; > Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; > Stephen Langella; Shannon Hastings; Manuel Pereira; Ted > Anderson; Leo Luan; Mark M. Morgan > Subject: Telcon for OGSA ByteIO WG charter > > Dear all, > > The ByteIO group plans on having it's first telecon next > Tuesday at 11AM Eastern (8AM Pacific, 4PM UK and midnight in > Japan). Our agenda for that telecon includes the group's > first discussion of the charter. Please see the attachments. > > > UK Dial In: 0845 245 0224 > US Dial In: 1866 838 0046 > International Dial In: +44 1452 542309 > > PIN Number: 632 065 > > Best wishes, > > > Dave Berry > Research Manager, National e-Science Centre > 15 South College St., Edinburgh > Tel: +44 131 6514039 >

1 0

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Savas Parastatidis 05 Apr '05

05 Apr '05

Dear all, I think something needs to be clarified with regards to handling multiple jobs with one message. The beauty of document-oriented interactions is that you can do things like... <job-details-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> </job-details-request> Or <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> </job-suspend-request> The schema for the above document can allow anything from 0 to N number of <job-id> elements. What WS-RF and WS-Transfer and REST are doing is require that each message be directed to only one resource. As a result, when it comes to defining groups of resources, additional resources (representing collections) have to be created. Populating and managing the collections require additional messages. The WS-RF/Ws-Transfer/REST model is a special case of the document-oriented model I described above...  <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> </job-suspend-request> In the WS-RF/WS-Transfer case the job ID will have to be part of the wsa:To (wsa -> WS-Addressing) header. In REST, it is the URI on which the operations are called (if we are using HTTP and the HTTP verbs, then the URI usually has the 'http' prefix). An example, of a WS-Addresing EPR... <my:MyEndpointReference> <wsa:Address> urn:ogsa:job:guid:bla-bla-bla-002</wsa:Address> </my:MyEndpointReference> Please note that the address doesn't have to carry transport/transfer specific semantics (i.e. it doesn't have to be an 'http' URI). The above would require a registry look up if that's necessary or perhaps a P2P network that will know how to direct the message to its destination based only on the above information. The sender of the message may never actually see the transport-specific address of the receiving service. This means that a SOAP msg like the one bellow will have to be sent... <soap:Envelope> <soap:Header> <wsa:To>urn:ogsa:job:guid:bla-bla-bla-002</wsa:To> </soap:Header> <soap:Body> <job:job-suspend-request /> </soap:Body> </soap:Envelope> Well... it turns out that this can by the special case of a message that looks like this... <soap:Envelope> <soap:Header> <wsa:To>urn:ogsa:job:service:Newcastle-Job-Service</wsa:To>  </soap:Header> <soap:Body> <job:job-suspend-request> <job:job-id>urn:ogsa:job:guid:bla-bla-bla-002</job:job-id> <job:job-id>urn:ogsa:job:guid:bla-bla-bla-003</job:job-id> <job:job-id>urn:ogsa:job:guid:bla-bla-bla-004</job:job-id> </job:job-suspend-request> </soap:Body> </soap:Envelope> What WS-RF and WS-Transfer seem to be doing is to expose to the wire the programming abstraction that most of us are used to (i.e. calling methods on an object). As a result, systems based on a special case are designed rather than the more general case. It's been our argument all along that this may not be the most efficient way of designing systems in general (perhaps in certain application domains the WS-RF/WS-Transfer approach may be appropriate) but I am prepared to be corrected on this :-) Best regards, -- Savas Parastatidis http://savas.parastatidis.name

4 3

RE: [ogsa-wg] RE: Modeling State: Technical Questions
by Savas Parastatidis 05 Apr '05

05 Apr '05

Dear Ian, My apologies... I should have made it clear that I was referring to the beginning of today's thread when the issue of how to address multiple jobs was discussed. Regards, -- Savas Parastatidis http://savas.parastatidis.name ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Tuesday, April 05, 2005 2:08 PM To: Savas Parastatidis; Mark McKeown; Karl Czajkowski Cc: Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; gray(a)microsoft.com; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com; Frank Siebenlist; Tony Hey; Dave Berry Subject: RE: [ogsa-wg] RE: Modeling State: Technical Questions Savas: I think your email misses the point of the current discussion. Of course, as you point out, if I have a handle of some sort for a job (a WS-Addressing EPR, as in WSRF/WS-Transfer, or a job-id, as you advocate below), then I can include several of these in a request to the job factory asking for some operation to be performed on them all. I don't believe that anyone's debating that. But that's not the topic of the recent thread. What Mark and Karl are discussing is how you would express more abstract requests such as "kill all jobs that have consumed more than one hour's CPU time." This is a question of query languages, I presume, not modeling of job ids. Ian. At 01:10 PM 4/5/2005 +0100, Savas Parastatidis wrote: Dear all, I think something needs to be clarified with regards to handling multiple jobs with one message. The beauty of document-oriented interactions is that you can do things like... <job-details-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-001</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-010</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-029</job-id> </job-details-request> Or <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-005</job-id> <job-id>urn:ogsa:job:guid:bla-bla-bla-008</job-id> </job-suspend-request> The schema for the above document can allow anything from 0 to N number of <job-id> elements. What WS-RF and WS-Transfer and REST are doing is require that each message be directed to only one resource. As a result, when it comes to defining groups of resources, additional resources (representing collections) have to be created. Populating and managing the collections require additional messages. The WS-RF/Ws-Transfer/REST model is a special case of the document-oriented model I described above...  <job-suspend-request> <job-id>urn:ogsa:job:guid:bla-bla-bla-002</job-id> </job-suspend-request> In the WS-RF/WS-Transfer case the job ID will have to be part of the wsa:To (wsa -> WS-Addressing) header. In REST, it is the URI on which the operations are called (if we are using HTTP and the HTTP verbs, then the URI usually has the 'http' prefix). An example, of a WS-Addresing EPR... <my:MyEndpointReference> <wsa:Address> urn:ogsa:job:guid:bla-bla-bla-002</wsa:Address> </my:MyEndpointReference> Please note that the address doesn't have to carry transport/transfer specific semantics (i.e. it doesn't have to be an 'http' URI). The above would require a registry look up if that's necessary or perhaps a P2P network that will know how to direct the message to its destination based only on the above information. The sender of the message may never actually see the transport-specific address of the receiving service. This means that a SOAP msg like the one bellow will have to be sent... <soap:Envelope> <soap:Header> <wsa:To>urn:ogsa:job:guid:bla-bla-bla-002</wsa:To> </soap:Header> <soap:Body> <job:job-suspend-request /> </soap:Body> </soap:Envelope> Well... it turns out that this can by the special case of a message that looks like this... <soap:Envelope> <soap:Header> <wsa:To>urn:ogsa:job:service:Newcastle-Job-Service</wsa:To>  </soap:Header> <soap:Body> <job:job-suspend-request> <job:job-id>urn:ogsa:job:guid:bla-bla-bla-002</job:job-id> <job:job-id>urn:ogsa:job:guid:bla-bla-bla-003</job:job-id> <job:job-id>urn:ogsa:job:guid:bla-bla-bla-004</job:job-id> </job:job-suspend-request> </soap:Body> </soap:Envelope> What WS-RF and WS-Transfer seem to be doing is to expose to the wire the programming abstraction that most of us are used to (i.e. calling methods on an object). As a result, systems based on a special case are designed rather than the more general case. It's been our argument all along that this may not be the most efficient way of designing systems in general (perhaps in certain application domains the WS-RF/WS-Transfer approach may be appropriate) but I am prepared to be corrected on this :-) Best regards, -- Savas Parastatidis http://savas.parastatidis.name <http://savas.parastatidis.name/> _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

1 0

RE: Modeling State: Technical Questions
by Ian Foster 05 Apr '05

05 Apr '05

Paul: My apologies for the slow reply: I left on vacation soon after sending my email. Your notes all look good to me. I'm putting together a revised version of my discussion document that trys to capture these and other points. Ian. At 12:14 PM 3/11/2005 +0000, Paul Watson wrote: >Dear Ian, > >Having faithfully promised myself that I wouldn't spend more time on >discussions about low-level WS specs, I found myself drawn in as this is >a very interesting comparison (it reminded me of the excellent work done >in the DAIS WG to compare different approaches to database access >services). In particular, it gives me a concrete example that I can use >to ask some questions about the use of WSRF. Given that I come from a >non-WSRF background (my experience is with services that use the >approach in your option #3) much of what I've written below is about >understanding the motivation for switching to the WSRF approach. But, >I'd like to stress that this isn't intended to be hostile ... it's meant >to improve my understanding and (hopefully) move on the technical >debate. > >I was going to send it to you only, as you offered to collate feedback, >but as Dave Berry is proposing to discuss these options next week (and I >won't be there) and has posted on it, I thought that I'd send it to Dave >and others too as input to these discussions. > > > OPTIONS > > > > 1) (WSRF) > > > > The job handle is an EPR to a WS-Resource, in which case the case the > > WSRF operations can be used to get status and delete: > > > > send "GetResourceProperty(status)" to job-handle > > send "Destroy" to job-handle > > > >If there are other operations that need to be supported on jobs, e.g. >"suspend, resume, checkpoint, change priority"... then am I right in >thinking that these would be provided by application-specific operations >on resources that were not defined by WSRF? > >e.g. send "Suspend" to job-handle, >send "changePriority" to job-handle etc. > > > In addition, one will probably also want to be able to send requests > > to the job-factory, which is straightforward as there is no strong > > encapsulation in WSRF. E.g.: > > > > send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service > >Given previous misunderstandings, it is good to see that your WSRF >example also includes some operations on the service. > >I think that the motivation for introducing operations on the service is >that these can then operate over a set of resources (e.g. >"all-jobs-owned-by-ian"). This reduces the number of messages (e.g. one >interaction with the service vs. one to each resource in the set of >"all-jobs-owned-by-ian"), and also allows the set of resources to be >selected using information encapsulated within the service (e.g. >"jobs-owned-by-ian", "jobs that have nearly reached their quota", "jobs >that have run for more than 24 hours"). Therefore, for similar reasons, >it would, I think, also be beneficial to define a "check-jobs-status" >operation on the service. This would allow, for example: > >check-jobs-status("all-jobs-owned-by-ian") > >Also, as, "all-jobs-owned-by-ian" defines a set of jobs, it would seem >reasonable to allow the consumer to specify the set of jobs by name: > >"destroy(job1,job27,job35)" >"check-jobs-status(job1,job27,job35)" > >(I may be wrong, but I think that the current naming proposal would >allow this by giving the consumer the abstract name for a resource as >well as the epr). > >These operations on the service are the sort I'd expect to see in option >#3 (as I'll explain below). So, I think that one could view option #1 as >taking the operations from option #3 and then adding to them a set of >operations on individual resources. > >These operations on the service allow a consumer to (I think) do >everything without using the operations on individual resources. This is >because these operations address the general case for a job submission >service... they provide operations over the set of resources >encapsulated by the service. They appear to have the advantage of >supporting and encouraging larger-grained operations, e.g. in one >message you can ask about a set of resources rather than just one. I >expect that will be important for performance, given the costs of >sending messages between web services. The operations on individual >resources seem to be a special case of the general case, and this raises >the question (to me) that if the job management service provides the >general case, then when is it better to use the special case? > > > 3) (Job id) The job-handle is a job-factory-specific string, > >I'd think that it could be an "abstract name" in OGSA naming terms >(though the naming proposal isn't fixed yet, so I may be wrong). > > > and we define > > job-factory-specific operations for manipulating the job, e.g.: > > > > send "check-job-status(job-handle)" to job-factory > > send "terminate-job(job-handle)" to job-factory > > > > #3 is very similar to #1 and #2: the message sent over the wire in > > each case contains the same information (operation name + Web service > > address + job-id-info). > >As described in my comments on option #1 above, I'd suggest that both >these operations should be defined to operate on a set of jobs (c.f. >option #1's "destroy(all-jobs-owned-by-ian)). > >e.g. the operations on the service would allow: > >"check-jobs-status(job1, job14,job27)" >"terminate-jobs(job2, job35)" > >Allowing multiple job names in a message is, I think, no more difficult >to implement, and naturally scales up to larger granularity operations >(e.g. one interaction with a service is enough to carry out actions on >1,2 or 500 jobs). > >Option #3 also differs from #1 and #2 as it does not rely on >ws-addressing (though it could use it). [A personal view is that I see >this as an advantage for those who want to design and build services now >or in the near future. This is because the service can use only >currently stable specifications found in the set "blessed" by >WS-Interoperability, and these are provided in an interoperable manner >by a wide range of existing WS platforms.] > > > What is different about #3 is that you have to manage this job-handle > > separately from the job-factory EPR. Also, you don't use the > > standardized WSRF/WSN operations. > > > > Have I captured all of the options that people think we should be > > considering? > > > >I note that Dave & Karl have now posted about the possible use of >ResourceGroups. I based the above on your message which did not discuss >their use, and so I wonder if it would therefore be helpful for someone >to produce a version of option #1 that creates and uses resourcegroups. > >This was a very good start for discussion, and I'd be interested on your >views on my comments above. > >Regards > >Paul. > > >-----Original Message----- > >From: Ian Foster [mailto:foster@mcs.anl.gov] > >Sent: 07 March 2005 04:47 > >To: Tony Hey; Frank Siebenlist > >Cc: Dennis Gannon; Samuel Meder; ogsa-wg; > >paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com; > >savas.parastatidis(a)ncl.ac.uk; gray(a)microsoft.com; > >humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; > >aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com > >Subject: Modeling State: Technical Questions > > > >Dear All: > > > >In an effort to move forward this debate about "OGSA > >plumbing", I thought > >I'd attempt to describe the different positions that I've seen > >expressed. > >Perhaps people can read this quickly, and provide feedback as > >to where I > >have not captured things correctly. I'll be happy to collate > >responses sent > >directly to me and forward them, if there is interest. > > > > > >CONTEXT > > > >The context is that OGSA-WG needs to develop some low-level > >specifications, > >such as execution management services, that require modeling > >interactions > >that involve server-side state. E.g., in the following > >pseudo-code example, > >we request the creation of a "job": > > > > send "create(jsdl-specification)" to job-factory-web-service > > receive "job-handle" from job-factory-web-service > > > >I think that everyone accept that this sort of interaction is > >needed. (Let > >me know if not.) > > > >Where people differ in their views is with respect to what the > >"job-handle" > >should be and how we should represent operations on the job. > >I've heard > >three views expressed, as follows. > > > > > >OPTIONS > > > >1) (WSRF) > > > >The job handle is an EPR to a WS-Resource, in which case the > >case the WSRF > >operations can be used to get status and delete: > > > > send "GetResourceProperty(status)" to job-handle > > send "Destroy" to job-handle > > > >In addition, one will probably also want to be able to send > >requests to the > >job-factory, which is straightforward as there is no strong > >encapsulation > >in WSRF. E.g.: > > > > send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service > > > >This approach exploits the standardized syntax and semantics for the > >various operations (GetResourceProperty, Destroy, etc.) defined by the > >WSRF/WSN specifications. > > > > > >2) (WS-Transfer) > > > >The job-handle is an EPR to a WS-Transfer resource, in which case the > >appropriate WS-Transfer operations can be used to get status > >and delete. > > > > send "Get" to job-handle > > send "Delete" to job-handle > > > >Assuming that there is no strong encapsulation in WS-Transfer > >either, one > >can also contact the job-factory directly when required: > > > > send "destroy(jobs-owned-by-ian)" to job-factory > > > >This approach exploits the syntax and semantics for the > >various operations > >(GetResourceProperty, Destroy, etc.) defined by the > >WS-Transfer specification. > > > >#2 is very similar to #1. One can argue the pros and cons of the two > >approaches. I'm concerned that you have to return the whole > >resource state, > >not just a single component (e.g., the status field). But that's a > >relatively minor issue. > > > > > >3) (Job id) The job-handle is a job-factory-specific string, > >and we define > >job-factory-specific operations for manipulating the job, e.g.: > > > > send "check-job-status(job-handle)" to job-factory > > send "terminate-job(job-handle)" to job-factory > > > >#3 is very similar to #1 and #2: the message sent over the > >wire in each > >case contains the same information (operation name + Web > >service address + > >job-id-info). What is different about #3 is that you have to > >manage this > >job-handle separately from the job-factory EPR. Also, you > >don't use the > >standardized WSRF/WSN operations. > > > >Have I captured all of the options that people think we should > >be considering? > > > > > >WHAT OGSA-WG SHOULD DO > > > >Given this characterization, I'd also be interested in > >people's views as to > >how OGSA-WG should proceed when considering specifications > >that involve > >this sort of interaction pattern. > > > >The majority of active participants OGSA-WG participants seem to favor > >option #1, but I've also heard people argue in favor of > >approaches #2 and #3. > > > >Tony Hey proposed, I think, that we should define > >specifications like job > >management in terms of some more abstract interface that can > >then be mapped > >to each of the approaches above, as desired. > > > >Frank Seibenlist observed that we can use WSRF/WSN as such an abstract > >interface: given an interface defined in terms of WSRF/WSN > >specifications, > >one can derive, via straightforward transformations, a concrete > >specification in the style of approach #2 or #3. > > > >Regards -- Ian. > > > > > > _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

3 5

Re: [ogsa-wg] RE: Modeling State: Technical Questions
by Hiro Kishimoto 05 Apr '05

05 Apr '05

Roger's email bounced. ---- Hiro Kishimoto Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions From: Roger Menday <r.menday(a)fz-juelich.de> To: Karl Czajkowski <karlcz(a)univa.com> Cc: ogsa-wg(a)gridforum.org, Mark McKeown <zzalsmm3(a)nessie.mcc.ac.uk> Date: Tue, 05 Apr 2005 12:48:07 +0200 On Tue, 2005-04-05 at 17:09 +0700, Karl Czajkowski wrote: > On Apr 05, Mark McKeown loaded a tape reading: > ... > > I am not sure why people think there should only be a one-to-one > > mapping of a job to a resource. > > I do not think anyone is saying there should ONLY be a one-to-one > mapping, but rather that there is a one-to-one mapping of job to > resource for the mythical 80% solution. In fact, it is this mapping > that gives us an inutitive sense of there being a job at all! I have > come to think that part of the appeal of the WSRF approach for many is > to be able to more clearly codify which operations are applicable to a > specific resource for these 80% cases. It does not preclude the other > 20% solutions, but gives us more firm ground upon which to think about > interoperability for the straightforward scenarios. > > As for the rest of your message (sorry, no pun intended), I think you > underestimate the difficulty: you need a consensus on how to normalize > the concept space around all the different job metadata that might be > useful to reference jobs in different usage scenarios. This > normalization is inherent in having the hierarchical URI space in > which you've framed your simple examples. My experience leads me to > have a flight response when I hear "consensus", "normalization", and > "concept modeling" in the same paragraph... > > As an example, I find it exceedingly strange that the job's transient > state is part of its structured name below, but its unique numeric > identifier is used as a reference parameter. To me, it should clearly > be the other way around. So, each job has it's own URI, eg, http://thegrid/users/ian/jobs/435 Then, doing a GET on this returns some document of job metadata (??) Roger > I don't think you can really avoid the > adoption of a query language for the 20% cases, whether it is some > ad-hoc URI+reference parameter strategy like this, or > XPath/XQuery/etc. against a structured group abstraction. I think a > fruitful standards activity must start with a flat per-job reference > model and then add (optional) grouping abstractions to handle these > more exotic cases. > > > karl > > > >... Applying REST: > > > > GET http://thegrid/user/Ian/jobs > > > > returns a representation of all of Ian's jobs > > (or maybe just Xlinks to resources that represent those jobs). > > > > To suspend all the active jobs send a suspend message to the > > resource that represents all the Active jobs: > > > > POST http://thegrid/user/Ian/jobs/Active 'Suspend' > > > > > > Suspending specific jobs of Ian's, send a suspend message to the > > resource that represents the specific jobs: > > > > POST http://thegrid/user/Ian/jobs/Active?job=27&job=35 'Suspend' > > > > or > > > > DELETE http://thegrid/user/Ian/jobs/Active?job=27&job=35 > > > > > > Suspend all jobs that have used over 1 hours of CPU time owned by > > Ian: > > > > POST http://thegrid/user/Ian/jobs/Active?MinCPUTimeUsed=3600 > > 'Suspend' > > > > > > > > Using conventional SOAP operation this looks like: > > > > suspend('All-jobs-owned-by-Ian + CPUtime > 36000' ) > > > > Doing it this way requires coming up with a suitable query language. > > Access control could be more difficult, in the REST case only Ian > > should be able to access resources starting with > > http://thegrid/user/Ian/. > > > > In theory the above could be done with WS-Resources using WSRF > > - I suspect it would be more difficult/complex though. > > > > > > Perhaps I am very wrong though... > > > > cheers > > Mark > > > > >

1 0

Re: [ogsa-wg] RE: Modeling State: Technical Questions
by Karl Czajkowski 05 Apr '05

05 Apr '05

On Apr 05, Roger Menday loaded a tape reading: > On Tue, 2005-04-05 at 17:09 +0700, Karl Czajkowski wrote: ... > > As an example, I find it exceedingly strange that the job's transient > > state is part of its structured name below, but its unique numeric > > identifier is used as a reference parameter. To me, it should clearly > > be the other way around. > > So, each job has it's own URI, eg, http://thegrid/users/ian/jobs/435 > > Then, doing a GET on this returns some document of job metadata > > (??) > > Roger > I suppose, or really http://server.somewhere.grid/jobsXYZ/TlkUjg13DunN8ie2 I think the URI is really just an opaque dispatch path that makes sense to the endpoint designer and not necessarily anyone else. As soon as you start trying to organize or decompose this space according to conceptual interface rather than implementation, you run headlong into the community modeling tar-pit. My starting assumption is that there will be different communities or sects with different domain models. The danger with using URIs and reference parameters for this is that it is very poorly typed, so there is very little tooling support to express how the concept space has been modeled nor to perform meaningful validation at runtime. There is also very little support for building discovery systems to catalog and organize information about different resources using such an implied model. Using something like XPath or XQuery to select resources from a virtual XML "group" document seems a lot more disciplined to me, as does having XML representation of the "valid" operations and metadata for those resources (WSDL and WS-ResourceProperties, in the WSRF approach). As to whether GET on resource URIs actually does anything useful, I'll leave that for people who care about such things. :-) Similarly, whether DNS is sufficient for practical, efficient, resilient naming of URI namespace "authorities" is also something I'll leave to others. Personally, I hope that the resource URI is more than a transient service address. It seems to me that some of the WS-Addressing debate relates to whether this is the case in practice or not. karl -- Karl Czajkowski karlcz(a)univa.com

1 0

Proposed agenda for April 6th call
by Hiro Kishimoto 05 Apr '05

05 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 6th Wednesday from 5pm to 7pm (CDT). The meeting is for "OGSA Profile definition" discussion. Please read the latest draft carefully in advance and bring your comments/questions to the call. Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0406 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 Agenda bashing 2) "OGSA Profile definition" discussion (60 min) We will submit an informational document "OGSA Profile definition" synchronized with "OGSA basic profile." In order to finalize it, we will have review sessions on this. - The latest revision https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profil… plate/en/3 3) Wrap up (10 min) AOB April 11 (5-7pm CDT) New WG status report April 13 (noon-2pm CDT) Basic Profile April 13 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

Data: Short telcon to discuss charter
by Dave Berry 04 Apr '05

04 Apr '05

Dear all, I will be 15 minutes late for this week's data telcon, so it will start at 7.45am PDT / 10.45am EDT / 3.45pm BST / 4.45 pm CEST. The main topic for discussion will be the conversion to a working group. Note that this is also a topic for discussion on the main OGSA WG today and we also discussed it last week, so I hope that Wednesday's discussion should be straightforward. We will also have an update on work for the architecture document. Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Proposed agenda for April 4th call
by Hiro Kishimoto 04 Apr '05

04 Apr '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on April 4th Monday from 5pm to 7pm (CDT). 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: 0404 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 (March 28) approval - http://tinyurl.com/44hff. Agenda bashing 2) May F2F meeting update (20 min) Hold a Basic Execution Services (BES) meeting on Sunday May 22, OGSA (including Naming) on Mon/Tue, and Data on Wed. Proposed location: Imperial College. Andrew to check Karl Czajkowski's availability, and will also send mail to Mathias Dalheimer. 3) OGSA-* WGs charter discussion (20 min) We should confirm that OGSA-WG and the emarging new WGs will go forward consistently. - OGSA BES-WG http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/03/msg00145.html - OGSA ByteIO-WG http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/04/msg00000.html - OGSA-D-WG http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/03/msg00142.html - OGSA-naming WG https://forge.gridforum.org/projects/ogsa-wg/document/draft-charter-naming-… /1 4) GFSG issues (20 min) - Design team WG promotion 5) "OGSA Profile definition" discussion (60 min) We will submit an informational document "OGSA Profile definition" synchronized with "OGSA basic profile." In order to finalize it, we will have review sessions on this. - The latest revision https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profil… plate/en/3 6) Wrap up (10 min) AOB April 6 (noon-2pm CDT) Basic Profile April 6 (5-7pm CDT) TBD April 11 (5-7pm CDT) New WG status report April 13 (noon-2pm CDT) Basic Profile April 13 (5-7pm CDT) Roadmap discussion See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

RE: [ogsa-wg] OGSA-BES DRAFT charter and F2F
by Dave Berry 01 Apr '05

01 Apr '05

Should this charter should be more specific about the interactions with the OGSA WG? E.g. Hiro's suggestion for the draft ByteIO charter says: "As the ByteIO interface is intended to be part of OGSA, the WG will have joint review discussion with OGSA-WG before every milestones, e.g. first draft recommendation document review before GGF14." It may also be sensible to list some of the things that are out of scope for this group. Dave. _____ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Andrew Grimshaw Sent: 31 March 2005 15:28 To: ogsa-wg(a)ggf.org; OGSA-BES-bof(a)ggf.org Cc: Bill Nitzberg; Stephen Pickles; 'Karl Czajkowski' Subject: [ogsa-wg] OGSA-BES DRAFT charter and F2F All, Attached is the draft BES charter. Please comment in the next several days so we can get this off to the GFSG. A few other administrative things. 1) We are planning a face-to-face in conjunction with the OGSA F2F in London at the end of May. The OGSA F2F is May 23-24. We will have the BES F2F the day before - on Sunday the 22. 2) The proposed weekly teleconference time is 10 AM Eastern (US) on Thursdays (NOT including today.) It is not an ideal time for the folks in Asia. Midnight in Japan, and 10 PM in Thailand. We are working on finding a conference call number and will post in advance. Any ideas are appreciated. Andrew

2 1

Telcon for OGSA ByteIO WG charter
by Dave Berry 01 Apr '05

01 Apr '05

Dear all, The ByteIO group plans on having it's first telecon next Tuesday at 11AM Eastern (8AM Pacific, 4PM UK and midnight in Japan). Our agenda for that telecon includes the group's first discussion of the charter. Please see the attachments. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

[ogsa-wg | Basic Profile - 1350] WS-I Copyright/attribution/reference on front matter
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1350 Submitted by: Tom Maguire Submitted date: 2005-03-31 12:41:49 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1350&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1350&group_id…) Summary: WS-I Copyright/attribution/reference on front matter Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1350 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 12:41:49 Submitted By: Tom Maguire Submit Date: 2005-03-31 12:41:49 Assigned To: &lt;None&gt; File(s): <None> Description: Front matter is largely taken from WS-I Basic Profile. Need to work the copyright issue/understanding with WS-I. View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1349] EDITORIAL - Abstract tighten up principles
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1349 Submitted by: Tom Maguire Submitted date: 2005-03-31 12:38:15 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1349&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1349&group_id…) Summary: EDITORIAL - Abstract tighten up principles Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1349 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 12:38:15 Submitted By: Tom Maguire Submit Date: 2005-03-31 12:38:15 Assigned To: &lt;None&gt; File(s): <None> Description: This sentence -"Guided by these principles and operating in the wider technical domain of distributed system management and grid computing, we define here the OGSA Basic Profile 1.0, the first of what is expected to become a set of normative profiles addressing issues relating to distributed system management." needs to be cleaned up View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1348] EDITORIAL - Abstract needs WS-I refs
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1348 Submitted by: Tom Maguire Submitted date: 2005-03-31 11:00:46 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1348&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1348&group_id…) Summary: EDITORIAL - Abstract needs WS-I refs Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1348 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 11:00:46 Submitted By: Tom Maguire Submit Date: 2005-03-31 11:00:46 Assigned To: &lt;None&gt; File(s): <None> Description: proper references for WS-I BP 1.1 and WS-I BSP 1.0 View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1347] EDITORIAL- Status of memo s/b recommendation
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1347 Submitted by: Tom Maguire Submitted date: 2005-03-31 10:55:46 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1347&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1347&group_id…) Summary: EDITORIAL- Status of memo s/b recommendation Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1347 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 10:55:46 Submitted By: Tom Maguire Submit Date: 2005-03-31 10:55:46 Assigned To: &lt;None&gt; File(s): <None> Description: This text - "This document does not define any standards or technical recommendations." is wrong View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Proposed agenda for March 30th EGA feedback call
by Hiro Kishimoto 31 Mar '05

31 Mar '05

Hi all, Tomorrow (March 30th) is NOT regular OGSA call but Enterprise Grid Alliance (EGA) feedback call. Even thought it is not regular one, you are very welcome to join. March 30th Wednesday from 5pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0330 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) EGA feedback discussion (60 min) GGF13 session #5 minutes (http://tinyurl.com/5fxfd/ggf13-minutes-session-5/en/1) > - The review document is intended as a starting point for a > discussion between EGA and OGSA-WG > - There is an EGA F2F beginning of April, which Andrew is scheduled > to attend. By that time OGSA (Hiro, Andrew, Jay) will finish a > review of the EGA OGSA version 1.0 review. Notes on the OGSA-WG's discussion of the EGA's review of OGSA https://forge.gridforum.org/projects/ogsa-wg/document/EGA_OGSA_Review_Discu… /en/1 Thanks, ---- Hiro Kishimoto

1 1

RE: [ogsa-wg] OGSA ByteIO WG charter
by Hiro Kishimoto 30 Mar '05

30 Mar '05

Mark's email bounced. ---- Hiro Kishimoto From: "Mark Morgan" <mmm2a(a)cs.virginia.edu> To: "'Hiro Kishimoto'" <hiro.kishimoto(a)jp.fujitsu.com>, "'ogsa-wg'" <ogsa-wg(a)gridforum.org> Subject: RE: [ogsa-wg] OGSA ByteIO WG charter Date: Wed, 30 Mar 2005 11:49:25 -0500 Just to let everyone know, the ByteIO group plans on having it's first telecon next Tuesday at 11AM Easter (8AM Pacific, and I "think" 4PM UK). Our agenda for that telecon includes the groups first discussion of the charter. More details to follow. -Mark > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Hiro Kishimoto > Sent: Wednesday, March 30, 2005 5:59 AM > To: 'ogsa-wg' > Subject: [ogsa-wg] OGSA ByteIO WG charter > > Hi all, > > GFSG asks me to send out revised OGSA-ByteIO WG charter draft > to OGSA-WG mailing list for your review. Two WGs should be > consistent and WG charter is binding document to materialize it. > > Please read them carefully and let me know if you have any comments. > Since GFSG will approve this WG on next Tuesday at earliest, yours > comment should be made by next Monday. If necessary, we can discuss > this topic at Monday call. > > The following is my comments. > > (1) Acronym, email address, web page should be the same, e.g.; > Acronym: OGSA-BIO > email list: ogsa-bio-wg(a)ggf.org > web page: https://forge.gridforum.org/projects/ogsa-bio-wg > > (2) OGSA infrastructure (first paragraph of scope section) It > should be based on "OGSA basic profile v1.0" instead of "WSRF." > > (3) Any other relevant information > This section should be described more specific in order to > make WG's documents will be consistent with OGSA-WG. > I prefer the following; > > As the ByteIO interface is intended to be part of OGSA, the > WG should have joint review discussion with OGSA-WG and > OGSA-D-WG before EVERY milestones, e.g. first draft > recommendation document review before GGF14. > > Thanks, > ---- > Hiro Kishimoto > > >

1 0

RE: [ogsa-wg] Draft charter for OGSA Data Architecture WG (promoting the design team)
by Dave Berry 30 Mar '05

30 Mar '05

We discussed the draft OGSA-D charter on today's design team call. You can find the minutes at http://tinyurl.com/3tjqa . I attach a revised version of the charter and the (unchanged) answers to the seven questions. One process question raised today is, if the OGSA-D WG were to produce a data profile recommendation document, what would be the process for issuing it as an OGSA profile? Would a document from the OGSA-D WG have the status of an OGSA profile (assuming that the OGSA WG agreed to it)? Or would the OGSA-D WG submit the document to the OGSA WG for formal release? Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: 28 March 2005 15:28 To: Dave Berry; 'ogsa-wg' Cc: 'Dave Pearson'; 'Mario Antonioletti'; 'Martin Westhead'; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; 'Allen Luniewski'; Malcolm Atkinson; 'Susan Malaika'; 'Peter Clarke (UCL)'; 'David E Martin'; 'Peter Kunszt'; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; 'Scott Oster'; 'Stephen Langella'; 'Shannon Hastings'; 'Manuel Pereira'; 'Ted Anderson'; 'Leo Luan'; 'Mark M. Morgan' Subject: RE: [ogsa-wg] Draft charter for OGSA Data Architecture WG (promoting the design team) Thanks Dave, I agree that this OGSA data architecture WG will develop informational data service architecture document which covers typical scenarios and detailed service descriptions. However, I don't know what the basic data profile looks like. Even though this WG will develop the basic data profile in the near future, I prefer not give a charter for profile development at this moment. I expect this WG will get clear outline of the date profile within a couple of months and then define the profile, deliberate within OGSA-D WG and with OGSA-WG and propose re-charter of OGSA-D to GFSG. Although it is overhead, but I think this procedure will guarantee necessary consistency between OGSA-WG and OGSA-D WG. Your thoughts? ---- Hiro Kishimoto > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Dave Berry > Sent: Monday, March 28, 2005 1:04 AM > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; > Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; > Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; > Gavin.Mccance(a)cern.ch; Scott Oster; Stephen > Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; > Mark M. Morgan > Subject: [ogsa-wg] Draft charter for OGSA Data Architecture WG > (promoting the design team) > > Dear all, > > Please find attached a draft charter for the promotion of the OGSA > data design team to a working group. We will discuss this on > Wednesday's call (times below). Please mail any minor comments to me. > Major issues may need discussion on the mailing list or at telcons. > > Dave. > > Data telcon times: 7.30am PST / 10.30am EST / 4.30pm GMT / 5.30 pm > CET >

1 0

OGSA Basic Profile Telecon Agenda 3/30
by Tom Maguire 30 Mar '05

30 Mar '05

The following is a proposed agenda for OGSA-WG telecon on March 30th Wednesday from noon to 2pm (CST). The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0330 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 Agenda bashing 2) Security discussion (60 min) 1324: Separate Security Basic Profile 1320: Transport and/or Message Level security 1321: Discovery of key-info for encryption in message level security 1322: Use of Proxy Certificates 1323: Communication of assertions 3) Basic Profile discussion (50 min) 1317: QueryRP should be optional 1262: Should set resource property be included in BPv1? 1211: What must a service satisfy before it can be called an "OGSA service?" 1314: Relationship to WS-I Basic Security Profile 1.0 4) Wrap up (10 min) AOB See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

2 1

"tactical-agreement" (#1321: Key-info discovery for encryption in message level security)
by Frank Siebenlist 30 Mar '05

30 Mar '05

#1321: Discovery of key-info for encryption in message level security Service Group Profile/ EPR embedding Use cases: When a client wants to send any encrypted message to a service, it will have to know the key associated with that service. When a client wants to make a policy decision whether or not it wants a certain service to serve its request, it has to know the service's key-info. Considerations: We have to assume that WS-I or some other organization will get its act together in the future to define a standardized profile for the embedding of the service's key-info in the EPR, and that that profile will then be supported by all vendors world-wide. Unfortunately, we cannot expect this to happen on any time scale that can accommodate our upcoming releases and Grid deployments in the near future. In order for our different implementation to talk to each other securely, we have to have agreements in place about where one party will put the key-info such that another party can find it. So we need to have a solution in place "now", no matter what, and we have to be prepared to change that method to the standardized one once it becomes available. This means that we will have to implement this (at least) twice. But note again that there is no alternative - we have to live with this. It may be politically better, however, to use words like "tactical-agreement" instead of "standard" for whatever method we choose, in order to emphasize that we are committed to follow what ever comes out of WS-I and friends over time. Hopefully that would make it easier for some of our partner vendors to work on a tactical-agreement without stepping on the toes of their colleagues who work on the concurrent WS-I efforts. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

OGSA ByteIO WG charter
by Hiro Kishimoto 30 Mar '05

30 Mar '05

Hi all, GFSG asks me to send out revised OGSA-ByteIO WG charter draft to OGSA-WG mailing list for your review. Two WGs should be consistent and WG charter is binding document to materialize it. Please read them carefully and let me know if you have any comments. Since GFSG will approve this WG on next Tuesday at earliest, yours comment should be made by next Monday. If necessary, we can discuss this topic at Monday call. The following is my comments. (1) Acronym, email address, web page should be the same, e.g.; Acronym: OGSA-BIO email list: ogsa-bio-wg(a)ggf.org web page: https://forge.gridforum.org/projects/ogsa-bio-wg (2) OGSA infrastructure (first paragraph of scope section) It should be based on "OGSA basic profile v1.0" instead of "WSRF." (3) Any other relevant information This section should be described more specific in order to make WG's documents will be consistent with OGSA-WG. I prefer the following; As the ByteIO interface is intended to be part of OGSA, the WG should have joint review discussion with OGSA-WG and OGSA-D-WG before EVERY milestones, e.g. first draft recommendation document review before GGF14. Thanks, ---- Hiro Kishimoto

1 0

Minutes from March 28th OGSA telecon
by Treadwell, Jem 29 Mar '05

29 Mar '05

Hi, the minutes from the March 28 OGSA telecon are now available at http://tinyurl.com/44hff. Thanks, - Jem -- Jem Treadwell Hewlett-Packard Company

1 0

Updated telecon schedule table
by Hiro Kishimoto 29 Mar '05

29 Mar '05

Hi all, Attached is an updated telecom schedule. https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/en/21 This Wednesday noon call is for basic profile discussion. Tom will send out agenda proposal shortly. The following is its dial-in information. Call in: 800-664-6895 Toll: 719-955-1126 passcode: 285178 Wednesday evening call is for EGA feedback discussion. Usual time and usual dial. Thanks, ---- Hiro Kishimoto

2 2

RE: [ogsa-wg] Draft charter for OGSA Data Architecture WG (promoting the design team)
by Dave Berry 28 Mar '05

28 Mar '05

Hiro, I am concerned about the data profile, in two different ways: 1 - I want to see work begin on this 2 - I don't want to commit to work that I can't deliver The second of these argues strongly in favour of your suggestion. However, I don't want the work to "drop off the radar". Perhaps someone in the data area can start twisting a few arms in the hope of finding a volunteer? Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: 28 March 2005 15:28 To: Dave Berry; 'ogsa-wg' Cc: 'Dave Pearson'; 'Mario Antonioletti'; 'Martin Westhead'; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; 'Allen Luniewski'; Malcolm Atkinson; 'Susan Malaika'; 'Peter Clarke (UCL)'; 'David E Martin'; 'Peter Kunszt'; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; 'Scott Oster'; 'Stephen Langella'; 'Shannon Hastings'; 'Manuel Pereira'; 'Ted Anderson'; 'Leo Luan'; 'Mark M. Morgan' Subject: RE: [ogsa-wg] Draft charter for OGSA Data Architecture WG (promoting the design team) Thanks Dave, I agree that this OGSA data architecture WG will develop informational data service architecture document which covers typical scenarios and detailed service descriptions. However, I don't know what the basic data profile looks like. Even though this WG will develop the basic data profile in the near future, I prefer not give a charter for profile development at this moment. I expect this WG will get clear outline of the date profile within a couple of months and then define the profile, deliberate within OGSA-D WG and with OGSA-WG and propose re-charter of OGSA-D to GFSG. Although it is overhead, but I think this procedure will guarantee necessary consistency between OGSA-WG and OGSA-D WG. Your thoughts? ---- Hiro Kishimoto > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Dave Berry > Sent: Monday, March 28, 2005 1:04 AM > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; > Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; > Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; > Gavin.Mccance(a)cern.ch; Scott Oster; Stephen > Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; > Mark M. Morgan > Subject: [ogsa-wg] Draft charter for OGSA Data Architecture WG > (promoting the design team) > > Dear all, > > Please find attached a draft charter for the promotion of the OGSA > data design team to a working group. We will discuss this on > Wednesday's call (times below). Please mail any minor comments to me. > Major issues may need discussion on the mailing list or at telcons. > > Dave. > > Data telcon times: 7.30am PST / 10.30am EST / 4.30pm GMT / 5.30 pm > CET >

1 0

RE: [ogsa-wg] Proposed agenda for March 28th call
by Dave Berry 28 Mar '05

28 Mar '05

I've now uploaded the minutes for session 8 and for the ByteIO BOF. http://tinyurl.com/4lyvu http://tinyurl.com/729t8 Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: 28 March 2005 13:44 To: 'ogsa-wg' Subject: [ogsa-wg] Proposed agenda for March 28th call Hi all, The following is a proposed agenda for OGSA-WG telecon on March 28th Monday from 5pm to 7pm (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: 0328 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 (May 23) approval - http://tinyurl.com/6x26p Agenda bashing 2) GGF13 Minutes approval (20 min) - Minutes approval. Please upload session minutes before the call. #1 http://tinyurl.com/5fxfd/ggf13-minutes-session-1/en/1 #2 http://tinyurl.com/5fxfd/ggf13-minutes-session-2/en/1 #3 http://tinyurl.com/5fxfd/ggf13-minutes-session-3/en/1 #4 http://tinyurl.com/5fxfd/ggf13-minutes-session-4/en/1 #5 http://tinyurl.com/5fxfd/ggf13-minutes-session-5/en/1 #6 http://tinyurl.com/5fxfd/ggf13-minutes-session-6/en/1 #7 http://tinyurl.com/4h459 #8 not yet? #9 http://tinyurl.com/5fxfd/ggf13-minutes-session-9/en/1 #10 http://tinyurl.com/5fxfd/ggf13-minutes-session-10/en/1 3) telecon schedule discussion (20 min) - Time allocation proposal for discussion o Basic Profile: every Wednesday until Apr. 20 (5 times, new time) o Profile Template: every other Monday (2 times) o roadmap: every Wednesday on and after Apr. 13 (3 times) o new WG & data design team reporting: monthly (2 times) See attached table (also http://tinyurl.com/5fxfd/telecon_schedule) 4) May F2F meeting discussion (10 min) We will have next interim F2F meeting in the week of May 23 in London UK. Please let me know your availability by answering simple four questions by accessing the following URL: http://www.zoomerang.com/survey.zgi?p=WEB2248D2NP9C3 As of May 28, 8 members have answered the survey. See attached table. 5) Wrap up (10 min) AOB Mar. 30 (noon-2pm CST) Basic Profile Mar. 20 (5-7pm CST) F2F schedule April 4 (5-7pm CDT) Profile template April 6 (noon-2pm CDT) Basic Profile April 6 (5-7pm CDT) TBD See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

Draft charter for OGSA Data Architecture WG (promoting the design team)
by Dave Berry 28 Mar '05

28 Mar '05

Dear all, Please find attached a draft charter for the promotion of the OGSA data design team to a working group. We will discuss this on Wednesday's call (times below). Please mail any minor comments to me. Major issues may need discussion on the mailing list or at telcons. Dave. Data telcon times: 7.30am PST / 10.30am EST / 4.30pm GMT / 5.30 pm CET

2 1

OGSA Resource Selection Services-WG
by Mathias Dalheimer 28 Mar '05

28 Mar '05

Hello! On GGF13 I was beginning to work on the formation of an OGSA-related working group. It will deal with Resource Selection Services and tries to specify the interfaces a grid scheduler should provide to the outside world. Now, I would like to invite more people from both OGSA-WG and Grid Scheduling Architecture-RG to contribute. You can find my draft of a charter and a timetable to GGF14 here in a wiki I set up: http://h63759.serverkompetenz.net/snipsnap (Yes, this is a really ugly temporary address - it will change...) So far, the list of supporters reads as follows: * Satoshi Matsuoka, Hwang Soonwook and Kazushige Saga of the NAREGI team * David Snelling (GGF Vice Chair, OGSA) * Ramin Yahyapour and Philip Wieder, Grid Scheduling Architecture-RG * Andrew Grimshaw and Hiro Kishimoto, OGSA-WG * Various Scheduler people: Walfredo Cirne (Universidade Federal de Campina Grande), Donal Fellows (Uni Manchester), Chris Smith (Platform Computing) and of course me (Fraunhofer ITWM). I hope I can add other people to this list. If you have any questions or want to come up with concrete plans how to contribute, please contact me. Same applies of you know someone that may be interested. Cheers, Mathias -- ______________________________________________________________________ Dipl.-Wirtsch. Ing. (Inform.) Mathias Dalheimer Fraunhofer Institut für Techno- und Wirtschaftsmathematik (ITWM) Europaallee 10 67657 Kaiserslautern, Germany Phone +49(0)631/303-1827 | mailto:dalheimer@itwm.fraunhofer.de Fax +49(0)631/303-1877 | ______________________________________________________________________

1 0

Proposed agenda for March 28th call
by Hiro Kishimoto 28 Mar '05

28 Mar '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 28th Monday from 5pm to 7pm (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: 0328 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 (May 23) approval - http://tinyurl.com/6x26p Agenda bashing 2) GGF13 Minutes approval (20 min) - Minutes approval. Please upload session minutes before the call. #1 http://tinyurl.com/5fxfd/ggf13-minutes-session-1/en/1 #2 http://tinyurl.com/5fxfd/ggf13-minutes-session-2/en/1 #3 http://tinyurl.com/5fxfd/ggf13-minutes-session-3/en/1 #4 http://tinyurl.com/5fxfd/ggf13-minutes-session-4/en/1 #5 http://tinyurl.com/5fxfd/ggf13-minutes-session-5/en/1 #6 http://tinyurl.com/5fxfd/ggf13-minutes-session-6/en/1 #7 http://tinyurl.com/4h459 #8 not yet? #9 http://tinyurl.com/5fxfd/ggf13-minutes-session-9/en/1 #10 http://tinyurl.com/5fxfd/ggf13-minutes-session-10/en/1 3) telecon schedule discussion (20 min) - Time allocation proposal for discussion o Basic Profile: every Wednesday until Apr. 20 (5 times, new time) o Profile Template: every other Monday (2 times) o roadmap: every Wednesday on and after Apr. 13 (3 times) o new WG & data design team reporting: monthly (2 times) See attached table (also http://tinyurl.com/5fxfd/telecon_schedule) 4) May F2F meeting discussion (10 min) We will have next interim F2F meeting in the week of May 23 in London UK. Please let me know your availability by answering simple four questions by accessing the following URL: http://www.zoomerang.com/survey.zgi?p=WEB2248D2NP9C3 As of May 28, 8 members have answered the survey. See attached table. 5) Wrap up (10 min) AOB Mar. 30 (noon-2pm CST) Basic Profile Mar. 20 (5-7pm CST) F2F schedule April 4 (5-7pm CDT) Profile template April 6 (noon-2pm CDT) Basic Profile April 6 (5-7pm CDT) TBD See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

RE: [ogsa-wg] Data: correction for EU daylight saving time
by Dave Berry 28 Mar '05

28 Mar '05

A final(?) correction: I should also have changed the names of the time zones affected by DST. Some readers weren't sure which time I meant. 7.30am PST / 10.30am EST / 4.30pm BST / 5.30 pm CEST Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Dave Berry > Sent: 27 March 2005 15:50 > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen > Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke > (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; > Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; > Stephen Langella; Shannon Hastings; Manuel Pereira; Ted > Anderson; Leo Luan; Mark M. Morgan > Subject: RE: [ogsa-wg] Data: correction for EU daylight saving time > > Of course, it would help if I got the correction right. As Susan > pointed out in e-mail, the times should actually be: > > 7.30am PST / 10.30amm EST / 4.30pGMT / 5.30 pm CET. > > I assume that everyone is now thoroughly confused ;-). > > Dave. > > > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of > Dave Berry > Sent: 26 March 2005 17:36 > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; > Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; > Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; > Gavin.Mccance(a)cern.ch; Scott Oster; Stephen Langella; Shannon > Hastings; > Manuel Pereira; Ted Anderson; Leo Luan; Mark M. Morgan > Subject: RE: [ogsa-wg] Data: correction for EU daylight saving time > > > Correction: the time of this meeting will be: > > 7.30am PST / 10.30am EST / 2.30pm GMT / 3.30 pm CET > > Dave. > > > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of > Dave Berry > Sent: 24 March 2005 12:58 > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; > Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; > Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; > Gavin.Mccance(a)cern.ch; Scott Oster; Stephen Langella; Shannon > Hastings; > Manuel Pereira; Ted Anderson; Leo Luan; Mark M. Morgan > Subject: [ogsa-wg] Data: proposed agenda for Wednesday March 30th > > > Dear all, > > I propose we have a telcon next Wednesday, March 30th, at our > new usual > time of 7.30am PST / 10.30am EST / 3.30pm GMT / 4.30 pm CET. > > UK Dial In: 0845 245 0224 > US Dial In: 1866 838 0046 > International Dial In: +44 1452 542309 > > PIN: 632 065 > > The two main topics I intend to cover are: > > - draft charter for becoming a working group > > - progress with the straw man document > > I will post a full agenda early next week. In the interim I intend to > circulate a draft of the WG charter and an update on the document. > > Best wishes, > > Dave Berry > Research Manager, National e-Science Centre > 15 South College St., Edinburgh > Tel: +44 131 6514039 > >

1 0

Re: [ogsa-wg] RE: Update on OGSA Basic Profile Security work
by Hiro Kishimoto 28 Mar '05

28 Mar '05

Hi all, Takuya's email bounced. ---- Hiro Kishimoto Date: Fri, 25 Mar 2005 11:58:39 -0600 (CST) To: security-area(a)ggf.org Cc: ogsa-wg(a)gridforum.org Subject: Re: [ogsa-wg] RE: Update on OGSA Basic Profile Security work From: Takuya Mori <mori(a)mcs.anl.gov> Dear All, There is an update on the telecon schedule. I applogize my duplicate, if you guys have already been noticed it. It is proposed to have the Basic Profile sessions 1-3pm ET on Wednesdays. The security related issues is also scheduled in the same time slot on Mar 30th now. If it does not work for you, please let me know it. Thank you, Takuya Mori From: "Hiro Kishimoto" <hiro.kishimoto(a)jp.fujitsu.com> Subject: [ogsa-wg] RE: Update on OGSA Basic Profile Security work Date: Wed, 23 Mar 2005 17:05:37 +0900 > Thanks Dane for your obliging email, > > Certainly OGSA-WG welcomes and requires security experts. Proposed > telecon date is March 30th. If it does not work for you, April 6th is > another option. Please let me know your preference. > > You can sub-scribe our mailing list; > https://forge.gridforum.org/projects/sourceforge/document/majordomo_he > lp/en/1/ma > jordomo_help.doc > http://www-unix.gridforum.org/mail_archive/ogsa-wg/threads.html > > Our Wednesday call is 5-7pm CST. The dial in number is 1-888-452-0308 > or 1-484-644-0505 and the pass code is 71815. > > You can download the latest basic profile draft from; > https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-b > asic-profi > le/en/3 > > Now we have four open security related issues on this profile; > #1320: Transport and/or Message Level security > MUST or SHOULD?? > #1321: Discovery of key-info for encryption in message level security > Service Group Profile/ EPR embedding > #1322: Use of Proxy Certificates > Standard but not widely adopted outside of grid communit > Time boxed certificates (short lived certs) > #1323: Communication of assertions > Profiles for common assertions in headers or Proxy > Certificate > #1324: Separate Security Basic Profile > Should we have a separate profile document for security > > Basic profile tracker is at; > https://forge.gridforum.org/tracker/index.php?group_id=42&atid=780 > > Thanks, > ---- > Hiro Kishimoto > > > > -----Original Message----- > > From: Dane Skow [mailto:dane@fnal.gov] > > Sent: Thursday, March 17, 2005 6:03 PM > > To: security-area(a)ggf.org > > Cc: Ian Foster; Hiro Kishimoto > > Subject: Update on OGSA Basic Profile Security work > > > > As Frank mentioned in the Security Area Meeting, the OGSA Basic > > Profile is now being worked intensely toward conclusion. The Working > > Group has set a goal of > > mid April for resolving all the open issues with the current draft. The > > majority of > > the new issues opened this meeting have to do with security. Takuya has > > asked for > > a week to allow the interested parties in the Security Area to read the > > current draft > > and comment on the current open issues (or raise others). This means > > that interested > > parties will need to engage within the next few days to have maximal > > effectiveness. > > I encourage those interested in OGSA to engage on the Basic Profile now. > > > > The response to the question about which use cases from the OGSA > > use case document must be supported by the Basic Profile was "all of > > them". However, since > > we will not have a normative spec for WS-Delegation by June, nor do I > > know > > any other credential delegation standard, I suspect there > > was likely a misunderstanding. Takuya will follow up on that question. > > > > I believe Hiro and Ian (chairs of OGSA-WG) > > will second me in saying that input on this document from security > > experts is welcomed and requested. The most effective form would be > > for people to join the mailing list and attend the relevant > > phonecons. The next most > > effective is to download and read the current drafts and provide > > comments to the list. > > > > Frank and Takuya have volunteered to try to alert the area about > > relevant phonecons and open issues. However, they will not be able > > to relay comments/discussion with this > > short timeline. Interested parties will have to join them directly to > > keep up with the discussion. > > > > Cheers, > > Dane > >

1 0

RE: [ogsa-wg] Data: correction for EU daylight saving time
by Dave Berry 27 Mar '05

27 Mar '05

Of course, it would help if I got the correction right. As Susan pointed out in e-mail, the times should actually be: 7.30am PST / 10.30amm EST / 4.30pGMT / 5.30 pm CET. I assume that everyone is now thoroughly confused ;-). Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Dave Berry Sent: 26 March 2005 17:36 To: ogsa-wg Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; Stephen Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; Mark M. Morgan Subject: RE: [ogsa-wg] Data: correction for EU daylight saving time Correction: the time of this meeting will be: 7.30am PST / 10.30am EST / 2.30pm GMT / 3.30 pm CET Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Dave Berry Sent: 24 March 2005 12:58 To: ogsa-wg Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; Stephen Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; Mark M. Morgan Subject: [ogsa-wg] Data: proposed agenda for Wednesday March 30th Dear all, I propose we have a telcon next Wednesday, March 30th, at our new usual time of 7.30am PST / 10.30am EST / 3.30pm GMT / 4.30 pm CET. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN: 632 065 The two main topics I intend to cover are: - draft charter for becoming a working group - progress with the straw man document I will post a full agenda early next week. In the interim I intend to circulate a draft of the WG charter and an update on the document. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] Data: correction for EU daylight saving time
by Dave Berry 26 Mar '05

26 Mar '05

Correction: the time of this meeting will be: 7.30am PST / 10.30am EST / 2.30pm GMT / 3.30 pm CET Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Dave Berry Sent: 24 March 2005 12:58 To: ogsa-wg Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; Stephen Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; Mark M. Morgan Subject: [ogsa-wg] Data: proposed agenda for Wednesday March 30th Dear all, I propose we have a telcon next Wednesday, March 30th, at our new usual time of 7.30am PST / 10.30am EST / 3.30pm GMT / 4.30 pm CET. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN: 632 065 The two main topics I intend to cover are: - draft charter for becoming a working group - progress with the straw man document I will post a full agenda early next week. In the interim I intend to circulate a draft of the WG charter and an update on the document. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

RE: [ogsa-wg] Minutes of March 23 Telecon (resend)
by Treadwell, Jem 24 Mar '05

24 Mar '05

Sorry, the version I attached before was illegible on Windows. The attached version should be better, but if not here's the URL: http://tinyurl.com/6x26p - Jem ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Treadwell, Jem Sent: Thursday, March 24, 2005 11:04 AM To: ogsa-wg Subject: [ogsa-wg] Minutes of March 23 Telecon Hi, The minutes of last night's (yesterday's) call are attached and on GridForge. - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

Minutes of March 23 Telecon
by Treadwell, Jem 24 Mar '05

24 Mar '05

Hi, The minutes of last night's (yesterday's) call are attached and on GridForge. - Jem -- Jem Treadwell Hewlett-Packard Company Phone: (732) 577-6043 200 Route 9 North Fax: (732) 577-6003 Manalapan, NJ 07726 E-mail: Jem.Treadwell(a)hp.com

1 0

RE: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion
by Djaoui, A (Abdeslem) 24 Mar '05

24 Mar '05

Correction: BST starts on Sunday 27th (not 28th) March. Abdeslem /////////////// -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Djaoui, A (Abdeslem) Sent: 24 March 2005 14:20 To: Tom Maguire; ogsa-wg(a)gridforum.org Subject: RE: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion Excellent idea. By the way the UK moves to summer time (GMT+1) on Sunday 28 March. I believe Daylight Saving Time starts on April 3 in the US. So apart from Wednesday 30 March, the relative difference should be the same. Abdeslem /////////// -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Tom Maguire Sent: 24 March 2005 13:59 To: ogsa-wg(a)gridforum.org Subject: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion Importance: High During the OGSA telecon last night (3/23) we discussed the telecon schedule for moving forward on OGSA BP 1.0. The suggestion was to move the telecon time to a more 'friendly' time for key contributors. In that spirit the suggestion is that we move the OGSA BP discussion to Wednesdays 1:00PM - 3:00PM ET (6:00PM - 8:00PM GMT, 10:00AM-11:00AM PT). The plan is to finalize the OGSA BP document by the end of April, as such these calls will take place through April 20th. The calls will devote the first hour to security discussions related to OGSA BP until the issues/trackers related to BP security section are closed down. We need to lock down on a telecon time by Monday 3/28. Is this time acceptable to those who wish to participate? Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

RE: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion
by Djaoui, A (Abdeslem) 24 Mar '05

24 Mar '05

Excellent idea. By the way the UK moves to summer time (GMT+1) on Sunday 28 March. I believe Daylight Saving Time starts on April 3 in the US. So apart from Wednesday 30 March, the relative difference should be the same. Abdeslem /////////// -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Tom Maguire Sent: 24 March 2005 13:59 To: ogsa-wg(a)gridforum.org Subject: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion Importance: High During the OGSA telecon last night (3/23) we discussed the telecon schedule for moving forward on OGSA BP 1.0. The suggestion was to move the telecon time to a more 'friendly' time for key contributors. In that spirit the suggestion is that we move the OGSA BP discussion to Wednesdays 1:00PM - 3:00PM ET (6:00PM - 8:00PM GMT, 10:00AM-11:00AM PT). The plan is to finalize the OGSA BP document by the end of April, as such these calls will take place through April 20th. The calls will devote the first hour to security discussions related to OGSA BP until the issues/trackers related to BP security section are closed down. We need to lock down on a telecon time by Monday 3/28. Is this time acceptable to those who wish to participate? Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

RE: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion
by Srinivasan, Latha 24 Mar '05

24 Mar '05

This time will work well for me. -Latha -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Tom Maguire Sent: Thursday, March 24, 2005 8:59 AM To: ogsa-wg(a)gridforum.org Subject: [ogsa-wg] Proposed new telecon time for OGSA Basic Profile discussion Importance: High During the OGSA telecon last night (3/23) we discussed the telecon schedule for moving forward on OGSA BP 1.0. The suggestion was to move the telecon time to a more 'friendly' time for key contributors. In that spirit the suggestion is that we move the OGSA BP discussion to Wednesdays 1:00PM - 3:00PM ET (6:00PM - 8:00PM GMT, 10:00AM-11:00AM PT). The plan is to finalize the OGSA BP document by the end of April, as such these calls will take place through April 20th. The calls will devote the first hour to security discussions related to OGSA BP until the issues/trackers related to BP security section are closed down. We need to lock down on a telecon time by Monday 3/28. Is this time acceptable to those who wish to participate? Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

Proposed new telecon time for OGSA Basic Profile discussion
by Tom Maguire 24 Mar '05

24 Mar '05

During the OGSA telecon last night (3/23) we discussed the telecon schedule for moving forward on OGSA BP 1.0. The suggestion was to move the telecon time to a more 'friendly' time for key contributors. In that spirit the suggestion is that we move the OGSA BP discussion to Wednesdays 1:00PM - 3:00PM ET (6:00PM - 8:00PM GMT, 10:00AM-11:00AM PT). The plan is to finalize the OGSA BP document by the end of April, as such these calls will take place through April 20th. The calls will devote the first hour to security discussions related to OGSA BP until the issues/trackers related to BP security section are closed down. We need to lock down on a telecon time by Monday 3/28. Is this time acceptable to those who wish to participate? Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

RE: [ogsa-wg] JISC Edinburgh conference on configuraiton
by Dave Berry 24 Mar '05

24 Mar '05

You might also be interested in the reports at www.gridweaver.org/docs/. Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Tom Maguire > Sent: 24 March 2005 00:16 > To: ogsa-wg(a)gridforum.org > Subject: [ogsa-wg] JISC Edinburgh conference on configuraiton > > > > > > http://homepages.informatics.ed.ac.uk/group/lssconf/config2005 > e/call.html#programme > > > > Perfection is achieved, not when there is nothing more to > add, but when > there is nothing left to take away. - Antoine de Saint-Exupery > > > T o m M a g u i r e > > > STSM, On Demand Architecture > > > Poughkeepsie, NY 12601 >

1 0

Data: proposed agenda for Wednesday March 30th
by Dave Berry 24 Mar '05

24 Mar '05

Dear all, I propose we have a telcon next Wednesday, March 30th, at our new usual time of 7.30am PST / 10.30am EST / 3.30pm GMT / 4.30 pm CET. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN: 632 065 The two main topics I intend to cover are: - draft charter for becoming a working group - progress with the straw man document I will post a full agenda early next week. In the interim I intend to circulate a draft of the WG charter and an update on the document. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

May interim F2F Meeting Planning Survey
by Hiro Kishimoto 24 Mar '05

24 Mar '05

Hi all, We will have next interim F2F meeting in the week of May 23 in London UK. Please let me know your availability by answering simple four questions. Please access the URL below: http://www.zoomerang.com/survey.zgi?p=WEB2248D2NP9C3 Based on your answers, we will choose the date at the next Monday call (March 28). Thanks, ---- Hiro Kishimoto

1 0

JISC Edinburgh conference on configuraiton
by Tom Maguire 24 Mar '05

24 Mar '05

http://homepages.informatics.ed.ac.uk/group/lssconf/config2005e/call.html#p… Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

RE: Update on OGSA Basic Profile Security work
by Hiro Kishimoto 23 Mar '05

23 Mar '05

Thanks Dane for your obliging email, Certainly OGSA-WG welcomes and requires security experts. Proposed telecon date is March 30th. If it does not work for you, April 6th is another option. Please let me know your preference. You can sub-scribe our mailing list; https://forge.gridforum.org/projects/sourceforge/document/majordomo_help/en… jordomo_help.doc http://www-unix.gridforum.org/mail_archive/ogsa-wg/threads.html Our Wednesday call is 5-7pm CST. The dial in number is 1-888-452-0308 or 1-484-644-0505 and the pass code is 71815. You can download the latest basic profile draft from; https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… le/en/3 Now we have four open security related issues on this profile; #1320: Transport and/or Message Level security MUST or SHOULD?? #1321: Discovery of key-info for encryption in message level security Service Group Profile/ EPR embedding #1322: Use of Proxy Certificates Standard but not widely adopted outside of grid communit Time boxed certificates (short lived certs) #1323: Communication of assertions Profiles for common assertions in headers or Proxy Certificate #1324: Separate Security Basic Profile Should we have a separate profile document for security Basic profile tracker is at; https://forge.gridforum.org/tracker/index.php?group_id=42&atid=780 Thanks, ---- Hiro Kishimoto > -----Original Message----- > From: Dane Skow [mailto:dane@fnal.gov] > Sent: Thursday, March 17, 2005 6:03 PM > To: security-area(a)ggf.org > Cc: Ian Foster; Hiro Kishimoto > Subject: Update on OGSA Basic Profile Security work > > As Frank mentioned in the Security Area Meeting, the OGSA Basic Profile > is now > being worked intensely toward conclusion. The Working Group has set a > goal of > mid April for resolving all the open issues with the current draft. The > majority of > the new issues opened this meeting have to do with security. Takuya has > asked for > a week to allow the interested parties in the Security Area to read the > current draft > and comment on the current open issues (or raise others). This means > that interested > parties will need to engage within the next few days to have maximal > effectiveness. > I encourage those interested in OGSA to engage on the Basic Profile now. > > The response to the question about which use cases from the OGSA use > case > document must be supported by the Basic Profile was "all of them". > However, since > we will not have a normative spec for WS-Delegation by June, nor do I > know > any other credential delegation standard, I suspect there > was likely a misunderstanding. Takuya will follow up on that question. > > I believe Hiro and Ian (chairs of OGSA-WG) > will second me in saying that input on this document from > security experts is welcomed and requested. The most effective form > would be for > people to join the mailing list and attend the relevant phonecons. The > next most > effective is to download and read the current drafts and provide > comments to the list. > > Frank and Takuya have volunteered to try to alert the area about > relevant phonecons > and open issues. However, they will not be able to relay > comments/discussion with this > short timeline. Interested parties will have to join them directly to > keep up with the discussion. > > Cheers, > Dane >

1 0

Proposed agenda for March 23rd call
by Hiro Kishimoto 23 Mar '05

23 Mar '05

Hi all, Thank you very much for making excellent presentations and having very productive and lively discussions at GGF13. It shows that OGSA is now GGF's flagship architecture both in name and substance. The following is a proposed agenda for OGSA-WG telecon on March 23rd Wednesday from 5pm to 7pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0323 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 Agenda bashing 2) GGF13 wrap-up (20 min) - Most of all materials are uploaded on GridForge. If you are yet to do please upload before the call. https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… - Minutes approval. Please upload session minutes before the call. #1 http://tinyurl.com/5fxfd/ggf13-minutes-session-1/en/1 #2 http://tinyurl.com/5fxfd/ggf13-minutes-session-2/en/1 #3 not yet #4 http://tinyurl.com/5fxfd/ggf13-minutes-session-4/en/1 #5 http://tinyurl.com/5fxfd/ggf13-minutes-session-5/en/1 #6 not yet #7 http://tinyurl.com/4h459 #8 not yet #9 not yet #10 not yet - WG promotion inquiry by GFSG http://tinyurl.com/5fxfd/GFSG-WG-promotion-inquiry/en/1 3) telecon schedule discussion (20 min) - Time allocation proposal for discussion o Basic Profile: every Wednesday until Apr. 20 (5 times) o Profile Template: every other Monday (4 times) o roadmap: every Wednesday on and after Apr. 27 (3 times) o EMS: every other Monday (4 times) o Resource Management: monthly (2 times) See attached table (also http://tinyurl.com/5fxfd/telecon_schedule) 4) May F2F meeting discussion (10 min) Arrange date and place/venue for interim F2F meeting (May 25 & 26 in London works for attendees at GGF13) 5) Basic Profile discussion (60 min) Tom will lead the discussion in order to close issues on the tracker 6) Wrap up (5 min) AOB ---- Hiro Kishimoto

1 0

NO call on monday
by Hiro Kishimoto 21 Mar '05

21 Mar '05

We resume regular call next Wednesday. ---- Hiro Kishimoto

1 0

Draft Charter WS-naming WG (RE: ** IMPORTANTE ** ROOM Change)
by Hiro Kishimoto 16 Mar '05

16 Mar '05

Hi all, The early draft charter draft is now on the gridforge. https://forge.gridforum.org/projects/ogsa-wg/document/draft-charter-naming-… /1 This is just an input for the upcoming BoF. ---- Hiro Kishimoto > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Wednesday, March 16, 2005 11:00 AM > To: 'ogsa-wg'; 'gfs-wg(a)gridforum.org' > Subject: ** IMPORTANTE ** ROOM Change (WS-naming WG BoF announcement) > > Hi all, > > WS-naming WG BoF will be held at GFS-WG at the Crystal Ballroom 2 > (instead of Emerald 3). Same time 1:30-2:15pm today. > > KISTI (the korean supercomputer center) are setting up a polycom > video service for the GFS-WG at the Crystal Ballroom 2. > > After the naming-WG BoF ends, OGSA team will go back to Emerald 3 > to have our own reporting session 2:15-3:30pm. > > You can participate in this naming WG BoF by dialing +1 (858)-678-558. > > This is apart from the polycom video conferencing. If your organization > has a polycom/video conferencing, you may wish to contact Arun to > receive the IP number to dial from your polycom(which can almost take > you there virtually). > > If you plan on calling from telephone, there is no pass code. If you plan > on video conferencing, we need your IP number. > > This session is held today at 8:30PM -9:15PM (California Time). > > Thanks and sorry for this the last minutes change. > ---- > Hiro Kishimoto > > > > -----Original Message----- > > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > > Sent: Wednesday, March 16, 2005 1:20 AM > > To: 'ogsa-wg'; 'gfs-wg(a)gridforum.org' > > Subject: WS-naming WG BoF announcement > > > > Hi all, > > > > OGSA-WG and GFS-WG agreed to have another WS-naming WG BoF > > session on March 16 (Wed) 1:30-2:15pm Korea time @ Emerald room > > (= Tue 8:30-9:15pm PST). > > > > We expect to hear GFS-WG's plan for RNS spec submission. And > > relationship between their RNS spec and new WG's deliverable will be > > discussed at this session. > > > > Dial-in information: > > toll: +1-323-785-4156 > > pass: 8980700 > > > > Thanks, > > ---- > > Hiro Kishimoto > >

1 0

** IMPORTANTE ** ROOM Change (WS-naming WG BoF announcement)
by Hiro Kishimoto 16 Mar '05

16 Mar '05

Hi all, WS-naming WG BoF will be held at GFS-WG at the Crystal Ballroom 2 (instead of Emerald 3). Same time 1:30-2:15pm today. KISTI (the korean supercomputer center) are setting up a polycom video service for the GFS-WG at the Crystal Ballroom 2. After the naming-WG BoF ends, OGSA team will go back to Emerald 3 to have our own reporting session 2:15-3:30pm. You can participate in this naming WG BoF by dialing +1 (858)-678-558. This is apart from the polycom video conferencing. If your organization has a polycom/video conferencing, you may wish to contact Arun to receive the IP number to dial from your polycom(which can almost take you there virtually). If you plan on calling from telephone, there is no pass code. If you plan on video conferencing, we need your IP number. This session is held today at 8:30PM -9:15PM (California Time). Thanks and sorry for this the last minutes change. ---- Hiro Kishimoto > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Wednesday, March 16, 2005 1:20 AM > To: 'ogsa-wg'; 'gfs-wg(a)gridforum.org' > Subject: WS-naming WG BoF announcement > > Hi all, > > OGSA-WG and GFS-WG agreed to have another WS-naming WG BoF > session on March 16 (Wed) 1:30-2:15pm Korea time @ Emerald room > (= Tue 8:30-9:15pm PST). > > We expect to hear GFS-WG's plan for RNS spec submission. And > relationship between their RNS spec and new WG's deliverable will be > discussed at this session. > > Dial-in information: > toll: +1-323-785-4156 > pass: 8980700 > > Thanks, > ---- > Hiro Kishimoto >

1 0

WS-naming WG BoF announcement
by Hiro Kishimoto 15 Mar '05

15 Mar '05

Hi all, OGSA-WG and GFS-WG agreed to have another WS-naming WG BoF session on March 16 (Wed) 1:30-2:15pm Korea time @ Emerald room (= Tue 8:30-9:15pm PST). We expect to hear GFS-WG's plan for RNS spec submission. And relationship between their RNS spec and new WG's deliverable will be discussed at this session. Dial-in information: toll: +1-323-785-4156 pass: 8980700 Thanks, ---- Hiro Kishimoto

1 0

RE: Karl's slides (RE: [ogsa-wg] Basic EM profile session)
by Hiro Kishimoto 14 Mar '05

14 Mar '05

Hi all, Karl asks me to revise his slides on the gridForge. You can find new one at; https://forge.gridforum.org/projects/ogsa-wg/document/ggf13-bes-ga-input/en… See you at the 9am session. ---- Hiro Kishimoto > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Monday, March 14, 2005 10:14 AM > To: 'ogsa-wg' > Subject: Karl's slides (RE: [ogsa-wg] Basic EM profile session) > > Hi all, > > Now, Karl gives me a input from Globus Alliance and it is now in > the GridForge. Have a look and prepare for the upcoming session. > > https://forge.gridforum.org/projects/ogsa-wg/document/ggf13-bes-ga-input/en… > > Thanks, > ---- > Hiro Kishimoto > > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro > > Kishimoto > > Sent: Monday, March 14, 2005 7:16 AM > > To: karlcz(a)univa.com; grimshaw(a)cs.virginia.edu; David Snelling; saga(a)grid.nii.ac.jp; > > andreas.savva(a)jp.fujitsu.com > > Cc: 'ogsa-wg'; mmm2a(a)virginia.edu > > Subject: [ogsa-wg] Basic EM profile session > > > > Karl, Andrew, Dave Snelling, Kazushige, Andreas, > > > > I upload *partially* written slide presentation for Basic EM candidate > > profile session to GridForge. > > > > https://forge.gridforum.org/projects/ogsa- > > wg/document/GGF13_basic_EM_profile/en/ > > 1 > > > > This session is schedule at March 15 (Tue) 9-10:30am @ Emerald room 3 > > and intended to be workshop style. Please come to join the discussion. > > It is GREAT if you can bring a couple of position paper slides with you. > > > > The following is a list of possible contributions; > > - OGSA Basic EM candidate profile proposal - Hiro > > - Candidate specifications > > o JSDL - Andreas > > o WS-Agreement - Karl > > o OGSA BES - Andrew > > - Related Grid project > > o Business Grid - Hiro > > o NaReGI - Kazushige > > o Globus - Karl > > o UNICORE - Dave > > > > If you have another great idea and want to share with us, > > please let me know before or at the session. > > > > Thanks, > > ---- > > Hiro Kishimoto > > > > > >

1 0

Discussion for OGSA-WG Basic Profile Session 3/15 3:00-4:30 (GMT +9:00)
by Tom Maguire 14 Mar '05

14 Mar '05

There will be an interesting discussion during the Basic Profile Session tomorrow at GGF13. The topic will be about the current thinking regarding Basic Profile surrounding 'core mandated requirements' vs 'conformance target requirements'. To be clearer should the Basic Profile mandate that use of say WS-ResourceProperties OR should the Basic Profile describe the requirements on WS-ResourceProperties IF the service uses WS-ResourceProperties. Dial in will be the published numbers in the GGF schedule Toll/Intl: 1-323-785-4156 Pass Code: 8980700 Sorry those of you in ET (1:00AM-2:30AM). Looking forward to the discussion. Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

[ogsa-wg | Basic Profile - 1324] Separate Security Basic Profile
by Sourceforge Tracker Monitor 14 Mar '05

14 Mar '05

A new artifact has been added: 1324 Submitted by: Tom Maguire Submitted date: 2005-03-14 03:31:48 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1324&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1324&group_id…) Summary: Separate Security Basic Profile Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1324 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-14 03:31:48 Submitted By: Tom Maguire Submit Date: 2005-03-14 03:31:48 Assigned To: &lt;None&gt; File(s): <None> Description: Should we have a separate profile document for security View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1323] Communication of assertions
by Sourceforge Tracker Monitor 14 Mar '05

14 Mar '05

A new artifact has been added: 1323 Submitted by: Tom Maguire Submitted date: 2005-03-14 03:27:21 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1323&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1323&group_id…) Summary: Communication of assertions Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1323 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-14 03:27:21 Submitted By: Tom Maguire Submit Date: 2005-03-14 03:27:21 Assigned To: &lt;None&gt; File(s): <None> Description: Profiles for common assertions in headers or Proxy Certificate View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1322] Use of Proxy Certificates
by Sourceforge Tracker Monitor 14 Mar '05

14 Mar '05

A new artifact has been added: 1322 Submitted by: Tom Maguire Submitted date: 2005-03-14 03:24:13 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1322&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1322&group_id…) Summary: Use of Proxy Certificates Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1322 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-14 03:24:13 Submitted By: Tom Maguire Submit Date: 2005-03-14 03:24:13 Assigned To: &lt;None&gt; File(s): <None> Description: Standard but not widely adopted outside of grid community View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1321] Discovery of key-info for encryption in message level security
by Sourceforge Tracker Monitor 14 Mar '05

14 Mar '05

A new artifact has been added: 1321 Submitted by: Tom Maguire Submitted date: 2005-03-14 03:21:14 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1321&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1321&group_id…) Summary: Discovery of key-info for encryption in message level security Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1321 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-14 03:21:14 Submitted By: Tom Maguire Submit Date: 2005-03-14 03:21:14 Assigned To: &lt;None&gt; File(s): <None> Description: Service Group Profile/ EPR embedding View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1320] Transport and/or Message Level security
by Sourceforge Tracker Monitor 14 Mar '05

14 Mar '05

A new artifact has been added: 1320 Submitted by: Tom Maguire Submitted date: 2005-03-14 03:18:34 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1320&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1320&group_id…) Summary: Transport and/or Message Level security Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1320 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-14 03:18:34 Submitted By: Tom Maguire Submit Date: 2005-03-14 03:18:34 Assigned To: &lt;None&gt; File(s): <None> Description: MUST or SHOULD?? View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Data: Proposed agenda for Wednesday 9th March: NEW TIME
by Dave Berry 14 Mar '05

14 Mar '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday March 9th, which will be at the NEW agreed time of 7.30am PST / 10.30am EST / 3.30pm GMT / 4.30 pm CET. UK Dial In: 0845 245 0224 US Dial In: 1866 838 0046 International Dial In: +44 1452 542309 PIN Number: 632 065 1) Early discussion (5 min) Note taker assignment Roll call Minutes approval (attached) - https://forge.gridforum.org/projects/ogsa-wg/document/Minutes_23rd_Febru ary_2005/en/1 Agenda bashing 2) Update on outstanding actions (5 min) - Dave to write draft charter for ByteIO WG - Mark to prepare document describing the draft ByteIO interface - Simon to mail the list about different types of metadata: data resource vs. service. - Mark to mail around URL of notes from London meeting - Dave to revise the current "straw man" document for next week - Dave to prepare concrete proposal for initial data profile (ByteIO, RNS, DAIS, GridFTP?) 3) GGF13 main session preparation (10 min) As part of the main OGSA outreach session, I will give a presentation on the data design team and the work we've done so far. I'd like to discuss this with the team on this call. 4) GGF13 BOF preparation (10 min) We have a BOF scheduled about the ByteIO interface. I have sent out a draft charter for the proposed WG. I would like to discuss how we should structure the BOF session. 5) GGF13 Profile preparation (10 min) Our first design team session is earmarked for discussion of an initial data profile, probably containing DAIS, SRM, ByteIO and possibly GridFTP. RNS has been put in a naming profile. I would like to discuss how we should structure the discussion. Also, it would be very helpful if someone would volunteer to write a first draft of a profile document. 6) Architecture update (15 min) I have put the current draft on GridForge - see https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Data_Architec ture_Straw_Man/en/1. We have a session booked to discuss this at GGF13, where we will concentrate on data architecture. 7) Wrap up (5 min) AOB Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

4 5

Basic EM profile session
by Hiro Kishimoto 14 Mar '05

14 Mar '05

Karl, Andrew, Dave Snelling, Kazushige, Andreas, I upload *partially* written slide presentation for Basic EM candidate profile session to GridForge. https://forge.gridforum.org/projects/ogsa-wg/document/GGF13_basic_EM_profil… 1 This session is schedule at March 15 (Tue) 9-10:30am @ Emerald room 3 and intended to be workshop style. Please come to join the discussion. It is GREAT if you can bring a couple of position paper slides with you. The following is a list of possible contributions; - OGSA Basic EM candidate profile proposal - Hiro - Candidate specifications o JSDL - Andreas o WS-Agreement - Karl o OGSA BES - Andrew - Related Grid project o Business Grid - Hiro o NaReGI - Kazushige o Globus - Karl o UNICORE - Dave If you have another great idea and want to share with us, please let me know before or at the session. Thanks, ---- Hiro Kishimoto

1 1

GGF13 ACS-WG sessions announcement.
by Keisuke Fukui 13 Mar '05

13 Mar '05

Folks, This is a reminder that we will have the ACS-WG#1 at Emerald 3 at 13:00. We welcome your participation. To see more detail, please enter acs in the search menu on the "GGF13 Schedule" on the GGF top page. http://www.gridforum.org/webevents/publish/webevent.cgi?cmd=listweek&ncmd=s… Thank you! -Keisuke

1 0

EGA feedback review session
by Hiro Kishimoto 13 Mar '05

13 Mar '05

Hi all, Enterprise Grid Alliance (EGA) have the kindness to give us a great feedback on our OGSA documents. Their feedback is now on the GridForge. https://forge.gridforum.org/projects/ogsa-wg/document/EGA_OGSA_review/en/1 > The OGSA version 1.0 document is extremely valuable in capturing the > requirements and consequent architectural requirements and capabilities > for grid systems, and as such is invaluable, the above comments not > withstanding. From an EGA perspective, greater clarity and focus is > required in order to ensure that the OGSA and its related standards > meets the needs of the enterprise grid community, and therein lies the > opportunity for future collaboration. OGSA-WG agreed to deliberate and make a suitable reply to EGA at the OGSA-WG session #5, March 15 (Tue) 11am-12:30pm. I believe that it will be a great opportunity that GGF and EGA will work together based on the OGSA architecture. OGSA spec authors: Please come and join this review session tomorrow. Thanks, ---- Hiro Kishimoto

1 0

outreach session draft slides
by Hiro Kishimoto 13 Mar '05

13 Mar '05

Hi all, I upload my slides presentation draft to GridForge GGF13 folder. https://forge.gridforum.org/projects/ogsa-wg/document/GGF13_outreach_sessio… tus/en/1 It is one of three presentations we will give at the OGSA outreach session today. The others are (1) what is profile by Dave Snelling and (2) OGSA data service architecture by Dave Berry. Please have a look and give me your feedback (hopefully) before the session; March 14 (Mon) 1-2:30pm Korea time. Thanks, ---- Hiro Kishimoto

1 0

updated GGF13 session plan
by Hiro Kishimoto 13 Mar '05

13 Mar '05

Hi all, Please find updated session plan for GGF13. It is also uploaded to GridForge. We may change dial-in number in order to reduce Hotel's phone charge. Please stay tuned. ---- Hiro Kishimoto

1 0

RE: Modeling State: Technical Questions
by Hiro Kishimoto 13 Mar '05

13 Mar '05

Paul's email bounced. ---- Hiro Kishimoto Subject: RE: Modeling State: Technical Questions Date: Fri, 11 Mar 2005 12:14:07 -0000 From: "Paul Watson" <Paul.Watson(a)newcastle.ac.uk> To: "Ian Foster" <foster(a)mcs.anl.gov> Dear Ian, Having faithfully promised myself that I wouldn't spend more time on discussions about low-level WS specs, I found myself drawn in as this is a very interesting comparison (it reminded me of the excellent work done in the DAIS WG to compare different approaches to database access services). In particular, it gives me a concrete example that I can use to ask some questions about the use of WSRF. Given that I come from a non-WSRF background (my experience is with services that use the approach in your option #3) much of what I've written below is about understanding the motivation for switching to the WSRF approach. But, I'd like to stress that this isn't intended to be hostile ... it's meant to improve my understanding and (hopefully) move on the technical debate. I was going to send it to you only, as you offered to collate feedback, but as Dave Berry is proposing to discuss these options next week (and I won't be there) and has posted on it, I thought that I'd send it to Dave and others too as input to these discussions. > OPTIONS >=20 > 1) (WSRF) >=20 > The job handle is an EPR to a WS-Resource, in which case the case the=20 > WSRF operations can be used to get status and delete: >=20 > send "GetResourceProperty(status)" to job-handle > send "Destroy" to job-handle >=20 If there are other operations that need to be supported on jobs, e.g. "suspend, resume, checkpoint, change priority"... then am I right in thinking that these would be provided by application-specific operations on resources that were not defined by WSRF? e.g. send "Suspend" to job-handle, send "changePriority" to job-handle etc. > In addition, one will probably also want to be able to send requests=20 > to the job-factory, which is straightforward as there is no strong=20 > encapsulation in WSRF. E.g.: >=20 > send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service Given previous misunderstandings, it is good to see that your WSRF example also includes some operations on the service. I think that the motivation for introducing operations on the service is that these can then operate over a set of resources (e.g. "all-jobs-owned-by-ian"). This reduces the number of messages (e.g. one interaction with the service vs. one to each resource in the set of "all-jobs-owned-by-ian"), and also allows the set of resources to be selected using information encapsulated within the service (e.g. "jobs-owned-by-ian", "jobs that have nearly reached their quota", "jobs that have run for more than 24 hours"). Therefore, for similar reasons, it would, I think, also be beneficial to define a "check-jobs-status" operation on the service. This would allow, for example: check-jobs-status("all-jobs-owned-by-ian") Also, as, "all-jobs-owned-by-ian" defines a set of jobs, it would seem reasonable to allow the consumer to specify the set of jobs by name: "destroy(job1,job27,job35)"=20 "check-jobs-status(job1,job27,job35)" (I may be wrong, but I think that the current naming proposal would allow this by giving the consumer the abstract name for a resource as well as the epr). These operations on the service are the sort I'd expect to see in option #3 (as I'll explain below). So, I think that one could view option #1 as taking the operations from option #3 and then adding to them a set of operations on individual resources. These operations on the service allow a consumer to (I think) do everything without using the operations on individual resources. This is because these operations address the general case for a job submission service... they provide operations over the set of resources encapsulated by the service. They appear to have the advantage of supporting and encouraging larger-grained operations, e.g. in one message you can ask about a set of resources rather than just one. I expect that will be important for performance, given the costs of sending messages between web services. The operations on individual resources seem to be a special case of the general case, and this raises the question (to me) that if the job management service provides the general case, then when is it better to use the special case? > 3) (Job id) The job-handle is a job-factory-specific string, I'd think that it could be an "abstract name" in OGSA naming terms (though the naming proposal isn't fixed yet, so I may be wrong). > and we define > job-factory-specific operations for manipulating the job, e.g.: >=20 > send "check-job-status(job-handle)" to job-factory > send "terminate-job(job-handle)" to job-factory >=20 > #3 is very similar to #1 and #2: the message sent over the wire in=20 > each case contains the same information (operation name + Web service=20 > address + job-id-info). As described in my comments on option #1 above, I'd suggest that both these operations should be defined to operate on a set of jobs (c.f. option #1's "destroy(all-jobs-owned-by-ian)). e.g. the operations on the service would allow: "check-jobs-status(job1, job14,job27)" "terminate-jobs(job2, job35)" Allowing multiple job names in a message is, I think, no more difficult to implement, and naturally scales up to larger granularity operations (e.g. one interaction with a service is enough to carry out actions on 1,2 or 500 jobs). Option #3 also differs from #1 and #2 as it does not rely on ws-addressing (though it could use it). [A personal view is that I see this as an advantage for those who want to design and build services now or in the near future. This is because the service can use only currently stable specifications found in the set "blessed" by WS-Interoperability, and these are provided in an interoperable manner by a wide range of existing WS platforms.] > What is different about #3 is that you have to manage this job-handle=20 > separately from the job-factory EPR. Also, you don't use the=20 > standardized WSRF/WSN operations. >=20 > Have I captured all of the options that people think we should be=20 > considering? >=20 I note that Dave & Karl have now posted about the possible use of ResourceGroups. I based the above on your message which did not discuss their use, and so I wonder if it would therefore be helpful for someone to produce a version of option #1 that creates and uses resourcegroups. This was a very good start for discussion, and I'd be interested on your views on my comments above. Regards Paul.=20 >-----Original Message----- >From: Ian Foster [mailto:foster@mcs.anl.gov]=20 >Sent: 07 March 2005 04:47 >To: Tony Hey; Frank Siebenlist >Cc: Dennis Gannon; Samuel Meder; ogsa-wg;=20 >paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com;=20 >savas.parastatidis(a)ncl.ac.uk; gray(a)microsoft.com;=20 >humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu;=20 >aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com >Subject: Modeling State: Technical Questions > >Dear All: > >In an effort to move forward this debate about "OGSA=20 >plumbing", I thought=20 >I'd attempt to describe the different positions that I've seen=20 >expressed.=20 >Perhaps people can read this quickly, and provide feedback as=20 >to where I=20 >have not captured things correctly. I'll be happy to collate=20 >responses sent=20 >directly to me and forward them, if there is interest. > > >CONTEXT > >The context is that OGSA-WG needs to develop some low-level=20 >specifications,=20 >such as execution management services, that require modeling=20 >interactions=20 >that involve server-side state. E.g., in the following=20 >pseudo-code example,=20 >we request the creation of a "job": > > send "create(jsdl-specification)" to job-factory-web-service > receive "job-handle" from job-factory-web-service > >I think that everyone accept that this sort of interaction is=20 >needed. (Let=20 >me know if not.) > >Where people differ in their views is with respect to what the=20 >"job-handle"=20 >should be and how we should represent operations on the job.=20 >I've heard=20 >three views expressed, as follows. > > >OPTIONS > >1) (WSRF) > >The job handle is an EPR to a WS-Resource, in which case the=20 >case the WSRF=20 >operations can be used to get status and delete: > > send "GetResourceProperty(status)" to job-handle > send "Destroy" to job-handle > >In addition, one will probably also want to be able to send=20 >requests to the=20 >job-factory, which is straightforward as there is no strong=20 >encapsulation=20 >in WSRF. E.g.: > > send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service > >This approach exploits the standardized syntax and semantics for the=20 >various operations (GetResourceProperty, Destroy, etc.) defined by the=20 >WSRF/WSN specifications. > > >2) (WS-Transfer) > >The job-handle is an EPR to a WS-Transfer resource, in which case the=20 >appropriate WS-Transfer operations can be used to get status=20 >and delete. > > send "Get" to job-handle > send "Delete" to job-handle > >Assuming that there is no strong encapsulation in WS-Transfer=20 >either, one=20 >can also contact the job-factory directly when required: > > send "destroy(jobs-owned-by-ian)" to job-factory > >This approach exploits the syntax and semantics for the=20 >various operations=20 >(GetResourceProperty, Destroy, etc.) defined by the=20 >WS-Transfer specification. > >#2 is very similar to #1. One can argue the pros and cons of the two=20 >approaches. I'm concerned that you have to return the whole=20 >resource state,=20 >not just a single component (e.g., the status field). But that's a=20 >relatively minor issue. > > >3) (Job id) The job-handle is a job-factory-specific string,=20 >and we define=20 >job-factory-specific operations for manipulating the job, e.g.: > > send "check-job-status(job-handle)" to job-factory > send "terminate-job(job-handle)" to job-factory > >#3 is very similar to #1 and #2: the message sent over the=20 >wire in each=20 >case contains the same information (operation name + Web=20 >service address +=20 >job-id-info). What is different about #3 is that you have to=20 >manage this=20 >job-handle separately from the job-factory EPR. Also, you=20 >don't use the=20 >standardized WSRF/WSN operations. > >Have I captured all of the options that people think we should=20 >be considering? > > >WHAT OGSA-WG SHOULD DO > >Given this characterization, I'd also be interested in=20 >people's views as to=20 >how OGSA-WG should proceed when considering specifications=20 >that involve=20 >this sort of interaction pattern. > >The majority of active participants OGSA-WG participants seem to favor=20 >option #1, but I've also heard people argue in favor of=20 >approaches #2 and #3. > >Tony Hey proposed, I think, that we should define=20 >specifications like job=20 >management in terms of some more abstract interface that can=20 >then be mapped=20 >to each of the approaches above, as desired. > >Frank Seibenlist observed that we can use WSRF/WSN as such an abstract=20 >interface: given an interface defined in terms of WSRF/WSN=20 >specifications,=20 >one can derive, via straightforward transformations, a concrete=20 >specification in the style of approach #2 or #3. > >Regards -- Ian. > > >

1 0

[ogsa-wg | Basic Profile - 1317] QueryRP should be optional
by Sourceforge Tracker Monitor 11 Mar '05

11 Mar '05

A new artifact has been added: 1317 Submitted by: Andreas Savva Submitted date: 2005-03-11 20:27:44 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1317&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1317&group_id…) Summary: QueryRP should be optional Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1317 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-11 20:27:44 Submitted By: Andreas Savva Submit Date: 2005-03-11 20:27:44 Assigned To: &lt;None&gt; File(s): <None> Description: [Submitted by Dave Snelling on the ogsa-wg ml] Folks, I would like to open an issue on this. It appears that Query resource Properties was made mandatory in the Base Profile. I believe that give the state and number of query technologies possible and the existence of two other mechanisms to access RPs, this should be optional. Thanks to Andreas for checking the minutes for me to ascertain if this issue was actually discussed. It was not and therefore, I feel it is safe to open it. Begin forwarded message: > From: Andreas Savva <andreas.savva(a)jp.fujitsu.com> > Date: 9 March 2005 7:19:16 GMT > To: David Snelling <David.Snelling(a)uk.fujitsu.com> > Subject: Re: Favour > > I also looked at my initial notes and I couldn't find a mention of this. I think this is a problem with my notes (the minute taker was broken at the time). Sorry. > > Is there anything else you want me to do? View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Dave Berry 11 Mar '05

11 Mar '05

-----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: 03 March 2005 15:03 * Interactions with multiple resources: I think that's a red herring. E.g., a job factory can return EPRs to WS-Resources representing jobs, thus allowing individual jobs to be monitored and controlled, if needed. The factory can also maintain a service group representing all jobs, and then support operations that allow a client to "destroy all jobs that match a certain pattern" (for example). It's not an either/or. I'd like to drill down on this issue, because to me it seems a rare technical question amongst a sea of WS-FUD. Tony has presented the case in abstract. DAIS raised a concrete example some months ago. The question, as I understand it, is how to send a single message to multiple resources held by a given service using WSRF. (The supposition is that you know that these resources are accessible via the same service). I've had two possible patterns suggested to me that address this question : 1. Pass multiple EPRs to an operation on the service 2. Use a service group To take these in turn, the first pattern is worth highlighting because some critics of WSRF assume that the only way to use an EPR is to call an operation on it directly. Of course this isn't true; you can actually pass EPRs as arguments to another operation if that suits your needs. The second pattern provides a single operation on a group of resources. At first glance this seems to have the downside that the server controls which resources are in the set, rather than the client passing in a list. However, Ian's comment above suggests that the service group can provide a mechanism that allows operations to be invoked on subsets of the resources. I don't know enough about service groups to comment, except that this seems a reasonable solution. I would appreciate seeing these patterns explored in more depth - possibly in a face to face meeting next week? From the above, it certainly seems that the technical concern that Tony articulated can be addressed. Dave.

2 1

Basic EM BOF: Issues
by Ian Foster 11 Mar '05

11 Mar '05

Dear All: Steven suggested that we raise issues on the list ahead of the BEM BOF, so I'll take the bull by the horns and make a few comments about the largish "elephant in the room" that we seem to be ignoring. OGSA WG has identified a few basic patterns that seem to arise frequently in distributed system management, at least, and apparently elsewhere too, and has proposed to use some conventional encodings of those patterns. E.g., it has proposed to use: a) EPRs as names for things b) portTypes defined in WS-ResourceLifetime for lifetime management (explicit and lease-based destruction) c) portTypes defined in WS-ResourceProperties for access to state/status information d) portTypes defined in WS-Notification for subscription. The Grimshaw/Newhouse proposal involves at least the first three of these patterns, but uses a different conventional encoding for each of them, i.e., it proposes to use abstract names plus context-ids to name things, and it introduces new portTypes for lifetime management and subscription. Thus, the elephant: what do we do about this? Does this make the proposed design non-OGSA-compliant? Does it mean that we are going to abandon attempts at common mechanisms for common things? Is this an implicit suggestion that we should be dropping those conventions in OGSA? We addresses exactly these questions at the last F2F, and agreed (I thought) that we *did* want to build on our previously agreed conventional encodings of standard patterns. However, it seems that the issue is being put back on the table. I think we need to resolve this before we move forward. I'll mention again that the GT4 GRAM design, which I circulated a few weeks ago, provides a complete job management interface based on the OGSA conventions. I'd like to suggest that people study this ahead of the meeting, as it shows how simple a rendering of BES functionality can be achieved based on WSRF/WSN conventions for state access, etc. Regards -- Ian. At 08:59 AM 3/8/2005 +0000, Dave Berry wrote: >I thought this was what Andrew meant. Anyway, it is important that >people taking part in the new WG realise that they are constrained by >decisions made in the overall group. They can of course raise issues to >be decided in the overall group, with the BEM service(s) as examples of >why the issues are important. But we don't want to end up in a >situation where (say) DAIS implements the "multiple arguments" pattern >one way and OGSA-BEM implements it a different way. > >Dave. > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > > Behalf Of David Snelling > > > > I would agree with Ian here based on our agreement at the Washington > > F2F. There we agreed the our ptofiles would be consistent with the > > architecture. I believe this should also apply to these spawned WGs. > > Technically however, the forming WG could charter its self to be > > constrained to the current EMS model. I would prefer that charter > > support the same "invariant" model we use for profiles. This would > > allow the EMS model to be modified in light of lessons learned in the > > new WG. _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

2 1

My apologies for Korea
by Ian Foster 10 Mar '05

10 Mar '05

I've said this to a few of you, but I wanted to say I won't be in Seoul due to a long-standing family commitment that requires me to travel to the U.K. I wish you all the best for what should be an important meeting. Regards, Ian. _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

1 0

GT 4.0 GRAM docs for input to BES discussions
by Karl Czajkowski 10 Mar '05

10 Mar '05

Here is a compact summary of the GT 4.0 WS-GRAM interface and links to further documentation. Please start by reading the documentation unless you are already an expert on GRAM, XSD, WSDL, and WSRF concepts. --------------------------------------------------------- GT 4.0 WS-GRAM documentation Note, these documents are in draft form... 1) GRAM Key Concepts http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/ke… 2) WS-GRAM Approach http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/ke… 3) Semantics and syntax of WSDL http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/ws… 4) Job Description Language http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/ws… 5) Links to more WS-GRAM docs than you can shake a stick at http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/ws… Because this is already a lot of documentation, the following is a terse overview of the WSDL rendering of the core WS-GRAM job discovery, submission, monitoring, and cancellation interface. --------------------------------------------------------- PORTTYPE ManagedJobFactoryPortType The Managed Job Factory Resource (MJFR) represents one localized job scheduler or compute element. (In GT 4.0, there is a separate MJFR for each deployed local scheduler adapter on a host.) It is a WSRF style resource with a resource properties document to represent the overall status and capabilities of the local compute element: <managedJobFactoryResourceProperties> <localResourceManager>xsd:string</localResourceManager> <globusLocation>xsd:string</globusLocation> <hostCPUType>xsd:string</hostCPUType>? <hostManufacturer>xsd:string</hostManufacturer>? <hostOSName>xsd:string</hostOSName>? <hostOSVersion>xsd:string</hostOSVersion>? <scratchBaseDirectory>xsd:string</scratchBaseDirectory>? <delegationFactoryEndpoint>wsa:EndpointReferenceType</delegationFactoryEndpoint> <stagingDelegationFactoryEndpoint>wsa:EndpointReferenceType</stagingDelegationFactoryEndpoint>? <condorArchitecture>xsd:string</condorArchitecture>? <condorOS>xsd:string</condorOS>? <gluece:GLUECE> <gluece:Cluster Name=xsd:string UniqueID=xsd:string InformationServiceURL=xsd:anyURI> <SubCluster/>* xsd:any##other* </gluece:Cluster>* <ComputingElement> <Info/>? <State/>? <Policy/>? <Job/>* <AccessControlBase/>? xsd:any##other* </ComputingElement>* xsd:any##other* </gluece:GLUECE>? <gluece:GLUECESummary/>? <ServiceMetaDataInfo> <startTime>xsd:dateTime</startTime> <version>xsd:string</version> </ServiceMetaDataInfo> </managedJobFactoryResourceProperties> These properties allow inspection of the underlying compute platform using an XSD rendering of the GLUE schema: gluece:GLUECE, gluece:GLUECESummary (Please see the GLUE schema for more information, using ad-hoc GRAM properties: hostCPUType, hostManufacturer, hostOSName, hostOSVersion while a few provide introspection on the GRAM deployment itself: localResourceManager, globusLocation, scratchBaseDirectory, ServiceMetaDataInfo The two EPRs are used by a client to discover where to delegate credentials that will be referenced by future job submissions: delegationFactoryEndpoint, stagingDelegationFactoryEndpoint. ---------- OPERATION job:createManagedJob Request creation of a Managed Executable Job Resource whose EPR will be returned in the response. INPUT message: createManagedJobInputMessage has one part: <createManagedJob> <InitialTerminationTime>xsd:dateTime</InitialTerminationTime>? <JobID>wsa:AttributedURI</JobID>? <wsnt:Subscribe></wsnt:Subscribe>? <desc:job> ... </desc:job> </createManagedJob> The optional JobID element is used to request idempotent invocation semantics in a binding-independent manner. The optional wsnt:Subscribe element is used to request automatic subscription to the newly created Managed Job. This call can also create a Managed Multi-Job Resource, i.e. a co-allocated job spread across multiple WS-GRAM hosts, because the job element is actually in an XSD choice with a multijob element. OUTPUT message: createManagedJobOutputMessage has one part: <createManagedJobResponse> <NewTerminationTime>xsd:dateTime</NewTerminationTime> <CurrentTime>xsd:dateTime</CurrentTime> <managedJobEndpoint>wsa:EndpointReferenceType</managedJobEndpoint> <subscriptionEndpoint>wsa:EndpointReferenceType</subscriptionEndpoint>? </createManagedJobResponse> The optional subscriptionEndpoint is returned if ----------- Other operations, composed from the WSRF service environment, are: [From WS-ResourceProperties] -- get access to factory status information GetResourceProperty QueryResourceProperties GetMultipleResourceProperties --------------------------------------------------------- PORTTYPE ManagedExecutableJobPortType A Managed Executable Job Resource (MEJR) represents one job that has already been submitted by a client. It is a WSRF style resource with a resource properties document to represent status of the job: <managedExecutableJobResourceProperties> <stdoutURL>xsd:anyURI</stdoutURL>? <stderrURL>xsd:anyURI</stderrURL>? <credentialPath>xsd:string</credentialPath>? <exitCode>xsd:int<exitCode/>? <serviceLevelAgreement> <desc:job> ... </desc:job> </serviceLevelAgreement> <Capacity>xsd:int</Capacity> <userSubject>xsd:string</userSubject> <fault/> <TopicExpressionDialects>xsd:anyURI</TopicExpressionDialects> <Topic Dialect=xsd:anyURI> xsd:any? </Topic>+ <TerminationTime>xsd:dateTime</TerminationTime> <localUserId>xsd:string</localUserId> <CurrentTime>xsd:dateTime</CurrentTime> <holding>xsd:boolean</holding> <RegistrantData>xsd:base64Binary</RegistrantData> <RendezvousCompleted>xsd:boolean</RendezvousCompleted> <FixedTopicSet>xsd:boolean</FixedTopicSet> <state>Unsubmitted|StageIn|Pending|Active|Suspended|StageOut|Cleanup|Done|Failed</state> </managedExecutableJobResourceProperties> These properties relate to job output file management: stdoutURL, stderrURL delegated credential management: credentialPath parallel task rendezvous (for MPICH-G2): Capacity, RegistrantData, RendezvousCompleted job status: exitCode, fault, holding, state job introspection: credentialPath, serviceLevelAgreement, localUserId for WSRF introspection: TopicExpressionDialects, Topic, FixedTopicSet, TerminationTime, CurrentTime. ---------- OPERATION exec:release Releases job from hold state. The hold state is an optional behavior selected in the job description to prevent post-execution file deletions (clean-up) from occuring while a remote client is still attempting to access the files. The release operation permits the normal clean-up to occur. INPUT message: releaseInputMessage has one (empty) part: <release/> OUTPUT message: releaseOutputMessage has one (empty) part: <releaseResponse/> ----------- In addition, a rendezvous provides an additional operation: [From GT4 rendezvous manager type] -- support for bootstrapping MPICH-G2 etc. register Other operations, composed from the WSRF service environment, are: [From WS-ResourceLifetime] -- schedule termination of a job SetTerminationTime Destroy [From WS-ResourceProperties] -- get access to job status information GetResourceProperty QueryResourceProperties GetMultipleResourceProperties [From WS-BaseNotification] -- subscribe for job status notifications Subscribe GetCurrentMessage --------------------------------------------------------- Job description document syntax for use in creating a Managed Executable Job Resource: <job> <factoryEndpoint>wsa:EndpointReferenceType</factoryEndpoint>? <jobCredentialEndpoint>wsa:EndpointReferenceType</jobCredentialEndpoint>? <stagingCredentialEndpoint>wsa:EndpointReferenceType</stagingCredentialEndpoint>? <localUserId> ... </localUserId> [0..1] <holdState> ... </holdState> [0..1] <executable>xsd:string</executable>? <directory>xsd:string</directory>? <argument>xsd:string</argument>* <environment> <name>xsd:string</name> <value>xsd:string</value> </environment>* <stdin>xsd:string</stdin>? <stdout>xsd:string</stdout>? <stderr>xsd:string</stderr>? <count>xsd:positiveInteger</count>? <libraryPath>xsd:string</libraryPath>* <hostCount>xsd:positiveInteger</hostCount>? <project>xsd:string</project>? <queue>xsd:string</queue>? <maxTime>xsd:long</maxTime>? <maxWallTime>xsd:long</maxWallTime>? <maxCpuTime>xsd:long</maxCpuTime>? <maxMemory>xsd:nonNegativeInteger</maxMemory>? <minMemory>xsd:nonNegativeInteger</minMemory>? <jobType>mpi|single|multiple|condor</jobType>? <fileStageIn>rft:TransferRequestType</fileStageIn>? <fileStageOut>rft:TransferRequestType</fileStageOut>? <fileCleanUp>rft:DeleteRequestType</fileCleanUp>? <extensions>xsd:any##other</extensions>? </job> An extended form of this syntax consists of an array of the above descriptions to define a "multi-job". -- Karl Czajkowski karlcz(a)univa.com

1 0

GGF13 OGSA session #5
by Hiro Kishimoto 10 Mar '05

10 Mar '05

Hi all, At today's OGSA-WG teleconference, we agree to use OGSA-WG session #5 (March 15 (Tue) 11am-12:30pm Korea time = 8-9:30pm CST) for EGA feedback discussion. We are doing our best to prepare GGF13 but unlikely to make "basic data profile" discussion ready by March 15. We agreed to skip it at GGF13 On the other hand, John Tollefsrud, GGF liaison to the Enterprise Grid Alliance (EGA), asks us to review and answer EGA's feedback on OGSA documents. UK eScience is a member of EGA and Steven Newhouse will be represent EGA at the session. Also another EGA rep in US can dial-in. Attached is their feedback document. Please have a look. Thanks, ---- Hiro Kishimoto

1 0

DRMAA view on BES
by Rajic, Hrabri 09 Mar '05

09 Mar '05

While the DRMAA group members would like to stay on the sidelines regarding the WS infrastructure, JSDL, and WS-Agreement issues we feel that OGSA-BES members could save some time when discussing task/job/whatever management, control, and status portTypes to look into section 6.3.8 on page 26 of the DRMAA IDL binding document. If this is something that the initiators have in mind to discuss at OGSA-BES BoF we could contribute a very (ultra?) short presentation. Greetings -Hrabri

1 0

Regrets for this evenings telecon (3/9)
by Tom Maguire 09 Mar '05

09 Mar '05

Need to tidy up a few things around the house before travel to Korea, Tom Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

Globus Alliance views on BES
by Karl Czajkowski 09 Mar '05

09 Mar '05

Hi, sorry for the delay but we've put together some documents summarizing our Globus Alliance view on what the important issues and constraints are for a successful Basic Execution Service standard. Please see the attached documents: 1. Approach -- a high-level survey of our concerns 2. Rendering -- more detailed thoughts about interface designs 3. Roadmap -- simple thoughts on a phased approach Later, I will send an additional note with links to Globus Toolkit 4.0 draft documents for our WS-GRAM job management component, and a brief overview of the service interface for those who want to think in WSDL and not read a bunch of documents. This probably will not be ready for another 12-18 hours. Please feel free to respond on the list or privately with comments about agreement, disagreement, or relative priorities! I will try to incorporate any feedback I hear into planning for my ultra short presentation at the BoF in Seoul. Thanks, karl -- Karl Czajkowski karlcz(a)univa.com

1 1

Proposed agenda for OGSA ByteIO BOF
by Dave Berry 09 Mar '05

09 Mar '05

All, Here is a draft agenda for Monday's ByteIO BOF. (I note Ian's concern about WG names and assume this will be thrashed out by the GFSG/ADs). Presentation of GGF IP Rules Pass around sign-up sheet Background & Use Cases (Dave) Discussion Proposed interface (Mark) Discussion Charter discussion Seven questions Existing WG or new WG? Milestones Stakeholders, co-chairs Scheduling of work, calls etc. Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Proposed agenda for March 9th call
by Hiro Kishimoto 09 Mar '05

09 Mar '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 9th Wednesday from 5pm to 7pm (CST). This is the last one before GGF13. Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0309 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) Agenda bashing 2) GGF13 session preparation (30 min) Confirmation of owner/note taker/guests for each session - OGSA session plan https://forge.gridforum.org/projects/ogsa-wg/document/GGF13_session_plan - GGF13 schedule http://tinyurl.com/4cz98 - Basic EM profile discussion (Hiro will send out proposal before the call) 3) roadmap discussion (if available) 4) Wrap up (10 min) AOB Mar. 13-16 GGF13 in Seoul ---- Hiro Kishimoto

1 1

Base Profile Issue: Query RP
by David Snelling 09 Mar '05

09 Mar '05

Folks, I would like to open an issue on this. It appears that Query resource Properties was made mandatory in the Base Profile. I believe that give the state and number of query technologies possible and the existence of two other mechanisms to access RPs, this should be optional. Thanks to Andreas for checking the minutes for me to ascertain if this issue was actually discussed. It was not and therefore, I feel it is safe to open it. Begin forwarded message: > From: Andreas Savva <andreas.savva(a)jp.fujitsu.com> > Date: 9 March 2005 7:19:16 GMT > To: David Snelling <David.Snelling(a)uk.fujitsu.com> > Subject: Re: Favour > > I also looked at my initial notes and I couldn't find a mention of > this. I think this is a problem with my notes (the minute taker was > broken at the time). Sorry. > > Is there anything else you want me to do? > > Andreas Savva wrote: >> I had a look at the f2f minutes but there is no mention of this.... >> Sorry. >> My notes from the first day were very bad as I had a very hard time >> staying focused. Terrible jet lag in the afternoon. >> I'll have a look through the raw notes which I have back home and let >> you know if I find anything. >> David Snelling wrote: >>> Andreas, >>> >>> Can you find (in the minutes) any info on the discussion at the F2f >>> as to why the QueryRP was made manditory? >>> > > -- > Andreas Savva > Fujitsu Laboratories Ltd > > -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

Proposed (DRAFT) Agenda for Basic EM BOF
by Andrew Grimshaw 09 Mar '05

09 Mar '05

The objective of the BOF is to form the OGSA Basic Execution Management Service Working Group (OGSA-BEM). The output of the OGSA-BEM will fit into the overall OGSA EMS architecture, as initially described in the OGSA V1 Document. It is expected that the OGSA EMS architecture will evolve over time - and that evolution will eventually need to be incorporated. Such incorporation may not take place in this working group - depending on whether OGSA-BEM completes before changes are made in the overall OGSA-EMS. Proposed Agenda Presentation of GGF IP Rules Pass around sign-up sheet Background on OGSA EMS Basic Execution Management - A Focus on Minimal Services Draft Service Containers description Charter discussion Should charter be extended to include "Actors"? Should the charter be extended to include any form of agreements? Milestones Scheduling of calls

4 7

RE: [ogsa-wg] A thought
by Von Reich, Jeffrin 08 Mar '05

08 Mar '05

Well, There is nothing like sense of humor for doing a self analysis :). for that maybe more coffee also might be required ( and more note taking too :) ) . take care, Jeffrin -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: Monday, March 07, 2005 5:12 PM To: Andrew Grimshaw; ogsa-wg(a)ggf.org Subject: Re: [ogsa-wg] A thought and consumed countless gallons of coffee!! At 06:55 PM 3/7/2005 -0500, Andrew Grimshaw wrote: Since Brussels the OGSA working group (including design teams) have had three face-to-face meetings - in Washington DC, Chicago, and London. They have - spent over eighty hours on group teleconferences - flown over 200,000 miles to face-to-face meetings - spent over 100 person nights in hotel rooms - eaten countless muffins and sweet rolls - gained more kilos than we can count _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

1 0

RE: [ogsa-wg] OGSA-BES-07Mar2005
by Dave Berry 08 Mar '05

08 Mar '05

I have a couple of thoughts about the proposed interface (quite apart from the "WSRF?" Discussion). I post them here because they might be relevant to the general question of the "multiple arguments" pattern. 1. The getActivityStatus operation takes an array argument and returns an array of array of strings. This looks like a design written by a C programmer(*). In the context of a Web Service interface, wouldn't it be more appropriate to return an XML document? It should be possible to define a simple XML schema that nests activity statuses under activity IDs, posibly restricting the range of permitted activity statuses (rather than using arbitrary strings). This would be more robust and self-documenting than relying on positional arguments in arrays. (*) I'm not implying that programming in C is bad per se, just that it's inappropriate for this level of interface. 2. The getActivityStatus and terminateActivity operations take an array of activity IDs. This means that the client has to include logic for deciding which IDs to pass in. An alternative might be to use a query language, so that the client could specify sets of activities that meet certain criteria. E.g. a simple query might specify "all activities owned by this client" (assuming a definition of ownership...). More complex queries might specify: - "all activities that have been running for more than x minutes" - "all activities that have failed to start" - "all activities taking more than X megabytes" - "the activities with IDs in this list" (i.e. providing the same behaviour as an array parameter). This may at first seem an ambitious suggestion, but of course we can use an existing query language rather than develop a new one. If the activities can be represented as a virtual XML document, then the query language can be XPath or XQuery. 3. We need to clarify when operations use abstract names and when they use addresses. This is a general question across the architecture, but it is particularly apparent here because we see clear differences between the proposals. Also, what happens when a job is migrated from one service to another? I realise that this is outside the scope of OGSA-BES, but the answer to that question may constrain the design here (or vice versa). Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Steven Newhouse > Sent: 07 March 2005 21:45 > To: ogsa-wg > Subject: [ogsa-wg] OGSA-BES-07Mar2005 > > Document for tonight's discussion. > > Steven > -- > ---------------------------------------------------------------- > Dr Steven Newhouse Tel:+44 (0)2380 598789 > Deputy Director, Open Middleware Infrastructure Institute (OMII) > Suite 6005, Faraday Building (B21), Highfield Campus, > Southampton University, Highfield, Southampton, SO17 1BJ, UK >

2 1

RE: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF
by Dave Berry 08 Mar '05

08 Mar '05

I thought this was what Andrew meant. Anyway, it is important that people taking part in the new WG realise that they are constrained by decisions made in the overall group. They can of course raise issues to be decided in the overall group, with the BEM service(s) as examples of why the issues are important. But we don't want to end up in a situation where (say) DAIS implements the "multiple arguments" pattern one way and OGSA-BEM implements it a different way. Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of David Snelling > > I would agree with Ian here based on our agreement at the Washington > F2F. There we agreed the our ptofiles would be consistent with the > architecture. I believe this should also apply to these spawned WGs. > Technically however, the forming WG could charter its self to be > constrained to the current EMS model. I would prefer that charter > support the same "invariant" model we use for profiles. This would > allow the EMS model to be modified in light of lessons learned in the > new WG.

1 0

A thought
by Andrew Grimshaw 08 Mar '05

08 Mar '05

Since Brussels the OGSA working group (including design teams) have had three face-to-face meetings - in Washington DC, Chicago, and London. They have - spent over eighty hours on group teleconferences - flown over 200,000 miles to face-to-face meetings - spent over 100 person nights in hotel rooms - eaten countless muffins and sweet rolls - gained more kilos than we can count

3 2

[ogsa-wg | Basic Profile - 1316] Should Basic Profile v1 rely on Naming Profile
by Sourceforge Tracker Monitor 08 Mar '05

08 Mar '05

A new artifact has been added: 1316 Submitted by: Tom Maguire Submitted date: 2005-03-07 21:06:08 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1316&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1316&group_id…) Summary: Should Basic Profile v1 rely on Naming Profile Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1316 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-07 21:06:08 Submitted By: Tom Maguire Submit Date: 2005-03-07 21:06:08 Assigned To: &lt;None&gt; File(s): <None> Description: What if any WS-Addressing reqt should be in BP if that is true View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1315] Remove WS-SecureConversation, WS-Policy and OGSI Non normative refs
by Sourceforge Tracker Monitor 08 Mar '05

08 Mar '05

A new artifact has been added: 1315 Submitted by: Tom Maguire Submitted date: 2005-03-07 20:21:41 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1315&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1315&group_id…) Summary: Remove WS-SecureConversation, WS-Policy and OGSI Non normative refs Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1315 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-07 20:21:41 Submitted By: Tom Maguire Submit Date: 2005-03-07 20:21:41 Assigned To: &lt;None&gt; File(s): <None> Description: not ref'd in any way in spec View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

NAREGI slides
by Kazushige Saga 08 Mar '05

08 Mar '05

Dear all, I'm Kazushige Saga of NAREGI project. I'm sending two slides which are requested in the meeting today. We would like to make presentations of them in some OGSA sessions in GGF13. Thanks, Kazushige Saga Center for Grid Research and Development (NAREGI), National Institute of Informatics web: http://www.naregi.org/index_e.html tel: +81 3 4212 2824 　　fax: 　　+81 3 4212 2802

1 0

OGSA-BES-07Mar2005
by Steven Newhouse 07 Mar '05

07 Mar '05

Document for tonight's discussion. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

RE: [ogsa-wg] Data: Proposed agenda for Wednesday 9th March: NEW TIME
by Dave Berry 07 Mar '05

07 Mar '05

If anyone rushed to download the current version of the architecture straw man document, you may want to download it again, as I have just uploaded a revised version. I will attempt to add more changes during the week - there is lots left to do... Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Dave Berry > Sent: 07 March 2005 15:50 > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen > Luniewski; Malcolm Atkinson; Susan Malaika; Peter Clarke > (UCL); David E Martin; Peter Kunszt; Ian.Bird(a)cern.ch; > Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; Scott Oster; > Stephen Langella; Shannon Hastings; Manuel Pereira; Ted > Anderson; Leo Luan; Mark M. Morgan > Subject: [ogsa-wg] Data: Proposed agenda for Wednesday 9th > March: NEW TIME > > Dear all, > > Here is a proposed agenda for the data telcon on Wednesday March 9th, > which will be at the NEW agreed time of 7.30am PST / 10.30am EST / > 3.30pm GMT / 4.30 pm CET. > > UK Dial In: 0845 245 0224 > US Dial In: 1866 838 0046 > International Dial In: +44 1452 542309 > > PIN Number: 632 065 > > > 1) Early discussion (5 min) > Note taker assignment > Roll call > Minutes approval (attached) - > https://forge.gridforum.org/projects/ogsa-wg/document/Minutes_ > 23rd_Febru > ary_2005/en/1 > Agenda bashing > > 2) Update on outstanding actions (5 min) > - Dave to write draft charter for ByteIO WG > - Mark to prepare document describing the draft ByteIO interface > - Simon to mail the list about different types of metadata: data > resource vs. service. > - Mark to mail around URL of notes from London meeting > - Dave to revise the current "straw man" document for next week > - Dave to prepare concrete proposal for initial data profile (ByteIO, > RNS, DAIS, GridFTP?) > > 3) GGF13 main session preparation (10 min) > As part of the main OGSA outreach session, I will give a > presentation on > the data design team and the work we've done so far. I'd like to > discuss this with the team on this call. > > 4) GGF13 BOF preparation (10 min) > We have a BOF scheduled about the ByteIO interface. I have sent out a > draft charter for the proposed WG. I would like to discuss how we > should structure the BOF session. > > 5) GGF13 Profile preparation (10 min) > Our first design team session is earmarked for discussion of > an initial > data profile, probably containing DAIS, SRM, ByteIO and possibly > GridFTP. RNS has been put in a naming profile. I would like > to discuss > how we should structure the discussion. Also, it would be > very helpful > if someone would volunteer to write a first draft of a > profile document. > > 6) Architecture update (15 min) > I have put the current draft on GridForge - see > https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Dat > a_Architec > ture_Straw_Man/en/1. We have a session booked to discuss > this at GGF13, > where we will concentrate on data architecture. > > 7) Wrap up (5 min) > AOB > > Dave Berry > Research Manager, National e-Science Centre > 15 South College St., Edinburgh > Tel: +44 131 6514039 > >

1 0

Teleconference minutes - 28 February 2005
by Andreas Savva 07 Mar '05

07 Mar '05

Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050228/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 28 February 2005 ====================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Ravi Subramaniam (Intel) Latha Srinivasan (HP) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Dave Berry (NeSC) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * GGF13 update - Hiro will add the dial-in number to the GGF13 sheet - ByteIO BoF is at the same time as the Basic Profile review (session #2 conflicts #11) - BES BoF conflicts with Data architecture (session #8 conflicts with #12) - Andrew is therefore double booked; he will probably be in BES. - #3: Probably do this as a BoF as agreed at the February F2F. The proposed group is probably in the Architecture Area so Andrew is the AD. - Andrew to arrange logistics - Also contact Manuel to find out if he'll be attending GGF13 (Confirmed attendance during the call) - #4: No draft document. Not sure how advanced things will be but will prepare for a discussion. Maybe an open-floor session without long presentations - #5: No draft document. - #6: Basic profile: Was naming and security pulled out? If so how far does this session cover. - Naming: probably everything relating to ws-addressing goes to another (naming) profile. (Something to discuss later.) - Security: not sure whether taking it out completely is good or not. Security is something to 'bake-in' to every spec. Tom and Dave decided to keep the current text in the BP and revisit this issue later. - #9: - What is the intended outcome of this session? - It's not clear whether this is a discussion/educational session or not, or how things will fit together. More likely a discussion, exploration style session. - Is there a list of standards? Or is there any consensus on what the architecture needs? (model driven) - OGSA version 1.0 has a resource management section but the ideas have not been applied consistently throughout. (Which entities are resources and which are not. What does that mean in each case, and is the treatment consistent and so on.) - Part of the work is in the EM/data design teams; with some/other work in the RM team. - Fred is working to bring things together for this session - (Need traceability of requirements back to OGSA version 1.) - Gaps in profiles and how to address them - A side-discussion from the EM profile discussion. - What to do with such gaps? - If something is really missing and it is needed - Ask the spec owners to fill it in (or find owners) - Fill it in the profile (assuming a relatively small and easily bounded gap) - Deliverables review - Three docs submitted so far - Two more from the original list remain to be submited: Data and Roadmap - Roadmap - Ian is working on the Roadmap. Hiro will check the status with him. - Agreed that the draft should go through a group review first before sending it to Stacey. - Data - Ask DaveB. (Hiro) - Visa for Korea: - [If you are unsure contact the nearest Korean embassy.] - A tourist visa should not be used if you are travelling for business. - Information on how strict Korean Immigration is varies. - Jay has more details from the Korean embassy. Email him if you need it. * EM refactoring doc (20050228) [Posted to gridforge after the call https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-ems/en/2] - Fig. 2 : business process/ workflow / ... / tasklet - Trying to describe the scope of area (so includes business process to tasklet) - Including business process here might raise concerns since there is a lot of work outside the grid on this. - Clarified that the intention is not the modelling of the business process but what is needed in the environemnt to support its execution. - Terminology issue: Should these terms be used (clearly overloaded) or should different terms be used (ref: Terms proposed by Andrew & Mark) - Fig 3 (demand - supply) - Added "execution plane" and "control plane" - Control plane 'controls' execution/provisioning activity - Trying to draw out similarity with other capabilities, e.g., data - Resource model would be part of a Resource Management framework - The group is working from both ends but there is a large gap between the lower level work (leading to a profile) and work at this level. - Obviously the situation is not ideal. It is a balance between the desire to do something that will last vs not being able to achieve anything within this year (and taking on the risk of some re-work later on) - A concern raised is whether there is really an incremental path to fill the space or not. - BES focus is 'job focus' ('work push'). Ravi also wants to have the opposite perspective of a resource 'pulling' a job ('work pull') included. - Could be done as extension to the current proposal at a later point (in any case it is not precluded) - OGSA EM v1 identified some core functionality; BES focuses on the simplest function within that picture. The expectation is that there will be a build-up from that base to do other functionality at a later stage. (E.g., CGS) - Next steps? - CGS is one likely candidate - To try and define CGS the following would also be needed: - How jobs describe resources (e.g., JSDL) - How resources describe themselves - And also have to 'unify' across capabilities (Ravi) - Jay argued that this is 'not a unification' but a 'relation'. - Model of how to manage data as data (can be used by the manager) - And a view/facet of that model that can be projected or used by the CGS - This view does not need to be the same as the manager's; only what is required by the CGS - Agreed that this is a good topic to discuss at the EM architecture session. Ravi to prepare for kicking off this discussion. * BES BoF preparation - Andrew, Mark, Steve have had a short call on logistics (who will present, etc) - Andrew to send out draft answers to the 7 questions - Steven will send out revised version of the draft API document (but refinement of this document is not the main focus of activities at the moment) - Will review these again before GGF13 (probably Mon Mar 7) * AOB ** Resource Management followup - Fred is working on a concrete proposal on how to proceed: - Resource modelling has to be done by both sides at the same time. The two sides being the capability (e.g., EM, Data) and the resource modelers (e.g., straight with the DMTF via the resource management team) - A draft document is nearly ready and will be distributed soon. - The CGS co-chair, Tom Rooney, is also interested and is getting involved in this activity. ** BP review postponed for next call

1 0

Modeling State: Technical Questions
by Ian Foster 07 Mar '05

07 Mar '05

Dear All: In an effort to move forward this debate about "OGSA plumbing", I thought I'd attempt to describe the different positions that I've seen expressed. Perhaps people can read this quickly, and provide feedback as to where I have not captured things correctly. I'll be happy to collate responses sent directly to me and forward them, if there is interest. CONTEXT The context is that OGSA-WG needs to develop some low-level specifications, such as execution management services, that require modeling interactions that involve server-side state. E.g., in the following pseudo-code example, we request the creation of a "job": send "create(jsdl-specification)" to job-factory-web-service receive "job-handle" from job-factory-web-service I think that everyone accept that this sort of interaction is needed. (Let me know if not.) Where people differ in their views is with respect to what the "job-handle" should be and how we should represent operations on the job. I've heard three views expressed, as follows. OPTIONS 1) (WSRF) The job handle is an EPR to a WS-Resource, in which case the case the WSRF operations can be used to get status and delete: send "GetResourceProperty(status)" to job-handle send "Destroy" to job-handle In addition, one will probably also want to be able to send requests to the job-factory, which is straightforward as there is no strong encapsulation in WSRF. E.g.: send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service This approach exploits the standardized syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WSRF/WSN specifications. 2) (WS-Transfer) The job-handle is an EPR to a WS-Transfer resource, in which case the appropriate WS-Transfer operations can be used to get status and delete. send "Get" to job-handle send "Delete" to job-handle Assuming that there is no strong encapsulation in WS-Transfer either, one can also contact the job-factory directly when required: send "destroy(jobs-owned-by-ian)" to job-factory This approach exploits the syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WS-Transfer specification. #2 is very similar to #1. One can argue the pros and cons of the two approaches. I'm concerned that you have to return the whole resource state, not just a single component (e.g., the status field). But that's a relatively minor issue. 3) (Job id) The job-handle is a job-factory-specific string, and we define job-factory-specific operations for manipulating the job, e.g.: send "check-job-status(job-handle)" to job-factory send "terminate-job(job-handle)" to job-factory #3 is very similar to #1 and #2: the message sent over the wire in each case contains the same information (operation name + Web service address + job-id-info). What is different about #3 is that you have to manage this job-handle separately from the job-factory EPR. Also, you don't use the standardized WSRF/WSN operations. Have I captured all of the options that people think we should be considering? WHAT OGSA-WG SHOULD DO Given this characterization, I'd also be interested in people's views as to how OGSA-WG should proceed when considering specifications that involve this sort of interaction pattern. The majority of active participants OGSA-WG participants seem to favor option #1, but I've also heard people argue in favor of approaches #2 and #3. Tony Hey proposed, I think, that we should define specifications like job management in terms of some more abstract interface that can then be mapped to each of the approaches above, as desired. Frank Seibenlist observed that we can use WSRF/WSN as such an abstract interface: given an interface defined in terms of WSRF/WSN specifications, one can derive, via straightforward transformations, a concrete specification in the style of approach #2 or #3. Regards -- Ian.

1 0

Teleconference minutes - 2 March 2005
by Andreas Savva 07 Mar '05

07 Mar '05

Minutes attached. This call was mostly a review of the basic profile. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050302/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 2 March 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Fred Maciel (Hitachi) Tom Maguire (IBM) Takuya Mori (NEC, ANL) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Latha Srinivasan (HP) Jem Treadwell (HP) Jay Unger (IBM) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * No minutes available * Minor change to the GGF13 schedule to add the teleconference information * Discussion generated from Tony Hey's article - Agreed to timebox (10 minutes) this discussion so that it would not take over the entire call. - Two stack interoperability problem? - It is a problem if we end up with different message protocols - Important to describe how the two stacks interroperate (one more analogy given: driving a car either on the left or the right side of the road) - It might be possible to write code that is agnostic but must make a choice about the wire format when running it on the grid. - Migration and co-existence are important issues. They should/could be addressed incrementally in later versions of the standards as they evolve (e.g., WSRF 2.0) - The article's point is that it is not possible to decide which is the right choice at the lower level at this moment; wait and see while defining things at a higher level in an independent manner; and follow the winner later. - Also possible to choose one approach and map to the other with some overhead - The suggested approach does not really solve the problem because it does not reach a common standard - Concern further clarified that building up an infrastructure by making the wrong choice (OGSI raised as an example) might end up messing up application code that is built specifically for it. - End of timebox; followup on the list. * Basic Profile review The latest draft is on gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… Aka: draft-ggf-ogsa-basic-profile-008 [Unassigned actions belong to Tom by default.] ** Front matter - Last line of "Status": This is a recommendation document so delete "...does not define any standards..." - Abstract: - l.4: There is a WS-I citation but no reference. Clarified that WS-1.1 is implied and will be referenced. (Tom to revise) - "Guided by these principlies" what does "these" refer to: > "interroperability, interaction" (Tom to revise) - Why is there no mention of WS-Resource? - In an earlier review agreed that the Profile is only discussing the WS-Addressing embodiment. - But there is a normative reference to WS-Resource. It should be removed (Tom to revise) - Also need to refer to Profile template document (Tom to revise) ** 1 Introduction - Pending action on WS-I copyright issues: - Tom & Hiro will follow up with their companies' representatives on whether the introductory text can be re-used as is or whether it has to be rewritten. - Suggestion to add a short (historical) paragraph on OGSI. - Rejected. No need to refer to OGSI. *** 1.2 Relationships - To add the relationship to Basic Security profile as well. *** 1.3 Notational conventions - UDDI namespace is not needed. Delete. - Other namespaces that are not used for normative statments should also be deleted (xsi, soap, ...) *** 1.4 Profile identification - Discussion on Profile 'name', versioning and what profile instance definition. - Note 'name' does not include the 'version' so the example given is correct. - Since a conformance URI (2.4) will also be defined consider doing the versioning definition just on the URI (or in conjunction) to avoid the need for similar versioning explanation appearing more than once. ** 2 Profile Conformance *** 2.2 Targets The new ones (introduced by this profile) are ENDPOINTREFERENCE and RESOURCE. The rest come from the WS-I BP 1.1. *** 2.3 Scope - It is stated that "extensions...when identified in the Profile..." - So what does it mean if an extension in a referenced spec is not identified in the profile? - There seems to be a minor gap in this explanation. [It is copied from the WS-I Profile explanation.] - The intention is, however, to list all relevant extensibility points from the referenced specs in the profile. ** 3 Addressing After the F2F Tom split off most of the text here to a separate document in anticipation of a separate Naming profile. - Discussed whether to move the remaining statement to the Naming profile or not. The consensus that those dealing with ServiceName and portType could be left here but the rest should go. - Tom will make this a tracker and revisit. ** 4 Resource Property - Description requirement on getmultipleproperties / query - This is already a recorded issue. ** 5 Resource Lifetime There has been some discussion but no firm conclusion on the destroy / resource destruction issue yet. It is recorded as an issue and will be revisited. ** ServiceGroup Tom has deleted this section as agreed at the F2F. ** 6 Notification No change. ** 7 Base Faults Tom added text that requires use of the structure, as agreed. ** 8 Security Dave S is not on the call. Postponed. * Basic Profile Tracker review ** Review of tracker setup Reviewed new tracker status values and discussed other configuration issues. It seems that only a person with OGSA-WG administrator rights can close an artifact on this tracker. Considered changing this but agreed it is good form in order to make sure that changes are properly verified before a tracker is closed. Use of priorities: To capture what to work on next; so it can (and should) be updated to boost the visibility of issues that become more important. ** Artifact review Spend about half an hour going through all artifacts updating them as necessary. For details refer to the BP tracker. Agreed that issues relating to Naming will be moved to a new tracker once the Naming profile draft becomes an independent (and publicly visible) document. > Andreas will take care of the transition.

1 0

Proposed agenda for March 7th call
by Hiro Kishimoto 06 Mar '05

06 Mar '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 7th Monday from 5pm to 7pm (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: 0307 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) Agenda bashing 2) GGF13 preparation (20 min) Conformation of owner/note taker/guests for each session - OGSA session plan https://forge.gridforum.org/projects/ogsa-wg/document/GGF13_session_plan/en… - GGF13 schedule http://tinyurl.com/4cz98 3) OGSA-BES BoF discussion (30 min, Andrew) BoF session description, Draft Charter, 7 questions discussion - current draft http://www.gridforum.org/Meetings/GGF13/Charters/GGF13_OGSA_Basic_Execution… ice_WG_BOF.pdf Revised draft charter etc. will be posted before the call. 4) Basic profile discussion (30 min) Revised basic profile draft https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… le/en/3 5) Wrap up (10 min) AOB Mar. 9 (10-11am CST) Data Design team Mar. 9 (5-7pm CST) Roadmap discussion, GGF13 session preparation Mar. 13-16 GGF13 in Soeul See telecon schedule until GGF: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0

A proposal to move forward CIM-related work in the GGF
by Fred Maciel 05 Mar '05

05 Mar '05

Hi, As I was telling you recently, I and Tom Roney (CGS-WG) have been working on how to move forward CIM-related work in the GGF and, specially, in OGSA. Here it is, in the attached file. Please give a look. Next week I'll be in Japan, and quite probably I won't participate in the OGSA-WG teleconferences. (Which means I'll escape all the nitpicking that I know that some of you will do on this document, at least for a week :-). But anyway, I intend to explain the contents (and get feedback) in the Resource Management design team session and, perhaps, also in the CGS-WG session. Let's discuss it there. See you in Korea, Fred Maciel.

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 04 Mar '05

04 Mar '05

>First, please allow me to say something about my claim that the OGSA WG >mandates WSRF, a claim which you have questioned. I may have >misunderstood the group's intentions, in which case I apologise, but >discussions with various people and minutes from meetings directed me >and many others towards making that conclusion (this was raised by >several people at the UK-OGSA meeting). Also, the current draft of the >OGSA Basic Profile, to which I assume all high-level services will have >to adhere, is described in terms of WSRF. Savas: What I meant about "mandating" (which upon reflection I suspect is what you meant too): A profile typically says simply that IF you use something, THEN this is how you must use it. It doesn't say you MUST use it. Thus, the OGSA Base Profile doesn't say anything about whether WSRF should be used or not, it just says how you should use it if you do. Where, then, is WSRF "mandated"? At present, nowhere. However, moving forward, it would seem likely that when OGSA WG considers say a management specification for inclusion in some future "management profile", it will look kindly on one that uses WSRF conventions to access remote state, rather than making up its own custom ones, because that is viewed as enhancing interoperability. It would then also want to see that WSRF is used in a way that adheres to the OGSA Base Profile. On the other hand, when considering specifications that have nothing to do with state (e.g., naming), there would be no reason for WSRF to come into the picture. The draft OGSA Naming Profile that Andrew Grimshaw is developing does not use any WSRF mechanisms. It *could*, but this hasn't been seen as particularly useful, so it doesn't. And (the point I was harping on, probably too much), there is nothing to say that you must use WSRF conventions when developing your own services. So, I guess WSRF is "mandated" in some places, and not in others. Steve Loughran wrote more eloquently on some related topics in an earlier post to ogsa-wg. Ian.

4 4

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Savas Parastatidis 04 Mar '05

04 Mar '05

Dear Ian, I guess I am considered as being part of the "other side" :-)) so please allow me to put forward some suggestions on what I personally would have liked to see as an outcome from OGSA. First, please allow me to say something about my claim that the OGSA WG mandates WSRF, a claim which you have questioned. I may have misunderstood the group's intentions, in which case I apologise, but discussions with various people and minutes from meetings directed me and many others towards making that conclusion (this was raised by several people at the UK-OGSA meeting). Also, the current draft of the OGSA Basic Profile, to which I assume all high-level services will have to adhere, is described in terms of WSRF. The argument on whether EPRs and WS-Context are equivalent to the way state is accessed was discussed in [1]. However, this is a technical argument and it has been around for some time, as Andrew Herbert pointed out in his two messages. There is no point in continuing it here. While I recognise that I am also responsible for fuelling this argument for the last couple of years, it has always been the case that the Newcastle team has been proposing an approach to designing the OGSA high-level services that focused on the use of stable WS standards for production Grid environments. I will attempt to summarise this position below. Please note that these ideas were first presented at GGF9 during the presentation of WS-GAF, and then summarised in [2]. We acknowledge that there is always going to be different approaches to building distributed systems. This is especially true at the current time when Web Services are still a relatively young technology that has not yet stabilised. Therefore, we advocate a 'safe' approach to designing and building the high-level services that are needed for realising the vision (to which you have been one of the main contributors) of interoperable Grid computing. This 'safe' approach suggests that only stable, widely accepted and implemented specifications are used for the OGSA services, even if that means that what is felt to be the best possible approach is not used. Stability, interoperability, wide-acceptance, and the availability of high quality tooling from multiple vendors is given precedence over having the ideal design (according to parts of the community :-) and new infrastructure. At this point I would like to point out that many UK e-Science (e.g. myGrid, Geodise, and many more) and International (e.g. SkyServer) projects successfully used existing tooling and simple WS specifications (SOAP, WSDL) as their underlying infrastructure. Perhaps with the addition of WS-Security, SAML, XACML, and even WS-Addressing (given that the entire industry is behind it even though it hasn't be finalised yet), we have an infrastructure that can be used in the design of high-level services. All these standards (specification in case of WS-Addressing) are supported by everyone and commercial, high-quality tooling already exists. I am not proposing a definite set of specs (I may have forgotten some or some may have to be removed). The OGSA WG will have to decide the common set of specs so that everyone is on board (even Microsoft). Also, I am not going to restart the 'state' argument here but I will point out that even with this simple set of specs large companies like Amazon and Google offer access to their data and functionality without requiring additional infrastructure (sorry... had to mention the 'state' word :-))) When in few years time Microsoft, IBM, Oracle, Sun, Axis and others have produced runtimes and tooling that support a new common set of infrastructure-specific standards, then we can start designing OGSA v2.0 with all the bells and whistles that the new infrastructure will offer. For example, when WSRF or WS-Transfer or WS-MyNewFavouriteSpecification becomes widely adopted and the entire industry has agreed because of market forces, then we can consider it for our next generation Grid computing platform. Until then, let's do things the simple way, even if that means that some common behaviour, which part of the community has identified, is not implemented by the underlying infrastructure. At least we are going to interoperate and everyone is going to be onboard. I think a good question we can ask in order to know when it is time to move to new infrastructure (or richer infrastructure if you want) is whether WebSphere, .NET/WSE/Indigo, Sun WSDP, Axis, etc. all implement/support a common set of standards. Please note that I say 'standards' and not 'specifications' (even if that means that we currently have to remove WS-Addressing from the list I gave above, although I personally happen to believe in WS-Addressing). I don't think that we should be in a situation where the architects of a high-level Grid computing platform define the underlying infrastructure without the common agreement of all the industry players who are producing the tooling and runtimes. Interoperability and wide adoption will be adversely affected. The issue of stability is very important. The recent example of the OASIS WSDM WG where the attempt to standardise the specification has been attacked due to the dependencies in other, unstable specifications (e.g. WSRF and WS-Addressing) is an indication on where things lead when we try to define all the layers of our platform at the same time. As Andrew Herbert suggested, and I think everyone agrees, there is nothing that can't be done using any of the technologies/approaches available to us. My suggestion is to use the technologies/approaches that are stable now for building the stable Grid computing platform that our users want, with wide-adoption in mind. At the same time, let's investigate new approaches for the infrastructure and only when we reach a level of maturity, stability, and wide adoption consider moving our Grid platform to it. The large set of current Grid systems built on existing, stable, and interoperable WS platforms demonstrate that we can indeed find solutions for the problems of Grid computing, even if those solutions do not leverage an underlying infrastructure of observed common behaviours, like what WSRF provides. As always, I am interested in your thoughtful perspective. Best regards, -- Savas Parastatidis http://savas.parastatidis.name [1] " Stateful Interactions in Web Services - A comparison of WS-Context and WS-Resource Framework", http://www.sys-con.com/story/?storyid=44675&DE=1 [2] "Using Web Services to Build Grid Applications - The "No Risk" WSGAF Profile", http://www.neresc.ac.uk/ws-gaf/WSGAF-NoRiskProfile.pdf [Previous messages snipped]

2 1

Teleconference minutes - 23 February 2005
by Andreas Savva 04 Mar '05

04 Mar '05

Attached. Gridforge https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050223/en/1 -- Andreas Savva OGSA Teleconference - 23 February 2005 ====================================== * Participants Dave Berry (NeSC) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Mark Morgan (UVa) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Data (ByteIO BoF) Review of basic proposal; simple data access interface. Dave B has sent the revised charter to Stacey (and the list). Malcolm's comments are taken care. (1) WG will produce informative usecase document (2) WG will define API including WSDL (i.e., a WS interface, not java binding) Dave B will also send 7 Q&A to Stacey and Data Area ADs (Malcolm and Dave Martin) (It is probably not required at this point and in any case one purpose of the BoF is to review and draft the final answers.) - Proposed Milestones - Draft document and implementation by June - Draft experience document by GGF15 - Is there no other similar or related WS standard? WS-Enumeration was mentioned but it deals with XML streams rather than bytestreams. * WS-Naming A number of documents were sent out prior to the call. 1. A presentation for review in this call 2. A document describing the proposal 3. A draft Naming profile that was split off from Basic profile - There is one more (earlier) document that discusses motivation, use cases, etc. - GGF13 Plans - A union of these documents will be presented at GGF13 - Everything except the 'resolve' can be a profile. So one spec and one profile - The reason for the alternative document (2) is also to present to people who may not have an interest in the wider OGSA picture. The Profile is based on extending WS-Addressing EPRs with additional information. These extended EPRs can be used as normal EPRs by existing clients with no changes. This is an important requirement that is neeed to help initial adoption. Two elements are added: 1. Abstract name: A string, globally unique, only equality comparison allowed - Anything in profile should be testable; so how can global uniqueness be tested? - Probably not testable though there could be an argument that they are. No good answer at this point. - Strings are already comparable; why re-state this? - To emphasize that lexicographic ordering is not meangingful. Only equality is defined. - Why not use a URI? - No need to constrain the Abstract Name further at this point - Interesting points on whether it might have structure, and whether it can be reasoned about to some extent. - Scheme presented as 3-levels; but actually there can be many more levels than that. - Three levels capture requirements of many systems. It's not the intention to constrain it to (at most) 3 levels. This should be made clearer. 2. Resolver - Optional: it may appear and if it does its usage is optional - Singleton or list? - Currently saying that this is at-most-one - Leaving this as an issue for the WG that will define this. - If a list then there is additional complexity with whether you get the same answer from all resolvers or not, which one to use, and so on. - The resolver is a WS with an EPR and a portType with the operation 'resolve' that receives an epr and returns an (equivalent) updated one. - Could there also be a WSRF binding that casts the resolver as a WS-Resource with just the operation 'resolve' (no arguments; the resource is 'pointing' to what needs to be resolved.) - If necessary, it could be defined as a separate profile. - EPR examples slide - Case with "No resolver," "Simple," and "Resolver with resolver" - Resolver with resolver can be stateful or close to the WSRF rendering of a resolver mentioned before. - Exactly one abstract name or is it possible to include different names or aliases in the same EPR? - Is it inevitable or not? (Perhaps) - Sameness issues? - Might be better to constrain it at this level and at this point in time. - Properties on resolver, e.g., to distinguish them? - It is out of band - Extensible scheme for Names so that people can introduce names that are unique for that authority or not? (context) - Names are defined as globally unique but there is nothing stopping an organization to produce them in such a way that they can be interpreted differently within a context or domain (and those domains do not overlap) - For example, IP addresses are globally unique but many organizations use certain spaces (10.*) internally. - Issue of addressability from other places - Can generate a unique name/id, but someone else could re-use it later. Can't stop people from doing that. - No guarantee. Need to be careful when saying 'globally unique.' Might need to look at making this statement in a better or more descriptive manner. - Andrew and Mark are working to bring Tom's document (Naming profile draft) and this document together. - OGSA Naming session will probably be used as BoF for these activities. * OGSA-BES update - Not ready for a detailed review yet. Will continue on a separate teleconference to discuss logistics and come back to the main call. - Haven't completed the 7 questions yet - The draft reviewed at the F2F is not updated yet. Refinement of that document is not the focus at the moment. * Basic security profile - Frank is not available before GGF13. Probably discuss this at that time.

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Dave Berry 04 Mar '05

04 Mar '05

As an aside, ironists among you may find amusement in that the reasons given in OGSA WG discussions for adopting WSRF in the OGSA Basic Profile are precisely that WSRF is stable, widely adopted and requires no special tooling or runtime support. Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Savas Parastatidis Sent: 03 March 2005 23:40 To: Andrew Herbert; Ian Foster; Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com; Jim Gray; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; gcf(a)indiana.edu; mark.linesch(a)hp.com Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Dear Ian, I guess I am considered as being part of the "other side" :-)) so please allow me to put forward some suggestions on what I personally would have liked to see as an outcome from OGSA. First, please allow me to say something about my claim that the OGSA WG mandates WSRF, a claim which you have questioned. I may have misunderstood the group's intentions, in which case I apologise, but discussions with various people and minutes from meetings directed me and many others towards making that conclusion (this was raised by several people at the UK-OGSA meeting). Also, the current draft of the OGSA Basic Profile, to which I assume all high-level services will have to adhere, is described in terms of WSRF. The argument on whether EPRs and WS-Context are equivalent to the way state is accessed was discussed in [1]. However, this is a technical argument and it has been around for some time, as Andrew Herbert pointed out in his two messages. There is no point in continuing it here. While I recognise that I am also responsible for fuelling this argument for the last couple of years, it has always been the case that the Newcastle team has been proposing an approach to designing the OGSA high-level services that focused on the use of stable WS standards for production Grid environments. I will attempt to summarise this position below. Please note that these ideas were first presented at GGF9 during the presentation of WS-GAF, and then summarised in [2]. We acknowledge that there is always going to be different approaches to building distributed systems. This is especially true at the current time when Web Services are still a relatively young technology that has not yet stabilised. Therefore, we advocate a 'safe' approach to designing and building the high-level services that are needed for realising the vision (to which you have been one of the main contributors) of interoperable Grid computing. This 'safe' approach suggests that only stable, widely accepted and implemented specifications are used for the OGSA services, even if that means that what is felt to be the best possible approach is not used. Stability, interoperability, wide-acceptance, and the availability of high quality tooling from multiple vendors is given precedence over having the ideal design (according to parts of the community :-) and new infrastructure. At this point I would like to point out that many UK e-Science (e.g. myGrid, Geodise, and many more) and International (e.g. SkyServer) projects successfully used existing tooling and simple WS specifications (SOAP, WSDL) as their underlying infrastructure. Perhaps with the addition of WS-Security, SAML, XACML, and even WS-Addressing (given that the entire industry is behind it even though it hasn't be finalised yet), we have an infrastructure that can be used in the design of high-level services. All these standards (specification in case of WS-Addressing) are supported by everyone and commercial, high-quality tooling already exists. I am not proposing a definite set of specs (I may have forgotten some or some may have to be removed). The OGSA WG will have to decide the common set of specs so that everyone is on board (even Microsoft). Also, I am not going to restart the 'state' argument here but I will point out that even with this simple set of specs large companies like Amazon and Google offer access to their data and functionality without requiring additional infrastructure (sorry... had to mention the 'state' word :-))) When in few years time Microsoft, IBM, Oracle, Sun, Axis and others have produced runtimes and tooling that support a new common set of infrastructure-specific standards, then we can start designing OGSA v2.0 with all the bells and whistles that the new infrastructure will offer. For example, when WSRF or WS-Transfer or WS-MyNewFavouriteSpecification becomes widely adopted and the entire industry has agreed because of market forces, then we can consider it for our next generation Grid computing platform. Until then, let's do things the simple way, even if that means that some common behaviour, which part of the community has identified, is not implemented by the underlying infrastructure. At least we are going to interoperate and everyone is going to be onboard. I think a good question we can ask in order to know when it is time to move to new infrastructure (or richer infrastructure if you want) is whether WebSphere, .NET/WSE/Indigo, Sun WSDP, Axis, etc. all implement/support a common set of standards. Please note that I say 'standards' and not 'specifications' (even if that means that we currently have to remove WS-Addressing from the list I gave above, although I personally happen to believe in WS-Addressing). I don't think that we should be in a situation where the architects of a high-level Grid computing platform define the underlying infrastructure without the common agreement of all the industry players who are producing the tooling and runtimes. Interoperability and wide adoption will be adversely affected. The issue of stability is very important. The recent example of the OASIS WSDM WG where the attempt to standardise the specification has been attacked due to the dependencies in other, unstable specifications (e.g. WSRF and WS-Addressing) is an indication on where things lead when we try to define all the layers of our platform at the same time. As Andrew Herbert suggested, and I think everyone agrees, there is nothing that can't be done using any of the technologies/approaches available to us. My suggestion is to use the technologies/approaches that are stable now for building the stable Grid computing platform that our users want, with wide-adoption in mind. At the same time, let's investigate new approaches for the infrastructure and only when we reach a level of maturity, stability, and wide adoption consider moving our Grid platform to it. The large set of current Grid systems built on existing, stable, and interoperable WS platforms demonstrate that we can indeed find solutions for the problems of Grid computing, even if those solutions do not leverage an underlying infrastructure of observed common behaviours, like what WSRF provides. As always, I am interested in your thoughtful perspective. Best regards, -- Savas Parastatidis http://savas.parastatidis.name [1] " Stateful Interactions in Web Services - A comparison of WS-Context and WS-Resource Framework", http://www.sys-con.com/story/?storyid=44675&DE=1 [2] "Using Web Services to Build Grid Applications - The "No Risk" WSGAF Profile", http://www.neresc.ac.uk/ws-gaf/WSGAF-NoRiskProfile.pdf [Previous messages snipped]

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Another Andy's email. ---- Hiro Kishimoto Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Date: Thu, 3 Mar 2005 18:16:35 -0000 From: "Andrew Herbert" <aherbert(a)microsoft.com> Ian My point in resurrecting the CORBA history was that in that debate neither "side" could understand what the other side needed that wasn't already provided for. I defer to those building systems who don't support WSRF to comment technically on what it is that they feel is over-constraining for them about WSRF in detail. They tell me they can build practical and effective systems using other web services standards and that they find systems based on WSRF are more complicated to program because there is more mechanism and parameterization to be dealt with. To my ears this would seem to be more a discussion about factoring functionality and keeping mandatory interfaces simple, than it is about specific mechanisms. And I guess people who are comfortable getting systems to work without WSRF find it hard to get motivated to enter technical discussion about something they don't see the need for in their systems. I realize this doesn't help you solve your problem. Andrew ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 03 March 2005 08:52 To: Andrew Herbert; Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; Jim Gray; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; gcf(a)indiana.edu; mark.linesch(a)hp.com Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Andy: One thing that would really help, I think, is for someone on "the other side" to explain what it is that they want to do that GGF/OGSA WG is preventing them from doing. I understand it must be something important, but think that there is genuine lack of understanding within GGF/OGSA WG as to what it is. A set of application scenarios would really help. A second thing that would be helpful would be a crisp characterization of what "the other side" wants to see GGF/OGSA WG do instead. Should we allow for the use of WS-Transfer as an alternative way of interacting with stateful resources? Or that we should allow for EPR + context-id as an alternative way of interacting with state? Or both? Or something else? Again, this hasn't been made clear: the only explicit communication we've received is that "we shouldn't use WSRF," which isn't a very satisfying answer. Clarity on these two issues would really help I think. A couple of other minor points: * I don't see the fact that people build Grid applications and systems in different ways as a reason not to work towards interoperability. Yes, people have built nice Grid-like systems with custom protocols, with JINI, with Web services, with CORBA, with DCOM, etc. But these systems don't interoperate, and interoperability is important in some situations. * I said management applications were "a primary focus" of OGSA, not "THE primary focus." Regards -- Ian. At 04:25 PM 3/3/2005 +0000, Andrew Herbert wrote: Ian, Tony This discussion reminds me very much of the early history of CORBA, when there was a create debate between those who believed dynamic interface types were central to object request broking and those who thought they were the spawn of the devil. Both approaches were able to emulate the other and so any argument about which was the more fundamental was sterile. There was certainly an element of bias towards different styles of application, and this was what split the OMG community since each camp had an legacy to carry forward and an investment in their view of the future. The OMG architecture was therefore positioned at a level where both approaches could be accommodated and as CORBA and CORBA Services were defined a case by case view was taken of the need for a static or dynamic interface, or both, or some unification of the two. It led to optional elements and even some duplication of function in the early OMG specifications, but as the standards process unfolded and users gained experience with the technology it became easier to make rational choices and if necessary go back and fix the specifications. Of course vendors initially implemented just the options they preferred but over time they converged on common components and interfaces. And of course the users also demanded interoperability between CORBA and DCOM and got it, even though for many CORBA vendors DCOM was the enemy. The academic question of the superiority of one style of object request broking over another was never actually resolved a workable hybrid evolved which meet the needs of the users and the OMG moved on. Interestingly given your comment about the position of names in messages, with hindsight many of the CORBA debates were ultimately a fight about where names stood relative to dot, comma, braand ketin object invocation semantics and fifteen years later I find it hard to remember the passions that made these things seem so important at the time. Ian positions the primary purposeof OGSA as being certain classes of management application. The problem Tony and others appear to be grappling with is the desire to have OGSA as the architecture for broader notions of Grid Computingand e-Scienceand this is where the shoe starts to pinch. Ian asks how to make progress. It seems to me that GGF has two choices make the scope of OGSA narrow so those interested in certain classes of management applicationcan develop an architecture for this unimpeded, or make the scope of OGSA broader and admit to the possibility of other classes of application of interest to the GGF community. I observe colleagues I respect building systems that clearly are doing Grid Computingof the kind envisioned in Ian and Karls book that coined the concept, and these people seem to manage to build and operate their systems without invoking WSRF so this makes me wary of any architecture for Grid computingand/or e-Sciencewhich mandates WSRF in its entirety in all cases. Andrew ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 03 March 2005 07:04 To: Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; Jim Gray; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; Andrew Herbert; gcf(a)indiana.edu; mark.linesch(a)hp.com Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Tony: I think your message captures nicely (although perhaps inadvertently!) the way in which people are talking past each other in this discussion. I would never say that the "messages to single resources approach" is the "the foundation for all operations on all services." I understand that some people in this strange religious debate that we've fallen into have characterized things that way, but that's far from the truth. >From my perspective, WSRF was motivated by our experiences building "service oriented infrastructure", and seeing that the same patterns were occuring repeatedly in different places as we built systems to manage Grid systems. The codification of those patterns in standard (and WS-I+-compliant, I like to emphasize) WSDL has allowed us to simplify many aspects of both service implementation and client tools. Others report the same positive experiences. The introduction of WS-Transfer, which provides similar functionality and seems to be intended for similar purposes, suggests that there is broad recognition of the importance of these patterns. However, the fact that these patterns are useful in building certain classes of management applications (a primary focus of OGSA, by the way) certainly doesn't mean that they are appropriate everywhere. I'd also like to suggest that when considering the assertion that "sending messages to single resources makes systems fragile", it is useful to recognize that the messages sent over the wire when using an EPR to a WS-Resource (the WSRF approach) vs. an EPR plus a context id (e.g., as in the eCommerce systems that are often mentioned) are close to identical. In fact, the only difference is really just the location of the "context id": in the EPR vs. in the body of the message! I don't see how the choice of one placement vs. the other can render a service "robust and scalable" vs. "fragile and nonscalable"--especially as the service itself can be implemented in an essentially identical manner in the two cases. My preceding paragraph suggest that there are opportunities for common ground, and I suspect that is the case. However, to find that common ground we need to identify clearly just what it is we are trying to do and then address different issues separately. I believe that there are far too many different issues being mixed together at present for useful progress to occur. Unfortunately, I'm not sure how to proceed to separate out the different issues. Ian. At 11:37 AM 3/3/2005 +0000, Tony Hey wrote: The point is not about how well the WS-RF and WS-Transfer stacks compare but rather whether it is always appropriate to use the "messages are directed at single resources" approach? Many people, including people whose technical judgement I respect such as Tony Storey, Ian Foster, Dave Snelling and others, apparently believe that the answer to this question is "everywhere: it is the foundation for all operations on all services". It is therefore not surprising that this group do not see the need to worry about the question "is it a good idea to build architecture around the idea of sending messages to single resources?" _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Andy's email bounced. ---- Hiro Kishimoto Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Date: Thu, 3 Mar 2005 16:25:09 -0000 From: "Andrew Herbert" <aherbert(a)microsoft.com> Ian, Tony This discussion reminds me very much of the early history of CORBA, when there was a create debate between those who believed dynamic interface types were central to object request broking and those who thought they were the spawn of the devil. Both approaches were able to emulate the other and so any argument about which was the more fundamental was sterile. There was certainly an element of bias towards different styles of application, and this was what split the OMG community since each camp had an legacy to carry forward and an investment in their view of the future. The OMG architecture was therefore positioned at a level where both approaches could be accommodated and as CORBA and CORBA Services were defined a case by case view was taken of the need for a static or dynamic interface, or both, or some unification of the two. It led to optional elements and even some duplication of function in the early OMG specifications, but as the standards process unfolded and users gained experience with the technology it became easier to make rational choices and if necessary go back and fix the specifications. Of course vendors initially implemented just the options they preferred but over time they converged on common components and interfaces. And of course the users also demanded interoperability between CORBA and DCOM and got it, even though for many CORBA vendors DCOM was "the enemy". The academic question of the superiority of one style of object request broking over another was never actually resolved - a workable hybrid evolved which meet the needs of the users and the OMG moved on. Interestingly given your comment about the position of names in messages, with hindsight many of the CORBA debates were ultimately a fight about where names stood relative to "dot", "comma", "bra" and "ket" in object invocation semantics and fifteen years later I find it hard to remember the passions that made these things seem so important at the time. Ian positions the "primary purpose" of OGSA as being "certain classes of management application". The problem Tony and others appear to be grappling with is the desire to have OGSA as the architecture for broader notions of "Grid Computing" and "e-Science" and this is where the shoe starts to pinch. Ian asks how to make progress. It seems to me that GGF has two choices - make the scope of OGSA narrow so those interested in "certain classes of management application" can develop an architecture for this unimpeded, or make the scope of OGSA broader and admit to the possibility of other classes of application of interest to the GGF community. I observe colleagues I respect building systems that clearly are doing "Grid Computing" of the kind envisioned in Ian and Karl's book that coined the concept, and these people seem to manage to build and operate their systems without invoking WSRF so this makes me wary of any architecture for "Grid computing" and/or "e-Science" which mandates WSRF in its entirety in all cases. Andrew ________________________________ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 03 March 2005 07:04 To: Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; Jim Gray; humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; Andrew Herbert; gcf(a)indiana.edu; mark.linesch(a)hp.com Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Tony: I think your message captures nicely (although perhaps inadvertently!) the way in which people are talking past each other in this discussion. I would never say that the "messages to single resources approach" is the "the foundation for all operations on all services." I understand that some people in this strange religious debate that we've fallen into have characterized things that way, but that's far from the truth. >From my perspective, WSRF was motivated by our experiences building "service oriented infrastructure", and seeing that the same patterns were occuring repeatedly in different places as we built systems to manage Grid systems. The codification of those patterns in standard (and WS-I+-compliant, I like to emphasize) WSDL has allowed us to simplify many aspects of both service implementation and client tools. Others report the same positive experiences. The introduction of WS-Transfer, which provides similar functionality and seems to be intended for similar purposes, suggests that there is broad recognition of the importance of these patterns. However, the fact that these patterns are useful in building certain classes of management applications (a primary focus of OGSA, by the way) certainly doesn't mean that they are appropriate everywhere. I'd also like to suggest that when considering the assertion that "sending messages to single resources makes systems fragile", it is useful to recognize that the messages sent over the wire when using an EPR to a WS-Resource (the WSRF approach) vs. an EPR plus a context id (e.g., as in the eCommerce systems that are often mentioned) are close to identical. In fact, the only difference is really just the location of the "context id": in the EPR vs. in the body of the message! I don't see how the choice of one placement vs. the other can render a service "robust and scalable" vs. "fragile and nonscalable"--especially as the service itself can be implemented in an essentially identical manner in the two cases. My preceding paragraph suggest that there are opportunities for common ground, and I suspect that is the case. However, to find that common ground we need to identify clearly just what it is we are trying to do and then address different issues separately. I believe that there are far too many different issues being mixed together at present for useful progress to occur. Unfortunately, I'm not sure how to proceed to separate out the different issues. Ian. At 11:37 AM 3/3/2005 +0000, Tony Hey wrote: The point is not about how well the WS-RF and WS-Transfer stacks compare but rather whether it is always appropriate to use the "messages are directed at single resources" approach? Many people, including people whose technical judgement I respect such as Tony Storey, Ian Foster, Dave Snelling and others, apparently believe that the answer to this question is "everywhere: it is the foundation for all operations on all services". It is therefore not surprising that this group do not see the need to worry about the question "is it a good idea to build architecture around the idea of sending messages to single resources?" _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org <http://www.globus.org/>

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Tony's email bounced. Tony: You can read whole mail threads triggered by your article at; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/02/threads.html http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/03/threads.html There are more opinions than you've already read. ---- Hiro Kishimoto Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Date: Thu, 3 Mar 2005 11:37:06 -0000 From: "Tony Hey" <Tony.Hey(a)epsrc.ac.uk> Dear OGSA WG members and others, I am interested by this debate (obviously) but fear that I did not get my essential point across. Let me try once more - sinc e I think this is a crucial decision point for the whole GGF and Cyberinfr astructure effort. First, to reassure Dave Snelling and others, I am NOT trying to endorse 'proprietary' proposals such as WS-Transfer from Microsoft; nor am I trying to impede the progress of WSRF etc through OASIS. IBM and others have indeed acted as I had urged and submitted their p roposals to a recognized standards body. Second, the point is not about whether one can implement WSRF in .Net technologies. I respect the work of Marty Humphrey and h is team but this also is not the point at issue. The point is not about how well the WS-RF and WS-Trans fer stacks compare but rather whether it is always appropriate to use the "messages are directed at single resources" approach? Many people, includi ng people whose technical judgement I respect such as Tony Storey, Ian Foster, Dave Snelling and others, apparently believe that the answ er to this question is "everywhere: it is the foundation for all op erations on all services". It is therefore not surprising that this group do not see the need to worry about the question "is it a good idea to build architecture around the idea of sending messages to single resources?" In fact, although I am clearly not an implementor, I t hink that this is not a closed issue. People whose technical judgement I a lso respect - such as Jim Gray, Pat Helland and Andy Herbert (yes, a ll from Microsoft but wait for the supporting cast) - believe that this is not a good way to build robust wide area, inter enterprise distributed sy stems. I understand why opinions from 'Microsoft' may be viewed wit h suspicion but in this case I think their views are deeply held matters of principle. Andy Herbert, for example, is from Microsoft Re search and spent a long time trying to make distributed systems lik e CORBA work. He came to the conclusion that while CORBA was just fine for local area networks it encouraged a style of programming for wide a rea networks that led to such implementations being 'brittle'. Thus I believe that they think that while something like WSRF may be fine for use within corporate computing centers behind corporate firewalls, this approach to building distributed systems will not lead to robust wide area implementations. (I hope Andy and the others cited will either support or correct my interpretation of their views.) So I think this is not a small matter of WSRF versus WS-Transfer. This view is supported by others in the distributed computing community - not only people like Paul Watson, Savas Parastatidis and Jim Webber, but also professional database people like Dave Pearson from O racle who I believe has concerns that in an inter enterprise computing context, many companies will not wish to expose details of their datab ases to open scrutiny. What changed for me recently was the realisation after months of trying to persuade Microsoft to engage with GGF/OGSA/WSRF that this issue was actually a matter of principle and that there was no prospect of Microsoft being able to join the WSRF bandwagon or of their 'morphing' their ideas to be compatible. This being the case - and it was confirmed for me by the OGSA-UK meeting I referred to - and recognizing that the non-WSRF folks might, just might, be proved correct in the long run, at least for certain types of e-Scien ce applications, then for GGF to tie its 'flagship' OGSA to this approa ch to resources by mandating the WSRF route would be to take an unnecessary high risk with our user community. Such a route would also be highly likely to effectively exclude Microsoft from GGF and hinder their pl aying any positive role in GGF, Grids and Cyberinfrastructure. In addition, speaking as someone with responsibility for t he UK e-Science applications people, I can state categorically tha t they are not interested in religious debates about how the distribu ted systems they rely on have been implemented. They just want the underlying distributed middleware to work and for GGF to concentrate on delivering timely and high level standards that will assist them in constructing their interoperable Cyberinfrastructure. They absolutely do no t want to be forced to choose between an 'IBM' camp and a 'Micro soft' camp - they just want a standard on which they can build higher le vel standards and APIs. They want to be insulated from any low-level dispu tes about how to fix the plumbing. So that's it folks. I believe it really is a crucial time for GGF to show that it is really an open standards body dedicated to delivering useful standards for users - rather than backing one bra nch of a religious debate right down at the plumbing level that i ts user community does not want to know about. However, is it possible to define OGSA in such a way that it does not mandate the WSRF approach to resources? Well I have talked with Andrew Grimshaw and o thers and Andrew believes that this might indeed be possible. I would the refore ask you to be open-minded and assist such an investigation. Obviously the first implementations of OGSA will be WSRF based and I expect many UK projects will be very happy to adopt WS RF, GT4 and a WSRF version of OGSA-DAI. What about a non-WSRF implementation? All I know is that Paul, Savas and Jim investigated alternative, non-WSRF ways of providing OGSA-like functionality in a small UK project - but I suspect that the final word has not yet been said on how to provide such implementations. I do not want to de-rail WSRF - as I said it will certainly be adopted by many UK projects. I just want GGF/OGSA to leave the door open - so that if it does turn out that the WSRF way is not so good for inter enterprise applications - then GGF and OGSA are not made obsolete. Ian often asks me why the UK are so keen on Web Services . I used to reply that Web Services were significant only because Microsoft and IBM had agreed to agree - the Men In Black philosophy. Following this philosophy it is surely self-evident that GGF, Grids and the whole Cyberinfrastructure agenda would be much, much stronger if both Microsoft and IBM were engaged. This is why giving some space between OGSA and specific implementations using WSRF is so importa nt. I should end by noting that these are my own opinions. Furthermore, the people I have explicitly cited may or may not agree wi th the opinions I have attributed to them. I hope at least that my views and intentions are now clear. Tony -----Original Message----- From: Frank Siebenlist [mailto:franks@mcs.anl.gov] Sent: 01 March 2005 07:08 To: Ian Foster Cc: Dennis Gannon; Samuel Meder; ogsa-wg; Tony Hey Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'C hallenging Times for GGF & Standards' So... if ws-transfer and ws-properties are sets of convent ions that do essentially the same thing, then it's actually a great c ompliment to ogsa's choice of wsrf that MS decided that it needs a similar functionality! Do I understand that Tony essentially asks the OGSA-WG t o come up with an additional abstraction layer that allows one to model the usage patterns such that it can map to either wsrf or ws-tra nsfer implementations? ...but if we model the usage patterns with wsrf, and w srf and ws-transfer are doing conceptually the same thing, isn't t he ogsa-wg doing just that: it uses an abstraction that can be us ed to describe the relevant usage patterns without losing any generality. The idea of inventing "yet an other abstraction layer" d oesn't sound very productive. -Frank. Ian Foster wrote: > Dennis: > > I'm not sure that the "we don't need WSRF" is th >e heart of the debate. > If it was, then I think things are fairly clear:=2 >0W SRF is just some > conventions for the messages that you send to do c >er tain things (e.g., > getResourceProperty to get state, Terminate to destroy=2 >0s omething, or > whatever the names are) in a WS context. If you >do n't have those > conventions, then everyone ends up defining their own, > so that e.g. a > job management interface might have "getJobStatus" and=2 >0" destroyJob", a > file transfer interface might have "getTransferStatus" a >nd > "destroyTransfer". This lack of consistency just makes=2 >0l ife difficult, > without providing any benefits. > > The debate with MS, as I understand it, seems to=2 >0r ather relate to the > fact that they are promoting a *different* set of >co nventions for > doing similar things, e.g., WS-Transfer instead of WS-ResourceProperties. > > Ian. > > > > At 10:23 PM 2/28/2005 -0500, Dennis Gannon wrote: > >> hi Sam, >> i don't think MS has any orchestrated view on WSR >>F at all (but i may >> be wrong.) I think it is more the case that >>th ere are people working >> on grid standards (outside of microsoft) that feel >>th at what exists >> in the ws-spec world is sufficient. hence if there >>20 is any onus, it is >> on those folks to show us that this is true. =2 >>0w hat tony is saying is >> that users, i.e. application builders, should not hav >>e to deal with >> these details. The should see clearly defined OGSA >>se rvices and they >> should have an easy to understand set of interactio >>n patterns to use >> these services to build thier applications. the OG >>SA point of view >> is that to be precise in the definition of these >>20 behavior patterns >> requires a framework like wsrf. >> >> i actually feel that these things can all coexist. >>20 but from the >> politics of "what is simple", we seem to live in >>20 interesting times. >> >> dennis >> >> On Mon, 28 Feb 2005, Samuel Meder wrote: >> >> > On Mon, 2005-02-28 at 14:38 -0800, Frank Siebenli >>st wrote: >> > > Could anyone summarize MS' WS-view, and how i >>t differs from WSRF? >> > >> > So far I have not seen any substantial differen >>ce between the two >> > approaches and I definitely believe the onus is=2 >>0o n MS to show why >> people >> > should adopt their proprietary specifications vs. a >>do pting >> > something that is being developed in a open sta >>nd ards body, is >> > getting very close to a 1.0 version and has m >>ul tiple implementations behind it. >> > >> > /Sam >> > >> > > >> > > Thanks, Frank. >> > > >> > > >> > > >> > > Hiro Kishimoto wrote: >> > > >> > > >Hi all, >> > > > > > >Absorbing article by Tony Hey. >> > > > >> > > >http://news.tgc.com/nview.jsp?appid=3D360&print=3D1#342708 >> <http://news.tgc.com/nview.jsp?appid=3D360&print=3D1#342708> >> > > >---- >> > > >Hiro Kishimoto >> > > > >> > > > >> > > > >> > > >> GRIDtoday >> > > >> NEWS AND INFOR >>MA TION FOR THE GLOBAL GRID COMMUNITY >> > > >> >> --- February 28, 2005: Vol. 4, No. 8 --- >> > > >> >> > > >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > > >>SPECIAL FEATURES >> > > >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > >> >> > > >>[ ] M342708 ) WSRF? WS-*? Where is GGF's >>20 OGSA Headed? >> > > >> By Tony Hey >>, Contributing Editor >> > > >> >> > > >> Tony Hey, director of e-Science for the >> Engineering and >> > > >>Physical Science Research Council, continues to >> elaborate the >> > > >>need for open standards in the realm of W >>eb services-based Grid >> > > >>computing. He discusses the great debate of=2 >>0W SRF vs. WS-*, and >> > > >>lays out what the >> > GGF >> > > >>must do with OGSA in order to give e-Scie >>nc e application >> > > >>developers something to rally around. >> > > >> >> > > >> >> > > > >> > > > >> > > > >> > > >> > -- >> > Sam Meder <meder(a)mcs.anl.gov> >> > The Globus Alliance - University of Chicago >> > 630-252-1752 >> > >> > >> > > > _______________________________________________________________ > Ian Foster =2 >0 www.mcs.anl.gov/~foster > <http://www.mcs.anl.gov/%7Efoster> > Math & Computer Science Div. Dept of Computer Sci >en ce > Argonne National Laboratory The University of Chic >ag o > Argonne, IL 60439, U.S.A. Chicago, IL 60637, > U.S.A. > Tel: 630 252 4619 Fax:=2 >06 30 252 1997 > Globus Alliance, www.globus.org <http: >// www.globus.org/> > -- Frank Siebenlist franks@mcs. anl.gov The Globus Alliance - Argonne National Laboratory ********************************************************************** Internet communications are not secure and therefore EPSRC does not accept legal responsibility for the contents of this message. Any views or opinions presented are solel y those of the author and do not necessarily represent those of the EPSRC unless specifically stated. All EPSRC staff can be contacted using Email addresses w ith the following format: firstname.lastname(a)epsrc.ac.uk **********************************************************************

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 03 Mar '05

03 Mar '05

Andy: One thing that would really help, I think, is for someone on "the other side" to explain what it is that they want to do that GGF/OGSA WG is preventing them from doing. I understand it must be something important, but think that there is genuine lack of understanding within GGF/OGSA WG as to what it is. A set of application scenarios would really help. A second thing that would be helpful would be a crisp characterization of what "the other side" wants to see GGF/OGSA WG do instead. Should we allow for the use of WS-Transfer as an alternative way of interacting with stateful resources? Or that we should allow for EPR + context-id as an alternative way of interacting with state? Or both? Or something else? Again, this hasn't been made clear: the only explicit communication we've received is that "we shouldn't use WSRF," which isn't a very satisfying answer. Clarity on these two issues would really help I think. A couple of other minor points: * I don't see the fact that people build Grid applications and systems in different ways as a reason not to work towards interoperability. Yes, people have built nice Grid-like systems with custom protocols, with JINI, with Web services, with CORBA, with DCOM, etc. But these systems don't interoperate, and interoperability is important in some situations. * I said management applications were "a primary focus" of OGSA, not "THE primary focus." Regards -- Ian. At 04:25 PM 3/3/2005 +0000, Andrew Herbert wrote: >Ian, Tony > > > >This discussion reminds me very much of the early history of CORBA, when >there was a create debate between those who believed dynamic interface >types were central to object request broking and those who thought they >were the spawn of the devil. Both approaches were able to emulate the >other and so any argument about which was the more fundamental was >sterile. There was certainly an element of bias towards different styles >of application, and this was what split the OMG community since each camp >had an legacy to carry forward and an investment in their view of the >future. The OMG architecture was therefore positioned at a level where >both approaches could be accommodated and as CORBA and CORBA Services were >defined a case by case view was taken of the need for a static or dynamic >interface, or both, or some unification of the two. It led to optional >elements and even some duplication of function in the early OMG >specifications, but as the standards process unfolded and users gained >experience with the technology it became easier to make rational choices >and if necessary go back and fix the specifications. Of course vendors >initially implemented just the options they preferred but over time they >converged on common components and interfaces. And of course the users >also demanded interoperability between CORBA and DCOM and got it, even >though for many CORBA vendors DCOM was the enemy. > > > >The academic question of the superiority of one style of object request >broking over another was never actually resolved a workable hybrid evolved >which meet the needs of the users and the OMG moved on. Interestingly >given your comment about the position of names in messages, with hindsight >many of the CORBA debates were ultimately a fight about where names stood >relative to dot, comma, braand ketin object invocation semantics and >fifteen years later I find it hard to remember the passions that made >these things seem so important at the time. > > > >Ian positions the primary purposeof OGSA as being certain classes of >management application. The problem Tony and others appear to be >grappling with is the desire to have OGSA as the architecture for broader >notions of Grid Computingand e-Scienceand this is where the shoe starts to >pinch. Ian asks how to make progress. It seems to me that GGF has two >choices make the scope of OGSA narrow so those interested in certain >classes of management applicationcan develop an architecture for this >unimpeded, or make the scope of OGSA broader and admit to the possibility >of other classes of application of interest to the GGF community. > > > >I observe colleagues I respect building systems that clearly are doing >Grid Computingof the kind envisioned in Ian and Karls book that coined the >concept, and these people seem to manage to build and operate their >systems without invoking WSRF so this makes me wary of any architecture >for Grid computingand/or e-Sciencewhich mandates WSRF in its entirety in >all cases. > > > >Andrew > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: 03 March 2005 07:04 >To: Tony Hey; Frank Siebenlist >Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson(a)ncl.ac.uk; >dave.pearson(a)oracle.com; savas.parastatidis(a)ncl.ac.uk; Jim Gray; >humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; Andrew Herbert; >gcf(a)indiana.edu; mark.linesch(a)hp.com >Subject: RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times >for GGF & Standards' > > > >Tony: > >I think your message captures nicely (although perhaps inadvertently!) the >way in which people are talking past each other in this discussion. > >I would never say that the "messages to single resources approach" is the >"the foundation for all operations on all services." I understand that >some people in this strange religious debate that we've fallen into have >characterized things that way, but that's far from the truth. > > From my perspective, WSRF was motivated by our experiences building > "service oriented infrastructure", and seeing that the same patterns were > occuring repeatedly in different places as we built systems to manage > Grid systems. The codification of those patterns in standard (and > WS-I+-compliant, I like to emphasize) WSDL has allowed us to simplify > many aspects of both service implementation and client tools. Others > report the same positive experiences. The introduction of WS-Transfer, > which provides similar functionality and seems to be intended for similar > purposes, suggests that there is broad recognition of the importance of > these patterns. However, the fact that these patterns are useful in > building certain classes of management applications (a primary focus of > OGSA, by the way) certainly doesn't mean that they are appropriate everywhere. > >I'd also like to suggest that when considering the assertion that "sending >messages to single resources makes systems fragile", it is useful to >recognize that the messages sent over the wire when using an EPR to a >WS-Resource (the WSRF approach) vs. an EPR plus a context id (e.g., as in >the eCommerce systems that are often mentioned) are close to identical. In >fact, the only difference is really just the location of the "context id": >in the EPR vs. in the body of the message! I don't see how the choice of >one placement vs. the other can render a service "robust and scalable" vs. >"fragile and nonscalable"--especially as the service itself can be >implemented in an essentially identical manner in the two cases. > >My preceding paragraph suggest that there are opportunities for common >ground, and I suspect that is the case. However, to find that common >ground we need to identify clearly just what it is we are trying to do and >then address different issues separately. I believe that there are far too >many different issues being mixed together at present for useful progress >to occur. Unfortunately, I'm not sure how to proceed to separate out the >different issues. > >Ian. > >At 11:37 AM 3/3/2005 +0000, Tony Hey wrote: > >The point is not about how well the WS-RF and WS-Transfer stacks compare >but rather whether it is always appropriate to use the "messages are >directed at single resources" approach? Many people, including people >whose technical judgement I respect such as Tony Storey, Ian Foster, >Dave Snelling and others, apparently believe that the answer to this >question is "everywhere: it is the foundation for all operations on all >services". It is therefore not surprising that this group do not see the >need to worry about the question "is it a good idea to build >architecture around the idea of sending messages to single resources?" > >_______________________________________________________________ >Ian Foster www.mcs.anl.gov/~foster >Math & Computer Science Div. Dept of Computer Science >Argonne National Laboratory The University of Chicago >Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. >Tel: 630 252 4619 Fax: 630 252 1997 > Globus Alliance, www.globus.org _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 03 Mar '05

03 Mar '05

Tony: I think your message captures nicely (although perhaps inadvertently!) the way in which people are talking past each other in this discussion. I would never say that the "messages to single resources approach" is the "the foundation for all operations on all services." I understand that some people in this strange religious debate that we've fallen into have characterized things that way, but that's far from the truth. From my perspective, WSRF was motivated by our experiences building "service oriented infrastructure", and seeing that the same patterns were occuring repeatedly in different places as we built systems to manage Grid systems. The codification of those patterns in standard (and WS-I+-compliant, I like to emphasize) WSDL has allowed us to simplify many aspects of both service implementation and client tools. Others report the same positive experiences. The introduction of WS-Transfer, which provides similar functionality and seems to be intended for similar purposes, suggests that there is broad recognition of the importance of these patterns. However, the fact that these patterns are useful in building certain classes of management applications (a primary focus of OGSA, by the way) certainly doesn't mean that they are appropriate everywhere. I'd also like to suggest that when considering the assertion that "sending messages to single resources makes systems fragile", it is useful to recognize that the messages sent over the wire when using an EPR to a WS-Resource (the WSRF approach) vs. an EPR plus a context id (e.g., as in the eCommerce systems that are often mentioned) are close to identical. In fact, the only difference is really just the location of the "context id": in the EPR vs. in the body of the message! I don't see how the choice of one placement vs. the other can render a service "robust and scalable" vs. "fragile and nonscalable"--especially as the service itself can be implemented in an essentially identical manner in the two cases. My preceding paragraph suggest that there are opportunities for common ground, and I suspect that is the case. However, to find that common ground we need to identify clearly just what it is we are trying to do and then address different issues separately. I believe that there are far too many different issues being mixed together at present for useful progress to occur. Unfortunately, I'm not sure how to proceed to separate out the different issues. Ian. At 11:37 AM 3/3/2005 +0000, Tony Hey wrote: >The point is not about how well the WS-RF and WS-Transfer stacks compare >but rather whether it is always appropriate to use the "messages are >directed at single resources" approach? Many people, including people >whose technical judgement I respect such as Tony Storey, Ian Foster, >Dave Snelling and others, apparently believe that the answer to this >question is "everywhere: it is the foundation for all operations on all >services". It is therefore not surprising that this group do not see the >need to worry about the question "is it a good idea to build >architecture around the idea of sending messages to single resources?" _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Ian Foster 03 Mar '05

03 Mar '05

Savas: I wondered when you'd join the debate, and as usual your comments are very much to the point. At 06:09 PM 3/1/2005 +0000, Savas Parastatidis wrote: >Please note that I am not suggesting that WS-RF (and WS-Transfer for >that matter) is not useful in certain cases. Indeed, in the systems >management area it may make sense to use them. However, what it is being >proposed in the OGSA working group (if I understand correctly) is that >WS-RF be used as the foundation for all high-level services. I don't think that the OGSA working group would argue for using it as a foundation for "all high-level services," but I understand that some people fear that this is intended. For system management applications (a major focus of OGSA), I do believe that there is value, as you also note. >However, a difference >that I personally see between the WS-RF/WS-Notification and WS-Transfer/ >/WS-Eventing/etc. camps is that the latter is much simpler and "much simpler" is a relative term of course, but I think we should also remember that there isn't a lot to even the "more complex" WSRF/WS-BaseNotification. See Blackberry note below. >lightweight. Most importantly, the MS suite of specifications is not >promoted as the uniform, underlying suite of common messaging behaviours >for all high-level services as WS-RF seems to be. Instead it is some That's not my understanding of WSRF. >patterns that are available to be used where they are appropriate. Also, >WS-Transfer is lightweight so it can be used in very-small-factor >devices. I've seen WSRF implemented on a Blackberry, with the complete SOAP-WSRF-WSN-WSDM stack occupying 102KB. I *think* that the "small factor" issue is a red herring. If you want to run on something with just 64KB memory, you probably shouldn't be using Web services. >So, it would be interesting to understand from the WSRF architects where >they feel the WSRF approach is and is not appropriate. E.g. is it >appropriate for interactions with multiple resources? Should it be used >in the design of all high-level Grid services? What are the semantics of >the 'destroy' messages? Here's my opinions: * WSRF (or indeed any WS-I-compliant specification) should be used when and where it's appropriate. * Semantics of destroy: these are defined fairly clearly in the WS-ResourceLifetime specification. * Interactions with multiple resources: I think that's a red herring. E.g., a job factory can return EPRs to WS-Resources representing jobs, thus allowing individual jobs to be monitored and controlled, if needed. The factory can also maintain a service group representing all jobs, and then support operations that allow a client to "destroy all jobs that match a certain pattern" (for example). It's not an either/or. _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org

1 0

Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Kerl's email bounced. I agree with Karl. Actually we have had almost the same discussion at today's OGSA-WG call. We should sort out either (1) message level standards or (2) APIs for the higher level middleware. ---- Hiro Kishimoto Date: Thu, 3 Mar 2005 16:10:31 +0700 From: Karl Czajkowski <karlcz(a)univa.com> To: Steven Newhouse <sjn5(a)doc.ic.ac.uk> Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Sorry, but I think this is an example of the confused discussion we are seeing. You are clearly talking about programming environments with terms like "application code interface" and MPI as a rhetorical example. The question "to WSRF or not to WSRF", on the other hand, is really not a programming question at all. (To Globus Toolkit, or to WSRF.NET might be a more reasonable programming question.) MPI is largely a programming methodology, despite its name... it is an API (and build environment) standard that let you port application code from one host to another. MPI did not in any way give interoperability between platforms so that your application could run some tasks here, some tasks there, etc. across multiple vendor platforms. Specific implementations of MPI have tried to address platform heterogeneity over time, but unless I have missed some recent advance, there is still no runtime interop of MPI implementations. Most of the Web services standards are targeted at a completely different area of runtime system interoperation. The WSRF model and Microsoft's comparable proposals talk about basic ways to structure message interchange and more importantly on some protocol-level reflection mechnanisms to help "find" interop at runtime in a heterogeneous environment. The only programming methodology they imply is an accident of current vendor tools and prototypes! I find it an interesting question whether OGSA is trying to standardize a message-passing architecture or whether they are trying to standardize a programming environment. I think it is rather ambitious, and counter to current Internet-inspired strategies, to try to do both at once. If OGSA want to define programming environments, I think it is very appropriate that they define another "abstraction layer", namely a programming language binding to build or access distributed Grid systems. Hopefully you intend to model a message-passing system, or all bets are off as to how well this binding can map to Web service technologies in a globally distributed setting. If OGSA do not want to define programming environments but do have a message-passing architecture that they would like to specify "concretely" using Web service methods, I think they should continue this discussion of how WSRF and the MS proposals relate. But in doing so, they should not get distracted by red herrings about what an API looks like, how portable their code might be, etc. If OGSA is split on this point, I suggest that the people should split their discussions and proceed in parallel. It does seem that there is this recurring dead-end debate where one person is arguing about message protocol mechanisms with someone else who is arguing about application programs and their terminology accidentally collides. karl On Mar 02, Steven Newhouse loaded a tape reading: > >The idea of inventing "yet an other abstraction layer" doesn't sound > >very productive. > > Neither does the idea of re-writing my application code interface when > WS-RF 2.0 comes out, or something else gets adopted by another > community, or... > > Just imagine where the parallel computing world would still be if we > where still exposed to machine specific networking stacks instead of > MPI? Layers of abstraction are (within reason) good. > > Also you are seeing caution in the UK. Remember OGSI...? The UK put in > considerable effort to adopt the 'betamax' of grid web service. Are we > now being offered VHS grid web services? Or will there be another > Betamax type revision? > > I'm finding some of the comments in this thread (not Frank's) are bit > worrying. Should dissenters really be given a 'good talking to' until > they come round to the WS-RF point of view? Wow... roll on GGF! > > Steven > -- > ---------------------------------------------------------------- > Dr Steven Newhouse Tel:+44 (0)2380 598789 > Deputy Director, Open Middleware Infrastructure Institute (OMII) > Suite 6005, Faraday Building (B21), Highfield Campus, > Southampton University, Highfield, Southampton, SO17 1BJ, UK -- Karl Czajkowski karlcz(a)univa.com

1 0

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Djaoui, A (Abdeslem) 03 Mar '05

03 Mar '05

I agree that defining the perfect layer of abstraction would be a good thing to do. But we have tried before and never got very far in agreeing on what that layer should be in a reasonable time. In order to make quick progress as expected from us, we would be better off discussing what it takes to compose WSRF services with non-WSRF (may be WS-Transfer?) services. some layers of integration (intermediaries, handlers,...) might be needed, but this is a small price to pay, compared to the alternatives of starting again or having a divided community. OGSA being a service oriented architecture will provide a choice of services. Market forces will ensure that the better services survive and the bad ones will be unused for a long time before they die peacefully. This way people can go their preferred way BUT AT THEIR OWN RISK but both approaches will be part of OGSA. Abdeslem. ///////// -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Hiro Kishimoto Sent: 03 March 2005 08:19 To: 'OGSA-WG' Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' Steven's email bounced. Steven, OGSA-WG is open to any plumbing proposal as our infrastructure service. However, we are under pressure from Grid community at large to publish concrete OGSA basic profile by GGF14. (And please use your registered email address.) Thanks, ---- Hiro Kishimoto Date: Wed, 02 Mar 2005 23:24:14 +0000 From: Steven Newhouse <s.newhouse(a)omii.ac.uk> To: Frank Siebenlist <franks(a)mcs.anl.gov> Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' > The idea of inventing "yet an other abstraction layer" doesn't sound > very productive. Neither does the idea of re-writing my application code interface when WS-RF 2.0 comes out, or something else gets adopted by another community, or... Just imagine where the parallel computing world would still be if we where still exposed to machine specific networking stacks instead of MPI? Layers of abstraction are (within reason) good. Also you are seeing caution in the UK. Remember OGSI...? The UK put in considerable effort to adopt the 'betamax' of grid web service. Are we now being offered VHS grid web services? Or will there be another Betamax type revision? I'm finding some of the comments in this thread (not Frank's) are bit worrying. Should dissenters really be given a 'good talking to' until they come round to the WS-RF point of view? Wow... roll on GGF! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Hiro Kishimoto 03 Mar '05

03 Mar '05

Steven's email bounced. Steven, OGSA-WG is open to any plumbing proposal as our infrastructure service. However, we are under pressure from Grid community at large to publish concrete OGSA basic profile by GGF14. (And please use your registered email address.) Thanks, ---- Hiro Kishimoto Date: Wed, 02 Mar 2005 23:24:14 +0000 From: Steven Newhouse <s.newhouse(a)omii.ac.uk> To: Frank Siebenlist <franks(a)mcs.anl.gov> Subject: Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards' > The idea of inventing "yet an other abstraction layer" doesn't sound > very productive. Neither does the idea of re-writing my application code interface when WS-RF 2.0 comes out, or something else gets adopted by another community, or... Just imagine where the parallel computing world would still be if we where still exposed to machine specific networking stacks instead of MPI? Layers of abstraction are (within reason) good. Also you are seeing caution in the UK. Remember OGSI...? The UK put in considerable effort to adopt the 'betamax' of grid web service. Are we now being offered VHS grid web services? Or will there be another Betamax type revision? I'm finding some of the comments in this thread (not Frank's) are bit worrying. Should dissenters really be given a 'good talking to' until they come round to the WS-RF point of view? Wow... roll on GGF! Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

[ogsa-wg | Basic Profile - 1314] Relationship to WS-I Basic Security Profile 1.0
by Sourceforge Tracker Monitor 03 Mar '05

03 Mar '05

A new artifact has been added: 1314 Submitted by: Tom Maguire Submitted date: 2005-03-02 20:39:31 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1314&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1314&group_id…) Summary: Relationship to WS-I Basic Security Profile 1.0 Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1314 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-02 20:39:31 Submitted By: Tom Maguire Submit Date: 2005-03-02 20:39:31 Assigned To: &lt;None&gt; File(s): <None> Description: Describe the extension model for BSP 1.0 View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Re: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Samuel Meder 02 Mar '05

02 Mar '05

On Mon, 2005-02-28 at 14:38 -0800, Frank Siebenlist wrote: > Could anyone summarize MS' WS-view, and how it differs from WSRF? So far I have not seen any substantial difference between the two approaches and I definitely believe the onus is on MS to show why people should adopt their proprietary specifications vs. adopting something that is being developed in a open standards body, is getting very close to a 1.0 version and has multiple implementations behind it. /Sam > > Thanks, Frank. > > > > Hiro Kishimoto wrote: > > >Hi all, > > > >Absorbing article by Tony Hey. > > > >http://news.tgc.com/nview.jsp?appid=360&print=1#342708 > >---- > >Hiro Kishimoto > > > > > > > >> GRIDtoday > >> NEWS AND INFORMATION FOR THE GLOBAL GRID COMMUNITY > >> --- February 28, 2005: Vol. 4, No. 8 --- > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>SPECIAL FEATURES > >>============================================================== > >> > >>[ ] M342708 ) WSRF? WS-*? Where is GGF's OGSA Headed? > >> By Tony Hey, Contributing Editor > >> > >> Tony Hey, director of e-Science for the Engineering and Physical > >>Science Research Council, continues to elaborate the need for open > >>standards in the realm of Web services-based Grid computing. He > >>discusses the great debate of WSRF vs. WS-*, and lays out what the GGF > >>must do with OGSA in order to give e-Science application developers > >>something to rally around. > >> > >> > > > > > > > -- Sam Meder <meder(a)mcs.anl.gov> The Globus Alliance - University of Chicago 630-252-1752

7 8

RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'
by Djaoui, A (Abdeslem) 02 Mar '05

02 Mar '05

Just clarifying a rather small part of the big puzzle! >The argument is about whether support for WS-Addressing is all that is >required in order to interact with services built on top of WS-RF. I >believe this to be an oversimplification. Support for WS-Addressing is >absolutely required. However, it's not enough. It is enough, for a client to interact with a service that implements a WSRF specification. Note: I did not use the term build on top (this term might imply that WSRF implementations have to be provided by the infrastructure). The service simply implements one of the WS-* specifications (ie WSRF)! The client then uses messages exchanges as defined in that services description. >The implementation of the >semantics of the ResourceProperties and Lifetime related messages have >to be provided. If they are not provided, a developer will end up >implementing them. Absolutely, this is true of any web service specification, including WS-Transfer (no offence intended to any WS-* specification!) Abdeslem /////////

1 0

Proposed agenda for March 2nd call
by Hiro Kishimoto 02 Mar '05

02 Mar '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 2nd Wednesday from 5pm to 7pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0302 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 0) Celebration of OGSA v1 documents formal launce GFD.30, "The Open Grid Services Architecture, Version 1.0" GFD.44, "Open Grid Services Architecture Glossary of Terms" GFD.45, "Resource Management in OGSA" 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if available) GGF13 update (if any) Agenda bashing 2) Basic profile discussion (60 min) Revised basic profile draft https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… le/en/3 New configuration of Issue tracker https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… 3) Profile template discussion (if available) 4) Roadmap discussion (if available) 5) Wrap up (10 min) AOB Mar. 7 (5-7pm CST) BES BoF preparation Basic profile discussion, basic security profile Mar. 9 (10-11am CST) Data Design team Mar. 9 (5-7pm CST) Roadmap discussion, GGF13 session preparation Mar. 13-16 GGF13 in Soeul See telecon schedule until GGF: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Hiro Kishimoto

1 0