middleware + multimedia = multimedia middleware?

2
Digital Object Identifier (DOI) 10.1007/s00530-002-0060-5 Multimedia Systems 8: 395–396 (2002) Multimedia Systems © Springer-Verlag 2002 Introduction to Multimedia special issue on multimedia middleware Middleware + multimedia = multimedia middleware? Thomas Plagemann Department of Informatics, University of Oslo, P.O. Box 1080, Blindern, 0316 Oslo, Norway This special issue is based on the Multimedia Middleware (M3W)Workshop held at the 9th ACM Multimedia Conference in Ottawa 2001. The workshop was well attended and charac- terized by very interactive and constructive discussions. Most participants stayed in the meeting room even during lunch to proceed with discussions – and that after three days of the ACM Multimedia Conference. The success of the workshop has finally led to this special issue. The authors of the 12 best papers at the workshop have been invited to submit a full journal paper to compete for publication. Based on the rec- ommendations of the M3W Program Committee, which did an excellent job in reviewing all submissions for this special issue, we present here four papers. These papers describe: novel solutions for integrated runtime support in QoS-aware middleware; dynamic end-to-end QoS management middle- ware; proxy architectures for collaborative media streaming; and abstractions for multimedia streaming. The topics of the four papers already indicate the broad range of research questions that are studied in the context of multimedia middleware, and readers who refer to the work- shop’s web page 1 will see even more topics of interest for multimedia middleware. Since the range of topics is so broad, it is legitimate to ask whether there is actually a clear defini- tion and scope of multimedia middleware. A straightforward definition might be that multimedia middleware covers all re- search topics related to the use of middleware for multimedia applications. The follow up question for readers familiar with the meaning of multimedia would probably be: What is mid- dleware? A short answer to this question could be that there is no clear definition. For many researchers and developers, the term ‘middleware’ is today synonymous with object-based middle- ware, like the OMG’s CORBA or Microsoft’s DCOM. How- ever, object-based middleware is only one type of middleware besides others like event-based and message-oriented middle- ware. Since multimedia middleware might be seen as another type of middleware, we refer to a more basic definition of middleware from Geoff Coulson 2 : The role of middleware is to ease the task of designing, pro- gramming and managing distributed applications by provid- 1 http://www.ifi.uio.no/m3w/ 2 http://dsonline.computer.org/middleware/index.htm ing a simple, consistent and integrated distributed program- ming environment. Essentially, middleware is a distributed software layer, or ‘platform’ which abstracts over the com- plexity and heterogeneity of the underlying distributed envi- ronment with its multitude of network technologies, machine architectures, operating systems and programming languages. In other words, abstraction away from complexity and het- erogeneity is the main goal of middleware. In this context, it is important to note that multimedia applications increase the heterogeneity problem. First, there exist many different en- coding formats for video, audio, graphics, etc. To relieve ap- plication developers from format considerations, multimedia middleware should provide services for compatibility control and management, e.g. implicit transcoding to allow peers with incompatible media formats to communicate. Secondly, the QoS requirements of communication partners might be dif- ferent due to end-user demands or available resources. Multi- media middleware should thus include QoS management ser- vices that establish and maintain (if possible) a QoS agreement that satisfies all peers [1]. Thirdly, there are already several QoS solutions at different system levels, e.g. intserv and diff- serv networks, adaptive CPU schedulers, self-adapting video players, and QoS aware Object Request Brokers. The reuse of existing QoS solutions and their combination and integra- tion in a single session requires a solution to this particular type of heterogeneity problem. Thus, Ecklund et al. describe in this special issue a dynamic end-to-end QoS management middleware platform that addresses this problem and shows how legacy QoS solutions can be integrated. Another problem addressed in this paper is the dynamic nature of sessions. The application structure as well as the configuration of the system can be changed during an ongoing session. Consequently, the QoS management structure has to be adapted accordingly, and is therefore dynamic. To manage QoS and get at the application level informa- tion about the system state to improve application adaptation, openness of the system and control over the system are nec- essary. In addressing these needs, Baochun et al. present an integrated runtime QoS-aware middleware framework. This is designed to provide runtime support for all stages of QoS

