FHIR Chat · fhircast-docs / Issue #61 STOMP based websocket proposal

Stream: fhircast-github

Topic: fhircast-docs / Issue #61 STOMP based websocket proposal

Github Notifications (FHIRcast) (Mar 01 2019 at 13:12):

@isaacvetter, @wmaethner - What is the plan for putting this into the spec for the May ballot? I have some concerns about the status of this proposal as well as the proposal that websockets will be used for more than just notifications sent from the hub to the client. I think it may be overkill and hinder the efforts of PACS developers - especially those with limited resources. I am moving forward with a prototype that:

1. Uses a "proprietary" authentication/authorization scheme in order for a client to obtain a topic (user session id). This is obviously essential for a working prototype.
2. Uses websockets for Hub->client notifications only. All other communication is done using the "standard" REST methods. NOTE: Subscibe is slightly altered for websocket clients per our modification to the FHIRCast spec.
3. Uses Raw data for json notifications and their responses.

Other than these differences, the prototype will not veer from the original FHIRCast/FHIR/Websub specifications.

Don't get me wrong - @bvdh has done an amazing job with this and other suggestions. I'm getting pushy because I am under pressure to get something "working" and demonstrable very soon.

Github Notifications (FHIRcast) (Mar 04 2019 at 11:18):

bvdh commented on Issue #61

I agree that we should decide on how to take this further.

The reasoning behind suggesting STOMP were
• open standard
• defines an "over the wire protocol" that we need anyway (character coding, framing, message formats, …)
• has been implemented and is being used by many systems
• libraries are available for all commonly used platforms (java, .net, angular, jquery,…)

Basically, my thought was if something exists that contains the stuff we need, we better use it instead of defining something of our own. Also, as there are libraries available, it should be easy to implement for most parties.

I'm open for proposals that suggest alternatives for STOMP, but we should be careful to not step into the trap of trying to re-invent the wheel.

Github Notifications (FHIRcast) (Mar 04 2019 at 16:35):

gkustas commented on Issue #61

I'll attempt to answer both of your points in one answer Bas. I've gave the
same questions some thought as I began implementation.

I also asked myself "how should we identify the subscription"? Then I
thought about it more and realized we don't. In my Hub, I accept the
subscription if the the topic is validated, and store it (currently) in a
collection of all subscribers, indexed by the topic. Remember, The topic is
created during authentication and can be validated in the database of
configured applications and user identities (see my proposal for
authentication - I think the same should apply for an OAuth
implementation).

So... Per the WebSub spec, all subscribers receive events - even the
publisher of the event. Therefor, when the Hub receives an event, it
publishes to every subscriber in my collection.

As far as the STOMP protocol goes - I'll say again that the only "message"
we currently have is the notification event, and that is already defined in
FHIR. So, if we add messages other than context (say for example, meta data
like measurements, procedure details, etc.), they would also be defined by
FHIR. The FHIR spec already clearly defines the JSON and XML formats.
However - because we are talking "WSS" and not "HTTPS", there is the issue
of the headers. Martin Bellemeur had a nice recommendation, which I also
included in my "Prototype Proposal" document. We simply wrap the FHIR JSON
and header info into a simple JSON object:
{
"header" : { <header data here> }
"body": { <FHIR object here> }
}

My personal opinion is that it is much easier to build simple classes i
nour Hub and Client, and "bind" them to JSON than it is to implement the
STOMP protocol. If we provide numerous samples (Javascript, C#, Java,
etc...), it should be easy for all vendors to implement.

BUT... That's all my opinion and I'll go along with the consensus. The main
thing is to make FHIRCast a standard.

I'll be glad to have a telephone conference at most times. I am flexible.

On Mon, Mar 4, 2019 at 6:18 AM Bas van den Heuvel <notifications@github.com>
wrote:

I agree that we should decide on how to take this further.

The reasoning behind suggesting STOMP were
• open standard
• defines an "over the wire protocol" that we need anyway (character
coding, framing, message formats, …)
• has been implemented and is being used by many systems
• libraries are available for all commonly used platforms (java, .net,
angular, jquery,…)

Basically, my thought was if something exists that contains the stuff we
need, we better use it instead of defining something of our own. Also, as
there are libraries available, it should be easy to implement for most
parties.

I'm open for proposals that suggest alternatives for STOMP, but we should
be careful to not step into the trap of trying to re-invent the wheel.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/HL7/fhircast-docs/issues/61#issuecomment-469216404>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFw87tJ1-X_wVOU51LEKWAATnXJyIBFuks5vTQDrgaJpZM4aGLV_>
.

--
George Kustas

Github Notifications (FHIRcast) (May 22 2019 at 14:56):

isaacvetter commented on Issue #61:

## :telephone_receiver: II Working Group Vote (5-22-2019)

Meeting notes: https://confluence.hl7.org/display/IMIN/Teleconferences

@isaacvetter moved the following disposition, seconded by @gkustas

Disposition: We will move forward with extending Websub to incorporate websocket support in lieu of the more complete and complex alternative messaging framework specified in STOMP. We will publish PR #57 on fhircast.org. We will modify the approach described in #57 to allow the subscriber to connect over wss: to a hub-provided url in the subscription response, instead of connecting directly to the hub.topic as a url. We will investigate replicating the verification of intent step from Websub when websockets is used.

Disposition Comment: Further, we will look to DICOMWeb's use of websockets.

