Minutes of SWSA Telecon of April 13, 2004

Mark B, Mike H., Amit S., Kunal Verma (UGA), Andi E., Tim F., Stuart W. 

Tim will do the sec & priv by next week. 
Mark will ping Carol about lifecycle section. 

MB: Question is do we want to add more structure like Mike H did in the
negotiation section - separate out architectural reqs from functional ones?

Mike H. Idea was to say where components or middle agents COULD participate
in a service.  There are some protocols that are independent of
implementation

Mark B: It often helps to thing of the middle agent case to make clear what
the protocol and ontology issues are - the middle agent then has a specific
function and the semantics needs to be explicitly conveyed to that agent. 

Tim: The protocols we design should support lots of architectures.
There should be a way for an agent to ask: what services do you provide? 
- add a way for a new middle agent to ask - please send me all your adverts. 

AS: There is also related work on federated uddi registries. 
(sent pointer by email msg: Here is some work on Federated UDDI Registry:
http://lsdis.cs.uga.edu/lib/download/MWSDI-ICWS04-final.pdf
This is accepted to be presented as Intl Conf on Web Services in July.)

Mark: Say more:

KV: - Peer to peer network where each registry is enhanced by federated
catalogs.

TimF: you send a query to me, I send to confederates who reply to me or
directly to you - those are the standard possibilities.

TimF: We should define 
peer to peer and centralized middle agents as two counter weights.
- define some of the requirements as relevant to one or the other. 

Be explicit about the ontology sharing across different architectures.
MB: moving to  enactment
AE: same as discovery - mediation and delegation factored out 
MH: choreog aspects managed by third parties. 

MB: Service Delegation should be separated out from Process Mediation?
(answer: Yes)

MH: Process status monitoring - add something about logging as a separate
function. 

TimF: Many scenarios may require a protocol that includes soliciting
additional information. eg if a client describes requirement, server may
ask for clarification or additional info.  

TimF: Define a protocol to allow for subdialogs at various
points.  add a separate top level bullet at least.

MB: For discovery, this could amount to asking for additional
discriminators.  


Community support

MB: This section needs to be more filled in (by me), but refers to middle
agents that can support community functions like membership, reputation,
ontology and mapping distribution and maintenance, and policy/protocol
control and distribution. The Ontologies supporting these functions are
important shared resources.

TF: Semantic certificate service (notary kind of service)
determining citizenship - outsourced to a trusted service. 
- providing semantic evidence to prove qualification for membership

Analogy to a semantically enabled notary agetn. 

Reputation servcies as historical repositories with interesting semantic
messaging - why/when did things break? In what way did they break?