September 2007 - ogsa-dmi-wg

Latest draft
by Ravi Madduri 26 Sep '07

26 Sep '07

All: As promised in the call today I uploaded the draft with my comments. Please let me know what you think or may be we can discuss them in the next call. Link to the version : http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-dmi-wg/doc… Cheers -- -- Ravi Ravi K Madduri The Globus Alliance | Argonne National Laboratory http://www-unix.mcs.anl.gov/~madduri

1 0

Meeting minutes
by Ravi Madduri 26 Sep '07

26 Sep '07

are here: http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-dmi-wg/doc… Please review and edit as appropriate -- -- Ravi Ravi K Madduri The Globus Alliance | Argonne National Laboratory http://www-unix.mcs.anl.gov/~madduri

1 0

OGF21 Slide deck v1
by Steven Newhouse 26 Sep '07

26 Sep '07

First draft of the OGF21 slide deck for the call. Steven

3 2

Apologies
by Michel Drescher 26 Sep '07

26 Sep '07

Folks, my apologies, but I can't make today's call. :( Cheers, Michel

3 2

DMI Telcon on Wednesday
by Mario Antonioletti 25 Sep '07

25 Sep '07

Hi, An early reminder that we will be having a DMI telcon on Wednesday - I will not be able to make this. Previous Telcon's Actions: [Michel] Distribute the slide set that was given at the OGSA F2F meeting. Done. [Michel] Create a new tracker to park things to consider for a future version of the DMI spec. Done. [Steve] Produce a zeroth slides draft for the OGF21 DMI session. [Allen] Come up a preliminary interface definition that will generate the Data EPRS. Done. [Michel] After discussion convert Allen's interface definition to WSDL. [Steven] Go through Mario's changes and comments and accept the trivial changes/comments and leave anything that's more complex to review at a future call. Done. Call details: Date: 26th September 2007 When: 9am (Pacific) 5pm (UK) PIN: 2719140 USA: +1 866 500 6738 (Toll: +1-203-480-8000) UK: +44 118 909 2000 Suggested Agenda: 1. IPR Notice 2. Agenda Bashing 3. Current Document Review (review any outstanding comments) 4. Allen's Data EPR interface proposal 5. OGF21 slides 6. AoB +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+

1 0

Updated
by Steven Newhouse 24 Sep '07

24 Sep '07

All, Updated specification on the website with most of Mario's comments accepted. http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-dmi-wg/doc… I think Michel now has the pen to remove the push/pull stuff to a tracker. Steven

1 0

Thoughts on <dmi: AvailableProtocols>
by Allen Luniewski 20 Sep '07

20 Sep '07

The requestDataTransferInstance operation on a DTF requires the information in <dmi:AvailableProtocols> in order to determine the protocol to be used in the data transfer. The spec. currently embeds this information in a <dmi:DataEPR> which is, essentially, an EPR to the source/sink that has had the AvailableProtocol information added to it. This note discusses this area of the spec. in more detail. A client of DMI will acquire EPRs to the source/sink in ways that are outside the scope of DMI. However, when we step back it is pretty clear that either the client has these because the client created the source/sink or because the client went to a service such as RNS or GFS to acquire them. Given that the specifications for these kinds of services already exist, as well as implementations of them, it seems quite clear that the EPRs returned by these services will not have the <dmi:AvailableProtocol> information in them. Thus in order to use DMI facilities, the client will need to get a DEPR from the EPR it has in hand. One way to get this information would be for the client to go to the source/sink service and ask for a DEPR. One would imagine the service would provide an operation such as GetDEPR () which returns a DEPR for that service. The client can clearly do this since the client has an EPR to the source/sink service. This approach would retain the current DTF interface unchanged. Alternatively, one could consider moving the <dmi:AvailableProptocol> information out of the DEPR and treat as a first class parameter to the requestDataTransferInstance operation. I strongly prefer this approach as it makes the required information in <dmi:AvailableProtocols> clear in the interface - it does not bury it inside of an EPR. In this approach the source/sink services would provide an operation such as GetAvailableProtocols () which returns a <dmi:AvailableProtocols>. Again, the DMI client can clearly do this since the client has an EPR to the source/sink in hand. A key thing to note is that in either approach, successful use of DMI, in practice, is going to require that data services willing to act as a source/sink in a DMI transfer will need to implement an additional, very trivial, operation to allow the DMI client get the <dmi:AvailableProtocol> information. Once the client has that information, it needs to be passed into the DTF either via a DEPR as in the current spec. or as an explicit parameter as I suggest above. Finally, it is clear that DMI can not mandate the operations suggested above. However, the DMI spec. certainly needs to recognize the need for operations such as those suggested above and suggest that data services provide an operation that supports the DTF interface that DMI specifies. Allen Luniewski IBM Cross Brand Services IBM Silicon Valley Laboratory 555 Bailey Ave. San Jose, CA 95141 408-463-2255 408-930-1844 (mobile)

1 0

Emailing: OGSA-DMI.ppt
by Michel Drescher 20 Sep '07

20 Sep '07

Folks, as requested, these are the slides Steve and I used at the OGSA-18 F2F mid-August in Sunnyvale. Cheers, Michel

1 0

Telcon Minutes
by Mario Antonioletti 19 Sep '07

19 Sep '07

DMI Call - 19 Sep 07 ==================== Attendees: Steve Newhouse, Microsoft Mario Antonioletti, EPCC Michel Drescher, Fujitsu Allen Luniewski, IBM Agenda: - Slide set for OGF21 - Michel's communications protocol taxonomy - Data EPRs - Mario's edit of the DMI spec Actions: [Michel] Distribute the slide set that was given at the OGSA F2F meeting. [Michel] Create a new tracker to park things to consider for a future version of the DMI spec. [Steve] Produce a zeroth slides draft for the OGF21 DMI session. [Allen] Come up a preliminary interface definition that will generate the Data EPRS. [Michel] After discussion convert Allen's interface definition to WSDL. [Steven] Go through Mario's changes and comments and accept the trivial changes/comments and leave anything that's more complex to review at a future call. +--- Michel mentioned pulling out some of the stuff in the currently in the spec to produce a WS-I rendering but we did not come back to discuss this. - Slide set for OGF21 Michel to mail out the slide set presented at the face-to-face. Steve will do a pass first pass through to create a slide set for OGF21. - Michel's communications protocol taxonomy The discussion was based on the mail that Michel posted to the DMI mailing list: http://www.ogf.org/pipermail/ogsa-dmi-wg/2007-September/000250.html Inclusion of the capabilities at the end point (in the EPR?) could give us lots of flexibility in the future but it would introduce a lot of complexity. Have lots of pull/push and end up with only five thing that result in valid transfers. The five use cases are restrictive - there might be a service at the source that can push data to the sink or a service at a sink that could pull data to a sink. These are plausible scenarios that have not been included. The table was constructed using Michel's existing knowledge of these protocols - in the future there may be additional protocols that can enable other possibilities. The table only shows what is possible today. Allen - some of the stuff is pretty obvious - if both the client and sink can only pull data then they will never be able to talk to each other. That's not going to change. Michel - In row 5 the source can push the data. Allen - the sink needs to be able to act as the end-point of a push operation. The table could be completed by adding two more columns with the source and sink end-points. Michel - it appears that the definition of pull and push is too fuzzy. Steven - does this add value to the spec or does it just add complexity? At the moment it seems adds more complexity than value. Michel - that is a good point - if we cannot simplify this then maybe we should remove it. Steve - this is trying to provide a taxonomy to classify the protocols, if we use a particular protocol can it act as a recipient of a push? That is an interesting classification to make. If we had such a taxonomy and relate it to a set of end points then that would allow us to compose protocols together. Michel - could leave this out for the first version of the spec, play with it and then see what is missing from the spec. Steve - could revisit this later on .... Michel - could take this out and put it in a tracker and re-examine at a later point. Michel will create a new tracker for items to consider for a future version of the DMI spec. When someone can formulate this item then it could be added to this tracker. - data EPRs Allen - we are dumping too much stuff in the Data EPR. This is information that should be available at the source and sink where this information can be queried. That might be a better way to do it. Steven - don't disagree with your point. Issue as to where this information comes from is one that we keep on coming back to. This may come up in public comment - where do the EPRs come from and how are they are formulated? As an EPR or as a look up with a document returned. Need to capture some text putting in the rationale for our decisions - at least more than we have at the moment - might be worth defining a third port type which could contain an operation called lookup. Allen - getting an EPR to a service is fairly natural. The way the spec is written is that we need a specialised form of an EPR - where is this thing being generated? Could get this from the source/sink and then we've generated another port type. Michel - this complements the way that grid file systems work - the RNS spec - they have identified the ability to specify data location using EPRs. The RNS spec is just a lookup of a logical name to produce an EPR that tells you where the data is stored. Steven - someone should sit down and produce a portType with some operations - need to think about what we are going to put in order to get something out ... Allen and Michel? Allen - I could write the interface - though not produce the WSDL. Michel - Allen can do the interface and I'll put together the WSDL. - Mario's edits of the DMI spec. Mario - I think the best way to proceed with this is for someone to sanity check the changes that I have made and leave anything that requires discussion for a future telcon. Steven is kindly volunteered to do this. Mario - just two salient points: - we refer to the DMI and the DTF explicitly as port types but at other points we seem to refer to them as service instances implicitly. It would be good to try and make this more consistent. - At various points we refer to time instances but we are not clear as where the standard clock for these are - the consensus, after some discussion, is that times should be related to the time at which the DTF/DTI services the client is communicating with. This needs to be stated clearly in the spec. AOB None. Meet at the same time next week. +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+

1 0

DMI Telcon
by Mario Antonioletti 19 Sep '07

19 Sep '07

Hi, A late reminder that we will be having a DMI telcon. Date: 19th September 2007 When: 9am (Pacific) 5pm (UK) PIN: 2719140 USA: +1 866 500 6738 (Toll: +1-203-480-8000) UK: +44 118 909 2000 Bash out an agenda at the meeting ... +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+

1 0