- ogsa-wg - lists.ogf.org

RE: EMS session agenda (Re: Proposed agenda for Sept. 7th call)
by Subramaniam, Ravi 08 Sep '05

08 Sep '05

Hi, Here is a synopsis of the agreed next steps from today's OGSA telephone meeting. Attendees, please review and update as required. GRAAP: Jim: Thanks again for the introduction to WS-Agreement today. We appreciate your taking time to engage. I would like to reiterate the couple of areas of focus we had discussed at the F2F a. Understand the domain terms that may apply in agreements in a specific EMS scenario (BES?) b. Look at how one might apply WS-Agreement to the multi-entity (for a single operation) scenario that is EMS. (Cluster girds have a single entity (scheduler?) to handle all resources and requests and so that could fit the two party model of WS-Agreement but I was thinking of EMS outside of this space where responsibility is distributed). CDDLM: Dejan/Stuart: Thanks for attending this session. Sorry for any mixup here. I hope you did get something useful from Jim's presentation. Based on our discussions around CDDLM, here is what I captured: a. Hiro will send out the pointers to the interaction of EMS services for the 3 scenarios that was developed at the last OGSA F2F. b. Stuart will take a look and see how the CDDLM architecture would address these scenarios and start and email thread in the OGSA mail list. c. Ravi would collect any difficult or long drawn discussion topics (as suggested by the respondents) as agenda items for discussion at the next OGSA telecom. d. The OGSA WG will study the high level scenarios from CDDLM that were the model for the CDDLM specs. Need to reconcile these into the EMS/OGSA space. We will *not* have a parallel small team meeting this week but will schedule over the longer term (beyond GGF15) to do so as an ongoing activity as we work to resolve the approaches. Speaking for myself right now: I would suggest that an output of this activity be the OGSA EMS diagram fleshed out with the provisioning services from CDDLM (this could be either a blowing up of the provisioning box or a refactoring that may be dictated by this joint activity). Thoughts? OGSA: Anyone on the call today, please let me know if I have missed any of the outcomes of the discussion here. Any other suggestions and topics for discussions and/or focus with CDDLM and GRAAP are welcome. Thanks! Ravi

1 0

Re: [ogsa-wg] Update to OGSA 1.5
by pete＠ziu.net 08 Sep '05

08 Sep '05

Andrew, Good idea. The most commonly accepted language for design within the our arena is UML. I think the exercise we performed at the face2face creating sequence diagrams for the various EMS scenarios proved to be very valuable. Perhaps some UML exercises that are larger in scope could be very productive. Other diagram types, and other design areas of the grid. I would be more than happy to participate in such an effort. I think a very good design area to document would be security as well. Pete Ziu 571.235.0208 (c) mailto:pete@ziu.net (h) mailto:5712350208@tmomail.net (sms) "Andrew Grimshaw" <grimshaw(a)cs.virginia.edu> Sent by: owner-ogsa-wg(a)ggf.org 09/07/2005 06:42 PM To "'Ogsa-Wg'" <ogsa-wg(a)gridforum.org> cc bcc Subject [ogsa-wg] Update to OGSA 1.5 All, While explaining OGSA to some very technical folks last week it came up that the 1.0 document does not describe an “object model” so to speak… in other words, what are the “atoms”, what is the minimum we assume, etc. For example, we assume: that resources have interfaces, that they process messages, that their behavior may be history dependent, that they are referenced with EPR’s, that the atoms may have a unique AbstractName that they may be both servers and clients of other services We also seem to assume that there is some mechanism to get/set some form of metadata (resource properties) We seem to want to be able to find out what interfaces are supported (it is in base profile …. And I think should be in any profile ? opinion) We seem to assume a factory pattern ? though it is not explicit, and not part of lifetimes I am sure there are others. Comments? Should I write something up along this line for inclusion in the 1.5 document? Andrew

1 0

RE: [ogsa-wg] UPDATED - Proposed agenda for Sept. 7th call
by Subramaniam, Ravi 07 Sep '05

07 Sep '05

Hi all, Please see the update to the EMS section of this agenda. This is based on the strawman from Hiro and conversations with Andrew. Sorry for the late update. Ravi -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: Sunday, September 04, 2005 11:46 PM To: ogsa-wg(a)ggf.org Subject: [ogsa-wg] Proposed agenda for Sept. 7th call Hi all, This Monday is US Labor day and we won't have a call. The following is a proposed agenda for OGSA-WG telecon on Sept. 7th. 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: 0907 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (August 31st) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050831/e n/1 Winter F2F meeting update OGSA WSRF Basic Profile 1.0 final call Agenda bashing 2) EMS architecture discussion (90 min) - WS-agreement overview (15-20 minutes) - Includes discussion of the key elements of WS-Agreement - How GRAAP sees WS-Agreement applied to EMS (including and beyond job instantiation) - Applicability in other areas of OGSA (may need a follow up conversation based on time) - Open discussion (10-15 minutes) - Technical based on the material above - How do we work together? - Next step (5-10 minutes) From F2F meeting minutes: > - Agreed to define one or two scenarios and go through them to > explore interactions between the various 'pieces' > - Volunteers: Andrew, Jay, Ravi, Stuart, Mike > - Goal to present something by GGF15. But need to produce > something before that. > - Agreed to continue the work on the OGSA teleconferences. From Toshi Nakata @ GRAAP-WG > We in GRAAP feel that WS-Agreement has a very important role in the > OGSA world. (I hope you have that perspective also.) Since the newer > draft of the WS-Agrement is close to the 2nd public review, > we were wondering how we should discuss the role of WS-Agreement in > OGSA esp. in OGSA-EMS. 3) Wrap up (10 min) AOB Sept. 12 (Mon) Basic security profile, roadmap document Sept. 14 (Wed) Architecture 1.5 (Profile Definition?) Sept. 19 (Mon) Information Modeling ---- Hiro Kishimoto