:+1: For: 13
:expressionless: Abstain: 2
:-1: Against: 0

:tada: The motion passed! :tada:

Github Notifications (FHIRcast) (May 22 2019 at 14:56):

isaacvetter commented on Issue #61:

@bvdh - mind if I close this issue?

Github Notifications (FHIRcast) (May 23 2019 at 07:10):

bvdh closed Issue #61:

Based on the discussions in the 20th connecthaton WGM, I wrote down a proposed fhir-cast websocket spec. This has been tested in the https://github.com/PhilipsOnFhir/fhir-cast repository.

# FHIR-CAST WEBSOCKET update
This implementation implemnents some proposed changes of the FHIR cast
Split the specification into(http://fhircast.org/) specification.

## Specification format
We propose to split the specifiaction into three layers:
1. channel protocol
2. subscribe/unsubscribe and event type
3. Event definitions
## Channel protocols
Channel protocols are the the different protocols that fhir-cast can use to connect to clients.
This implementation of fhir-cast implements three different
1. WebSub (exisiting spec)
2. Websockets (see below)
3. pull based context (exisiting spec)
In order to separate the channels on different end-points:

WebSub: \<baseurl>/\<topic>/websub

WebSocket: \<baseurl>/websocket

Context: \<baseurl>/\<topic>/context

GET on \<baseurl>/\<topic> will give you a list of the supported protocols.

# Websocket
The websocket part uses STOMP 1.2.
Some functionality is not required for FHIR CAST. Clients and server SHALL implement the required functionality and SHOULD implement the other.

## STOMP subset
We will be using STOMP 1.2 over WebSocket. Not all functionality from STOM is required.
The table below indicates the functionality that MAY be unsupported. It is RECOMMENDED that
the client and server implement the other functionality required by STOMP although it will
not be used by this specification.

The following table shows the support requirements for the different STOMP messages.
| Message | Source | Status | Description |
| --- | --- | --- | --- |
| CONNECT | Client REQUIRED Connect to websocket
| SEND | Client REQUIRED
| SUBSCRIBE | Client | REQUIRED | Subscribe to channel
| UNSUBSCRIBE | Client | REQUIRED | Unsubscribe from channel
| BEGIN | Client | OPTIONAL | Start transaction
| COMMIT | Client | OPTIONAL | Commit transaction
| ABORT | Client | OPTIONAL | Abort transaction
| ACK | Client | REQUIRED | Acknowledge
| NACK | Client | REQUIRED | Not Acknowledge
| DISCONNECT | Client | REQUIRED | Disconnect websocket
| MESSAGE | Server | REQUIRED | Send message to client
| RECEIPT | Server | REQUIRED | Indicate receipt content
| ERROR Server | REQUIRED | Indicate error occurred

## Destinations
Clients send messages to destinations, a destination is a directory like name on the server.
All FhirCast destinations are targetting the hube will be prefixed with /hub/.
All FhirCast destinations are targetting the spplications will be prefixed with /app/.

### Client-->Server
Client-->Server communication SHALL use the following pattern:
/hub/fhircast/\<topic>/
where
\<clientid>: is a unique id of the client, e.g. the client-id used in OAUth

### Server ->Client
Server ->Client SHALL use the following destinations:
/app/fhircast/<topic>/<event>
where
\<clientid>: is a unique id of the client, e.g. the client-id used in Oauth
\<event> is the event name/id the client sends a message to

Implementations can distinguish on OAuth role, adding client-id makes it easier to filter who receives what.

## Use cases
### Client Subscribe/ Unsubscribe
All clients can register for events on the websocket endpoint.

SUBSCRIBE /hub/fhircast/\<topic>/\<event>
subscribe app for event \<event> on topic \<topic>

UNSUBSCRIBE /hub/fhircast/\<topic>/\<event>
Unsubscribe for the event on the topic.

Deny subscription
TBD

### Sending events
#### Server sends event
MESSAGE /app/fhircast/topic>/<event> Event
The Event is formatted as a WebSub event. E.g.
THe event is formated as is displayed below:
{
event": {
    "hub.topic": "https://hub.example.com/7jaa86kgdudewiaq0wtu",
    "hub.event": "close-patient-chart",
    "context": [
      {
        "key": "patient",
        "resource": {
          "resourceType": "Patient",
          "id": "798E4MyMcpCWHab9",
          "identifier": [
            {
              "system": "urn:oid:1.2.840.114350",
              "value": "1345687"
            },
            {
              "system": "urn:oid:1.2.840.114350.1.13.861.1.7.5.737384.27000",
              "value": "7539"
            }
          ]
        }
      }
    ]
}
#### Clients updates context
MESSAGE /app/fhircast/\<topic>/\<event>
Send the event to the event endpoint. The implementation SHALL refuse messages send to the wrong endpoint.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · fhircast-docs / Issue #61 STOMP based websocket proposal · fhircast-github

Stream: fhircast-github

Topic: fhircast-docs / Issue #61 STOMP based websocket proposal

Github Notifications (FHIRcast) (Mar 01 2019 at 13:12):

Github Notifications (FHIRcast) (Mar 04 2019 at 11:18):

Github Notifications (FHIRcast) (Mar 04 2019 at 16:35):

Github Notifications (FHIRcast) (May 22 2019 at 14:56):

Github Notifications (FHIRcast) (May 22 2019 at 14:56):

Github Notifications (FHIRcast) (May 23 2019 at 07:10):