Horizontally scaled versions of OMERO are applicable to many use cases. Building upon a pure read-only instance of OMERO (#71) a transparent, horizontally scaled ability to utilize multiple OMERO instances, classified as either read-only or read-write, at a time is strongly desired. The only client exposure to this ability is a "pure read-only" parameter to disable access to read-write methods when creating a read-only/read-write stateful service. This decision would persist for the entire lifecycle of a service created in such a manner.
Overview
The second major step in "Horizontal Scaling" is to allow a single connection to an OMERO instance to transparently route service creation or retrieval requests to a readable or writable OMERO instance. This instance will then host the service based on the needs of that service request for the duration of its lifecycle. All requests for stateless services can be executed by any appropriate (based on the read-only or read-write requirement of the request) OMERO instance endpoint. Note that a shared filesystem will need to be in place between OMERO instances for this to be possible for certain service types which access the OMERO binary repository.
Read-only or read-write services will need to be classified ahead of time, bound for the length of the session and stored in a persistent, cluster-wide manner. If a node is removed from the cluster its associated stateful services will be destroyed with it and the client developer will be expected to handle such a failure condition.
For stateful services that have methods which have both read-only and read-write containment, a default of a writeable endpoint will be necessary. An optional parameter to disable access to read-write methods when creating a service of this type will be provided.
The result of this work is a transparent, horizontally scaled ability to utilize multiple OMERO instances, classified as either read-only or read-write, at a time. The only client exposure to this ability is a "pure read-only" parameter to disable access to read-write methods when creating a read-only/read-write stateful service. This decision would persist for the entire lifecycle of a service created in such a manner.
This could facilitate an automatic means of load balancing (for read-only), such as round-robining of requests.
History, state of play, and rationale
Horizontally scaled versions of OMERO are applicable to many use cases. Building upon a pure read-only instance of OMERO (#71) a transparent, horizontally scaled ability to utilize multiple OMERO instances, classified as either read-only or read-write, at a time is strongly desired. The only client exposure to this ability is a "pure read-only" parameter to disable access to read-write methods when creating a read-only/read-write stateful service. This decision would persist for the entire lifecycle of a service created in such a manner.
Overview
The second major step in "Horizontal Scaling" is to allow a single connection to an OMERO instance to transparently route service creation or retrieval requests to a readable or writable OMERO instance. This instance will then host the service based on the needs of that service request for the duration of its lifecycle. All requests for stateless services can be executed by any appropriate (based on the read-only or read-write requirement of the request) OMERO instance endpoint. Note that a shared filesystem will need to be in place between OMERO instances for this to be possible for certain service types which access the OMERO binary repository.
Read-only or read-write services will need to be classified ahead of time, bound for the length of the session and stored in a persistent, cluster-wide manner. If a node is removed from the cluster its associated stateful services will be destroyed with it and the client developer will be expected to handle such a failure condition.
For stateful services that have methods which have both read-only and read-write containment, a default of a writeable endpoint will be necessary. An optional parameter to disable access to read-write methods when creating a service of this type will be provided.
The result of this work is a transparent, horizontally scaled ability to utilize multiple OMERO instances, classified as either read-only or read-write, at a time. The only client exposure to this ability is a "pure read-only" parameter to disable access to read-write methods when creating a read-only/read-write stateful service. This decision would persist for the entire lifecycle of a service created in such a manner.
This could facilitate an automatic means of load balancing (for read-only), such as round-robining of requests.
Current work
OMERO 5.2.x
OMERO 5.3.x
TBD
Related reading
History
Thu Jan 26 12:46:30 GMT 2017: Initial version