OGSA-WG F2F 18 - DMI Session 
============================

  - Venue: Fujitsu facility in Sunnyvale 
  - Date: 15 August 07

* Participants:

  Hiro Kishimoto
  Andreas Savva
  Michel Drescher
  Mark Morgan
  David Snelling
  Donal Fellows
  Steve McGough
  Steven Newhouse
  Vesso Novov (minutes)
  Fred Machiel
  Chris Kantarjiev
	
  Bridge: ZKert, Ravi Subramanian


** Michel: Brief overview of status of DMI.
        -- What the Data EPRs must support.
        -- Lifetime - well defined and long-lived.
        -- Lifecycle - Mappable to RM-Lifecycle v1.0.

        Mark: What if the Sink does not accept the transfer request from the Source? Not clear if the Source request may be denied.
        Steven N.: This is worth further discussions.


** Steven Newhouse: Presents the DMI architecture diagram(refer to "OGSA-DMI Functional Specification 1.0").

       Mark: Are the DataEPR specifically related to a Web Services or do they represent a more generic data services/endpoints?
       Steven N.: This is under discussion.

** Steven Newhouse: Presents some Use Cases and the different ways the DataEPR are structured. 
       -- Defined 3 data transfer protocol identifiers: gridftp; scp; http. DMI mandates the support for the various identifiers but does not mandates the support for the actual protocol.
       -- Defining the DataEPRs as port types allows for changing the actual port type back-end implementation.

       Hiro: Some data sources may already be OGSA data sources. Is the use of WS-Naming prohibited ?
       Steven N.: The XML element for the 'http' protocol could be extended/used to refer to WS-Naming compliant EPRs. The focus of the DMI protocol is the actual movement of data.
       Michel: The use of WS-Naming is not explicitly prohibited. Whether the EPRs are WS-Naming compliant is irrelevant, the DMI protocol is agnostic in that respect.

       Donal: Stresses the importance of confidentiality of the data transfer.

       Mark: How do we distinguish between a Source and a Sink? What if an EPR is simultaneously the Source and the Sink - an issue arises if certain protocols are used only with a Source or only with a Sink - would rather have more generic Data Source as opposed to Web Service-specific EPRs.
       Steven N.: Changes to the XML representation could account for this possibility.


** Steven N.: Explains the DMI state diagram(refer to "OGSA-DMI Functional Specification 1.0").

       Donal: Will there be a way of asking DTFactory what instances are known to the factory?
       Steven N.: This is not decided for now.

       Hiro: Is there an information model?
       Steven N.: Currently there isn't an information model defined as such.
       Hiro: Suggest the data information be aligned with the Information model work of Ellen.


** Michel: Presents additional DMI Use Cases. The cases cover more sophisticated use of the DEPRs. The purpose is to provide motivation for using EPRs when communicating with a DTF.

       Steven N: Is there an issue for using 'fake' EPRs(not representing actual WS instances)?
       Michel: The WS-Addressing Standard does not mandate a 'valid' value inside the <wsa:Address> field, as long as there is a value entered in that field.