Minutes of the First OGSI-WG Interim Meeting Argonne National Laboratories 4-6/Sep/2002 Attendees: Bhatia, Karan Czajkowski, Karl Fay, Dan Finkelstein, Shel Graham, Steve Grimshaw, Andrew Gunabal, John Karpovich, John Murphy, Declan Oinn, Thomas Savva, Andreas Snelling, David Tuecke, Steve Vanderbilt, Peter 1) Minutes from August 28, 2002 approved. 2) Agenda: - Set Agenda - Bugzilla Item Review - Discussion Topics A - QNames vs. URIs: 18, 33, 34, 32 B - Registry Discussion C - Discussion of Client D - Discuss the formal language aspects of serviceType inheritance. E - Are QNames resolvable?: 36 F - Absolute vs relative time: 13, 16, 22, 23 G - Add a generic setSDE operation to the GridService portType. H - Semantics of destroy I - Working Group Time line J - Change Management: 24, 25 K - Handles, Sameness: 17!, 26R, 27R, 28R, 29R, 37!, 38! L - Notification: X - Extensibility patterns: 34 X - Factory: 5, 19, 34 X - queryBy issues: 30, 31 X - Message id: 39 X - Does minoccurs=1 make sense: 40 X - Document walk through 3) Discussion Topics: A - QNames vs. URIs: 18, 32, 33, 34 Background: 18 Add gsdl:subscriptionExpression type? 32 xsd:float use is misleading 33 QNames as sole extensibility mechanism 34 Model FindServiceData(URI), CreateService(qname), Subscribe(URI), & RegisterService(qname) specializations... A qname is a URI plus a local name from within the namespace referred to by the URI. In this context, a URI is (possibly resolvable) reference to a namespace. The spec uses both. Is there a good reason to use both or should we have only one? There are about 4 places in the spec where this construct appears. The main goal here is to provide polymorphic arguments. What do we put in an SDE to describe content? URI, qname, other structure (input, output, comment). Resolved: For CreateService, RegisterService, FindServiceData and Subscribe we will use one extensibility argument. The service infers what to do based on the tag of the root element of the argument. (#34) Resolved: In the Service Data, for CreateService, RegisterService, FindServiceData and Subscribe, we put the qnames of the XSD element definitions accepted by the service. (#34) Implication: #33 is resolved as qnames are the sole extensibility mechanism. Implication: #18 is resolved that no second argument is required. Please submit written arguments to the contrary. B - Registry Discussion: Resolved: The RegisterService operation takes two arguments both required, a Locator and an argument that conforms to one of the qnames listed in its SD. There may be support provided in the SD for empty or complex required second arguments. Resolved: The RegisterService operation is a void RPC operation (with possible exception). C - Discussion of Client Clearly Clients are many things (e.g. Services themselves). "Initiator of exchanges" was proposed as a starting point (e.g. Requester). What about persistence? Services have Handles, Clients which are services will also have these. Part is also related to the binding, but it is not the whole story. It was also proposed that all entities including clients have handle. This discussion will continue on the mailing list, see actions below. D - Discuss the formal language aspects of serviceType inheritance. What we are talking about with respect to the specification we are only talking about interface. We could view it as syntatic sugar, but it may be more. The closest example is the Java interface inheritance plus the intent that the semantics are also preserved. The potential of name clashes was raised, but this is also true of WSDL 1.2. We should follow their lead. Discovery issues: There are issues related to how the client tests if the service actually implements the operations from the super-type. Should this information be included in the definition of the subtype directly? The leaning is toward no, i.e. walk the serviceType WSDL tree if necessary. Arguments for extends: 1) Inheritance in the interface expresses the designer's intent. 2) It provides support for discovery, "I want another one like this one." 3) Knowing that the semantics are inherited helps client tooling. 4) Complexity management. Resolved: The tree could be in the Service Data of the instance, but we will postpone this until later. Resolved: Extension by set union of portTypes with conjunction semantics. Resolved: The semantics implied by extension are based on the "isa" relation applied to all portType. Resolved: We will ask WSDL people for serviceType Extension (note extends not inheritance). E - Are QNames resolvable?: 36 Qnames have many uses: WSDL documents SDE's, XSDs, namespaces, .... At present we say nothing about the availability of these documents. Status within the XML community: XSI schema location = (URI1, URI2) => some information about URI1 can be found at URI2 (a URL). Resolved: We will rely on the implicit understanding that XML and WSDL resolution mechanisms exist and are adequate for our purposes. Resolved: For instance SDEs, where the service provider MAY imply that a name qname needs resolution, an gsdl attribute MUST appear. It should be fashioned after the XSI schema location. For structural SDE's, tools SHOULD ignore this attribute. F - Absolute vs relative time: 13, 16, 22, 23 #13 Use Measured TimeStamps #16 Should setTerminationTime be absolute or relative. #22 What if SDE lifetime attributes are not specified? #23 Expressing "forever" in SDE lifetime attributes Time is used in several places, setTerminationTime, etc. Currently, only absolute time is used. Resolved: There is no plan to support relative time (16). Resolved: Remove the client time stamp from setTerminationTime. Resolved: Add a current time SDE to the GridService. Resolved: No real notion of success or failure on setTerminationTime request (faults are still possible). Resolved: Retain the current service time stamp return from setTerminationTime (rename to currentTimeStamp). Resolved: Remove maximum extension from setTerminationTime returns. XDS supports a simple Date object. The GGF performance WG developed a spec for measured time stamps that included parameters for precision and accuracy. GSS used time for termination time, goodFrom etc. There are some complexities associated with using it as an attribute. Cost barrier of tooling was critical in the decision. Resolved: We will not use measured time stamps. If there is a way to create a simple derived type for measured time on top of Date, we should revisit this issue. (13) Resolution: With the inclusion of "forever" modelled by DateTime the SDE lifetime attributes, their absence indicates "don't know". G - Add a generic setSDE operation to the GridService portType. Background: Initial author's axiom, "state modification requires an operation". A set/get approach makes policy enforcement more complex. SD is not commonly thought of as a store, but rather a window/view of the service. Resolution: No set methods. H - Semantics of destroy Resolution: Following a destroy operation the Service SHOULD NOT respond to any further requests. Resolution: Following a destroy operation the Client SHOULD NOT rely on the existence of the service. Resolution: We will not attempt to test for death or non existence. I - Working Group Time line GGF6 will be a working group session rather than a public comment session or update session. Draft structure: Oct_01_2002 XML schemas, most current decisions, some cleaning on text Oct_13_2002 Working document for the WG sessions with tracked changes Nov_12_2002 All open issues resolved Dec_15_2002 Ready for insertion into the GGF process, with the possibility of doing a v1.1 The GGF process takes over from here. J - Change Management: 24, 25 #24 Loosen serviceType immutability statement #25 Version numbers vs immutable service description Motivation for immutability: Discovery, interoperability, ... Simple solutions (version naming, using the inheritance framework) raise problems with compatibility. Attempts to incorporate change compatibility in a version number or similar is not practical. Resolved: Retain the current language, but add explanatory text covering development time etc. (24, 25) Resolved: NOT to add a deprecated/superseded/mutable attribute/element to serviceType/portType with a pointer to the new version. NB: Deprecation is an inherited property and we have no propagation mechanism. Resolved: There was no clear argument for revisiting compatibility assertions in this version of GSS. Resolved: An instance's serviceType can only be extended. K - Handles, Sameness: 17!, 26R, 27R, 28R, 29R, 37!, 38! #17 Recommend client use of HandleResolver over direct resolver protocols #37 Does GSR need expiration time, GSH(s)? #38 unique service instance reference Background on #17: A GSH is a URI that implies the semantics of the resolver scheme (i.e. not necessarily protocol). Details in external specification. There is a Resolver portType, which a handle resolver MAY use to may a GHS to a locator, GSR, a referral to another resolver, or Hunnh? Handle resolver services can be outsourced. Resolved: This WG will put effort into the development of specifications of resolver schemes. L - Notification Background and issues. Communication outside the WS world, e.g. RMI. Needs include "Heart beat" through "Latest published paper". Significant application of negotiation required. Bookmarking from a given point in an event stream on. What is notification used for in GT3? Changes in Job status, monitoring GridFTP, driving workflow, Other protocols can be used by applying it at the binding layer. But where the endpoint does not support WS, it is out of scope for the spec. Higher level portTypes might be considered in the OGSA Frameworks WG (still pending). Resolved: This WG does not need to address QoS issues of a GridService at this time. The find service data mechanisms can be enhanced, e.g. through the query language, to wait until a state change in the service data. But this requires greater infrastructure in the implementation that had been isolated in the Notification portType. 4) Actions: Action: Steve Graham to derive a way to say (as a simple type) DateTime or "Forever". Action: Shel, Dan, Steve G. to check the complexity of deserialization of a DateTime or "Forever". Action: Steve Tuecke to devise language for qname resolution attribute in instance SDEs. Action: Steve Graham to drive the creation of an XML Schema for the specification, #35. Action: Steve Graham and Peter Vanderbilt to address #32 xsd:float use is misleading. Action: Thomas Oinn to summarize the meaning of the presence/absence of service data content. Action: Karl Czajkowski to summarize the meaning of returned states from RegisterService calls (follow up with Create Service). Action: Shel Finkelstein to write a working definition of Client and some case studies where QoS properties become critical. Action: Steve Graham to craft language for recommendations to developers for use of resolvers Action: Dave Snelling and Andrew Grimshaw to look at requirements and solutions for pull like semantics. 5) Open Issues: Not yet numbered: - What does a successful return from a RegisterService call? - Track the IPR status of WSIL. - Should WS-Inspection document (or other formats) be explicitly noted in the spec? - What assumptions can be made about the properties of a service resolved by a resolver? - Explore further the implications of subscriptions as Grid Services.