[dais-wg] Minutes from the DAIS telcon on 13/04/05.
Mario Antonioletti
mario at epcc.ed.ac.uk
Wed Apr 13 05:39:42 CDT 2005
Hi,
Simon beat me to it :-(. Minutes from yesterday's DAIS telcon.
Mario
+----
DAIS Telcon - 12/04/05
======================
Chair: Norman Paton
Note Taker: Mario Antonioletti
Attendees:
Mario Antonioletti, EPCC
Thomas Soddemann, RGZ
Norman Paton, University of Manchester
Savas Parastatidis, University of Newcastle
Susan Malaika, EPCC
Allen Luniewski, IBM
Simon Laws, IBM
Dave Pearson, Oracle
Agenda:
Mappings of DAIS Specifications (Discuss
Proposal from GGF13 Session 2)
Actions:
[Simon] Post note to list on refined GGF13 proposal and relationship to
mapping approach (4).
[Norman] Seek to ensure that relevant OGSA/WSRF people are following the
process.
---
Start with a top level discussion about options and gradually progress
to discuss the GGF proposals that has been posted to the list. Then
discuss on how we proceed.
Start from the postings made to the DAIS mailing list:
http://www-unix.gridforum.org/mail_archive/dais-wg/2005/04/msg00003.html
Also:
http://www-unix.gridforum.org/mail_archive/dais-wg/2005/04/msg00001.html
http://www-unix.gridforum.org/mail_archive/dais-wg/2005/04/msg00002.html
Hope to reach a resolution by discussion and consensus.
There are four possibilities for DAIS:
1] Use WSRF for all types of resource.
2] Use no WSRF at all.
3] Use WSRF only for some resources.
4] Use a twin tracks approach.
Mario: At GGF WSRF seemed very credible but there was no major opposition
present.
Norman: but the conclusion was not to use a WSRF only solution - (3)
seemed to be the preferred option
Susan: I had a very extensive discussions with Savas before the meeting
to take his point of view into account.
Savas: ... but my twin track approach was not really discussed.
...
Norman: For (3) is it desirable to have a subset that is only
dependent on WS-I?
Susan: is that the conduit only bit?
Norman: suggesting the mapping into portTypes that Simon described is
not necessarily the one that we would use. In approach (3) we
have: three type of resources and their mapping to services
..... the type 2 would not have a mapping to WSRF.
Susan: if this will make more people use it then that would be a good
approach. As long as it does not make it any harder to write
the spec.
Norman: There will be a core spec that will only provide access to
type 2 resources and another one that does all 3 resources.
Mario: what does that do to interoperability?
Norman: In the core all type 2 implementations would be
interoperable. There is only one way of doing each thing. You
then need to know if you are talking to a resource that
implements part of or the full specification.
There seems to be tentative support for having a section that
only has WS-I dependencies if it will get more people on board
who might not use the spec otherwise. There are some UK
e-Science projects that fall under this category.
Mario: what about Microsoft and Oracle?
Savas: a core that is not dependent on WSRF will make it more
palatable for companies like Microsoft and Oracle.
Susan: At the second DAIS session in GGF13 we had OGSA and WSRF people
in the room. The key point that we got across was that DAIS is
not representing some of the resources in the database or
managing them - but is about providing access to these. So,
that's why they agreed that not everything could be represented
by WSRF. I did not think though that a particular solution
came out.
Norman: but a proposal has gone out. Services to represent type (3)
resources are identical to those in DAIS. In type (2) the
naming scheme is in the body and does not use the WSRF
lifetime management - resource names are in the message body
and WSRF lifetime management is not used
Savas: if this group accepts the fact that there are going to be two
worlds out there - a core WS world with which everyone is happy
with and extensions that not everybody is happy with, then the
functionalities that use these extension that are not
implemented will simply be lost. What if there was an approach
if everyone had access to this functionality in a different
way?
The idea would be that all the functionality that DAIS wants to
make available is done only with the WS-I based specifications
with the proviso that there would be a route for WSRF for those
wanting to use WSRF.
Norman: does that not raise interoperability problems?
Savas: yes, but if the functionality is there then that will also be
a problem ....
Norman: let's push on the GGF 13 proposal and then you can detail a
mapping for possibility (4).
Susan: If we go through Simon's note:
http://www-unix.gridforum.org/mail_archive/dais-wg/2005/04/msg00002.html
The scenario is where you say he conflatated the two portTypes.
There are some service templates - you would get properties of
the service conduit and could get information about the resources
that would come out of the CIM model.
Norman: only in the relational case.
Susan: as they have not done XML yet. The split then is quite natural.
Then you have the messages targeted at the conduit portion,
you have all the properties, you can destroy the conduits. You
can have messages targeted at the resources themselves and you
can get the properties and you have an SQLExecute with messages
targeted at a service. Then there is the ability to create a
result set rather than execute the query and then there is a
generic response ... those are the operations for the combined
conduit and resource type 2 resource.
The second type of service would expose the properties of a
rowset created by the previous portType. You would then have
messages to get access to the resource set.
Then there is a scenario to use the services. Can deploy,
configure, get the properties, the data, get a results set.
Finally there are some points for further discussion.
You can model the type 3 resources under the conduit as type 2
resources. Things could be laid out differently.
Can express properties of the conduit and capabilities over and
above the WSDL.
Norman: in essence the properties of the conduit help what task -
service selection?
Susan: could put info in a registry and ask questions of the service.
Norman: it could expose properties of the underlying resources and the
service
Susan: in the proposal to the mailing it would, as it combines the
conduit with the resources. If you were to split these then
that would not be the case.
Norman: if someone wanted to use a resource you may ask questions of
the potential interaction they could have with that service.
You could also ask questions about the underlying resource.
You could interrogate the resource or you could use a
registry. The conduit has local metadata properties of that
conduit - like a local registry. When you have metadata from
the local resource or somewhere else there is also a question
about the coherency and quantity of the metadata available
....
Susan: in the spec you would have to be very clear. if you split this
then you might only get the appropriate metadata from a single
source ....
...
Susan: the points raised is that when you create a result set you
could give it to the database to manage or you could give it to
DAIS to manage. In the first instance you will give it to DAIS
to manage.
We have a document with many resources ....
*Simon joins*
Susan continues going over Simon's point for discussion.
...
Norman: the suggestion that one has separate portTypes for type 1, 2
and 3 resources.
Simon: not trying to imply that all of these messages would live in
the same portType.
Norman: there are 2 things we would like to clarify:
which information is available from a type 1 resource and how
that compares to what is available through a type 2 resource.
Is it the complete set or a sub set?
Separating type 2 and seeing if there is felt to be support
for a proposal to have a subset that does not have the WSRF
dependency if that increase the number of adopters.
Simon: type 2 does not have a WSRF dependency at the moment.
Norman: the proposal is slightly more lumping rather than separating
at the moment.
Simon: you would like to see what the portTypes look like?
Norman: yes
Simon: that is reasonable.
Norman: So, Savas wanted to make an approach to mapping approach 4.
Savas: it's not exactly sharing messages. The proposal is very similar
to how execution services are being designed - work being done
by Steve Newhouse and Andrew Grimshaw for submission at the
next GGF. A service is a container of resources. The approach
they are taking is that you talk with a service and the
resources are named. You use abstract name for the resources
and there is a way of resolving those names into WSRF EPRs if
you want to and from then onwards you can treat the interaction
with the resources as WSRF. However, the service also supports
interaction that do not require WSRF.
In DAIS there would be no need to distinguish between type 2
and type 3 resources.
Norman: so you could send a messages to a data service you would send
a SQL query with an optional abstract name and you could
optionally get the EPR and use that afterwards ...
Savas: ok, so you are assuming that many data resource could be
accessible through the services. You could send the SQL
statement and then you could send an abstract name. You could
ask for the results to be kept at the service and the you could
do things with those results kept at the service. If you want
to manage the lifetime in a WSRF way, the service will support
a resolve method the abstract name can be converted to an EPR.
Simon: I've talked to Savas as well so I have an understanding of his
method. The resolver could sit happily on service A and provide
that type of functionality. The question pushes down on the
things that people talked about that were WSRF specific that
could be pulled into the conduit. Savas is saying that
everything could be pulled under the conduit. We would have to
make sure that the lifetime was covered.
Savas: for the non-WSRF you would need to define explicit lifetime
messages.
Norman: questions like how do we construct message bodies that type 2
and 3 looks pretty consistent in the GGF13 proposition would
come up against issues that are very like this. The GGF 13
proposal is something rather like Savas' proposal but where
you are told what to use for a particular resource.
Savas: I'm saying that the functionality will be the same but you will
have to provide something in DAIS that replicates WSRF
functionality.
Norman: I think we are on the same page.
The pros of this approach is that everyone can use whatever
they like, have different capabilities.
The con is that individuals implementing the DAIS specs end up
with two routes in and we have to decide which ones are
optional and mandatory. There is then a case of publicising
this to a potential client.
Susan: are there considerations for naming?
Simon: we need to know how to write or handle names in both cases.
Norman: My feeling is that the the blend of mapping approach 4 and
mapping approach 3 are not miles away from each other. It's
just approach 3 has a MUST which is not in approach
4. Approach 4 gives you an alternative ....
Savas: as a result it allows those that do not support WSRF can now
implement the spec.
Norman: inching towards a smaller decision. Can discuss this with
stake holders. How do we proceed?
Susan: need to do a sketchy write up.
Simon: can add Savas' model to this ...
Susan: would you have alternatives or options?
Norman: it is reasonable to put both these options into the same
document - given that you have these collection of switches
you can use whichever you want or you can pre-set those
switches.
*Dave Pearson joins*
Norman provides a brief summary for Dave.
Norman: did you have any views on the proposal?
Dave: still struggling with what interoperability between WS-I and
WSRF is?
....
Savas: if you implement a service with only WS-I everyone can talk to
you. If you use WSRF then any extra functionality then you can
only use that if you use WSRF. That is not to say that WSRF
does not comply with WS-I.
....
Dave: my view is you use WSRF, mainly for result sets, because it is a
data resource and the database is a WSRF resource then you are
saying you use WSRF only full stop.
Norman: if you take the proposal that was circulated strictly as
described you are using WSRF. A small modification would
involve separate portTypes for type 1,2 and 3. This allows us
to pull out type 2 so that it only has dependencies on WS-I so
that you would not have need for WSRF. You would however not
get the factory pattern
Dave: what are the implications on tooling? How will the tooling know
whether you are interacting with a type 2 or 3.
Savas: in what I suggested there is no distinction between 2 and 3 it
will all look the same. If semantically you try to send the
wrong message then that will be dealt by the
implementation. This could also be applied in the WSRF case -
no distinction between type 2 and 3.
Norman: yes, they could always be represented the same way.
Savas: to move forward we document this but we need WSDL - happy for
the non-WSRF to case to work with a simple implementation to
test the idea to see what the portTypes look like.
Norman: very happy for people to do experiments.
Dave: provided there is a time scale ...
Norman: trying to progress quite rapidly. The next call is in 2 weeks
on this topic.
Savas: offered to get together with Dave Snelling to discuss this.
Norman: That would be very useful.
Simon will adjust the proposal to incorporate Savas' ideas.
Simon: produce a new one - leave the other for historical reasons.
Norman: then pass that out to the list. Once that is done then we can
discuss it. We should also explicitly bat a reference to that
proposal to the OGSA list for discussion.
Dave: the time to bat something the OGSA list when we are confident
about things else the control may pass over to the OGSA list.
We should get the OGSA team.
Norman: will try to invite comment from a smaller set of people.
Hopefully these things can be done quite quickly and then
widen the discussion. Savas raised the issue about having a
meeting in London.
Simon: happy to contribute WSDL to that effort.
Dave: what if Savas and Simon do some work and if it's not possible
in London to set up a web conference or AG?
Savas: we could do that but its replication of effort.
...
Dave: if you are going to have a meeting in London, let me know and I
can arrange for an Oracle office to be used.
+-----------------------------------------------------------------------+
|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