Pizza Design Discussion

Here we outline some of the interesting design decisions in the pizza party application; Why did we use the mechanisms that we did? How do various things work?

The intentions is that this discussion will help illuminate the intent of various Cougaar features, and how to take advantage of various Cougaar components.

In progress......

Why do we use Assets for Kitchens and Pizza?

What is the point of the prototype Pizza Assets?

Why do we use a Relay for the invitation?

What else could have been used to issue the invitations?

Why do we use a Community to define the people to invite?

Could we have used Plugin parameters?

Could we have used Asset PropertyGroups?

Could we have used Relationships?

Why must we have Cambridge and MA agents?

Some agent has to host the Yellow Pages. The Yellow Pages data is stored in an in-memory HSqlDb, not on the Blackboard. So in fact, we could have configured the Yellow Pages to be at any Agent that is a member of the YP Community. In our case, that means either Alice, or the Pizza Provider (Joes or Dominos). It is a little clearer to put the YP at a separate Agent, but not necessary.

Why are there separate classes for the Relay Target and Source?

See Cougaar Bug 3726. There is a bug, which we help to avoid by keeping the Target from implementing Relay.Source - which means that it does not have a Targets list. As a result, it avoids this bug, which could cause a flood of messages.

More generally, it is cleaner to read and understand. The Relay Source is the "query" or the source information. The Target is the representation of the "query" at the destination Agents. In our case, the Relay is a question of sorts, and the same content in both the Source and Target. For other applications, the Target could be wholly different than the Source.