The purpose of the document is to explore the tasks required, and issues involved in incorporating 3rd party UPnP implementations. One of the first questions to ask is what parts of the implementation are going to be replaced. The OCAP RI implements several aspects of UPnP in order to be a DLNA compliant DMS and DMP. On top of that, it implements the HN-EXT API in terms of this underlying implementation. Here is an enumeration of several of the functional areas implemented, please refer to the HNP specification for details.
The 3rd party implementation may account for some or all of the above areas of functionality.
The RI implements most UPnP related activities in the OCAP Java stack. The exception to this is servicing HTTP requests for recorded and live content. In the case of content delivery the RI listens and takes the request in from the Java stack, formulates and sends the HTTP headers, then passes the socket through to the MPE porting layer to a native C implementation that is responsible for sending the content that was requested.
All advertisement and listening to incoming requests is done using an open source 3rd party library called Cybergarage. The version of Cybergarage we use is 1.6, but it has been heavily modified in order to satisfy requirements unique to OCAP as well as to be compliant and pass UPnP & DLNA certification tests. In OCAP 1.2, the UPnP Diagnostics API was introduced and includes unique requirements that call for the ability to view and modify all incoming and outgoing message traffic, including SSDP and SOAP requests and responses. This low level API is not traditionally found in 3rd party libraries and can represent a substantial amount of work by integrators in order to satisfy the specification.
There are several approaches that can be taken. Each has a different level of involvement and risk.
This is the class that initializes the UPnP device and services provided by the RI. This could be left alone if using the UPnP Diagnostics API to initialize the device and services.
The implementation here utilized the Cybergarage Device class. This could be replaced with JNI calls or use of another Java API that provides similar semantics.
This class holds an in memory object graph of sub-devices, services, icons and state variables as constructed using the UPnP Diagnostics API. Since Cybergarage like many 3rd party APIs does not allow for online manipulation of it's data structures, this class will remove and reload the Cybergarage Device class every time there is a change to the object graph representing this device and it's components. After reloading this class walks the re-created Device in Cybergarage and reassociates the Cybergarage constructs with the UPnP Diagnostics equivelents, Cybergarage Service to UPnPManagedService and so on.
These interfaces are perhaps the most difficult to implement with a 3rd party library. We had to heavily modify the cybergarage code in order to implement the APIs that allow this feature.
Data structure that contains all of the properties for a container or item. In the RI implementation this class is used in both client and server functionality. In order to facilitate both functions, MetadataNodeImpl can be constructed from and can produce an XML DIDL-Lite fragment. If a reimplementation includes CDS functionality, there needs to be a mapping created for MetadataNode. There are three main areas of difficulty to be aware of.