July 2005 - acs-wg - lists.ogf.org

Directions to IBM meeting site for ACS Face to Face
by Thomas Studwell 02 Aug '05

02 Aug '05

I apologize for not sending this sooner. Two docs. One showing detail map of IBM site in RTP. We are meeting building 675. The second doc shows the route to take from the RDU Airport to IBM Building 675. The Clarion is just south of I40 on Miami Blvd so is less than a mile from the IBM site. Actually JUST past the overpass on the western side of Miami. I think you need to head South, find a place to turn around, and then head North to IBM site but it will be obvious once you are there. (See attached file: from_ RDU airport to_ 4401 Silicon Dr Durham.pdf)(See attached file: sitemap.pdf) Thomas W. Studwell Senior Technical Staff Member, Autonomic Computing Architecture IBM Software Group B140/Bldg 500 4205 S Miami Blvd, Durham, NC 27703 (919) 254-7574 Fax: (919) 254-7628 Mobile: (919) 619-1038 studwell(a)us.ibm.com "Things should be made as simple as possible, but not any simpler." Albert Einstein (1879-1955)

3 2

Aug F2F agenda
by Keisuke Fukui 28 Jul '05

28 Jul '05

Folks, In creating the agenda and the timetable for the face-to-face meeting next week, I need volunteers to lead the discussions. Here are list of the agenda I have in mind. The lead doesn't necessarily mean to be responsible to create the materials, rather I expected to arrange have them or any input ready for discussion. - Below is the agenda we have candidates for leaders: Role call, note taker, time keeper, agenda bashing by KF. (30 min) Security and signature on ACS by KF+Sachiko (60 min) Data Transport by KF (60 min) AA Creation use case by KF (120 min) Detailing the proposed schedule for spec. writing by KF (60 min) - Leaders are called for for the below topics: OGSA F2F presentation (60 min) ACS use case for SDD TC (60 min) Version Management (60 min) Asynchronous Messaging (60 min) AA Modification (60 min) AA Deletion (60 min) AA Replication (60 min) (time estimate is tentative) If you have additional agenda or comments, please let us know. Thanks in advance! -Keisuke

1 0

Teleconference minutes - July 27
by Sachiko Wada 28 Jul '05

28 Jul '05

Hi team, Here is the minutes of the last teleconf. Please review it and point out where the record is not correct, if any. It is also available at Gridforge: https://forge.gridforum.org/projects/acs-wg/document/minutes-20050727/en/1 Sachiko ====================================================================== ACS Teleconference ----------------------------------------------------------------------- Date and Time: July 27 20:10-21:00 EDT 2005 / July 28 9:10-10:00 JST, 2005 Participants: Keisuke Fukui (Fujitsu) Tom Studwell (IBM) Peter Ziu (Northrop) Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes ------------------------------------------------------------------------ * OGSA F2F agenda Pete or Mike will present overview of ACS at the OGSA F2F. We will discuss the presentation material at the ACS F2F next week. * Review of the "proposed schedule for the spec. writing." We will discuss the process to write the draft at the F2F. Action: Everyone, to find which of the chapters he/she can contribute by F2F. * Continued discussion of use case for archive creation We will discuss this at the F2F. This topic comes up at the early session of the first day. Keisuke requested the answers to the question posted on July 21. * Updates ** Meeting with NAREGI PSE. Keisuke reported the overview of the meeting with NAREGI PSE. - They are satisfied with overall framework of ACS. - They will implement their own version control and won't rely on the ACS on version control, and they simply register and remove the archive rather than keep updating. - The signature is not required on AA in their use case. - They are planning their own meta data repository because they believe most will be their use case specific. - Keisuke asked them to show us their meta data items so that we examine if we can incorporate them in the AAD as opaque items for ACS. ** SDD and ACS SDD TC is now gathering use cases and requesting one from ACS. The gathered use cases will be observable on the SDD TC site. We will discuss this at the F2F. * Next call We will discuss the schedule toward GGF15 at the F2F Action: Keisuke, to send agenda of the F2F.

1 0

Next Call
by Sachiko Wada 27 Jul '05

27 Jul '05

