[dmis-bof] Comments on the charter?

[Michel Drescher]

Hi All,


On 14 Dec 2005, at 14:30, Peter Kunszt wrote:

> hi bill
>
> here it comes  - my dreaded comments ;-)
>
>>  - I changed the name to OGSA-DMI
>
> i don't like that. having my EGEE hat on, please consider that we  
> cannot
> adapt and use OGSA in any of the near future (next year) as everything
> is set up for production pretty much now. there is no time for us  
> to migrate
> to OGSA quickly and to deploy and use it. there are lots of  
> question marks
> concerning especially the security infrastructure and how that will  
> interoperate
> with classical transport-level security.

I have basically no objections to either approach - with an  
inclination to OGSA/WSRF.
So I propose here to adopt Hiro's suggestion and write an abstract  
service description and provide at least one rendering, i.e. a WS-I  
rendering. As I am inclined to OGSA, I'd prefer a WSRF rendering, but  
we can provide two renderings (WS-I and WSRF) if need be.

> so to recap: we would very much appreciate a pure WS-I interface  
> standardization
> first, where we can talk cleanly about interfaces and semantics and  
> we would not
> clog our discussions about which semantics of WSRF should be  
> applied to what. we
> could focus on the transfer specs. then someone can take the spec  
> and 'ogsafy' it.
> so please consider to keep this just as DMIS-WG. (sorry hiro - i  
> have to be pragmatic here)

Peter, did you follow the Byte-IO and/or BES development? Both WGs  
specified the abstract service description and provided concrete  
renderings later. Worked out very well. So again, I'd propose this  
path due to good experience.

>>  - 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.

+1

>>  - There is a general issue which will affect a lot of this
>> and that is just extensible WSDL.  How do we allow parameters
>> to change when options in the WSDL change.
>
> the pragmatic approach is to increase the minor version number
> for compatible changes and the major one for incompatible changes.
> however, there are alternatives that we have investigated also in
> the GSM-WG: it is possible to leave an extensibility hook in the WSDL,
> so that new functionality can be tried on existing services, before
> it is migrated into the mainstream WSDL. this is a good idea also
> for interoperating between versions.

I am not entirely fluent with WSDL, but my experience with JSDL is  
that extensibility hooks work out very well if used the right way.  
Combined with a WSRF style of designing the WSDL (note that this does  
not force you to use WSRF - it just is a design pattern on how to set  
up your XSD and WSDL) we should be able to end up with an abstract  
yet concrete enough specification.

>>  - I think we all agree that this needs to be transport
>> agnostic, but we need to figure out how best to implement
>> that (related to the WSDL question)
>
> unless i'm mistaken, doc/literal should just do the trick..?

One possible (and to me, plausible) way to do this may be:
a) Each peer exposes an (ordered?) list of supported transfer protocols
b) The peers agree on the highest common denominator
c) The peers negotiate the agreed data transfer protocol's parameters
d) The peers initiate (at some may be scheduled) point in time) the  
agreed data transfer
e) ...

Note that this rough sketch has been inspired, if not copied from,  
the SSL/TLS handshake protocol.

>>  - what statement do we want to make (and does the OGSA data
>> architecture
>> need) about delivery semantics
>
> i think we need to make as detailed statements as possible/reasonable!
> we need to define what states the transfer service exposes to the  
> client
> and what failure modes the client has to expect.

+1

>>  - 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.

+1
I see the parameters that are actually used for a particular data  
transfer session as a set of "resource usage" description which may  
be charged accordingly.

>>  - A sort of pet project of mine is monitoring /
>> troubleshooting.  I would like to potentially include
>> elements in the WSDL or state that is exposed that would
>> enable better/easier monitoring and troubleshooting.  For
>> instance, some sort of unique job identifier that can be
>> passed down to children, so that you can trace the chain back
>> when you have a failure.
>
> yes, statistics gathering is another one. very important to have -
> i already sent the wsdl's we have today to this list..

Shame on me, but I didn't check these WSDL's. Are they sort of  
compatible to a usage like RUS-WS's output?

>>  - groups that we need to be aware of to one extent or
>> another include OGSA, OGSA-D, info-d, gsm, byte-io, naming,
>> grid file systems, authz (other security groups),
>> ws-agreement (GRAAP?).  are there others? how should we
>> liaise with those groups?  some will require more work than others.
>
> :-) the best thing to have is if there are individuals participating
> in both who can act as liaisons. i am happy to take gsm and parts of
> ogsa-d, together with you of course.

I might volunteer as a Byte-IO liaison.

Cheers,
Michel