Minutes of SWSA Telecon of March 2, 2004

Andi E, Chris B, Mark B, Mike H, Massimo P, Carole G

CG: <something about WS-Agreement was lost>

CG: WS-RF (resource framework) is a new model for grid (IBM led activity thru globus aliance)
addresses:
state
lifetime mgmt
reducing ws to set of patterns/idioms

MH: Its a way of making computing services into web services
when you do that you are interested more in Qos than functionality

CG: interested in both,
dynamic provisioning - fronting resources to fulfill a contract 

CG: The model covers any resource, not just cpu cycles, but may include
storage, database, algorithm could be bandwidth

CG: I could find some reference to QOS in grid - found in distrib & parallel
computing. "What's in a service" 2002 by Justin O'Sullivan.

Boualem B  referenced it ins paper on QoS for WS composition. 

<something about WS-context>

CG or MH: Where does OWL-S talk about QOS?

MP: In the profile you can talk about QoS, but that's about it. It needs to
be addressed further.

MB: Modeling QoS certainly has an affect on negotiation. 

CG: What we ended up with on the question of 'what is architecture?'

The context for us was a set of services - end up with a bag of services
and no arch. We were completely scenario driven.  We devised completely
different models for software management & deployment views - integrated
from the view of deployment scenarios. We used the different views to
communicate with our biologists - what would be the core services - what would be
running to meet a particular scenario.

The question of how to integrate across them is difficult. You end up
diverging if you are not careful. 

AE: The key lesson is to be scenario driven. 
CG: It kept our feet on the ground - we camp up with interesting semantic issues. 

Problem like qos, licensing. In GRID, we don't have problem with finding the service,
but with enabling licensing.

AE: Without scenarios, it is easy to focus on the wrong problem.

CG: We worked on maintaining a provenance trail - as you executed the
workflow, it is important to have this trail for restarts and user assisted
adaptation.

CG: What they are really interested in is a knowledge template that is the
result of 35-40 services.  If you put a gene into the workflow, run for a
while, lots of intermediate results, then get result saying gene is related
to some nucleotide. What they want is the end relationship. They don't want to
know the process, what elements were searched.

(MB: They might be interested in the latter if it failed.)

CG: We found it useful to explore different perspectives. 

Helped to explain things to people. Hard to describe, describing different things
deployment, functionality, etc. 

CG: Worked 3 Scenarios from user perspective.  Most helpful was how people
used these things.  One problem was having identical services with different qos
in different places with different runtime constraints.  

Biologists really care which DB was used. but there may be 40 copies out
there.  If one goes down, want to suspend and resume elsewhere. This causes
havock with the provenance trail. We hadn't anticipated this.

Fell under the rhetoric that web services are reliable. They're not.
Network crashes, interface changes, unobtainable services. BLAST changes
its specs all the time.  We are working on a taxonomy of errors. The MIT
Process handbook was a useful resource in this context.