Upload: thomas-plagemann

Post on 15-Jul-2016

227 views

Category:

Documents


1 download

TRANSCRIPT

Digital Object Identifier (DOI) 10.1007/s00530-002-0060-5Multimedia Systems 8: 395–396 (2002) Multimedia Systems

© Springer-Verlag 2002

Introduction to Multimedia special issue on multimedia middleware

Middleware + multimedia = multimedia middleware?

Thomas Plagemann

Department of Informatics, University of Oslo, P.O. Box 1080, Blindern, 0316 Oslo, Norway

This special issue is based on the Multimedia Middleware(M3W)Workshop held at the 9thACM Multimedia Conferencein Ottawa 2001. The workshop was well attended and charac-terized by very interactive and constructive discussions. Mostparticipants stayed in the meeting room even during lunch toproceed with discussions – and that after three days of theACM Multimedia Conference. The success of the workshophas finally led to this special issue. The authors of the 12best papers at the workshop have been invited to submit a fulljournal paper to compete for publication. Based on the rec-ommendations of the M3W Program Committee, which didan excellent job in reviewing all submissions for this specialissue, we present here four papers. These papers describe:novel solutions for integrated runtime support in QoS-awaremiddleware; dynamic end-to-end QoS management middle-ware; proxy architectures for collaborative media streaming;and abstractions for multimedia streaming.

The topics of the four papers already indicate the broadrange of research questions that are studied in the context ofmultimedia middleware, and readers who refer to the work-shop’s web page1 will see even more topics of interest formultimedia middleware. Since the range of topics is so broad,it is legitimate to ask whether there is actually a clear defini-tion and scope of multimedia middleware. A straightforwarddefinition might be that multimedia middleware covers all re-search topics related to the use of middleware for multimediaapplications. The follow up question for readers familiar withthe meaning of multimedia would probably be: What is mid-dleware?

A short answer to this question could be that there is noclear definition. For many researchers and developers, the term‘middleware’ is today synonymous with object-based middle-ware, like the OMG’s CORBA or Microsoft’s DCOM. How-ever, object-based middleware is only one type of middlewarebesides others like event-based and message-oriented middle-ware. Since multimedia middleware might be seen as anothertype of middleware, we refer to a more basic definition ofmiddleware from Geoff Coulson2:

The role of middleware is to ease the task of designing, pro-gramming and managing distributed applications by provid-

1 http://www.ifi.uio.no/∼m3w/2 http://dsonline.computer.org/middleware/index.htm

ing a simple, consistent and integrated distributed program-ming environment. Essentially, middleware is a distributedsoftware layer, or ‘platform’ which abstracts over the com-plexity and heterogeneity of the underlying distributed envi-ronment with its multitude of network technologies, machinearchitectures, operating systems and programming languages.

In other words, abstraction away from complexity and het-erogeneity is the main goal of middleware. In this context, itis important to note that multimedia applications increase theheterogeneity problem. First, there exist many different en-coding formats for video, audio, graphics, etc. To relieve ap-plication developers from format considerations, multimediamiddleware should provide services for compatibility controland management, e.g. implicit transcoding to allow peers withincompatible media formats to communicate. Secondly, theQoS requirements of communication partners might be dif-ferent due to end-user demands or available resources. Multi-media middleware should thus include QoS management ser-vices that establish and maintain (if possible) a QoS agreementthat satisfies all peers [1]. Thirdly, there are already severalQoS solutions at different system levels, e.g. intserv and diff-serv networks, adaptive CPU schedulers, self-adapting videoplayers, and QoS aware Object Request Brokers. The reuseof existing QoS solutions and their combination and integra-tion in a single session requires a solution to this particulartype of heterogeneity problem. Thus, Ecklund et al. describein this special issue a dynamic end-to-end QoS managementmiddleware platform that addresses this problem and showshow legacy QoS solutions can be integrated. Another problemaddressed in this paper is the dynamic nature of sessions. Theapplication structure as well as the configuration of the systemcan be changed during an ongoing session. Consequently, theQoS management structure has to be adapted accordingly, andis therefore dynamic.

