Server Communication
up
As of 2011-02016, this area is under discussion and subject to change. Please see the Nabble discussion on this topic for an updated view.
The Power TAC competition is designed as a clock driven, competitive simulation. Two kinds of events drive activity:
- One is the passage of time -- the simulation clock (org.powertac.common.TimeService) maintains a queue of "actions" that will be triggered at specific times. Any object can post an action to be triggered in the future, and actions can re-enter themselves in the queue for later times, leading to repeating events. This type of activity is, of course, restricted to a single process context.
- The other is message arrival, where the activity of one actor (say Broker Bob) results in a message being created and sent, which may be received by other entities (say a response of one of Broker Bob's customers) who may then act on the received message. This is the mechanism by which distributed portions of the system interact (Brokers and the Server, for example).
In support of message-driven interaction, the Power TAC server offers a messaging framework that supports light-weight, event-driven interaction between the different core entitites of Power TAC. As shown in the figure below, two different entitites (called endpoints) are connected via message channels which allow them to exchange messages.
A message is a generic wrapper for any Java object combined with metadata used by the framework while handling that object. It consists of a payload and headers. The payload can be of any type and the headers hold commonly required information such as id, timestamp, correlation id, or return address. In Power TAC, message payloads are either serializable "value" objects from the domain model, or lists of such serializable value objects. A value object is a simple immutable Java Bean that carries data required for some specific interaction between two Power TAC entities (say a broker and a customer). Examples of such value objects are TariffSpecification and CashUpdate.
In the following sections all communication flows defined between brokers and server as well as within the server are described in detail.
For consistency we try to maintain the Naming conventions for communication channels.
