Swim unifies the traditionally disparate roles of database, message broker, job manager, and application server, into a few simple constructs.
Read this in other languages: 简体中文
Swim implements a general purpose distributed object model. The "objects" in this model are Web Agents.
Creating a class that extends swim.api.agent.AbstractAgent defines a template for Web Agents (though not a useful one until we add some lanes).
- Created two additional web agents in DataSource
- Created unique Records (msg2 and msg3) to vary the data sent to different agents
Visit the documentation for further details about Web Agents.
If Web Agents are objects, then lanes serve as the "fields" of those objects. Lanes come in many flavors, e.g. value lanes, map lanes, and command lanes.
Continuing our analogy, lane callback functions serve as the "methods" of Web Agents.
Each lane type defines a set of overridable (default no-op) lifecycle callbacks. For example, sending a command message to any command lane will trigger its onCommand callback. On the other hand, setting a value lane will trigger its willSet callback, then update its value, then trigger its didSet callback.
- Added 5 new SwimLanes in UnitAgent
- the 'avg' ValueLane keeps track of changes to the mean cumulatively
- the 'localAvg', 'localVar', and 'localStdDev' ValueLanes run calculations on the 5 most recent data points sent from histogram
- the 'stats' ValueLane is an alternative design choice which tracks each of the above metrics using one lane of type Value (rather than 4 individual lanes of type Long)
Visit the documentation for further details about lanes.
A Swim server is loaded with a plane, which provides the runtime for Web Agents and routes messages to the correct lanes.
A plane must declare a SwimRoute field for each Web Agent type.
Use the ServerLoader utility class to load the default kernel modules.
Visit the documentation for further details about these concepts.
Every Swim server can be written to and read from by external processes using the Swim API. The simplest way to utilize this API is to use a Swim client instance to send commands to command lanes.
Visit the documentation for further details about these concepts.
Swim client instances use Swim links to pull data from a Swim lanes. Like their corresponding lanes, links have overridable callback functions that can be used to populate UIs.
Visit the documentation for further details about links.
- See the solutions branch for an example of changes you could make to the UI to reflect these possible solutions