To manage QoS and get at the application level informa-tion about the system state to improve application adaptation,openness of the system and control over the system are nec-essary. In addressing these needs, Baochun et al. present anintegrated runtime QoS-aware middleware framework. Thisis designed to provide runtime support for all stages of QoS

Verwendete Distiller 5.0.x Joboptions
Dieser Report wurde automatisch mit Hilfe der Adobe Acrobat Distiller Erweiterung "Distiller Secrets v1.0.5" der IMPRESSED GmbH erstellt. Sie koennen diese Startup-Datei für die Distiller Versionen 4.0.5 und 5.0.x kostenlos unter http://www.impressed.de herunterladen. ALLGEMEIN ---------------------------------------- Dateioptionen: Kompatibilität: PDF 1.2 Für schnelle Web-Anzeige optimieren: Ja Piktogramme einbetten: Ja Seiten automatisch drehen: Nein Seiten von: 1 Seiten bis: Alle Seiten Bund: Links Auflösung: [ 600 600 ] dpi Papierformat: [ 2834.5 2834.5 ] Punkt KOMPRIMIERUNG ---------------------------------------- Farbbilder: Downsampling: Ja Berechnungsmethode: Bikubische Neuberechnung Downsample-Auflösung: 150 dpi Downsampling für Bilder über: 225 dpi Komprimieren: Ja Automatische Bestimmung der Komprimierungsart: Ja JPEG-Qualität: Mittel Bitanzahl pro Pixel: Wie Original Bit Graustufenbilder: Downsampling: Ja Berechnungsmethode: Bikubische Neuberechnung Downsample-Auflösung: 150 dpi Downsampling für Bilder über: 225 dpi Komprimieren: Ja Automatische Bestimmung der Komprimierungsart: Ja JPEG-Qualität: Mittel Bitanzahl pro Pixel: Wie Original Bit Schwarzweiß-Bilder: Downsampling: Ja Berechnungsmethode: Bikubische Neuberechnung Downsample-Auflösung: 600 dpi Downsampling für Bilder über: 900 dpi Komprimieren: Ja Komprimierungsart: CCITT CCITT-Gruppe: 4 Graustufen glätten: Nein Text und Vektorgrafiken komprimieren: Ja SCHRIFTEN ---------------------------------------- Alle Schriften einbetten: Ja Untergruppen aller eingebetteten Schriften: Nein Wenn Einbetten fehlschlägt: Warnen und weiter Einbetten: Immer einbetten: [ ] Nie einbetten: [ ] FARBE(N) ---------------------------------------- Farbmanagement: Farbumrechnungsmethode: Alle Farben zu sRGB konvertieren Methode: Standard Arbeitsbereiche: Graustufen ICC-Profil: RGB ICC-Profil: sRGB IEC61966-2.1 CMYK ICC-Profil: U.S. Web Coated (SWOP) v2 Geräteabhängige Daten: Einstellungen für Überdrucken beibehalten: Ja Unterfarbreduktion und Schwarzaufbau beibehalten: Ja Transferfunktionen: Anwenden Rastereinstellungen beibehalten: Ja ERWEITERT ---------------------------------------- Optionen: Prolog/Epilog verwenden: Nein PostScript-Datei darf Einstellungen überschreiben: Ja Level 2 copypage-Semantik beibehalten: Ja Portable Job Ticket in PDF-Datei speichern: Nein Illustrator-Überdruckmodus: Ja Farbverläufe zu weichen Nuancen konvertieren: Nein ASCII-Format: Nein Document Structuring Conventions (DSC): DSC-Kommentare verarbeiten: Nein ANDERE ---------------------------------------- Distiller-Kern Version: 5000 ZIP-Komprimierung verwenden: Ja Optimierungen deaktivieren: Nein Bildspeicher: 524288 Byte Farbbilder glätten: Nein Graustufenbilder glätten: Nein Bilder (< 257 Farben) in indizierten Farbraum konvertieren: Ja sRGB ICC-Profil: sRGB IEC61966-2.1 ENDE DES REPORTS ---------------------------------------- IMPRESSED GmbH Bahrenfelder Chaussee 49 22761 Hamburg, Germany Tel. +49 40 897189-0 Fax +49 40 897189-71 Email: [email protected] Web: www.impressed.de
Adobe Acrobat Distiller 5.0.x Joboption Datei
<< /ColorSettingsFile () /AntiAliasMonoImages false /CannotEmbedFontPolicy /Warning /ParseDSCComments false /DoThumbnails true /CompressPages true /CalRGBProfile (sRGB IEC61966-2.1) /MaxSubsetPct 100 /EncodeColorImages true /GrayImageFilter /DCTEncode /Optimize true /ParseDSCCommentsForDocInfo false /EmitDSCWarnings false /CalGrayProfile () /NeverEmbed [ ] /GrayImageDownsampleThreshold 1.5 /UsePrologue false /GrayImageDict << /QFactor 0.9 /Blend 1 /HSamples [ 2 1 1 2 ] /VSamples [ 2 1 1 2 ] >> /AutoFilterColorImages true /sRGBProfile (sRGB IEC61966-2.1) /ColorImageDepth -1 /PreserveOverprintSettings true /AutoRotatePages /None /UCRandBGInfo /Preserve /EmbedAllFonts true /CompatibilityLevel 1.2 /StartPage 1 /AntiAliasColorImages false /CreateJobTicket false /ConvertImagesToIndexed true /ColorImageDownsampleType /Bicubic /ColorImageDownsampleThreshold 1.5 /MonoImageDownsampleType /Bicubic /DetectBlends false /GrayImageDownsampleType /Bicubic /PreserveEPSInfo false /GrayACSImageDict << /VSamples [ 2 1 1 2 ] /QFactor 0.76 /Blend 1 /HSamples [ 2 1 1 2 ] /ColorTransform 1 >> /ColorACSImageDict << /VSamples [ 2 1 1 2 ] /QFactor 0.76 /Blend 1 /HSamples [ 2 1 1 2 ] /ColorTransform 1 >> /PreserveCopyPage true /EncodeMonoImages true /ColorConversionStrategy /sRGB /PreserveOPIComments false /AntiAliasGrayImages false /GrayImageDepth -1 /ColorImageResolution 150 /EndPage -1 /AutoPositionEPSFiles false /MonoImageDepth -1 /TransferFunctionInfo /Apply /EncodeGrayImages true /DownsampleGrayImages true /DownsampleMonoImages true /DownsampleColorImages true /MonoImageDownsampleThreshold 1.5 /MonoImageDict << /K -1 >> /Binding /Left /CalCMYKProfile (U.S. Web Coated (SWOP) v2) /MonoImageResolution 600 /AutoFilterGrayImages true /AlwaysEmbed [ ] /ImageMemory 524288 /SubsetFonts false /DefaultRenderingIntent /Default /OPM 1 /MonoImageFilter /CCITTFaxEncode /GrayImageResolution 150 /ColorImageFilter /DCTEncode /PreserveHalftoneInfo true /ColorImageDict << /QFactor 0.9 /Blend 1 /HSamples [ 2 1 1 2 ] /VSamples [ 2 1 1 2 ] >> /ASCII85EncodePages false /LockDistillerParams false >> setdistillerparams << /PageSize [ 595.276 841.890 ] /HWResolution [ 600 600 ] >> setpagedevice

