Stopping). The HL API controls the transitions between states and hides the "plumbing" of Golem mechanics so that the developer can focus on their service's details.
SimpleService), hosted in a standard Golem VM runtime, where service "requests" are the shell commands executed repeatedly on the VM while the service is running.
Demandstructure and published on the Golem market.
start()method follows a 'work generator' pattern. It uses a
Scriptinstance (acquired via
_ctx- the activity's work context) to build a sequence of actions which then gets returned to the service execution engine to be asynchronously relayed to the Provider's runtime. Please take a look at the methods provided by
Scriptobjects to get familiar with the possible work steps that can be performed via Golem APIs:
start()sequence of actions is executed only once in Service's lifecycle and must result either with success, or indication of failure, in which case, depending on the
respawn_unstarted_instancesflag of the
Golem.run_service()call, the Service's startup is retried on another provider if the flag is
Trueor immediately moves to
Runningstate - this ends the actions specified for
Runningstate and triggers the transition to
WorkContext) is still available, the Service moves to a
Stoppingstate, in which a Requestor Agent still may have an ability to e.g. recover some artifacts from the service instance, or perform some general clean sweep.
Stoppingactions are executed only once in Service's lifecycle.
Golemexecution processor object, which hides all the technical nuances of market interaction, activity tracking, and service state lifecycle:
Golemcall returns a
Clusterof (in this case)
SimpleServiceobjects, each representing an instance of the service, as provisioned on the Golem network. The
Clustercan be used to control the state of the services (e.g. to stop services when required).