Minutes SWSA Telecon of of October 7, 2003
Chris, Boualem, Michal, Massimo, Tim, Mark.

Topic: Description of Boualem's Use Case (forwarded again during the telecon)

- use of state machine-like model for protocols, extended with temporal constraints 
(e.g., time out can change state) in order to model compensation, resource locking. 


Could concievably use petri nets. 
Wanted some thing very simple

When you are in a certain stage, allowed to do some things and not others. 

Need to model committments as outcome (state) of operations. E.g. response to PO

Service should be self describing. 

Tim: Relevant would be Munindar Singh papers on committment in agent communities last couple
years (in AAMAS) - Tim can you provide refs?

Tim: I have found in the past that Petri nets nice theoretical, but practitioners
like Agent UML (AUML) - has extensions that make it useful for talking to
N agents. (e.g. send msg to N agents, wait for M responses).

AUML framework has a way of annotating the interaction diagrams with
assertions about what has to hold at each state. see http://www.auml.org

Chris: Doesnt this mean that all clients need to understand the formalism?
Boualem: This is a question about how the semantics is represented - language issue?

MB: What are the architectural implications?

Analogy to idea of containers in JavaBean - have description files. 

Participants read conversational protocol descriptions and make sure conversations
happen according to those specifications. Enforcing consistency dynamically.

MB: Who enforces client or server? 
BB: each partner should have this element. 

MB: What about middle agents? Example of travel agent that monitors state
of services it taps to make different kinds of reservations for user. It
should forward those states to the user, as they have implication for
follow-on actions (canceling, changing...). These actions probably need to
be asynchronously managed by middle agent, so it might be hard to do as a
finite-state model, although it might be that if decomposed to atomic
transactions (each item on a PO, for example,) it is possible.

BB: Another issue is checking compatibility of composite service conversation. We have used
conversation numbers given out at the begining of each conversation. 

Next time you access amazon.com - you give this number in your msg - this
is used to 're-establish' state of the conversation in the
server. (MB: Similar to KQML/FIPA msg reference tags?) 

MB: How to manage state model: travel agent is managing several 'orders'
(parts of a travel reservation for airline/hotel/car...)
simultaneously. State of full order is changing asynchronously based on the
msgs coming from the originating services for each part. Similarly, Amazon
may have different parts of an order in different 'states' of
processing/shipment from different warehouses/distributors/vendors they act
as agents for.

Tim: what about an n-party conversation example? A comparative shopper -
lookup price at several sites and buy from the cheapest.

CB: Not really an n-partner converstation. The servers don't know about each other. 

Tim: true. Still worth modeling. 

CB: Can hide the backend parties by abstracting their state contributions,
so it looks like one service. 

MB: I think you will want to have a model where parts of their protocols
are visible. One situation where it will be hard to generalize/abstract
away the specifics of the backend servers is for compensation. Each may
have some peculiarities to deal with (e.g. differences in compensation
policies for hotels vs airlines for a travel agent, or books vs electronics
vs ... for amazon.)  There may be a generalized set of PO and ordering
mechanisms, but it would be easier if the language allowed the middle agent
to tell the client to go "use the compensation policy of the originating
provider". 

MB: Lets do a meeting next week, same time. Even though it is just before travel for some 
of us.