Description
The illustration identifies key software items involved in the runtime operation of iPAM. The connectivity indicated by the solid black lines is hypothetical, for discussion only. Blue and red items are part of the iPAM image. The gray items indicate software processes that are external to iPAM.
iPAM can be run as a standalone Java executable that provides its own limited Web service. iPAM was also designed so it could be run as a peer of a "real" server capable of running Servlets. The illustration above is correct in either mode of operation.
At runtime, the executive schedules and activates PIMs, Jugglers, and DIMs. This line of control is illustrated by the dotted lines in the illustration. However, the executive does not handle any of the internal product moved between these units. If a Juggler needs product from one of its inputs it can directly browse its input list and request Product from each source. Likewise, the DIM can directly request Product from each of its sources.
Jugglers can be both Sources and Sinks. This allows the creation of super-Jugglers whose input may come from other Jugglers. The framework will allow such configurations though minimal testing has been performed of such configurations.
DIMs can accept input from more than one Juggler. When the executive activates a DIM it identifies why the DIM has been activated, by passing a reference to the Juggler with new Product to the DIM. At that point, the DIM is free to request information from that Source or from all of its Sources if required.
The DIMs job is to build a product in a format suitable for delivery over one of the push Datacasters. PAM does not assume that the push Datacaster server is co-hosted with PAM. Each DIM notifies a Datacaster-unique proxy when new information is available. The DIM may pass the information to the proxy, but the preferred approach is that the proxy reach back into the PAM system via an HTTP URL request which is handled by a PAM supplied Servlet. The preferred approach is illustrated above.
There are two principal ways that the datacaster can get data from the DIMs. One way is to for the output DIM to create a directory with all the necessary Datacaster files in it. The DIM can then notify the Datacaster and pass a directory spec. Another way is for the DIM to pass a URL to the Datacaster that refers to the product root page or single product file. Clearly the method will vary with the capabilities of the Datacaster , its publishing tool, or its API.