[dmis-bof] Comments on the charter?

Mon Dec 19 08:09:04 CST 2005

hi dave

thanks! i admit that i didn't have the time to follow the latest
developments in the past year. for the open source stuff,
i have not found e.g. the jboss and apache implementations in any of
the mainstream (say axis) code yet... or did i miss it?

but back on topic: i think we all agree that we need standardisation on
the transfer interface. the question is now what is the context we embed
this standardisation into? if it is OGSA/WSRF then for production grids
as EGEE we cannot expect to have robust off-the-shelf implementations
within the next 18 months (that is my personal assessment of the
current state of the art, maybe i'm wrong). if it is WS-I then there
is a possibility to have implementations very soon, and thus have
interoperability within a short time.

we agreed here that the functional spec of the interface can be done
first, and then the rendering into WS-I or WSRF can come as needed. 
so all i'm saying is: don't use a concept like WS-Addressing in the
functional spec as it is rendering-specific! however, we can use
a "URL" as a concept as it is generic enough. keeping the functional
spec independent of the implementation is a good idea. then of course
the WSRF rendering can and should use concepts that are within its
context, including WS-Addressing.

of course how the different implementations/renderings will interoperate
is a different topic altogether. if the functional semantics are the
same then at least you can write clients that understand both flavors.

cheers,

peter

On Mon, 2005-12-19 at 09:39 +0000, Dave Berry wrote:
> Hi Peter,
> 
> There are implementations of WS-A by at least MS, IBM, BEA, Sun, JBOSS &
> Apache.  
> 
> Dave.  
> 
> > -----Original Message-----
> > From: Peter Kunszt [mailto:peter.kunszt at cern.ch] 
> > Sent: 19 December 2005 08:38
> > To: Dave Berry
> > Cc: Michel Drescher; allcock at mcs.anl.gov; Hiro Kishimoto; 
> > dmis-bof at ggf.org; Ian Foster
> > Subject: RE: [dmis-bof] Comments on the charter?
> > 
> > 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/fa6721ba/attachment.bin 