Hi team, Here is the proposed teleconference schedule from Keisuke. Next call: Apr 20 Wed 20:00 EST/Apr 21 Thu 9:00 JST If anyone has problems with this, please feel free to respond to this message. # Keisuke, let us know the calling info. By the way, I assume that we have agreed to cooperate to develop ACS specification but I don't think that we have agreed the process. I wonder how I can contribute to our work. We are going to write up a first working draft by GGF14, late June. It is about time to take some concrete actions. Deciding who writes which part of the document is one way, but there may be some issues left that need to be discussed before starting to write. If there are such issues I want to summarize them first. (Keisuke listed up such issues previously and we have already been discussing about Naregi requirements, but do they enough?) So, I'd like to hear your opinion about this at the next telconf. ... Does this make sense? Regards, Sachiko Wada

4 24

Teleconference minutes - July 20
by Sachiko Wada 27 Jul '05

27 Jul '05

Hi team, Here is the minutes of the last teleconf. Please review it and point out where the record is not correct, if any. It is also available at Gridforge: https://forge.gridforum.org/projects/acs-wg/document/minutes-20050720/en/1 Sachiko ====================================================================== ACS Teleconference ----------------------------------------------------------------------- Date and Time: July 20 20:00-21:40 EDT 2005 / July 21 9:00-10:40 JST, 2005 Participants: Keisuke Fukui (Fujitsu) Tom Studwell (IBM) Peter Ziu (Northrop) Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes ------------------------------------------------------------------------ * Data transport in GetContents. Agreed that the current protocol selection model is OK. Below topics are the TBD for now: - http server location in case for register/create. - Detailed format in case of the SOAP attachment is specified. * Review the skeleton draft. ** TOC Review The structure of the skeleton draft was approved. Agreed to start discussions on the Architecture and Example Usage chapter. ** Schedule We have a plan to submit the draft to GGF Editor at GGF15 in charter. If it seems to be difficult to finalize the draft until GGF15, we may reschedule the milestone. Action: Keisuke, to send a detailed schedule to write up the draft. * Use case discussion ** Replication (Pete's diagrams) We agreed that it is worth while for ACS to have extensibility to be able to include this kind of use case. But it may be too broad scope to take the sophisticated replication capabilities into the current draft. We continue work on this topic. ** AA Creation (Tom and Keisuke's diagrams) We still need more discussion to make consensus. We continue work on this topic. * Security Agreed to have security discussions at the coming F2F meeting. Mike mentioned he may be able to get an input from security expert. * Next call Date: Jul 27 Wed 20:00 EDT/Jul 28 Thu 9:00 JST Calling #: will be announced later

2 1

RE: [acs-wg] An AA creation use case
by Ziu, Peter 26 Jul '05

26 Jul '05

