Scenarios

On this page different scenarios are presented where data has to be streamed. It provides a common base to design a web service streaming specification.

Firewire camera with remote control

A personal computer with an attached video camera that could be remote controlled.

  • Device: Computer
    • Service: Firewire video cam
      • Web service operations (request-response MEP) to set and get focal length, zoom, ...
      •  RTP stream (rtp://239.35.129.11:10000)

Notes:

  • In this scenario the stream refers to a hosted service (the remote controll service)
  • Only meta data must be provided, no additional operation must be included in the WSDL for the stream itself.

Patient monitor

  • Device: Patient monitor
    • Service: SPO2
      • ...
    • Service: ECG
      • Web service operations to set alarm boundaries for example
      • Events (according to  WS-Eventing) for alarms
      • SOAP-over-UDP multicast stream with ECG data (soap.udp://239.12.23.23:12345)

Notes:

  • WS-Eventing changed the notation in WSDLs. In the first version it uses output operation in the WSDL while the current W3C draft uses NotificationWSDLs. The new approach is does not conflict in cases where we have notifications that are not handles with WS-Eventing.
  • See SOAP-over-UDP-Multicast for a possible solution

GPS receiver

  • Device: GPS receiver (with wifi or 6lowPan :-)
    • Service: no operation, just position data, thus no real hosted service
      • SOAP-over-UDP stream with position data (1 to 10 times a second depending on the model)

Note:

  • Only SOAP-over-UDP is used for this service. A HTTP binding is only necessary to provide meta data information such as the WSDL with the SOAP message specification.

Internet Radio

  • Device: Internet radio (without remote control)

Notes:

  • No web service, do we want to handle this (the firewire cam has web services for remote control)?
  • The URL looks like a normal web services endpoint (conflicts?).

Tracking Server

  • Device: Tracking Server (e.g. for NDI) that sends location data (position, rotation) of some marker in a proprietary format in a regular interval.
  • Such devices are used for navigated interventions in the OR and the data may be used by multiple devices in parallel (orthoMIT or FUSION scenario)
  • Very small frames are send in a typical framerate of 20-60 Hz.

OSAmI Scenario Device Integration

  • OSAmI uses a common device integration component in the OSGi based OSAmI platform for integration of devices like medical devices into applications
    • Device Integration is Technology-independent -> Applications don't depend on DPWS, Bluetooth, ZigBee?, ...
    • Device Integration is based on OSGis service concept to integrate "device services"
    • Device Integration consists of guidelines how to design device service interfaces
      • offers stream concept based on Java object streams
    • Drivers implement device service interfaces
      • DPWS can be directly mapped to device service interfaces -> One generic driver for all device services
      • How to implement Stream feature in an interoperable way with DPWS?
      • Streaming technology depends on device.
      • How to describe stream?

OSAmI Scenario Remote Services

  • OSGi is a base technology for local service oriented architectures
  • With the Remote Service Specification OSGi also supports distributed services
    • This specification doesn't define distribution technology but only required interfaces in OSGi
    • Any distribution technology can be used to implement OSGi remote services
  • OSAmI uses a Remote Service implementation based on DPWS
    • Distributed service interfaces offer Java Streams. How to implement Streams in an interoperable way with DPWS?
    • Technology is clear: DPWS+MTOM+ Object Serialization Stream Protocol
    • How to describe stream?

MEDIBUS Scenario

Mail from Christian Mauro, to be translated to english:

  • Ich habe mir mal die Dräger MEDIBUS Spezifikation für Beatmungsgeräte angesehen (das könnte man auch gleich als weiteres Szenario nehmen, ist aber wohl dem Monitoring sehr ähnlich, oft werden Beatmungsgeräte ja an einen Monitor angeschlossen und über diesen die Daten bezogen). Dort ist ein Realtime-Modus beschrieben, der im Wesentlichen nichts anderes als Streaming ist. Aus den dort beschriebenen Funktionalitäten könnte man folgende weitere Anforderungen für WS-Streaming ableiten:
  • Neben subscribe/unsubscribe wird eine Funktionalität benötigt, um die Konfiguration des laufenden Streams ändern zu können (bspw. um das Sendeintervall oder Dinge wie Videoauflösung, Linseneinstellung, etc. zu ändern). Alternativlösung wäre ein unsubscribe, gefolgt von einem subscribe mit den neuen Parametern, was aber etwas unhübsch wäre. Vermutlich reicht einfach ein subscribe mit der neuen Konfiguration. Daraus würden sich dann 2 Anforderungen ergeben
    • Bei einem subscribe erzeugt der Service eine eindeutige Id für den subscribe. In der subscribe Bestätigung wird die Id mit zurückgegeben (braucht man ja vermutlich eh für den späteren unsubscribe?)
    • Beim einem subscribe kann optional eine subscribe Id mit übergeben werden. In diesem Fall handelt es sich nicht um einen neuen subscribe sondern um eine Konfigurationsänderung eines vorherigen subscribe. Entsprechend braucht es eine Fehlerrückmeldung, falls die Id nicht (mehr) existiert.
  • Es wird eine Funktionalität benötigt, um den Client darüber zu informieren, dass sich am laufenden Stream etwas an der Konfiguration geändert hat. In der MEDIBUS Spezifikation wird als Beispiel die Wahl eines anderen Narkosegases beschrieben. Bei bildgebenden Verfahren wäre denkbar, dass manuell Dinge wie Auflösung, Fokus, Zoom, etc. geändert wurde. Ansonsten müsste man immer die komplette Streamkonfiguration bei jedem Datenpaket mitsenden. => Abbildung dieser Funktionalität über WS-Eventing ausreichend? Vielleicht sollte es bei WS-Streaming standardmäßig einen Event StreamingConfigurationChanged? oder Ähnliches geben?
  • Bei MEDIBUS lässt sich die aktuelle Streamkonfiguration abfragen. Könnte so etwas Sinn machen? Es wird dazu benutzt, um nach dem Event "Realtime Configuration Changed" dem Client die Möglichkeit zu geben, die aktuelle Konfiguration abzufragen. Diese Infos könnte man allerdings auch mit dem Event mitschicken. Vielleicht gibt es aber ja Szenarien, wo sowas Sinn macht? Auf jeden Fall macht es Sinn, die Konfiguration in der subscribe-Bestätigung mitzuschicken.
  • Der Client kann einen unsubscribe senden. Wie aber meldet ein Service einem Client, dass ein Stream zu Ende ist? Reicht es, solche Dinge auf Ebene des jeweiligen Streamingprotokolls zu regeln?