[dmis-bof] Comments on the charter?

[Peter Kunszt]

hi dave

can you point me to the implementation of ws-addressing that you refer
to as 'just about everybody'?

cheers
peter

On Sat, 2005-12-17 at 16:23 +0000, Dave Berry wrote:
> I'd push for WS-Addressing EPRs where possible.  The simplest EPR is
> just a wrapped URI (actually an IRI, I believe), so it is a
> straightforward extension of using URLs.  WS-Addressing is implemented
> by just about everybody, I believe.
> 
> If you use WS-A then it should be straightforward to generalise or
> extend to include other specs based on WS-A.  These include WSRF and
> WS-Naming, of course, but also other specs being developed within the
> industry.
> 
> Having said that, I would add the caveat that I'm not expert on WS-A and
> it would be good to get input from someone who really understands this
> stuff in detail.
> 
> Dave.
> 
> -----Original Message-----
> From: owner-dmis-bof at ggf.org [mailto:owner-dmis-bof at ggf.org] On Behalf
> Of Michel Drescher
> Sent: 16 December 2005 11:04
> To: Peter Kunszt
> Cc: allcock at mcs.anl.gov; Hiro Kishimoto; dmis-bof at ggf.org; Ian Foster
> Subject: Re: [dmis-bof] Comments on the charter?
> 
> 
> Hi all,
> 
> On 14 Dec 2005, at 17:06, Peter Kunszt wrote:
> 
> >>>>  - we need to address naming.  What will we accept as source and 
> >>>> destination names? URLs? URIs? any string? EPRs?
> >>>
> >>> URL seems like a good choice, this would probably suit all
> >> use cases.
> >>> this is what we use in the GSM-WG. we have storage URLs.
> >>> an EPR is nothing more than a decorated URL so a simple URL
> >> would suit
> >>> that too.
> >>
> >> URLs work fine for files, and I *suspect* it will be what we use for 
> >> V1.0, but if we take our file blinders off and try and think about 
> >> source other than files, i.e. a service that is virtualizing some 
> >> non-file data source, we might want EPRs.  This is related to the 
> >> next issue.
> >
> > well, if you take rich URLs, you can get away with anything. 
> > ?query=...
> 
> I strongly support URLs. Note that, opposed to the very popular  
> perception, URLs describe *resources*, not (only) files. Apart from  
> the scheme and authority parts of URLS (i.e. "http" and  
> "forge.gridforum.org[:80]") URLs describe resources in a  
> hierarchically ordered domain. THe query part is just a piece of  
> information that further transports information specific to the  
> addressed resource.
> 
> So if you want to publish for example the coffee temperature in your  
> mug using HTTP, you could do that with the following imaginary URL:
> 
> 	http://users.mcs.anl.gov/~allock/resources/sensors/coffem-mug? 
> refresh=10
> 
> Requesting that URL may result in a nice data stream sending the  
> current temperature in 10 second intervals.
> Note that the path element does not necessarily have to map to a file  
> system path - refer i.e. to the J2EE Servlet specification that  
> splits the path information into three elements:
> - context path (a J2EE enterprise application)
> - servlet path (a locator for servlets within a J2EE enterprise  
> application)
> - path info    (the residual URL path element)
> All three elements concatenated form the original URL path element;  
> and the context path and servlet path may be null. The mapping is  
> purely virtual and is specified in the EAR deployment descriptors.
> 
> >> I guess now that I think about it, your way works too.  As long as 
> >> the query mechanism is there, as long as you don't send a block the 
> >> site doesn't support, you wont fail validation... I don't like it, 
> >> but unless we discover a bigger problem than that, I guess it is an 
> >> option :-).
> >
> > the trick is easy. you put in an element that you don't define. you 
> > then extend it and play around the way you like it, and once you know 
> > what you want, you just take it into your mainstream WSDL as a proper 
> > part of it. see our discussion/example in 
> > https://uimon.cern.ch/twiki/bin/view/SRMDev/XmlSolution
> 
> This URL requires authentication which I cannot provide for AFS...
> 
> >>
> >>>
> >>>>  - what about scheduling / planning aspects?  Do we want
> >> to include
> >>>> elements in this WSDL that specify rate (bandwidth),
> >> quantity (file
> >>>> size), and timing (START BY, FINISH BY, etc)
> >>>
> >>> our experience: individually for each transfer job: no.
> >> that is very
> >>> complicated and of questionable use.
> >>> on the scale of the service itself as a service
> >>> parameter/configuration: yes.
> >>
> >> I half agree with you.  Clearly the service, may want to have limits 
> >> that can be set.  In that regard, it is acting as a resource manager 
> >> and protecting the resource for which it is responsible, much like a 
> >> compute scheduler.  Btw, I would argue that this is outside the scope
> 
> >> of this working group, since an external entity has no need to be 
> >> involved with that.  At most we might want to agree on some state 
> >> that such a service MAY (in the SPEC sense of the word) expose.
> >>
> >> However, it is not clear to me that requests per job are of 
> >> questionable use.  Clearly they should be optional elements, but if 
> >> the submission has no such information, on what basis does the 
> >> service make decisions when it has a resource constraint?  I would 
> >> also add priority to the list.  If I have multiple jobs submitted, I 
> >> may want to make sure that one of them gets service over the others.
> >
> > ok, i was sloppy. it is true that you should be able to influence the 
> > priority of your transfers and maybe even their speed/bandwidth within
> 
> > your allocated 'quota'.
> 
> Yes, I agree here as well. We're on the right track I think, so let's  
> fight over the details in the meetings. ;-)
> 
> Cheers,
> Michel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1395 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dmis-bof/attachments/20051219/2229e520/attachment.bin