Minutes of the OGSI-WG Teleconference
14/Aug/2002 @ 15:00-16:30 GMT

Minute taker: Steve Tuecke

Attendees:

Tim Banks, IBM
Edward Boden, IBM
Steve Graham, IBM
Fred Maciel, Hitachi
Andreas Savva, Fujitsu Labs
Frank Siebenlist, ANL
Steve Tuecke, ANL
Peter Vanderbilt, NASA Ames
Mike Williams, IBM

--------------------

1)  Approval of minutes of GGF5 sessions

http://www-unix.gridforum.org/mail_archive/ogsi-wg/msg00404.html

Approved

--------------------

2)  Approval of minutes of August 7th call

http://www-unix.gridforum.org/mail_archive/ogsi-wg/msg00407.html

Approved

--------------------

3) Technical discussion: Change management

   Change Management
      24 Loosen serviceType immutability statement
      25 Version numbers vs immutable service description

Steve Tuecke: Overview of the change management problem.

Brainstorming options for expressing (in-)compatibility
  a) Steve Tuecke: Current draft uses immutable names

     * Clarify this with language about "immutability" and putting it
       in the wild (Pete has suggestions on language here). Need
       language that talks about the ability to communicate changes to
       all possible interested parties
     * Tim Banks: Do we want a timeout on the serviceType, just like we
       have it on a service/GSR?
       - Is this just a social process?
       - Or is there some mechanism that helps in that social process, by
         allowing the communication of such serviceType timeouts.

  b) Tim Banks: Instead of compatibility assertion statement, consider
     a deprecation statement, similar to Java.  So the only change
     that can be made to a serviceType is to add an element that
     refers to another serviceType that deprecates this one.

  c) Steve Tuecke & Steve Graham: Version numbers
     * Include a version number in the serviceType
     * Probably need to define relationships between version numbers,
       such as ordering & (in-)compatibility between versions.

  d) Pete Vanderbilt: Use serviceType inheritance to represent backward
     compability.
     * Can end up with long chains over time
     * Cannot represent various forms of compatibility, such as
       extensions to operation parameters, or additional operations in
       a portType.

Pete Vanderbilt: What about service element mutability?

  * Can a running instance, in mid-stream, change its WSDL service
    definition to implement a new serviceType?  What are the
    compatibility implications? Options:
    1) New serviceType MUST be backward compatible with old
       serviceType.  Then client does not have to worry about these
       changes. 
    2) Leave it to the offline semantic definition of the
       serviceType. That is, serviceType semantics may or may not
       require that any new serviceType that replaces it in the
       service element of the GSR be backward compatible
    3) Have a syntactic extension to WSDL to express #2.
  * Implementers of the same serviceType may want to make different
    decisions about this.  This might imply #3.
  * A client would be able to see a change in serviceType by checking
    the service element in the GSR whenever it gets a new one

Pete Vanderbilt: Can a serviceType make statements about the lifetime
of any instances that implement that serviceType?  
  * Steve Graham: Probably not. We would need to see a use case.

Note: Treat serviceDataDescriptions the same as portTypes, with
respect to compatibility.

Brainstorming on requirements on compatibility:
  a) Change serviceType on a running instance (service element
     mutability)
  b) Make a backward compatible change to a parameter of a particular
     operation, for example to add a new option or extension without
     changing any existing options. (Note that this can be done either
     via extensibility elements in the parameter, or via XSD complex
     type extension.)
  c) Add a new operation to a portType, without changing or removing
     any existing operations in...