05/27/2003 9:49 PM
post4189
|
2002-08-28 TELECON
Minutes of the Forth OGSI-WG Teleconference
28/Aug/2002 @ 15:00-16:30 GMT
Attendees:
Tim Banks <IBM>
Karl Czajkowski <ISI>
Steve Graham <IBM>
Fred Maciel <Hitachi>
Andreas Savva <Fujitsu>
David Snelling <Fujitsu>
John Tollefsrud <Sun>
Steve Tuecke <ANL>
Peter Vanderbilt <NASA>
Shell? <Sun>
1) Minutes of 21 Aug 2002 Teleconference were approved as published to
the list.
2) Goals and Strategy for Face to Face meeting next week.
- 13:00 Wednesday Sept. 4th to 15:00 Friday Sept. 6th.
- The plan is that there will be no fee required (depending on
numbers).
- Wireless network will be available.
- Agenda will be based on existing list plus Bugzilla items (post
issues ASAP).
- We will consider crafting text for Handles, but straw-men before
hand would help.
- Bring your own hard copy of the GSS.
3) ServiceType Inheritance Discussion
As the WSDL group will meet in two weeks time, we covered the issues
surrounding serviceType inheritance so that Steve Tuecke will know
where we all stand (roughly).
The issue was not dealt with in detail last time because it was late
in the day, but the concerns as reported by S. Graham centered around
the question: Why not just cut and paste portTypes or use include
files?
The GridService community's argument is roughly:
- Inheritance in the interface expresses the designer's intent.
- It provides support for discovery, "I want another one like this
one."
- The server side implementation need not be OO, see CORBA approach
to C.
- However, this may have been one of the acceptance problems with
CORBA.
- Knowing that the semantics are inherited helps client tooling.
- Overloading was raised as an issue, but is already present
without inheritance.
Action: Steve Tuecke to write to WDSL working group asking that this
item be placed early on the agenda so people have time to think about
it.
Our serviceType inheritance means the transitive closure of both the
interfaces and semantics of all portTypes in all the serviceTypes of
the hierarchy, i.e the union. Note that it is like a set, i.e. no
duplicated portTypes even if they appear in several constituent
serviceTypes.
If they ask what we plan to do if they don't include serviceType
inheritance, our position is that we will do it ourselves by
extension. We will note that so will others, as it will be a very
useful extension. We should stress the standards issue as part of the
reason for doing it.
If they decide not to do it, we should press them for clear a
justification to pass back to the Grid community.
Item for next week's agenda: Discuss the formal language aspects on
what we mean by serviceType inheritance. This should help with the
WSDL meeting as well as clarify our own thinking.
4) Technical Discussion: Registration portType
Background: The Registration portType provides a method for a client
(in this case usually a GridService) to notify the GS implementing
this portType that it exists and has a handle. This portType will be
common on any GS acting as a registry, but may also be implemented by
other services. What is done with the Handle and any other information
about the registering GS is up to the implementation. [Note: I use the
term 'registry' below for a GS that implements the Registration
portType. It may not have all or any of the functions we normally
associate with a registry, but this will aid the discussion.]
The questions are then:
a) Do we bind, in the specification, the service data describing
the content of the registry to this portType?
b) If we do bind it, is there at least one (minoccurs=1)
mechanism/format for describing the content on the registry?
c) If yes, is that format a WS-Inspection document?
It was clear from the discussion that a "document only" approach
presented a problem for very a large registry with millions of
entries. Some form of...
View Full Message
|
|
|