SOPA - Self Organizing Processing and Streaming Architecture

SOPA v0.9

What is SOPA?

SOPA is the architecture of a multimedia component framework. It envisiones a general processing and streaming architecture featuring autonomous assembly of stream processing components. The goal is to provide an easy to use framework where dynamically organized processing graphs are build out of components from various distributed sources. Based on state-of-the-art solutions for component based software development the system simplifies the implementation and the configuration of multimedia streaming applications and associated tools. It supports stream synchronization transparently while extending components are installed on the fly according to the existing requirements that may change at any time. SOPA is an essential part of the lecture recording system E-Chalk.

For whom is SOPA?

SOPA is aimed at developers of multimedia technology that includes the streamed processing of timed multimedia data. SOPA abbreviates the path between the assembly of prototype components and their glueing for the final release. When you have working components, you are ready to release as SOPA will handle the assembly.

What is the Difference between SOPA and ...?

• JMF
  JMF is a Java API that supports capture, playback, streaming and transcoding of audio, video, and other time-based media. It also provides a plug-in architecture that enables developers to support custom data sources and sinks, effect plug-ins, and CODECs. JMF supports a wide variety of different specifications, including various sound formats, MPEG-1 (ISO/IEC 11172), H.261 (ITU-T Recommendation H.261, 1990), H.263 (ITU-T Recommendation H.263, 1998), Macromedia Flash, and others. Although their plug-in loading mechanism can load classes at runtime, they do not offer package dependency checking or automatic updating, as one would expect from a well defined component management. It is therefore not suitable as a base for a dynamically configurable system. The main disadvantage, however, is its complexity. JMF consists of 11 packages of 212 different classes and interfaces. They are deduced from the properties and technological restrictions of the supported hardware and the implemented formats.
  

• MAC OS X Audio Toolbox
  Apple's MacOS X operating system's audio core contains a package called Audio Toolbox. Inside this, one can find the AUGraph API. An AUGraph is a high-level representation of a set of so called AudioUnits, along with the connections between them. AudioUnits are used to generate, process, receive, or otherwise manipulate streams of audio. They are building blocks that may be used singly or connected together to form the audio signal graph. Information to and from AudioUnits is passed via properties. AudioUnits are identified by a string based, Apple propietary, hierarchic identification mechanism. One can use the API to construct arbitrary signal paths through which audio may be processed, i.e., a modular routing system. The API deals with large numbers of AudioUnits and their relationships. AudioGraphs allow realtime routing changes, that means connections can be created and broken while audio is being processed. Apples API comes very near to what is described in this paper. However, the API is restricted to audio and - although available in Java - can only be used in Mac OS X. There is also no concept for self configuration or distributed programming.
  
  
• Microsoft Direct Show
  Microsoft Operating Systems also contain a component architecture for multimedia streaming and processing. They are distributed under the Direct Show API. Direct Show also features dynamic assembly of stream processing graphs. However, Direct Show contains no layer on the administrative end, i.e. all the assembly has to be done on the devlopment level. DirectShow is not platform independent and does not feature remote discovery.
  

The main difference between SOPA and the above mentioned frameworks is that SOPA is an abstract general framework that is to build by conceptual demands and not by technological push. Technology is later filled in by implementors that want to create concrete applications.

What Technologies does SOPA rely on?

• SOPA is implemented in Java.
  
• It relies on Oscar, a free implementation of the OSGi standard.
  
• It uses Eureka for remote component discovery.
• It needs SAX as an XML parser.
  

I want to try it - where can I get SOPA?

Source:

• SOPA is released under the GNU LGPL. Source code will be available soon at Sourceforge.

Binaries:

• You can download the jar file here.
  

Documentation:

• A conceptual Technical Report
• An overview of how to create OSGi componets
• The SOPA API documentation
• Code templates for a SOPA Node (or as to demonstrate that it isn't all that complicated)

Examples that use SOPA:

• If you want to see SOPA in action, you should visit E-Chalk's homepage.
• Exymen shares the bundle cache with SOPA.
• Protypes and demonstrators benefit from the reuse of SOPA components.
  

Who should I contact for further Questions?

Contact echalk@inf.fu-berlin.de for further questions.