Minutes of SWSA telecon 9/16/03

Mike Dean, Michael Kifer, Chris Bussler, Mark Burstein, Carole Goble
Tim Finin, Massimo Paolucci 

Agenda:
Status of Use Case development. 

Grid Use Case:

Carole is working on a BLAST use case - classical bioinformatic
service. Hopes to have a draft in the next two weeks. She has talked to
David Snelling talked, who is enthusiastic to contribute.  She sent 2 docs
to the mailing list - two counter arguments.  (Mark B will put them on the
website.)

Ubiquitious Computing

Tim F. has collected material to draw on, but has not put it together
yet. Hopefully first cut by next week.

B2C: DAML-S vs Web Services Architecture Cmtee model:
Massimo P. says he will have first cut next week. 

Chris B, Stuart W - B2B, B2C
Focusing on the semantics of the interaction, not on discovery. 

Mark B. briefly described WISE paper on translation issues. 

TimF commented that the translation involved in discovery suggests an 
architectural assumption: matchmaker return complete description, 
so that more refined translation could take place for final service selection. 
Mark B: That is the current DAML-S model. 

Discussion about Service Discovery: 

In human world - yellow pgs, then more research, then dialog with agent
itself.  By analogy, architecture should envision protocols for asking
questions of potential service provider. Further out on a roadmap?  Does
SWSL contemplate this kind of protocol?

Potential issues involved in this kind of "service interview" dialog
Reasons why matchmaker couldn't do it:
- Use restrictions based on who's asking for the service (issue in Ubiq Comput)
- Scheduling issues: time at which service could be provided, or time to complete
- Content issues: Specific information available from the service at a particular time
   (changes too frequently to advertise)

MB to Chris: Matchmaking not an issue in current B2B?
Chris - contract is completed outside the environment, then environment
takes over with dictated protocols. 
- other reason is closed (small) marketplaces - process of admission puts down rules, type
of payment, protocols, bidding is more automatic.

Small closed markets. -- spectrum of services limited

Car industry - parts very standardized, few suppliers. No trust issue. 
Big vs small - Walmart dictates contracts. 
Negotiated price changes part of contract, so not much dynamism even there. 

Translation is the big problem that makes them interested in SW

Updating semantic models/translations dynamically could be an area to push
SWS (rather than published changes every 6 months.

RFQ process with constraints & protocols is another potential area for SWS> 

Carole:

In Grid, somewhat similar situation: only certain suppliers of critical
processes. Those providers act like "big guys", scientists have to go
along. Changes to APIs can happen without notice, other things that impact
how you use it. No automatic way of accomodating the changes. One of the
reasons for interest in semantically described/published use models.


Contract negotiation, when discover, use depends
when operate on metadata more frequently (provenance, credibility)
How to configure, what format for data, 
metadata used by machine vs metadata used by people. 

Translation services as "experimentally neutral" vs services 
with exact same algorithms, configuration, performance, 
which version of the algorithm. 

What it DOES generally is the least of the problem. 

CG: Dichotomy between CORBA model and service model - big battle in GRID, 
Snelling could help out here. 

Chris: WSDL being forced to look like distributed object world, but doesnt
fit. - see java as specification, not WSDL.

Tim: might think of two different classes where SWS could be useful
- a lot of services to chose among 
- (also pervasive) 0, 1, 2 available, 
 - e.g.  portable device for finding hotspot web access services. 
-> impact on architecture, kind of components. 

CaroleG: In Grid, small closed world, matchmaking not too useful. Small amt
of metadata knocks out most, then can hold onto small set of useful
services for given class of problems solved by particular researcher (few
may change but always few real candidates).  She has toyed with just having
a pool of frequently used services in a GUI for semi-manual composition.

Chris: Cache of repeatedly useful services. 

Tim?: Can we classify static vs dynamic situations where need to find new candidates each time?

Carole: In grid world, some classes of  new services only show up occasionally (e.g. databases)
But matchmaking used for scheduling "Current set of resources"
- This is classical GRID, similar to UbiqC. Main example:
Condor-G has resource scheduling metadata, computation lasts for several month. 
Uses 'Classified Advertisements' - has a model of resource schedules, 
matching algorithm. - Knows if memory capacity is sufficient. 

Next week: Review first drafts of some Use cases.