How Sophora Cloud Delivery works
In a classical Sophora setup, a Sophora Client connects to a single Sophora Server and creates a session. This session is the basis for various functionalities like event dispatching and locking documents. However, an explicit login request and a session with a single server won't work when a load balancer sends the request to any available server.
Therefore Sophora Cloud Delivery takes a different approach by using these techniques:
1. Client requests are sessionless
A Sophora Client can send its request to any Staging Server straight away without creating a session first. A login is not required. In order to still authorize the request, the client needs to have an access token and must send it alongside every request. The receiving server then reads the token, relates it to a regular Sophora User and authorizes the request.
2. Events are polled source-time based
The classical event dispatching is closely connected to Sophora Sessions and does not work if there are no sessions in the first place. As an alternative approach Sophora Cloud Delivery uses source-time based event polling. The sourceTime is a date property of ServerEvents that is identical on all Sophora servers. If one server sends a DocumentChangedEvent with a specific source time, then all other Sophora servers will send the same event with the same source time. This allows for an event fetching strategy that works no matter which server receives the request.
3. The Sophora Server knows if it is sufficiently up-to-date to serve a request
Individual Sophora servers might be behind in replication. In order to prevent serving old data to a request, the server has an implicit up-to-date check. The client sends its most recent source time as additional request parameter with every request. The server can use this information to check whether it is delayed in synchronization; if this is the case, it will answer with a specific exception. This exception is properly handled by the client, which will then silently retry the request.
Instantiating a sessionless Sophora Client
An instance of a sessionless Sophora Client may be built by using the SophoraClientBuilder, or by using a special configuration for the Sophora Delivery.
Using the SophoraClientBuilder
An instance of a sessionless Sophora Client may be built by using the SophoraClientBuilder, or by using a special configuration for the Sophora Delivery.
SophoraClientBuilder.newBuilder()
.withHost("<loadbalancer-url>")
.withAccessToken("<accesstoken>")
.sessionless()
.build();
Using a Delivery Configuration
sophora.delivery.client.sessionless=true
sophora.delivery.client.accesstoken=<accesstoken>
Using a sessionless Sophora Client
An invocation of the ISophoraClient#login() method is not necessary if this feature is used. But in order to release local resources, the ISophoraClient#close() method should be used once a client is no longer needed.
A client in a sessionless setup supports reading requests in a regular way.
Restrictions
This sessionless feature is only available when using a http or https connection. RMI is not supported. Sophora Cloud Delivery furthermore only supports connections to Sophora Staging Servers.
Sophora Cloud Delivery does not require a specific load balancer. Any load balancer that can handle http requests will work. Request dispatching can be done by a variety of strategies, including sticky connections and round robin.
Configuration of Access Tokens
Access tokens are part of the sophora.properties. By using the property sophora.authenticate.tokens you can specify a comma separated list of tokens that clients can use to access the servers. Every token has to be a valid UUID. All token-based requests by clients will be executed as if performed by the admin user.
Distinction Between "Sophora Cloud Delivery" and "Cluster for Sophora Delivery Web Application"
The Cluster addon includes the capability for deliveries to configure multiple backup staging server connections. This feature is named "Cluster for Sophora Delivery Web Application" and is described here. It allows a Sophora Delivery to connect to failover staging servers if its preferred staging server becomes unavailable. During regular operation, only one direct connection between the delivery and its currently used staging server is established; there are no active connections to the failover servers. This is a different approach than accessing multiple staging server behind a load balancer.
The feature "Cluster for Sophora Delivery Web Application" is intended to be used in a traditional deployment of a Sophora Delivery in an on-premise environment.
