[dmis-bof] Comments on the charter?

[William E. Allcock]

Michel, and all,

Sorry for the delay.  I knew SC was going to consume me, but didn't plan on
a proposal that we decided to go after :-).  I am going to march through the
emails respond to them and try and incorporate the comments into the draft
and then we will send that out for more comments.

FYI, I have requested a single 90 minute session for us.  The plan would be
to review and accept the charter, review some of the existing interfaces,
and begin a discussion of how they do or do not meet our charter / community
needs.

As to your comments and slides in this email.  Yes, I think that ultimately
this will be:
 - a web service
 - These types of services need to expose a lot of state, and I suspect one
of the points of contention will be how to do that.
 - It needs to be transport agnostic up and down the stack (I would argue it
should be network transport protocol (TCP vs. others) agnostic as well as
application transport protocol agnostic (GridFTP vs. HTTP vs. ...).
 - I think the variable parameters are going to be the hard part, though
WS-Agreement may help us there.  I say may because I am not sure that it can
change the agreement terms on the fly and it either needs to do that to
adopt to what each protocol needs.  I.e., do you need to set the TCP buffer
size or not, do you need to specify parallel streams or not.  If it can't
change those terms on the fly then we have to list every possible term and
that solution su... is one I don't like :-).  

Being an old C programmer, I would wish for WSDL that could act like a
tagged union.  You have an enumerate field where you can specify an option,
say the type of application level transport protocol you want and then based
on that it, loads a bit of schema to validate the following WSDL.  That
would, IMHO, make extensibility trivial.  A service can advertise anything
it wants and as long as a client knows how to send WSDL for that option, you
are good to go.

Comments on your slides.  The first two use cases are standard put and get.
The third party transfer option is common, but raises some issues.  For
instance, your use cases imply some things:

 - you can contact the source or the destination
 - you contact only one of them.

Are those requirements?  What if there is system that is always driven by
the source or the destination?  I.e., it specifies you must contact one or
the other?  What if there is system that wants the client to do the
coordination and it contacts both ends (which is what standard FTP does) and
a broker trying to do some sort of co-scheduling might do?  What about
standard HTTP which does not support 3rd party transfers?

I would also argue that your final use case is actual just a get followed by
a put.

Bill

> -----Original Message-----
> From: Michel Drescher [mailto:Michel.Drescher at uk.fujitsu.com] 
> Sent: Tuesday, October 25, 2005 10:24 AM
> To: allcock at mcs.anl.gov
> Cc: dmis-bof at ggf.org
> Subject: Re: [dmis-bof] Comments on the charter?
> 
> 
> Hi Bill,
> 
> for a quick kick-off, this charter is certainly fuzzy enough. ;-)
> 
> Seriously, what I currently envision with DMIS is that this group  
> will define a web service that provides means to negotiate 
> acceptable  
> protocols and protocol dependent parameters to invoke (or let  
> invoke?) one of the negotiated protocols to actually get the 
> file (or  
> data in the end) moved from its source to its destination.
> 
> Does this sort of match what you have in mind? Moreover, if it  
> matches my thoughts, how does it relate to, say, WS-Agreement?
> 
> Anyway, I attached two slides to visualise some use cases and  
> possible roles and actions involved. Note that I did not include any  
> WS-* aware element as I consider these present at all three 
> role takers.
> 
> Cheers,
> Michel
> 
>