Minute of from SWSA Telecon of 13 May 03


Mark Burstein, Mike Dean, Tim Finin, Stuart Williams, Fabio Casati, 
Carole Gobel, Chris Bussler, Michael Kifer, Massimo Paolucci


We started out discussing the draft committee mission statement. 
This quickly led us to discussion on different ways of approaching
architectures for middleware agents to support matchmaking and
registration, and how our scope should be much wider than these issues.


Tim proposed we develop a set of APIs for (e.g.) registration. Others
contriguted other examples: lifetime service support, discovery, testing
for existence (heartbeat), deregistration. We briefly touched on the need
to come to a shared understanding with the language committee on our role
wrt language vs architecture for such issues. That is, should SWSA be using
SWSL service language products to construct APIs for key middleware
services? We think yes - especially to the point that we should use a
semantic services language to describe these APIs. We must still decide the
extent that we focus on APIs as opposed to defining architectural elements
and layers.


We discussed how matchmaking would potentially be different when in a
Grid-like environment where there are many similar instances, with
potentially different resources/workloads/quality of service rather than
very heterogeneous services.  An API we might want to develop as a result
of a Grid use case would be a heartbeat protocol. This is an example of a
long-term coordination protocol that must be agreed to.


Grid also must deal with other aspects of long term service existence, the
use of service factories, which themselves are services, and the alternate
models of such factories as middle agents that stand for and mediate
communictations with the services they spawn as opposed to ones that spawn
services as needed that communicate directly with clients - possibly only
one client, and then go away or are put back in a pool. Factories are also
potentially responsible for GCing services.


In some cases, instances will not be advertised as services - e.g. short
term, single transaction service.


Security issue wrt service factories:
Who has access to the handle?  (I forget what the issue was here)


We agreed that we should describe protocols for architectural support
services in a semantic service description language, such as produced by SWSL. 


Massimo noted the difference between matchmaker and facilitator - Carole
pointed out that there are philosophical differences in how they are used,
but that both are possible in Grid.


We discussed the need to develop use cases outlining the need for
architecural components over the whole lifecycle of agents or processes
involving communities of agents. This includes registration, advertisement,
discovery, contract acceptance or denial, heartbeat monitoring, status
monitoring, death, substitution of service agents.


A detailed example might look at state of the interaction with the
server. - can you backtrack or shift servers?  Can the service support
compensation protocols? How does this change when compensation involves
third party services?


We should identify the lifecycle elements in each of our usage 'domains' -
Grid, Pervasive, Web, Agent


Mark: We need to focus on where does semantics contribute to each of these
to distinguish from other agent and web service definition efforts. Also
mentioned that we need to keep in mind the role of semantic translation in
each of these cases. (Still trying to finish a paper on this topic.)


Carole talked briefly about her work with the Interoperable Informatics
Infrastructure Consortium (www.i3c.org) and the fact that they are also
collecting use cases we might make use of. She has mentioned SWSA to them.


A number of people are going to WWW so we are probably not having a telecon 5/20
(and, indeed, didn't.)