HNTF/Home Network TF Discussions/ServiceMigration

From Web and TV IG

Service Migration

Submitter: Jean-Claude Dufourd, Telecom ParisTech

Tracker Issue ID: ISSUE-7

Description: An application moving across HNTF user agents in a decentralized situation (local application, without a server).

A radio service is split into a radio application which resides typically on a HiFi, TV, personal music player or computer, and a radio controller application which resides on a device with intuitive interaction capability such as a phone, computer or tablet. The radio application is implemented as a document exposing a service interface on the network, and has a state that needs preserving if the document is migrated. The radio controller application is a pure interface, and does not have its own state.

The radio application does not have a visual interface. The radio application exposes a service of type JCDsRadioApp with seven possible messages:

  • setURI(radioStationURI, radioName),
  • play(),
  • stop(),
  • setVolume(n),
  • getURI(),
  • getRadioName(),
  • getPlayState(),
  • getVolume().

The radio application is running on a TV set.

The radio controller application has a visual interface, comprising:

  • a button to choose the radio station.
  • a play button.
  • a stop button.
  • a label for the current radio station name.
  • a volume bar to display the current volume.
  • two buttons to increase and decrease the volume.

The radio controller application is running on a smartphone. The radio controller application looks for a service called JCDsRadioApp by using the HNTF discovery mechanism, then establishes a connection with the above application. The radio controller application gets the radio name, volume, play state of the radio application and displays that information.

The stage is now set.

The user wants to move from the TV in the main room to the computer in her office:

  • In the HNTF user agent on the TV, the user requests to migrate the radio application.
  • The TV HNTF UA looks for other HNTF UAs on the network, by discovering service "HNTFUserAgentv1.0".
  • The result of the discovery is a list of HNTF UAs: the one on the phone, the one on the computer, possibly other ones.
  • The user selects the HNTF UA running on the computer.
  • The TV HNTF UA sends the message migrate(appURI, contextURI) to the computer HNTF UA.
  • The computer HNTF UA requests the appURI to get the radio application, then requests the contextURI, which contains all the information needed to place the radio application in the same state it was in on the TV.
  • The computer HNTF UA loads the radio application, then the context. Loading the context first sets the volume to half and the station to "Jazz".
  • Then the computer HNTF UA exposes a service of type JCDsRadioApp.
  • Then the smartphone HNTF UA understands that its connection to the radio application in the TV is down, so it starts again a discovery of service type JCDsRadioApp. It finds one on the computer HNTF UA, and sends a connection request.
  • The computer HNTF UA receives a connection request from the device mentioned in the migration context as formerly connected. It accepts the connection without requiring a user validation.

End of migration.

When moving the radio document, the following needs to be preserved:

  • the service needs to be restarted and exposed on the new device
  • the connection to the (same) radio controller needs to be reestablished
  • the radio needs to be playing the same station, with the same volume, etc.

Another possible example is a multi-user game, e.g. with lots of players sending location and activity information about their character/cars. Upon migration, the game state needs to be transfered to the new device, and the connections to other players need to be reestablished.

Implementation:

Justification:

  • no way to discover a service from an application
  • no way to expose a service from an application
  • no way to move an application to another device and restart it while keeping an execution context

Dependencies:

This use case depends on discovery. This is a refinement of ISSUE-15, where the migrated document uses a service rather than exposes a service.

Comments: This use case also advocates for multiple bindings on one single interface in the case of the multi-user game.

Former comments on this UC have been moved to the Document Migration use case.

Retrieved from "https://www.w3.org/2011/webtv/wiki/index.php?title=HNTF/Home_Network_TF_Discussions/ServiceMigration&oldid=513"