RTS Endpoint Models

#RTS Endpoint Models RTS endpoints are build on top o WebSockets and JSON formatted messages. The use of JSON-RPC was initial proposed for these messages, unfortunately JSON-RPC is also really bound to basic Request/Response model. The model we want to extend, needs at least a way to send provisional responses, and a correct way to identify these messages. Without too much details, RTS messages are composed of the fields:

• id message identification. Unique field when combined with clt.
• clt some form or extension of UUID for client identification.
• typ message type. Valid values are: pub (publish), snd (send), rpl (reply)
• cmd second message type. Valid values are: ok (ok reply or publication, res field has the response or published value), err (error reply, res field has the error value), obs (observable reply, res field has the uuid of the observable), cpl (observable complete publication, end of stream) or any other service method name.
• path endpoint address. Refers to destination when in a request context, and to origin when in a response.
• headers group for other custom fields without clashing with predefined headers.
• args array of arguments of the invoked method.
• res response value when bound to a response context.

##Endpoint models Here we refer to clients and endpoints that are build on top of network clients and servers (if based in TCP connections). These distinction is needed because RTS endpoint services are not necessarily in the network server. Services can be installed in network clients and servers, however the connection is still from client to server, avoiding network and firewall issues. Existing models are represented in the simplified sequence diagrams.

basic	publish	reactive	reactive + backpressure control

As stated before, the basic model is the one used in REST services. JSON-RPC is enlarged to the publish model, with notifications. RTS extends this with the concept of Reactive Streams.

##Component Interaction Details Looking at the architecture overview we have identified some Pipeline components. The next sequence diagrams add details of the basic and reactive model interactions. The client waits for the asynchronous response using the well know Promise pattern. In the service side returning a Promise is optional and is not identified in these diagrams.

• PipeResource is an abstraction for any connection context (using TCP or any other protocol). Is also a placeholder for connection resources, hence the name. Any resources or subscriptions are released on disconnect.
• PipeContext is an abstraction for a request context. In a REST endpoint this has the same life-cycle of a PipeResource, but in RTS with keep alive WebSockets, PipeResource's can live much longer than any PipeContext.
• Service is a user class extension of an available interface IComponent (more on this later). Services expose methods as public endpoints.

When the message is delivered to the Service, it's translated to a method invocation, as is also the method return translated to a reply message. The basic model flow is easily identified in the above diagram, no other explanation is needed here.

In the reactive diagram, two new components are presented, C-Observable and S-Observable, but actually can be considered the Stub (C)lient-Observable and Skeleton (S)ervice-Observable sides of the same component. In the Typescript client module (rts-ts-client), the C-Observable is in truth a ReactiveX Observable. Part of the initial flow is identical to the basic model, but when a service return's an Observable, it's detected by the framework and a message reply with cmd="obs" is generated instead. The result value is an UUID for the Observable. The PipeContext is prolonged until the stream is complete or an error is thrown.