Stream: fhircast-github
Topic: fhircast-docs / Issue #104 May 2019 Ballot Comment: Inclu...
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot opened Issue #104
## May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot labeled Issue #104
## May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot labeled Issue #104
## May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 19:51):
hl7-fhircast-bot edited Issue #104
## May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Apr 30 2019 at 20:43):
isaacvetter labeled Issue #104
## May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 06 2019 at 18:56):
gkustas commented on Issue #104
I too would like the websocket proposal added, but for other reasons than the single page application. Several discussions have occurred on the subject in Zulip as well.
Github Notifications (FHIRcast) (May 07 2019 at 19:19):
bvdh commented on Issue #104
Websocket options that where discussed include:
1 STOMP
2 basic websocketBasic requirements to be met with the web-socket solution:
1 Allow web-only clients to receive FHIR-Cast events.
2 Allow to subscribe to events, unsubscribe from events.
3 Only clients authorized for an event can receive it.
4 Only clients authorized to send an event can send it.
5 Easily implementable using available technologiesSTOMP
STOMP (https://stomp.github.io/) supports all of these requirements out of the box. It is a full alternative to the web-sub approach and can be seen as an alternative implementation. Libraries are available for all common languages: https://stomp.github.io/implementations.html
STOMP libraries typically have native support for authentication.Basic Websocket
This approach indicates websocket as an alternative channel for sending events. Subscribe/Unsubscribe to events is done using the WebSub pattern. Additional specification is required to verify that the receiver is the one that made the request and is the only one that can receive the events. The websocket URL would be unique for each client and difficult to guess in order to prevent that unauthorized clients can connect.
A pattern that could work could be something like the following:
A->B : POST with channel = websocket
Return -> 202 Accepted – include websocket URL to be used.
A->B: connect to websocket URL
B->B detects websocket connection
B -> A: send intent verification (over websocket)
A->B: send verification response (REST-full or over websocket?)
This approach will also cover the requirements but does require further FHIRCast specific specification and verification effort.Based on an ease of implementation and specification effort, the STOMP approach would have my preference.
Github Notifications (FHIRcast) (May 07 2019 at 21:59):
isaacvetter commented on Issue #104
Hey @bvdh ,
For your Basic Websocket feedback, can you read this proposal as the [proposed websocket](https://github.com/HL7/fhircast-docs/pull/57/files?short_path=1a523bd#diff-1a523bd9fa0dbf998008b37579210e12 ?
What do you think about this?
Isaac
Github Notifications (FHIRcast) (May 07 2019 at 22:00):
isaacvetter edited a comment on Issue #104
Hey @bvdh ,
For your Basic Websocket feedback, can you read this proposal as the proposed websocket solution ?
What do you think about this?
Isaac
Github Notifications (FHIRcast) (May 07 2019 at 22:40):
gkustas commented on Issue #104
Bas, Isaac
I need to read through this all more carefully, but just for starters:
Regarding the websocket connection and validation:
The important thing that isn't mentioned here is the authentication
mechanism and how it relates to obtaining a "topic" (or user session). We
discussed this in great detail at the last connectathon.Once a client has authenticated and receives a topic, it can establish a
secure websocket connection with the hub. It simply uses an "application
secret" in the bearer authentication header and a topic. The hub can easily
validate this identity and allow/disallow the connection, correct? I don't
see the need for the protocol you provided in the "basic" approach.This is what I've implemented in out prototype. I proposed it a while ago
in Zulip:1. Client calls a GetTopic RESTful method on the authentication server
(which is our hub). It sends an application secret and a user name. The
user name is configured somewhere is persistent storage, in our case an SQL
table, and it is associated with a randomly created topic (another
discussion: these topics should probably be automatically recreated
periodically as an additional security precaution).We envision this current implementation moving to an OAuth version and
hopefully standardizing on email addresses as identifiers for radiologists
across applications (PACS, RIS, etc.)2. If the application secret and the user name jive, the topic is returned
to the client.3. The client then subscribes to the hub using the application secret (in
the header) and topic, and specifying the websocket channel type4. The client establishes a websocket connection with the hub using the
hub's base url and the topic as an endpoint, like
wss://fhirhub.company.com/<topic
goes here>. The hub can re-authenticate the topic as belonging to the
application identified by the secret, reasonably assuring that this
connection attempt is valid.I think that limiting websocket use to where it is needed (events only)
would help keep the implementation "clean" with respect to the RESTful
spec. Remember, as Martin recommended, we also wrap our websocket messages
in an object that contains a "header" and "body" which also aids in that
effort. The header will always contain the app secret. The body will
contain a notification event which will have an ID (defined by the
publisher) and a timestamp.On Tue, May 7, 2019 at 5:59 PM Isaac Vetter <notifications@github.com>
wrote:Hey @bvdh <https://github.com/bvdh> ,
For your Basic Websocket feedback, can you read this proposal as the
[proposed websocket](
https://github.com/HL7/fhircast-docs/pull/57/files?short_path=1a523bd#diff-1a523bd9fa0dbf998008b37579210e12
?What do you think about this?
Isaac
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/HL7/fhircast-docs/issues/104#issuecomment-490270605>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABODZ3QBOALOZBMSEBFOJKLPUH3T3ANCNFSM4HJPVEHA>
.--
George Kustas
Github Notifications (FHIRcast) (May 08 2019 at 09:07):
bvdh commented on Issue #104
There are multiple topics in this discussion we should separate from each other.
Determination of the topic to be used
This is an important topic but outside the scope of the websocket discussion. I propose to keep this in line with the current spec. The controlling application (by magic) can create a sessions, the Smart launch mechanism is used to communicate this to the clients. If we want to change this, this should be handled as a separate ticket.Feedback on Basic Websocket proposal
It starts with indication that websocket is to be used using Subscribe(hub.channel.type=websocket).
The result of this action is that: client is subscribed to a sub-set of events to be send over websocket.Based on the session management I can distinguish between the different web-socket sessions.
In order to send the correct events to the correct client, I need to link the session to a subscription.
The handshake I indicated in my previous proposal will allow for such linkage. Other approaches are also possible.
I have difficulties understanding what is meant in step 4 with “The hub can re-authenticate the topic as belonging to the application identified by the secret, reasonably assuring that this connection attempt is valid.” Is this step intended to link the session to the subscription?Overall, I do agree that using the Websocket only for sending events has it advantages. It reuses the websub pattern in an elegant way and prevents having to implement a bidirectional protocol over websosckets.
But, the discussion presented above does provide proof that this will require us to specify, test and verify a new way to use websockets. STOMP has already walked that path and would prevent us doing this additional work. It also comes with an extensive set of libraries we can use.
What advantages does this alternative approach have that justifies us spending this time and effort?As such I still propose that we use the STOMP approach.
Github Notifications (FHIRcast) (May 08 2019 at 13:40):
gkustas commented on Issue #104
Yes, in step 4, the hub checks that the application secret and topic are
valid (using the authentication data in the DB using our implementation). I
see how that is not exactly elegant, and I am open to any suggestion. The
problem is I don't understand how STOMP is doing for us. You mention the
steps:1. A->B : POST with channel = websocket
2. Return -> 202 Accepted – include websocket URL to be used.
3. A->B: connect to websocket URL
4. B->B detects websocket connection
5. B -> A: send intent verification (over websocket)
6. A->B: send verification response (REST-full or over websocket?)
- How does STOMP accomplish this for us? Can you provide a pseudo-code
example possibly (don't go to a lot of effort)
- I assume step 1 is the RESTful call to subscribe, and the hub would
return an endpoint similar to our implementation using some unique id?
- What is step 5-6? After step 4 isn't everything done?
- Sending and acknowledging events (although another "topic") still
needs to be considered. How will STOMP work compared to a simple JSON
approach?I will need to read more about it, but steps 1-4 seem like what we are
doing, the only difference being the hub returns the endpoint in the
Subscribe (which I like - I should have done that to begin with).Like I said, I'm open, but I was very intimidated by STOMP when I looked at
it. It seemed like a lot of work.On Wed, May 8, 2019 at 5:08 AM Bas van den Heuvel <notifications@github.com>
wrote:There are multiple topics in this discussion we should separate from each
other.Determination of the topic to be used
This is an important topic but outside the scope of the websocket
discussion. I propose to keep this in line with the current spec. The
controlling application (by magic) can create a sessions, the Smart launch
mechanism is used to communicate this to the clients. If we want to change
this, this should be handled as a separate ticket.Feedback on Basic Websocket proposal
It starts with indication that websocket is to be used using
Subscribe(hub.channel.type=websocket).
The result of this action is that: client is subscribed to a sub-set of
events to be send over websocket.Based on the session management I can distinguish between the different
web-socket sessions.
In order to send the correct events to the correct client, I need to link
the session to a subscription.
The handshake I indicated in my previous proposal will allow for such
linkage. Other approaches are also possible.
I have difficulties understanding what is meant in step 4 with “The hub
can re-authenticate the topic as belonging to the application identified by
the secret, reasonably assuring that this connection attempt is valid.” Is
this step intended to link the session to the subscription?Overall, I do agree that using the Websocket only for sending events has
it advantages. It reuses the websub pattern in an elegant way and prevents
having to implement a bidirectional protocol over websosckets.
But, the discussion presented above does provide proof that this will
require us to specify, test and verify a new way to use websockets. STOMP
has already walked that path and would prevent us doing this additional
work. It also comes with an extensive set of libraries we can use.
What advantages does this alternative approach have that justifies us
spending this time and effort?As such I still propose that we use the STOMP approach.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/HL7/fhircast-docs/issues/104#issuecomment-490410342>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABODZ3Q4PA4RHXBZR46NFB3PUKJ67ANCNFSM4HJPVEHA>
.--
George Kustas
Github Notifications (FHIRcast) (May 08 2019 at 14:13):
bvdh commented on Issue #104
The example above is not a STOMP proposal but my take on Basic Websockets.
An example of a STOMP implementation can be found at https://github.com/PhilipsOnFhir/fhir-cast
The server side implementation is https://github.com/PhilipsOnFhir/fhir-cast/tree/develop/library/src/main/java/com/github/philipsonfhir/fhircast/server/wsstomp
The client side implementation (angular)
https://github.com/PhilipsOnFhir/fhir-cast/tree/develop/websocketSTOMP is a full alternative to the websub specification. Implementing it from scratch will be more work than the Basic Websocket approach. Implementing it based on libraries is a lot easier because a lot of the current websocket deployments are using STOMP.
Github Notifications (FHIRcast) (May 08 2019 at 14:23):
isaacvetter commented on Issue #104
Resolution: Considered for future use
Websocket support is critical path for FHIRcast, we still need more implementer feedback and experience. Following STU1 ballot, will publish #57 and specifically test websocket support at connectathon in Sept.
Mover: Isaac, Niklas
Affirmative, Abstention, Negative: 14-0-0
Github Notifications (FHIRcast) (May 08 2019 at 14:23):
wmaethner labeled Issue #104
## May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (May 08 2019 at 16:59):
gkustas commented on Issue #104
Thanks Isaac. I agree we all need more experience. I hope we can attract
all the players to FHIRCast.Thanks to you too Bas. I started looking at your angular app to get a
better understanding. I'd like to continue the conversation sometime. Right
now Nuance is pushing us to get this going, so I'm hoping that whatever I
implement at least comes close to the eventual spec ;-)On Wed, May 8, 2019 at 10:23 AM Isaac Vetter <notifications@github.com>
wrote:Resolution: Considered for future use
Websocket support is critical path for FHIRcast, we still need more
implementer feedback and experience. Following STU1 ballot, will publish
#57 <https://github.com/HL7/fhircast-docs/pull/57> and specifically test
websocket support at connectathon in Sept.Mover: Isaac, Niklas
Affirmative, Abstention, Negative: 14-0-0—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/HL7/fhircast-docs/issues/104#issuecomment-490506203>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABODZ3URWW5NJWBU3LL3K6DPULO57ANCNFSM4HJPVEHA>
.--
George Kustas
Github Notifications (FHIRcast) (May 10 2019 at 13:50):
gkustas commented on Issue #104:
Bas, Can a client communicate to a FHIRCast hub that is implemented using
STOMP, without using STOMP itself?- If a vendor doesn't want to use a third party library, can they simply
send messages to the hub per the STOMP format/spec? I realize that this
would be re-building the STOMP library (or a small subset of it).
- What does STOMP do other than support a message format and initial
handshaking, and is that in a spec?
- The FHIR data is represented in JSON or XML. It would remain that way
embedded in a STOMP message, correct?I don't know if I'm making sense, because I haven't researched STOMP fully
- I am starting on it this morning.I don't think Nuance will have a problem with the third party library as
long as it is open source, but I'm concerned someone might.Thanks very much!
On Wed, May 8, 2019 at 12:59 PM George Kustas <gkustas@gmail.com> wrote:
Thanks Isaac. I agree we all need more experience. I hope we can attract
all the players to FHIRCast.Thanks to you too Bas. I started looking at your angular app to get a
better understanding. I'd like to continue the conversation sometime. Right
now Nuance is pushing us to get this going, so I'm hoping that whatever I
implement at least comes close to the eventual spec ;-)On Wed, May 8, 2019 at 10:23 AM Isaac Vetter <notifications@github.com>
wrote:Resolution: Considered for future use
Websocket support is critical path for FHIRcast, we still need more
implementer feedback and experience. Following STU1 ballot, will publish
#57 <https://github.com/HL7/fhircast-docs/pull/57> and specifically test
websocket support at connectathon in Sept.Mover: Isaac, Niklas
Affirmative, Abstention, Negative: 14-0-0—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/HL7/fhircast-docs/issues/104#issuecomment-490506203>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABODZ3URWW5NJWBU3LL3K6DPULO57ANCNFSM4HJPVEHA>
.--
George Kustas
--
George Kustas
Github Notifications (FHIRcast) (Sep 03 2019 at 22:12):
isaacvetter edited a comment on Issue #104:
Montreal May 2019 Working Group Vote
@isaacvetter moved the following disposition, seconded by Niklas
Disposition: Considered for future use
Disposition Comment: Websocket support is critical path for FHIRcast, we still need more implementer feedback and experience. Following STU1 ballot, will publish #57 and specifically test websocket support at connectathon in Sept.:+1: For: 14
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (FHIRcast) (Sep 03 2019 at 22:13):
isaacvetter assigned Issue #104:
May 2019 Ballot Comment: Include web sockets proposal
Submitted by @MichaelTClifton on behalf of @isaacvetter (isaac@epic.com )
Chapter/section: Overall
Url:
Type: NEG :exclamation: EnhancementSummary: Include web sockets proposal
Comment: We should include the draft web sockets interactions as defined in this github PR: https://github.com/HL7/fhircast-docs/pull/57
Multiple implementers have tested this functionality.
_This issue was imported by @hl7-fhircast-bot from the consolidated FHIRcast May 2019 ballot spreadsheet._
Github Notifications (FHIRcast) (Sep 03 2019 at 22:14):
isaacvetter commented on Issue #104:
No action as part of ballot resolution is necessary for this issue, but leaving open to merge websocket proposal into draft spec as soon as ballot is published.
Last updated: Apr 12 2022 at 19:14 UTC
