Routing and Protocols
Currently WebSemaphore can route jobs over HTTPS, WebSockets and Websemaphore. More protocols and standards are considered.
The delivery method is chosen using the chain of responsibility pattern, i.e. routing options will be attempted in order until either succeeds or we run out of routing options.
The order of protocols is currently fixed: websockets must precede http must precede websemaphore. This order is determined by the relative stability of the channel, websockets being the most unstable and websemaphore being most suitable for a final fallback when everything else fails.
Routing can be overriden by a mapping function. To maintain protocol order as describe, returning a routing instruction from the mapping will override all routes that use protocols of lower and equal stability to the protocol in the instruction. For example if a semaphore configuration is defining websockets, https and websemaphore as routing options and the mapping returns an "https" routing instruction, the job will be delivered to the returned https endpoint. In case of failure it will be delivered to the semaphore defined in the configuration. Note that the original websockets and https routes will be discarded in such case.
1. Websockets
Websockets allow us to achieve all the benefits of a REST connection. Since websockets are bidirectional, both client- and server-side applications can take both the roles of requestor and processor.
-
In asynchronous mode websockets have the advantage to perform a callback to a client that is not accessible over HTTP due to firewalls or lack of public IP address.
-
In synchronous mode websockets still operate in a partially asynchronous manner since the protocol does not provide an immediate response mechanism and it must be sent as a separate message to the client.
-
Websockets lock requests are currently coupled with the websocket session id and lock acquisition/rejection signals are only communicated to that session. Since sessions are unique, a server restart or a page reload may leave orphan lock requests in waiting or acquired state.
The timeout option may be used to release such stale resources when resource availability is of higher concern than lossless communication.
2. HTTPS
When used over HTTPS, the requestor sends a request to acquire a semaphore either synchronously or asynchronously.
- In asynchronous mode, the message will be received and stored in WebSemaphore until delivered to the client. The processing endpoint must be decoupled and accessible to WebSemaphore via an ip / domain.
- In synchronous mode, the response is a straighforward http response with a confirmation of lock acquisition or rejection.
3. Websemaphore
Using websemaphores as a target is useful in multiple scenarios such as:
- Failover - when all other options are exhausted the job may be passed to another semaphore to target an alternative system or for later resolution
- Multidimentional resource limit / isolation requirements such as when the traffic is targeting multiple systems each having their own limits and also must adhere to a common limit on another resource (see a sample use case in the blog).
