Optimization Services









Optimization Services process Language (OSpL)

Click to see or download the OSpL XML Schema -> OSpL.xsd [actively under development, near stable]

Besides static entity information (OSeL), the Optimization Services registry also keeps dynamic process information (such as number of jobs being solved) using Optimization Services process Language.

OSpL (process) is a specification of process information to describe the dynamic information of an optimization service (such as number of jobs being solved).

Unlike the OSeL information that is submitted at registration, OSpL information is collected at run time. During runtime, the Optimization Services registry periodically “knocks” on the registered services (OShL, Optimization Services hook-up Language) to make sure they are live and running and to collect the OSpL information. It is also possible that the services themselves push the OSpL information to the OS registry.

The decentralized Optimization Services system leaves open the question of how optimization “jobs” are scheduled to run on available solver services. Certain centralized schemes, such as that used by the NEOS server, may maintain one queue for each solver/format combination, along with a list of the workstations on which each solver can run. In Optimization Services, we want to maintain this scheduling control, while at the same time making the scheduling decisions more distributed. Optimization Services process Language can play an important role in dynamic optimization scheduling in a decentralized environment.

The following figure illustrates the general OSpL Schema.



Click to see or download the OSpL XML Schema -> OSpL.xsd