[dmis-bof] Comments on the charter?
Dave Berry
daveb at nesc.ac.uk
Mon Dec 19 03:39:06 CST 2005
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
> >
>
More information about the dmis-bof
mailing list