Stream: fhircast-github
Topic: docs / Issue #33 why must a subscriber have an accessible...
Github Notifications (FHIRcast) (May 29 2018 at 14:45):
isaacvetter edited Issue #33
During the HL7 working group meeting in May in Köln, there was strong feedback from @bvhd and @joshmandel a subscriber ought not to be required to host an accessible url. WebSub requires that the subscriber host an accessible url which receives notifications.
This requirement can dictate a subscriber's use of a client/server architecture. Alternatives could include using a long-running server/client communication method such as HTTP Long-Polling/Comet, HTML Server Sent Events (SSE) or websockets, thereby allowing the subscriber to not host a url accessible to the Hub.
The downside to these approaches is that the use of proxies (proxy or reverse proxy servers, firewalls, load-balancing routers and so on) between the browser and the Hub which are often designed for short-lived HTTP requests and multiple network hops increase the expense of keeping sockets.
Generally, long-polling is the most primitive and expensive method. Server-Sent Events are uni-directional (server->client) and further, are not supported by IE 10 or 11. Websockets is the server <->client contender.
Is the use of websockets viable? Hosting FHIRcast applications within the same network as the Hub would help address common problems experienced due to proxies. What about a hub or client hosted within a multi-application/user app server, such as Citrix? -- a common deployment method for fat clients in healthcare.
Github Notifications (FHIRcast) (May 29 2018 at 17:25):
isaacvetter assigned Issue #33(assigned to isaacvetter)
During the HL7 working group meeting in May in Köln, there was strong feedback from @bvhd and @joshmandel a subscriber ought not to be required to host an accessible url. WebSub requires that the subscriber host an accessible url which receives notifications.
This requirement can dictate a subscriber's use of a client/server architecture. Alternatives could include using a long-running server/client communication method such as HTTP Long-Polling/Comet, HTML Server Sent Events (SSE) or websockets, thereby allowing the subscriber to not host a url accessible to the Hub.
The downside to these approaches is that the use of proxies (proxy or reverse proxy servers, firewalls, load-balancing routers and so on) between the browser and the Hub which are often designed for short-lived HTTP requests and multiple network hops increase the expense of keeping sockets.
Generally, long-polling is the most primitive and expensive method. Server-Sent Events are uni-directional (server->client) and further, are not supported by IE 10 or 11. Websockets is the server <->client contender.
Is the use of websockets viable? Hosting FHIRcast applications within the same network as the Hub would help address common problems experienced due to proxies. What about a hub or client hosted within a multi-application/user app server, such as Citrix? -- a common deployment method for fat clients in healthcare.
Github Notifications (FHIRcast) (Jun 26 2018 at 15:41):
isaacvetter commented on Issue #33
@lbergnehr , @wmaethner and I talked through this issue offline today.
This issue is important for enabling simple, standalone native apps (desktop and mobile) and single page applications and also potentially improves the user experience of synchronization (app receives notifications faster). This moves effort from the subscribing app and puts it on the Hub, which seems appropriate. Further, support of web sockets also means that a internet-hosted sandbox (not running locally) can be tested against with a local app, which should improve the onboarding of new developers.
Websocket support is available starting in IE 10, and is widely supported by both browsers and various libraries.
I'm going to draft a PR that adds web socket support for the event notification message that's sent from the Hub over a connection established by the the subscribing app. We're going to keep the existing rest hook/ WebSub messaging mechanism as well.
Hubs MUST support the rest hook method and SHOULD also support web socket connections. This creates optionality, the enemy of interoperability, but we think that it's appropriate in this case.
The bidirectional event notification requests described in #24 will remain distinct HTTP Posts (not use the web sockets communication channel). This allows the Hub to support only a single mechanism for receiving these requests, while allowing the client to potentially not have a web server.
Github Notifications (FHIRcast) (Sep 30 2018 at 15:48):
isaacvetter commented on Issue #33
In conversation with Glenn Potter, Sagy Mintz, @jeremysrichardson during the FHIR connectathon this weekend, we talked through the importance of a websocket-type communication channel for FHIRcast and, on Sunday, decided on this path forward:
1) Continue with rest-hook support in the first iteration of the specification. While a rest-hook approach does require the subscribing app to host a publically accessible endpoint, this is both reasonable and simpler for a significant number of subscribing applications.
2) Add optional and experimental websocket support to the specification following the lead of FHIR Subscriptions. This area needs implementer feedback and is likely to change.
Github Notifications (FHIRcast) (Oct 03 2018 at 12:44):
isaacvetter {} a comment on Issue #33
In conversation with Glenn Potter, Sagy Mintz, @jeremysrichardson during the FHIR connectathon this weekend, we talked through the importance of a websocket-type communication channel for FHIRcast and, on Sunday, decided on this path forward:
1) Continue with rest-hook support in the first iteration of the specification. While a rest-hook approach does require the subscribing app to host a publically accessible endpoint, this is both reasonable and simpler for a significant number of subscribing applications.
2) Add optional and experimental websocket support to the specification following the lead of FHIR Subscriptions. This area needs implementer feedback and is likely to change.Draft
## WebSockets
Following WebSub, FHIRcast is modeled on a rest-hook interaction in which a subscribing app receives notifications over REST. Some apps may be unable to expose an outward-facing HTTP server to receive triggered notifications. For example, a pure client-side Web app or mobile app may want to receive notifications of context changes directly. This can be accomplished using a websocket notification channel.This capability is experimental, likely to change and implementer feedback is welcome.
- Client authenticates to server using a server-specified Web socket protocol (e.g. OAuth bearer token presentation).
- Client sends a bind :id message over the socket (using the logical id of the subscription). For example, the client might issue: bind 123).
- Server responds with a "bound :id" message to acknowledge.
- Server sends a "ping :id" message to notify the client each time a new result is available
Github Notifications (FHIRcast) (Oct 16 2018 at 16:38):
gkustas commented on Issue #33
Thanks @isaacvetter ,
At Nuance we are just starting with FHIR, and we were wondering what the community was doing about this issue. We want to avoid installing SSL certs on EVERY one of our desktop clients. We were wondering if SignalR was going to be supported, because there are the beginnings of implementation in the sandbox source code :-)
We are happy to start our prototype using the webhooks (rest-hook) on our clients if we know that we have other radiology vendors (like Sectra and Epic) to test it against. I look forward to further discussion!
Github Notifications (FHIRcast) (Oct 16 2018 at 16:55):
gkustas {} a comment on Issue #33
Thanks @isaacvetter ,
At Nuance we are just starting with FHIR, and we were wondering what the community was doing about this issue. We want to avoid installing SSL certs on EVERY one of our desktop clients. We were wondering if SignalR was going to be supported, because there are the beginnings of implementation in the sandbox source code :-)
We are happy to start our prototype using the webhooks (rest-hook) on our clients if we know that we have other radiology vendors (like Sectra and Epic) to test it against. I look forward to further discussion!
We are also interested in participating with the experimental WebSockets if it will eliminate the need for SSL certs and provide robust security as well. Is that something I can assume? How is the data encrypted over a websocket, or isn't it?
Github Notifications (FHIRcast) (Nov 20 2018 at 22:07):
isaacvetter commented on Issue #33
Hey @gkustas, apologies for the delayed response.
As Leo pointed out in another issue, websockets are securing via TLS using the wss protocol.
The problem with SignalR is that it's not a standard and wraps the bare websocket communication with it's own thin, comm layer, such that only a SignalR client can communicate with a SignalR server.
To support websockets in FHIRcast, we can't mandate use of a tech-stack specific technology.
Happy to talk more about this as you work on websockets.
Last updated: Apr 12 2022 at 19:14 UTC
