[dais-wg] Telcon Minutes notes from 08 Jul 05
Mario Antonioletti
mario at epcc.ed.ac.uk
Mon Jul 11 03:45:05 CDT 2005
DAIS Telcon 08 July 2005
========================
Chair: Norman Paton
Notes: Mario Antonioletti
Attendees:
Simon Laws, IBM
Norman Paton, University of Manchester
Mario Antonioletti, EPCC
Dave Pearson, Oracle
+---
Simon:
Go through the email that Simon posted to the list regarding issues.
http://www-unix.gridforum.org/mail_archive/dais-wg/2005/07/msg00007.html
Page 5, Sec 3.8: As a resource may be identified by an endpoint and a
separate abstract name, I wondered if this wasn't quite right.
Simon: When I wrote this I was implying that the data resource
includes an EPR and enough information to distinguish the data
resource. Later on this is described in more detail in the
factory section. Have a construct that has an EPR and the name
of a resource. The WS-Naming draft states that the abstract
name is included in the EPR and will be using that structure to
use these pieces of information. Seems like a good idea. Wish
to use this.
Norman: the resource is identified by its address and in another case
it is identified by the address and the abstract name. Hence
the text in 3.8 is ok but it is not very precise. Maybe it
should be more precise.
Simon: could tidy this up but this is a general point as to what we
think an address is ....
Norman: so maybe that is alright ... is there a tighter definition
later on?
Simon: have reworded the naming section ... for the purposes of WS-DAI
an abstract name is a URI, have included a bit of xml and
changed the WSDL ... have also simplified the text that
follows...
Norman: so that structure is being used to feedback the result ....
Simon: same as before but we got rid of a layer of XML which
simplifies ... when passing a message to a DAIS resource the
consumer must provide the address and information to
discriminate the resource that is being used .... goes on to
describe that the two cases fall out: WSRF and the non-WSRF
section. Leave as is and tighten up later ...
...
Page 12, Sec 5.1: do we have a property that indicates the languages
supported on a resource?
Mario: there is in the relational and now that if we have a generic
query operation maybe this could be promoted to the core spec.
Simon: but:
Page 12: I wonder if we should have a placeholder here for a CIM
description of the installed data resource management system. This is
in practice the only way of working out what language expressions can
be passed.
Could use this to describe the language.
Norman: may not be good to use a generic place holder ... have a top
level query operation - we know the value it takes in as a
parameter but we do not know what the actual language means
... there is no inter-operable way of defining this ... there
is no formal way of describing this ....
Mario: can't we just promote the language properties thing?
Simon: concerned that you don't know what message it refers to ...
languages supported at the top level does it only refer to the
top level operation?
Norman: yes..
Simon: then it does get a bit complicated ...
Norman: with SQL you can be told what version of the standard it is
claiming to support ... but you have a greater degree in the
real world ... so you can get round that by specifying other
things ...
Simon: the data resource description has been introduced as a
configurable property that you can introduce by the manager to
describe it ... you could introduce another static property
that describes the data resource ... do we say it's a CIM
thing? ...
Norman: at some point will people pick our spec and find the
non-interoperable bits ... if we want to build an
inter-operable thing we need to build in a model. Can connect
into CIM to describe the DBMS and another to describe the
Schema ...
Dave: can say that we expect this that you will be able to do this
once the CIM model is there....
Simon: so we add something like CIMDataResourceDescription as a static
property to describe this sort of thing ...
Norman: should check with Sue ... leave some CIM stuff in the
relational one to describe the schema and a bit of CIM in here
to describe the DBMS ... this will provide information on how
to use the generic query operation ...
...
Simon:
Page 18: end point(s) - why > 1? What are the semantics of that?
refers to something coming out of a factory. Have changed so
this comes out of an EPR. If we want more than 1 then we would
have to adjust the return type of the addresses. It is not a > 1
cardinality now.
In the WS-Naming they are using an old version of WS-Addressing
...
...
Simon: there is a very early draft of WS-Naming ...
Dave: they say early draft in early June and specification on March
'06 so can't really use as yet ...
...
Simon:
Page 20, Sec 6.2: As the conduit is a WS-Resource, surely it doesn't
need these messages - instead they must be defined in such a way that
they are available for all resources not represented as WS-Resources.
Put some message to describe things generically but as we are
now calling it a WS-Resource can we just say that these
messages will be generically available.
So can remove these messages and refer to WSRF.
Norman: still need a destroy operation.
Simon: need to put the destroy back in section 5.3 and put it back on
the WSDL.
...
Page 21, Sec 7.1.2: is it stated what the behaviour of lifetime
messages is if the conduit is used with externally managed resources?
Do the messages all fault?
Norman: you could have an externally managed resource that is a WSRF
data resource in which case you invoke a destroy ... ok in
both case ... so the messages fault ....
Simon: or the data resource goes away ...
Norman: need to be clear .....
Simon: in the non-WSRF case it faults, but in the WSRF version.
Dave: destroy is like a drop table command ... thinking whether it is
necessarily a fault ... a user may want to remove it if they
have created ....
Simon: the case though it is an externally managed resource ..
Dave: but if it is a derived data resource it could create this...
Simon: we do not provide a way of specifying this ...
Norman: but we have the property ....
Simon: but I made that static ...
Norman: so the factory can choose whatever it wants so it could be an
externally managed resource...
Simon: so do we fault or just remove the WS-Resource?
Norman: my inclination is that you remove the WS-Resource else you are
stuck with it for ever ....
Dave: it's the kind of thing that they pick up on implementation....
Norman: they may complain if you can't remove a WS-Resource...
Simon: but the data resource does not disappear.
...
ParentDataResource:
"If this data resource is a service managed data resource this
property holds the data resource abstract name of the data resource
from which it was generated. If the data resource is an externally
managed data resource this property will be empty."
Simon: wrote this text with a mistake understanding - a factory
message can result in internally/externally managed resource so
just need to fix the text ...
Norman: could envisage created a service managed data resource out of
band.
...
MessageResourceMap: This is referred to in several places in the
direct data access part of the spec where I think the reference should
be to the MessageDatasetMap.
Simon: have 2 maps where they were used inconsistently that needs
fixing.
...
<RequestDocument/>
"contains the request expression. The structure of this document is
specific to the expression being used. The name of this element SHOULD
indicate the language used by the expression."
Simon: is there a requirement to change the WS-DAI?
Norman: change the WS-DAIR version .... the request has been split
over two top level elements ...
Envisage that the parameters are not the top level ....
...
Simon: moment have SQLExecuteRequest ... the WSDL is different from
the spec? ... has executerequest ....
Need to fix the relational text.
...
Collecting the major points of change at the end of the
message. Status is as in the message. WSDL and document
match. Can put a new version on Grid Forge if that is useful
.....
...
+-----------------------------------------------------------------------+
|Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. |
|Tel:0131 650 5141|mario at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ |
+-----------------------------------------------------------------------+
More information about the dais-wg
mailing list