Keisuke, I believe that the most prudent solution needs to take into account the following two principles: - the repository needs to be able to handle (within the limits of the hardware set) any amount of application contents and associated data for a system (one notional AA). - Something must maintain the notion of the version and integrity of system (via one notional AA), through proper referential integrity and signature. In response to your questions: >I'd like to ask everyone which of the below is the real issue we >are facing: >- Name for the things to be registered; i.e. AA file in my diagram, or > Archive description and Application contents file(s) (includes DD) in > Tom's one. If this is an issue, I can be so much flexible about how > we can call it (them). I am not particularly hung up on names right now, that is a refinement issue, and not a defining structure. The issue is whether there should be a porttype which has a method for pushing an entire and complete physical AA into a repository. Here is my take on the issue: - In the case of an ACS implementation, sending an entire AA imposes a need to "know" about a physical file format. This is contradictory to our statement that "we will not define how an ACS will store it's data". For example, if my implementation of ACS requires a method in the porttype that requires the acceptance of a physical AA file, then I must parse the AA file into parts in order to store it into the format that my implementation has chosen. Perhaps my AA file is stored in thousands of DB2 or Oracle records, since using one record to store an AA file will most likely fail at some point when too big. If I had porttypes that allowed me to remotely construct an AA, we can punt on a physical format and an entire physical AA transmission format. Providing we have the appropriate porttypes to remotely construct, inspect, and retrieve parts of an AA, then we only need to define on the wire how to move parts of an AA around, yet we can still maintain the notion of an AA and it's integrity, since the interface that constructed it can enforce it's integrity. This is why Tom has outlined sending the entire AAD (hope that the correct acronym) when replicating. The receiver of the replica can inspect and traverse the AAD to find the parts to pull the file over in chunks... especially if there was "modified date" time stamp info on each individual part, then we could explore the replication model I outlined. >- A physical format of the archive; a zip is described in the strawman. > If this is an issue, we can focus on this topics. However, it is not > mentioned as this so far. - I think this is what Tom has been trying to focus on in his .ppt last meeting. I seemed to have put my physical file comments in the previous question, sorry. >- Partial update of the archive in the repository (It seems to me a > separate issue that can be discussed independently.) - it is related since defining how parts of an AA are created, accessed, modified, and removed have implications that, in the case of physical file formats, would need to be known by ACS if an ACS impl. decided to just write the received AA file to disk, and then later have to modify it. >- Assuming IDE products to be bound to ACS specification (IMHO, it's > desirable, but the decision remains up to the vendors.) I am not sure I understand this question. No matter what porttype spec we come up with, as long as we do not create any issues for the IDE's or ant (or any other client type), we should be ok. I think that having the client create one file will have scalability issues to remote clients of ACS for large AAs. >- Or anything else? That's my take. Pete -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of Keisuke Fukui Sent: Thursday, July 21, 2005 4:48 AM To: Thomas Studwell; acs-wg(a)ggf.org Subject: Re: [acs-wg] An AA creation use case Folks, Today we gone through a good amount of discussion in the call on this. I'm comfortable with trying to find a better placement of the things in this way. I also appreciate Pete's time check today:-) I think it's valuable for us to brainstorm this so that we can have a logically correct, feasible and adoptable specification for our purpose. Having said that, I'd like to clarify the real point of the discussion: At first I thought it is a matter of whether register() or create(), then it turned out that it is the use case where the archive is created. Now it again becomes ambiguous to me what is the real matter behind the two different definitions for AA (or AA file). I'd like to ask everyone which of the below is the real issue we are facing: - Name for the things to be registered; i.e. AA file in my diagram, or Archive description and Application contents file(s) (includes DD) in Tom's one. If this is an issue, I can be so much flexible about how we can call it (them). - A physical format of the archive; a zip is described in the strawman. If this is an issue, we can focus on this topics. However, it is not mentioned as this so far. - Partial update of the archive in the repository (It seems to me a separate issue that can be discussed independently.) - Assuming IDE products to be bound to ACS specification (IMHO, it's desirable, but the decision remains up to the vendors.) - Or anything else? FYI, when I say we will standardize transport format of AA, it is to me means to define: - An XML schema of the Archive Descriptor (AD). - At least one physical format of the archive that contains everything needed either in real entity or in external reference. - Required piece of information (or file), optional one and extension mechanisms in an archive besides the AD. Is it a wrong assumption? Please be open to discussion. I'm trying to be fair in the process. I'm just struggling for the best way to address to everyones points. I appreciate any contributions to improve our concept. Thanks in advance! -Keisuke

3 4

Teleconference minutes - July 13
by Sachiko Wada 21 Jul '05

21 Jul '05

Hi team, Here is the minutes of the last teleconf. Please review it and point out where the record is not correct, if any. It is also available at Gridforge: https://forge.gridforum.org/projects/acs-wg/document/minutes-20050713/en/1 Sachiko ====================================================================== ACS Teleconference ----------------------------------------------------------------------- Date and Time: July 13 20:00-21:30 EDT 2005 / July 14 9:00-10:30 JST, 2005 Participants: Keisuke Fukui (Fujitsu) Tom Studwell (IBM) Peter Ziu (Northrop) Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes ------------------------------------------------------------------------ * August face-to-face dates. Agreed F2F meeting plan: Dates: Aug. 1, 2 Place: RTP in N.C Keisuke, Pete, Mike, Keisuke and Sachiko will attend. Tom has kindly accepted hosting the meeting. Teleconference equipment, projector and power supply are available. * Tentative Glossary definition. The refined glossary Keisuke sent has approved. * Create or Register. Discussion on "Create or Register" issue didn't reach conclusion. This issue seems not just a naming matter but concern with the usage scenario of AA creation. Tom and Keisuke will send a picture of their own model to ml, then continue work on deepening our understandings on mailing list. Action: Tom, Keisuke, to send a picture of their own model. * Roles in ACS for the draft spec. description. Keisuke suggested to make the description for the Replicator to be a note rather than a separate role. Finally we agreed to keep Replicator remained in the introductory part of Working Draft because Replicator may have specific capabilities rather than Consumer/Producer, especially related to security. Action: Keisuke, to send skeleton of the latest Working Draft merging the agreed glossary and ARI part for more discussion. * Data transport in GetContents. - Interaction with CDDLM We will wait for their feedback. - Register interface The issue is "in case of http is used, should we allow both http server hosted by ACS and http server outside of the ACS?" Discussion was postponed due to time restriction. * Versioning Extensions to WebDAV Kisuke's question: Isn't this specific to WebDAV? Although its capability seems to meet some of the ACS requirements, it may not applicable to ACS since we won't stick to the WebDAV protocol. Action: All, to keep an eye on this. * Next call Date: Jul 20 Wed 20:00 EDT/Jul 21 Thu 9:00 JST Calling #: will be announced later

