OGSA Teleconference - 9 August 2007
===================================

* Participants

  Hiro Kishimoto (Fujitsu)
  Andreas Savva (Fujitsu)
  Chris Kantarjiev (Oracle)
  Steven Newhouse (Microsoft)
  Donal Fellows (UMAN)
  Steve McGough (Imperial)
  Bahareh Rahmanzadeh

  Minutes: Andreas Savva

* Minutes of July 26 approved with no changes

* Action Item review

>  AI-0511b: Michel to pull a workflow strawman proposal together

  Need to confirm that this is still a valid action. 
  [Confirmed at F2F that this is paused.]

>  AI-0614a: Steven Newhouse will check whether Windows Workflow can
>           also be used with CCS / BES style services

  Done. Closed.
  
>  AI-0614d: Steve McGough will compile the list and put it on the
>  wiki

  Ongoing.

>  AI-0614e: Steve McGough will look for the workflow material 
>                 from the Berlin GGF

  This is input for this work. Closed this action. Andreas will add
  note to action AI-0614d that it should be used as input.

>  AI-0726a: Show typical/existing use cases for cyclic
>            dependency declarations
>            (spawned from AI-0508a, owner unspecified)

  Unicore design probably has good input for this
  Talk about it at the F2F. 
  [Confirmed at F2F that this is paused.]

* Workflow discussion (Steve McGough)

>   - Re-focus of activity discussion
>   - Covering action points
>   - Best practices discussion
>     - - Systems to discuss and who to research
>     - - Scope of functionality to discuss
>   - How to provide support for workflows in the Grid (as mentioned
>     before we may postpone this till we know more from Best
>     practices)
>

Recap of last call's discussion and general difficulty of doing one
more workflow language and issues of acceptance, etc.

The current proposals are 
  - Community practice document
  - Make sure that workflow language can be used with OGSA.
    In other words, invoking ogsa style services.

A new proposal is that the focus should be at integrating workflow
at the service level (web 2.0 style for example) and the internals of
the composed services are just a blackbox
  - Anyone 'diving' in to the 'black box' has to deal with the
    proprietary nature inside. It is not possible to deal with all the
    different ways people have done workflow and do grand unification.

    Two examples were given, a BPEL approach might use complex XPath
    to manipulate elements (UCL); and the MS experience again shows a
    different way of doing it with its own set of complications. It
    would not possible to easily compose inside the different
    approaches.

Agreed that grand unification is not a goal.

(How about special cases such as parameter sweep where the 'units' are
workflows? Not a focus at the moment.)
  
The requirement for the new proposal would be that a workflow composed
service should be exposed as a service

Agreed that a community practice document is probably still a good
idea, to understand what is needed:
  - what is used; how it is used; what the problems are
  - focus on what we want to know: how to allow the further
    composition; and security issues (delegation)

Security is one requirement that is needed for things to work from an
architectural point of view; especially for cross-administration
scenarios.
  - What is the Windows workflow security system? It is whatever
    windows platform supports, e.g., user name/password, etc.
  - Workflow as service / workflow as activity: something to keep in
    mind when asking questions to people
  
Agreed to work on the survey. People agreeing to give some time to
this work:
     Steve McGough
     Bahareh Rahmanzadeh
     Andreas Savva (limited time)
     Steve Newhouse (on criteria, etc)

Steve McGough to do initial questionnaire [this was done at the F2F]

Discussed and agreed that the survey should be open to all who want to
respond. Some further selection is probably needed for further
drill-down and to make the document more useful. 

Proposed two separate documents:
  1.  The entire set of questionnaires 
  2.  A selected and refined subset that is more useful for
      identifying architecture requirements

Further brainstorming and updates to the wiki:
  - Security model
  - Service or task oriented
    - Ordering relationships or tasks
  - How composition with other workflows is done (is it possible?)
  - Large data transactions
  - Process dependent or data dependent

Agreed to swap workflow and general session