Class: TransitionHandling

This method is named endpoint_transition due to its servicing the operations of an endpoint server (as defined in the package message-relay-server). This method looks for a token on the message (body). If the token is not there, it assumes the message arriving at the endpoint is in the first phase of transition processing and sends the data on to the transition handler.

If the token is present, the method assumes that the message is targeted to the secondary action.

The branches return the result of the methods they call, and the UserMessageEndpoint instance is written to send the response back to the relay client (message-relay-server) in an appropriate form using the transtion hanlder results.

This method progresses a transtion request towards finalization provided that the transition can be identified by its token. The previously generated data that was not sent to the client will be extracted from the transition object keyed by the token.

Just one check, a match between the object sent in the request from the client and the cached transition object needs to pass. The match test might be one of a number of possible checks, ranging in in complexity from the check to see is a field is present, to checking if same name fields of the two objects are equal, to signature verification using elliptic key crypotgraphy, or perhaps more. The match implementation is part of the application.

Once the match is passed, the secondary transition handler calls up the transition finalization method for the transition machine operating with respect to the current session.

The transition hanlder is the CopiousTransitions entry point into an application's state transition implementation. This method supplies the basic framework for stepping the transition request through permission, acceptance, processing setup, until the state transition can be finalized either in response to the first request or in response to a secondary request (secondary_action).

The transition handler first calls the session manager's guard. The guard can provide a certain amount of access control and may also know about the state of the server and the permissibility of certain types of transactions. A failure to pass the guard yields a reson of unavailability to the requester.

If the guard is passed, the validator checks the trasition body for addmissable data types, etc. In many use case, the call to the validator is moot. Yet, in some operations the application will prvodide checking methods that the validator framework can use.

After validation, the transition is examined for feasibility. By feasibility is meant that the state of the server relative to the session can allow for the transition to a desired state and that the resources required for the transition are available. The check must be determined by the application. The check can be any degree of complexity from something simple such as accepting the name of the transition to something quite complicated such as checking that certain machines are attached to the server and that certain measurement are with desired ranges. What is provided here, is that the transition server will call on the feasibility test provided by the application after validation and before transition processing and, furthermore, the transition handler will wait (await) the completion of the feasibility testing.

Requests remaining after they are deemed feasible, can be processed using the session manager's process_transition, which sets up the data needed for finalization and determines if the transaction will happen in one step or require a secondary action.

Those transitions that can be done in one step proceed immediately to finalization. The finalization method, provided by the application, should set the state transition for the session. The method should result in a the transition machine owned by the session being in an identifiable state. When the session is queried for the state of the machine, the state of the last finalization should be reported. A query of the state should remain the same with respect to the session until another state transition is requested.

Those transitions requiring a secondary action before finalization will cache data in preparation for the second action to be done in response to an ensuing request. The transition handler calls out to the dynamic data producer to produce the data to be cached. The transition handler will cache the data using the methods provided by LocalTObjectCache; the data is cached into a map structure with the transition's token as the key. Once the data is cached, the partial transition object containing data for the client will be sent to the requester along with the parts of the generated data chosen to be sent. Data is sent in preparation for the secondary action according to a contract of design established for the synchronization of client and server operations and negotiations.

Given the client comes back with the request for the seconary action, the next handler secondary_transition_handler will continue the process of progression the transtion to finalization.

This method does a very short one step version of transtion processing in response to websocket messages inbound from the client. This method only check on the feasiblily of the transition and if it finds it feasible, the transition will be move on to finalization.