3 3

Updated ACS use cases
by Thomas Studwell 21 Jul '05

21 Jul '05

I updated the text description to use cases 1 & 2 to reflect the image and my thinking. (See attached file: AA_CreateUseCasesV2.0.ppt) Thomas W. Studwell Senior Technical Staff Member, Autonomic Computing Architecture IBM Software Group B140/Bldg 500 4205 S Miami Blvd, Durham, NC 27703 (919) 254-7574 Fax: (919) 254-7628 Mobile: (919) 619-1038 studwell(a)us.ibm.com "The optimist sees opportunity in every danger; the pessimist sees danger in every opportunity." Winston Churchill, Sir (1874-1965)

1 0

FW: [acs-wg] An AA creation use case
by Ziu, Peter 19 Jul '05

19 Jul '05

Here are some additions for replication (clone/transfer)to show the benefits of granular updating. Pete -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of Keisuke Fukui Sent: Tuesday, July 19, 2005 2:54 AM To: acs-wg(a)ggf.org Subject: [acs-wg] An AA creation use case Folks, I attach two slides in response to the below "Action" for my part. Sachiko Wada wrote in "[acs-wg] Teleconference minutes - July 13": > * Create or Register. > Discussion on "Create or Register" issue didn't reach conclusion. > This issue seems not just a naming matter but concern with the usage > scenario of AA creation. > Tom and Keisuke will send a picture of their own model to ml, then > continue work on deepening our understandings on mailing list. > Action: Tom, Keisuke, to send a picture of their own model. I retouched the diagram we discussed at the last GGF14 to depict the use case I have in mind as in (1) or (2) in the first slide. The description in the strawman spec. seen "4. Example Usage" corresponds to the view, though it now needs to be modified to convey more precise image for this. I believe that one of the main theme in ACS is to ease the submission and the following management of the application related files, (3) deviates a bit from our initial purpose. -Keisuke

1 0

[Fwd: Re: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14 (re-send)]
by Keisuke Fukui 19 Jul '05

19 Jul '05

FYI, -------- Original Message -------- Subject: Re: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14 (re-send) Date: Tue, 19 Jul 2005 17:36:38 +0900 From: Keisuke Fukui <kfukui(a)labs.fujitsu.com> To: Steve Loughran <steve_loughran(a)hpl.hp.com> CC: 'cddlm-wg(a)ggf.org' <cddlm-wg(a)ggf.org> References: <42B92AB0.3080802(a)labs.fujitsu.com> <42B94FBC.70406(a)hpl.hp.com> <42BB559D.6020600(a)labs.fujitsu.com> <42BBD923.1010509(a)hpl.hp.com> <42BC935C.4090501(a)labs.fujitsu.com> <42C92E87.6090508(a)hpl.hp.com> <42D1D6EF.5010108(a)labs.fujitsu.com> <42DB9DCE.307(a)hpl.hp.com> Hi Steve, I think I got your point on slide 2. Thanks for a heads up. I modified the diagram so that it convey the intent more precisely. GetResourceProperty can be called either the client or component. I assumed that in preparation to register the application contents, the client will do the call and prepare for it in the components. Does it look better in terms of your comments? As for the comments on the slide 3, I'm not very sure about your proposal. I understand that we can include multiple files as an attachment using this framework. It may include appropriate number of URIs needed, which refers to the attached contents. We need more study on this, but we are not intended to generate any extension to the existing standards on this area. Steve Loughran wrote: > > 4. Caching/performance. If the URL-fetching app is written with the > assumption that the repository is some distance away, or intermittently > unreachable, it will want to download the resource and cache it. So an > HTTP HEAD request may be needed, or a GET with a lastModifiedSince (or > better yet, an etag). I guess the ACS repository would be the one that offer a local cache in the system. That's the largely the motivation to have the ACS standards. -Keisuke

1 0