Minutes of SWSA Telecon of 12/23/03

Mark Burstein, Mike Huhns, Chris Bussler, Carole Goble, Massimo Paolucci, Mike Dean (joined at different times)

MB: Topic is discussion of requirements for our SWS Functions from the list
at http://www.daml.org/services/swsa/sws-functions.html One question is how
we will address the distinction between 'within agent' requirements and
those of the infrastructure. E.g., in discovery the client must be
structured so as to have explicit objectives that are not 'hard wired'
within its program structure, and be able to compose queries describing
those functions or desired effect in a general fashion to find candidate
services to fulfill them. The queries must delineate the type of service
and any operational constraints that the client has on their performance
(or on the generation of a request for such performance).

MH: WRT the three bullets you have on the list for advertising, matchmaking and selection 
(generation of adverts, service discovery, selection) 
Do they cover third party generation of descriptions of web servcies? 

MB: I'd be cautious about third parties describing services they don't
provide, but perhaps ones that act as mediators/brokers (like AMAZON as a
retail sales broker, or a travel agent) and act as a unifying front end to
some third party services qualifies under this banner.

CB: For example, there might be a worldwide travel agency, but a middle
agent using that service only does Europe.

MH: Also, lots of hotels have descriptions that are not consistent, so there are web services that 
unify them under a single service model. 

MB: Agreed we should make a 4th bullet for middle agent service adverts. 

CG: In grid, negotiation with the broker can be quite complicated Resource
broker can do a lot automatically - but it can be quite complicated. They
manage compute cycles, worry about whether the are the code binaries there,
check software environment capabilities, etc.  The broker also does assembly of
services to accomplish composite functions. 

Another set of services are more like web services - user is looking for a
large application (e.g. db or replica of db) - very specific to the
scientist - and a detailed negotiation with the scientist takes place to
ensure that the service provided is correct. Uses web portal with mixed text/structured descriptions. Applies to both 
specific dbs and pre-configured
workflows. Descriptions in NL for the scientists, data formats, etc.

Interesting at the moment are 'dark matter services' - transformers,
managers of databases - more interchangable. Broker can decide which
replica is available at the time. Broker will schedule front end transformers and
filters as necessary.

Editorial in IEEE Internet Computing on 'dark matter' - things
you need to string together servcies. (Oct 02?) Will forward the article.


Massimo - We should try to figure out the functions and the see who might do
them in different architectures.  Then we can show different architectures - UDDI,
GRID, UC using Brokers

MB:  I will draft a list. Some of these may be more difficult. Negotiated contracting, for example. What is the 
semantic requirement associated with non-repudiation? 
Carole:  Digital sigs, determining whether what was said was true. 
MB: Also means of determining whether what happend was consistent with a contract. 

CG: Might cover Negotiated service contract change.  
- bogged down if services can change underneath 
- then what happens? How do you know that the services are interchangeable. 

In an architecture, we need some kind of provenance service. 

MB: Send along ref to paper on annotation service by L. Stein (mentioned at WISE'03)

Admin: We will try to have a late meeting on Tues Jan 20, 04. Mark will check that this time works for new members. 
Next meeting Jan 6, 04 at regular time. 

Happy Holidays.