Architectural Overview

Coherence can be sectored into three zones - the core, the devices and their backends.

Coherence-Architecture

The Core

The core of Coherence provides a (hopefully complete) implementation of

  • a SSDP server,
  • a MSEARCH client,
  • server and client for HTTP/SOAP requests, and
  • server and client for Event Subscription and Notification (GENA)
  • a growing number of UPnP service interfaces

And a large wharf for device implementations to dock at.
This should allow any coupled up device to stay away from the wire, handing off any communication related task to the core.

The Devices

Around the core UPnP device implementations can be grouped.
These device implementations link to the core by their respective UPnP service interfaces.

A MediaServer for example is supposed to provide four services:

ContentDirectory and ConnectionManager are required services, whereas AVTransport and ScheduledRecording? are optional.

So if a MediaServer device implementation registers with the core, it at least has to establish linkage with the ContentDirectory and ConnectionManager interfaces the core offers.

The core sets up these service interfaces per device and upon request. They are autogenerated out of 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 only has to attach callbacks to the Actions that require maybe a backend interaction and return the required 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 and declares which service interfaces it is using and attaches callbacks which map the service Actions to its backend. It also can request to get notified upon any other device/service presence announcements or notices of departure the core receives.
  • the core generates an UUID
  • the core creates a node with an uri looking like http:/address/uuid:foobar/ in its web-server tree representing the root of the device and mounts beneath
    • the device description
    • the service descriptions
      • their SOAP interfaces for the services Action calls
      • their interfaces for StateVariables? Event Subscription requests
    • any (x)html fragment, that the device wants to send out as its presentation
    • any backend content, e.g. audio,video,image,... files, the device wants to expose via its backend
  • the core sends out a SSDP presence announcement for the device and the services and adds them to the list for periodic SSDP alive notifications
  • the core takes orders from other devices for StateVariable? Event Subscriptions and sends out the Event Notifications upon the StateVariable? change
  • or subscribes for other devices StateVariable? Events and informs the device implementation about incoming Event Notifications
  • if the core receives a SOAP request for a services 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 in the Action call only the querying of StateVariable? values is involved the core just returns their current values without further bothering 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 in conclusion 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 addressed before a backend for a file-system could provide for example a more abstracted view, it could parse the tags of the audio files and present the content in a presorted manner. Or we detach ourselves right from the start from that plain file-system conception and let the backend connect to some MediaStore?, access the recordings of a MediaCenter? or subscribe to Flickr or YouTube.

Or by opening a new worm-hole to the next universe, we can take the content of an iPod or translate between DAAP and UPnP A(/V).

Or to bring in a first flash of Convergence, access the VoiceBox? of an Asterisk or some similar VoIP system.

Same for a MediaRenderer device. Beside the direct audio/video hardware access we could relay to a MediaCenter? or more likely at first sight a MediaClient? like the MediaMVP, using their specific remote control protocol.

Attachments