1 0

OGSA-WG and fellow WG Winter F2F Survey
by Hiro Kishimoto 07 Sep '05

07 Sep '05

Hi all, and sorry for the cross-posting. OGSA-WG and fellow WGs are planning to have Winter F2F meeting in December or January. At the OGSA-WG F2F meeting in week before last, I took action item to ask all expected attendees for their availability for Winter F2F meeting. Please take the time to fill in the following online survey by next Monday (September 5th). We hope to decide date and city next week. Post the survey on a Web site - use this URL: http://www.zoomerang.com/survey.zgi?p=WEB224LBPWYVUT Thanks in advance, -- Hiro Kishimoto

1 3

RE: [ogsa-wg] RM teleconference reminder - September 6, 2005
by Fred Maciel 06 Sep '05

06 Sep '05

Hi yet again, > I meant September 6th, not 5th. Sorry. And on the top of that, I got the times wrong (it's in the usual time slot, 11AM Pacific). Here is the correct announcement. Sorry again. This is a reminder of the Resource Management design team teleconference next Tuesday (September 6, 2005). This teleconference will be mostly *internal* discussions within the *core* team, which means that if you are just observing the work you could skip this one -- on the OGSA-WG teleconference on Wednesday I'll report what was discussed. The agenda is: - review what we achieved at the face-to-face (and what we didn't achieve yet) - review what homework we have from the face-to-face, and divide and schedule the work. - perhaps review Ellen and Steven's first draft of the resource management section for the OGSA 1.5 spec (still being reviewed within the Design Team). Date: Tuesday, September 6, 2005, at the following times: - 11:00-12:00 US Pacific (GMT - 7) - 12:00-13:00 US Mountain (GMT - 6) - 13:00-14:00 US Central (GMT - 5) - 14:00-15:00 US Eastern (GMT - 4) - 18:00-19:00 GMT - 19:00-20:00 UK (GMT + 1) - 20:00-21:00 Central Europe (GMT + 2) - 03:00-04:00 Japan (GMT + 9, following day) -- sorry. Dial-in: Toll Free: (888) 422-7120 Int'l Access: (608) 250-0194 Participant code: 693305 If screen sharing is needed, let's use Glance: URL: http://ogsa.glance.net Session key: 0719 Explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html See you there, Fred Maciel Hitachi America R&D

1 0

RM teleconference reminder - September 5, 2005
by Fred Maciel 06 Sep '05

06 Sep '05

Hi, This is a reminder of the Resource Management design team teleconference next Tuesday (September 5, 2005). This teleconference will be mostly *internal* discussions within the *core* team, which means that if you are just observing the work you could skip this one -- on the OGSA-WG teleconference on Wednesday I'll report what was discussed. The agenda is: - review what we achieved at the face-to-face (and what we didn't achieve yet) - review what homework we have from the face-to-face, and divide and schedule the work. - perhaps review Ellen and Steven's first draft of the resource management section for the OGSA 1.5 spec (still being reviewed within the Design Team). Date: Tuesday, September 5, 2005, at the following times: - 07:00-08:00 US Pacific (GMT - 7) - 08:00-09:00 US Mountain (GMT - 6) - 09:00-10:00 US Central (GMT - 5) - 10:00-11:00 US Eastern (GMT - 4) - 14:00-15:00 GMT - 15:00-16:00 UK (GMT + 1) - 16:00-17:00 Central Europe (GMT + 2) - 23:00-24:00 Japan (GMT + 9, following day) Dial-in: Toll Free: (888) 422-7120 Int'l Access: (608) 250-0194 Participant code: 693305 If screen sharing is needed, let's use Glance: URL: http://ogsa.glance.net Session key: 0719 Explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html See you there, Fred Maciel Hitachi America R&D

2 1

RE: [ogsa-wg] RM teleconference reminder - September 6, 2005
by Fred Maciel 06 Sep '05

06 Sep '05

Hi again, I meant September 6th, not 5th. Sorry. Regards, Fred Maciel

1 0

Proposed agenda for Sept. 7th call
by Hiro Kishimoto 05 Sep '05

05 Sep '05

Hi all, This Monday is US Labor day and we won't have a call. The following is a proposed agenda for OGSA-WG telecon on Sept. 7th. 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: 0907 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (August 31st) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050831/en/1 Winter F2F meeting update OGSA WSRF Basic Profile 1.0 final call Agenda bashing 2) EMS architecture discussion (90 min) Andrew and Ravi will send out detailed agenda before the call. From F2F meeting minutes: > - Agreed to define one or two scenarios and go through them to > explore interactions between the various 'pieces' > - Volunteers: Andrew, Jay, Ravi, Stuart, Mike > - Goal to present something by GGF15. But need to produce > something before that. > - Agreed to continue the work on the OGSA teleconferences. From Toshi Nakata @ GRAAP-WG > We in GRAAP feel that WS-Agreement has a very important role in the > OGSA world. (I hope you have that perspective also.) Since the newer > draft of the WS-Agrement is close to the 2nd public review, > we were wondering how we should discuss the role of WS-Agreement in > OGSA esp. in OGSA-EMS. 3) Wrap up (10 min) AOB Sept. 12 (Mon) Basic security profile, roadmap document Sept. 14 (Wed) Architecture 1.5 (Profile Definition?) Sept. 19 (Mon) Information Modeling ---- Hiro Kishimoto

1 0

OGSA WSRF Basic Profile v1.0 Final call
by Tom Maguire 03 Sep '05

03 Sep '05

A clean copy of the OGSA WSRF Basic Profile v1.0 has be uploaded to Gridforge. Please send any comments you may have on this refactored profile (removal of security sections to allow for better composition) to the mailing list. I would like to get a rough consensus on the Wednesday call 9/7. Thanks, Tom Frey’s Law: “Every 5 years the number of architecture components double and the ability to comprehend them halves” 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

Implied Abstract Name Profile
by Frank Siebenlist 02 Sep '05

02 Sep '05

I'd like to make a case for the definition of an "Implied Abstract Name" profile for ws-addressing. By claiming to adhere to this profile, the EPR-minter would indicate that care has been taken with the construction of the EPR's address to provide it enough uniqueness properties such that it can be used as a "name" by itself. The observation is that if an EPR-minter can determine that the reference refers to a uniquely identifiable resource such that an "abstract name" can be constructed, then in many cases it could also add enough uniqueness properties to the EPR's address such that the address itself could be used as an alternative abstract name. For example, if a uuid could be generated as an abstract name, then the implementation may also be able to choose to base the dispatching information in the address' URI on that same uuid, which would give the address's URI and the abstract name's URI equivalent uniqueness properties. Now, in some cases, the resource identifiable information is not present in the address value, but is somewhere embedded in the optional reference parameters. Again, the EPR-minter may have a choice to make that resource identifier information for the reference parameters just as "unique" as the equivalent abstract name it could create. In those cases, one could standardize a recipe to construct a unique "implied abstract name" from the address and the reference parameter values. For example, one could concatenate the address and the base64-blob of the canonicalized reference parameters to yield a URI-value for the implied abstract name. (Or one could concatenate the address and the digest value of that base64 blob if you care about the length of the value... at the expense of being able to reconstruct the address+reference-parameters from that implied abstract name...) In summary, if the EPR-minter is able to generate a abstract name value for a resource, then in many implementations, the EPR-minter could also generate an address (+reference parameters) that would yield an implied abstract name with the same uniqueness properties. The EPR-minter could communicate the adherence to this "Implied Abstract Name" profile by labeling the EPR somehow. The spec shows that one can add attributes to the address element: /wsa:EndpointReference/wsa:Address/@{any} such that we could label such an address element with an attribute that would tell you the profile that this address value adheres to, like implied-abstract-name="true". Tom Maguire suggested (and prefers) an approach that attachs a claim (wsi:claim) to a wsdl element (likely a port or binding). wsi:claim="http://example.org/ImpliedAbstractName There may be other (better) ways... Now... why would this be any better or worse or why do we need this at all? The abstract name as it is defined now in the ws-naming spec is part of the EPR, but does not get communicated on the wire. In other words, once the soap message is constructed from the EPR according to the ws-addressing recipe, we loose the abstract name as it doesn't get mapped into the message header content. In other words, from the header information we can not derive any unique identifier for the resource this message is meant for. In order to enforce resource specific policy on a soap message or to write traceable information in audit logs, we somehow have to obtain a unique identifier for the resource. In some cases, and certainly when we're inside of the dispatching service itself, we can assume that that application can find the mapping back to the abstract name that was issued in the EPR. However, that mapping is application specific logic and therefor not easily accessible from within the runtime where transparent policy enforcement is applied. Also, any soap-routing intermediate won't have access to the abstract name. Hopefully, these example make the case for such an "Implied Abstract Name" profile, as it would allow one to obtain a unique identifier for the resource from a message that was generated from a profile compliant EPR. Note that this profile would not make the abstract name element obsolete as for resources that change their reference over their lifetime one needs a stable resolvable name. Having both an abstract name and an implied abstract name would allow one also to keep mapping tables outside of the EPR-minting applications, which is needed to correlate policy and audit trails for the same resources. --- If the requirement for an implied abstract name and the need for an associated profile hold water, then it may be appropriate for the ws-naming wg to add such a profile definition to its charter. Regards, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

2 1