396 T. Plagemann

management, particularly the probing of QoS parameters, in-stantiation of initial configurations, and adaptation at runtime.

Openness and control are apparently contradictory to thetransparency that is given by classical middleware solutions,including object-based middleware, i.e. there must be a trade-off between transparency on the one hand and openness andcontrol on the other. The fundamental research question re-lated to this trade-off is: Is there an architectural concept thatcan provide suitable abstractions and transparency togetherwith openness and control? Traditional solutions use layeredarchitectures to provide transparency. To implement the nec-essary control with traditional solutions, the layering principlehas to be broken or bypassed.

Research projects that strive for new architectural conceptsand abstractions to support both transparency and control bythe middleware often develop open and flexible solutions, likethat of Kristensen et al. [2], and apply a combination of com-ponent technology and reflection, like that of Blair et al. [2].Black et al. introduce in this special issue an abstraction forinformation flows called Infopipes. Applications can be builtby connecting pre-defined Infopipe components like sources,sinks, multicasting pipes, etc. This abstraction represents com-munication in application-level terms, instead of hiding com-munication. Infopipes are intended to reify communicationsuch that the application can interrogate and manipulate them.

Another important question in addition to the design ofthe middleware platform is which services should be pro-vided. Earlier we identified QoS management services andtranscoding services; but other services that are of relevancefor multimedia middleware include stream operations like fil-tering, mixing and aggregation; data management services likepersistency, caching and replication; and group and sessionmanagement services. Kahman et al. show in their paper inthis special issue how to use IETF multimedia session con-trol protocols together with a proxy architecture to providecollaboration services in the middleware.

