Architectural Overview

  1. Architectural Overview
    1. The Core
    2. The Devices
    3. The Backends



Architectural Overview

Coherence is divided into three main parts: the core, the devices, and the device backends.

Coherence-Architecture

The Core

The core of Coherence provides a implementation of:

  • a SSDP server,
  • a MSEARCH client,
  • server and client for HTTP/SOAP requests
  • server and client for Event Subscription and Notification (GENA)
  • a growing number of UPnP service interfaces
  • a large wharf at which device implementations can dock. This allows a docked device to hand off any communication-related tasks to the core.

The Devices

Device implementations are linked to the core by their respective UPnP service interfaces.

For example, a MediaServer can provide four services:

ContentDirectory and ConnectionManager are required services, whereas AVTransport and ScheduledRecording? are optional. This means that when a MediaServer implementation registers with the core, it must at least establish linkage with the ContentDirectory and ConnectionManager interfaces the core offers.

The core sets up service interfaces per device and on request. These service interfaces are autogenerated from the UPnP schema files and produce a complete set of StateVariables? and Actions.

To ease the burden of the device implementation, it needs only to update the StateVariables?, any relating Event Notification is done by the core.

The Actions are organized quite similarly. Actions that return only StateVariables? are handled within the core. The device implementation has only to attach callbacks to the Actions that require backend interaction and return the resulting arguments from that call. The result is transfered to the requesting client. Any StateVariables? within that result are updated automatically and the related Event Notifications are again handled by the core.

In a summary:

  • a device implementation registers with the core, declares which service interfaces it is using, and attaches callbacks which map the service Actions to its backend. It can also request to be notified upon any other device/service presence announcements or notices of departure the core receives.
  • the core generates a UUID
  • the core creates a node with an URI of the form "http:/address/uuid:foobar/" in its web-server tree representing the root of the device and creates the following subnodes:
    • device description
    • service descriptions
      • SOAP interfaces for the services Action calls
      • interfaces for StateVariables? Event Subscription requests
    • any (x)html fragment, that the device wants to send out as its presentation
    • any backend content, such as audio, video, or image files that the device implementation wants to expose via its backend
  • the core sends out a SSDP presence announcement for the device and services, and adds them to the list for periodic SSDP alive notifications
  • the core takes requests for StateVariable? Event Subscriptions from other devices and sends out the Event Notifications upon the StateVariable? change. The core can also subscribe to other devices StateVariable? Events and inform the device implementation about incoming Event Notifications
  • if the core receives a SOAP request for a service's Action call, it checks whether there is a callback to the backend attached for that action. If so, the callback is called with the incoming arguments and the result of the callback is sent back to the caller. Any StateVariables? values in the result are used to update the services StateVariables?, which may lead to Event Notifications.

If querying of a StateVariable?'s value is the only purpose of the Action call, the core simply returns the StateVariable?'s current values without further interaction with the backend.

  • the core responds to SSDP discovery requests with SSDP presence announcements
  • if a device unregisters the core sends out SSDP bye-bye notifications

The Backends

This is the place where the 'real' work gets done.

The backends are the worm-holes out of the UPnP universe into other worlds:

  • file-systems
  • audio/video hardware
  • some User Interface

to name the obvious ones for UPnP A/V devices.

As mentioned before, a backend for a file-system might provide a more abstracted view. For example, it could parse the tags of the audio files and present a presorted content list to the client. We can also drop plain the file-system concept completely and let the backend connect to a MediaStore?, access the recordings of a MediaCenter?, or subscribe to Flickr or YouTube.

Other possibilities for 'opening a new worm-hole' exist: we can list the content of an iPod, translate between DAAP and UPnP A(/V), or, to bring in a first flash of Convergence, access the VoiceBox? of an Asterisk or similar VoIP system.

The same principle applies to a MediaRenderer device. Besides the direct audio/video hardware access, we could relay to a MediaCenter? or more likely at first sight a MediaClient? such as MediaMVP, using their specific remote control protocol.

Attachments