[ogsa-dmi-wg] Thoughts on <dmi: AvailableProtocols>

[Allen Luniewski]

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20070920/a05b869b/attachment.html