The case of generic services as part of middleware alsonicely illustrates why the boundaries of middleware are andwill continue to be fluid. For example, fully fledged operatingsystems include services that are regarded as ‘middleware’ inmicro- and nano-kernel operating systems: successful appli-cations that solve generic tasks are often later migrated downto the middleware as a service. Therefore, it is not meaningfulto draw a clear boundary for multimedia middleware. Sincethere are many research groups actively working in this area,the scope of multimedia middleware will continue to be de-veloped.

The four articles in this special issue will give readers aglimpse of the problem and solution domains in multimediamiddleware. I hope you will enjoy reading these articles. Inclosing, I want to thank all those who contributed to the successof the Multimedia Middleware Workshop in Ottawa and whoenabled this special issue to be published.

References

1. Vanegas R, Zinky J, Loyall J, Karr D, Schantz R, Bakken D (1998)QuO’s Rruntime support for quality of service in distributed ob-jects. In: Davies et al. (eds) Proc. IFIP Int. Conf. on DistributedSystems Platforms and Open Distributed Processing (Middle-ware ’98), The Lake District, UK. Springer, Berlin HeidelbergNew York

2. Kristensen T, Kalleberg IB, Plagemann T (2001) Implementingconfigurable signalling in the MULTE-ORB. In: 4th IEEE Con-ference on OpenArchitectures and Network Programming (IEEEOPENARCH’01), Anchorage, Alaska. IEEE

3. Blair G, Coulson G, Robin P, Papathomas M (1998) An archi-tecture for next generation middleware. In: Davies et al. (eds)Proc. IFIP Int. Conf. on Distributed Systems Platforms and OpenDistributed Processing (Middleware ’98), The Lake District, UK.Springer, Berlin Heidelberg New York

Dr Thomas Plagemann received hisDiploma in Computer Science from theUniversity Erlangen-Nurnberg (Germany)in 1990, and his Doctor of TechnicalScience from Swiss Federal Institute ofTechnology (ETH) Zurich (Switzerland)in 1994. In 1995, he was honoured with theMedal of the ETH Zurich for his doctoralthesis, in which he developed the Da CaPocommunication subsystem. From 1994–1996 Thomas Plagemann was a researcherat UniK – Center of Technology at Kjellerand Telenor R&D (Norway). Since 1996,

Thomas Plagemann has been a Professor at the University of Oslo.His research interests include multimedia middleware, protocol ar-chitectures, QoS, operating system support for distributed multime-dia systems, content distribution infrastructures, and interactive dis-tance learning.