<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Towards Interoperability of Distributed Interactive Simulations through Node-based OpenGL Stream Processing</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Maik Mory</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Norbert Siegmund</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Alexander Blankenburg</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Gunter Saake</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Otto-von-Guericke-Universität Universitätsplatz 2</institution>
          ,
          <addr-line>D-39106 Magdeburg</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Coupling heterogeneous simulation environments is a requirement in the engineering domain. A novel approach exploits simulations' visualizations to setup distributed simulations: OpenGL stream processors intercept the dialogue between OpenGL clients and servers, and (distributedly) process the request-reply stream. As a first step towards an holisitic approach, we describe the Vanadium node-based OpenGL stream processing framework from the viewpoint of an integrated interoperability model. Results are a systematic examination of the framework's capabilities and limits; identification of open research questions; and an initial benchmark for architectural comparison with other OpenGL stream processing frameworks.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>Engineers use plenty of heterogeneous software. Thus, interoperability between various
software products is an issue in the daily work of almost any engineer or sophisticated
craftsman. We focus on distributed simulations. A simulation system primarily is
software that supports engineers in decision making. In Digital Engineering, this definition
includes digitally tracked mockups or prototypes. A simulation is distributed, if it uses
at least two dedicated, heterogeneous software systems that interact by any means to
implement the simulation required by the engineer.</p>
      <p>
        There are plenty of file formats for almost any imaginable use case. Inherent latency
renders file exchange unfeasible for interactive simulations and other use cases relying on
bidirectional data flow. Nowadays, most engineering-software provides one or more
application programming interfaces (API). Prominent examples are NX [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] and Matlab [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ].
Coupling engineering-software via software-specific APIs requires a software developer
with knowledge about the respective API, and it requires to establish interoperability
between the software-specific API and the system landscape. Software-specific APIs
allow for sophisticated integration solutions, but development might be too expensive
for many scenarios.
      </p>
      <p>
        Node-based OpenGL stream processing enables interactive distributed simulations
at the convenience and cheapness of file-based methods. First, we describe the
working principles of OpenGL stream processors. In Section 3, we present one selected
node-based OpenGL stream processing framework along Manso et al.’s [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] integrated
interoperability model with seven levels of interoperability. Finally, we discuss our
results.
      </p>
    </sec>
    <sec id="sec-2">
      <title>Background</title>
      <p>Since the 1990s, OpenGL has been the dominant solution for visualization. OpenGL
declares a client-server architecture. The OpenGL client requests configuration of the
rendering pipeline, direct drawing operations, and geometric primitives. The server
renders according to the client’s requests to a framebuffer, which commonly is mapped
to a display device.</p>
      <p>
        In 1996, the concept of an OpenGL stream was established [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. An OpenGL stream
is the sequence of requests and replies between an OpenGL client and an OpenGL server.
WireGL [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] was one of the first comprehensive node-based OpenGL processors, which
targeted at distributed processing in commodity clusters. WireGL was open-sourced
and renamed to Chromium [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]. The Chromium project drove development of many
algorithms and technologies towards a comprehensive node-based OpenGL stream
processing framework. For us, it is relevant that Chromium brought into focus, how to
intercept the client-server dialogue with proprietary visualization software. Chromium’s
development stalled in 2008.
      </p>
      <p>
        The German software company IC.IDO published an advertisement video about
their software product IDO.Capture in 2007 [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. The video illustrates an application
scenario, which uses OpenGL stream processing for interactive distributed simulation.
The technology leader in OpenGL stream processing TechViz advertises a similar
solution called TechViz Fusion [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. Apparently, both commercial competitors do not
directly contribute to the academic discourse. Nevertheless they indicate that OpenGL
stream processing is feasible in complex scenarios.
      </p>
      <p>
        In previous work, we develop the Vanadium node-based OpenGL stream processing
framework [
        <xref ref-type="bibr" rid="ref10 ref9">9, 10</xref>
        ]. This is inspired by Chromium’s architecture, involves some lessons
learned from other OpenGL stream processors (HijackGL [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] for example), and
reconsiders some design decisions with respect to today’s options. We describe details about
Vanadium’s architecture in Section 3 as necessary.
3
      </p>
    </sec>
    <sec id="sec-3">
      <title>Vanadium’s Interoperability Concept</title>
      <p>
        We use Manso et al.’s interoperability model [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], because their broad survey defines a
consistent and coherent vocabulary, which serves well in engineering-software scenarios.
The authors declare seven levels of interoperability: technical, syntactic, semantic,
pragmatic, dynamic, conceptual, and organizational. The remainder of this section will
evaluate the Vanadium node-based OpenGL stream processing framework with respect
to these levels.
      </p>
      <p>
        Technical interoperability enables the interconnection of systems through common
communication protocols allowing information exchange at a basic level [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. We rely on
two libraries for technical interoperability: the ØMQ library and the Detours library.
      </p>
      <p>
        ØMQ [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] is a multi-platform messaging library. Its message primitive are bytestrings.
The ØMQ library delivers messages inter-thread, inter-process, cluster-wide, and
worldwide. ØMQ’s minimalist programming interface supports request-reply, publish-subscribe,
and push-pull messaging patterns. We emphasize ØMQ’s support of reliable multicast
protocols, which came in handy for us in distributed rendering scenarios [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ].
      </p>
      <p>
        Node-based OpenGL stream processing commonly assumes that stock software
should serve as source for the OpenGL commands to be processed. However, special
care has to be taken for proprietary software. Based on a survey [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], we select the binary
interception technique together with the Detours library [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] as reference
implementation. We successfully use the Detours library with Kuka’s KukaSim, Bitmanagement’s
BSContact, and Siemens’ NX 7.5, among others.
      </p>
      <p>
        Syntactic interoperability ensures common data format or structure, language,
logic, registers and files [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. A robust syntax requires a complete formal specification. A
special manifestation of OpenGL’s formal specification are the so-called specfiles [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ],
which declare all of OpenGL’s identifiers, symbols, and constants in a formal language
again. Similar to Chromium, we rely on automated source-code generation. The OpenGL
specfiles are input to our code generator, which creates mappings between the binary
application interface as provided by the Detours library and the networking interface as
encapsulated by the ØMQ library and vice versa. The entities introduced by OpenGL’s
specification are the symbols we talk about.
      </p>
      <p>
        A shared, common vocabulary that avoids inaccuracies or mix-ups when interpreting
the meaning of terms or symbols [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] enables semantic interoperability. Since we use
OpenGL’s formal specification for syntactic interoperability, it is obvious that OpenGL’s
documentation as provided with the OpenGL software development kit [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] serves
as the semantic counterpart. OpenGL’s informal specification is in English language,
comprehensive, consentaneous, and mature.
      </p>
      <p>
        Manso et al. [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] state that pragmatic interoperability is about interconnected
systems knowing each other, so they are able to exploit application/services interfaces, to
invoke methods or procedures, and handle the data they need to exchange with other
systems. Due to OpenGL’s architecture, the majority of visualizing software are either
monolithic renderers or use tree-like scenegraphs. Monolithic renderers act as exclusive
OpenGL clients, where invocations are scattered to the entire software application. In
contrast, a scenegraph is a tree where the nodes are snippets of OpenGL invocations.
The most popular and reference scenegraph is OpenSG [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ].
      </p>
      <p>
        One may wiretap a client-server dialogue and publish it for subscription. This
converts OpenGL’s bidirectional architecture into directed communication. It has been
shown, that such a stream of OpenGL request-reply tuples is feasible for
implementation of complex tasks [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] and well-suited for multicasting. Thus, we end up with a
directed graph where the nodes are OpenGL stream processors and the edges are
publishsubscribe relationships. We currently search for the limits of the proposed directed-graph
architecture. We expect that the proposed architecture supports modularized virtual
reality effects like they are motivated by Haringer and Beckhaus [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ].
      </p>
      <p>
        Dynamic interoperability allows the systems to monitor the running of the other
systems and to respond to the changes in the transfer of information by taking advantage
thereof [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. We intentionally reduce interdependencies in our framework. Therefore, an
OpenGL stream processor node in our framework does not even know its predecessors
or successors; ideally, nodes faithfully process messages. Hence, we see dynamic
interoperability as the ability for an OpenGL stream processor node to join or leave the graph
at runtime.
      </p>
      <p>In this consideration, it is important to know, that a published client-server dialogue
implies (hidden) states of the OpenGL server between any request-reply tuple of the
stream. Thus, a node may join the graph, if it is able to catch up the implied server state
as required to work properly. A node may leave the graph, if its subscribed nodes are
able to catch up the implied server state to whatever will replace the leaving node. If a
node leaves without replacement, its successors break down too.</p>
      <p>
        Knowing and reproducing the functioning of a system based on documentation,
usually articulated in a format as used in engineering, yields conceptual
interoperability [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. Vanadium’s exploited concept is geometric primitives with scanline rendering.
Every engineering-software with an OpenGL-based visualization supports this concept.
Every engineer should hopefully be able to interpret a geometric visualization. However,
the wide range of framework participants is a trade-off towards sophisticated functions.
If an OpenGL stream processor node receives a geometric primitive, there is no hint
whether the primitive is a rigid body’s surface, a fluid particle, an electrical field, or
a user annotation. Therefore, Vanadium does not substitute tight couplings between
distributed simulations. We expect to ease lightweight couplings between heterogeneous
simulations.
      </p>
      <p>
        Organizational interoperability is about business targets, process models,
regulations and policies of access and use of data and services [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. Many engineers and other
stakeholders appreciate Vanadium’s simple and low-barrier approach. However, we have
to take into account other stakeholder’s interests too. For example, there is the argument
that OpenGL stream processors might “steal” models. OpenGL is an open client-server
system. The Vanadium framework is just another OpenGL server, which might extend
an engineering application’s value.
4
      </p>
    </sec>
    <sec id="sec-4">
      <title>Discussion</title>
      <p>Based on a brief introduction to OpenGL stream processing, this paper describes the
Vanadium node-based OpenGL stream processing framework. Our architecture is
analyzed with respect to technical, syntactical, semantic, pragmatic, dynamic, conceptual,
and organizational interoperability respectively in detail. This analysis enables a sound
reasoning when to apply OpenGL stream processing as interoperability solution in
engineering scenarios.</p>
      <p>The systematic examination unveiles open research questions with respect to OpenGL
stream processing. Dynamic interoperability has not been considered before. We could
show that dynamic interoperability interferes with the pragmatic interoperability level,
and we create a stub for further research.</p>
      <p>Finally, this paper establishes a schema for an irrespective description of OpenGL
stream processing frameworks. Thus, we enable qualitative comparability between
frameworks. At the same time, this paper serves as initial benchmark for architectural
comparison with other OpenGL stream processing frameworks. We encourage the
research community to use similar comparison approaches.</p>
      <p>Acknowledgments. Maik Mory and Norbert Siegmund are funded by German Ministry
of Education and Science (BMBF) within the ViERforES project No. 01IM10002B.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Siemens</surname>
            <given-names>PLM</given-names>
          </string-name>
          <article-title>Software: NX Programming and Customization Fact Sheet</article-title>
          , http://www. plm.automation.siemens.com/zh_cn/Images/4988_
          <fpage>tcm78</fpage>
          -
          <lpage>4564</lpage>
          .pdf (
          <year>July 2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>MATLAB R : C/C+</surname>
          </string-name>
          <article-title>+</article-title>
          and Fortran API Reference, http://www.mathworks.de/help/ techdoc/apiref/bqoqnz0.html (
          <year>September 2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Manso</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wachowicz</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bernabé</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Towards an Integrated Model of Interoperability for Spatial Data Infrastructures</article-title>
          .
          <source>Transactions in GIS 13(1)</source>
          (
          <year>2009</year>
          )
          <fpage>43</fpage>
          -
          <lpage>67</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Dunwoody</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <string-name>
            <surname>The OpenGL Stream Codec - A Specification</surname>
          </string-name>
          .
          <source>Silicon Graphics</source>
          , http: //www.opengl.org/documentation/specs/gls/glsspec.txt . (
          <year>1996</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Humphreys</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Eldridge</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Buck</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stoll</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Everett</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hanrahan</surname>
            ,
            <given-names>P.:</given-names>
          </string-name>
          <article-title>WireGL: A Scalable Graphics System for Clusters</article-title>
          .
          <source>In: Proceedings of the 28th annual conference on Computer graphics and interactive techniques. SIGGRAPH '01</source>
          , New York, NY, USA, ACM (
          <year>2001</year>
          )
          <fpage>129</fpage>
          -
          <lpage>140</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Humphreys</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          , Houston,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Ng</surname>
          </string-name>
          ,
          <string-name>
            <surname>R.</surname>
          </string-name>
          , Frank,
          <string-name>
            <given-names>R.</given-names>
            ,
            <surname>Ahern</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            ,
            <surname>Kirchner</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.D.</given-names>
            ,
            <surname>Klosowski</surname>
          </string-name>
          ,
          <string-name>
            <surname>J.T.</surname>
          </string-name>
          :
          <article-title>Chromium: A Stream-Processing Framework for Interactive Rendering on Clusters. In: ACM SIGGRAPH ASIA 2008 courses</article-title>
          . SIGGRAPH Asia '
          <volume>08</volume>
          , New York, NY, USA, ACM (
          <year>2008</year>
          )
          <volume>43</volume>
          :
          <fpage>1</fpage>
          -
          <lpage>43</lpage>
          :
          <fpage>10</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <given-names>ESI</given-names>
            <surname>Software Germany GmbH: IC.IDO Virtual</surname>
          </string-name>
          <article-title>Reality: Software IDO</article-title>
          .Capture, http: //www.youtube.com/watch?v=1tymAyDmdNM
          <source>(March</source>
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Boutin-Boila</surname>
          </string-name>
          , E.: TechViz Fusion, http://www.techviz.net/wp-content/uploads/ TechViz_Fusion_
          <year>2011</year>
          .pdf (
          <year>March 2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Mory</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Masik</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Müller</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Köppen</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Exposing Proprietary Virtual Reality Software to Nontraditional Displays</article-title>
          .
          <source>In: Proceedings of the 20th International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision</source>
          . WSCG Communication Proceedings, Union
          <string-name>
            <surname>Agency</surname>
          </string-name>
          (
          <year>2012</year>
          )
          <fpage>35</fpage>
          -
          <lpage>43</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Mory</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pukall</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Köppen</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Saake</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>Evaluation of Techniques for the Instrumentation and Extension of Proprietary OpenGL Applications</article-title>
          . In: 2nd International ACM/GI Workshop on Digital Engineering (IWDE), Magdeburg, Germany (
          <year>2011</year>
          )
          <fpage>50</fpage>
          -
          <lpage>57</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Mohr</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gleicher</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>HijackGL: Reconstructing from Streams for Stylized Rendering</article-title>
          .
          <source>In: Proceedings of the 2nd International Symposium on Non-Photorealistic Animation and Rendering. NPAR '02</source>
          , New York, NY, USA, ACM (
          <year>2002</year>
          )
          <fpage>13</fpage>
          -
          <lpage>20</lpage>
          and 154
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Hintjens</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <string-name>
            <surname>ØMQ - The Guide</surname>
          </string-name>
          . iMatix Corporation, http://zguide.zeromq.org/
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Hunt</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brubacher</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          : Detours:
          <article-title>Binary Interception of Win32 Functions</article-title>
          .
          <source>In: Proceedings of the 3rd conference on USENIX Windows NT Symposium - Volume 3. WINSYM '99</source>
          , Berkeley, CA, USA, USENIX Association (
          <year>1999</year>
          )
          <fpage>14</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14. Khronos Group: Enumerant and
          <string-name>
            <given-names>Function</given-names>
            <surname>Registry</surname>
          </string-name>
          , http://www.opengl.org/registry/ #specfiles
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15. Khronos Group:
          <article-title>OpenGL Software Development Kit Documentation</article-title>
          , http://www.opengl. org/sdk/docs/
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Reiners</surname>
          </string-name>
          , D.:
          <article-title>OpenSG: A Scene Graph System for Flexible and Efficient Realtime Rendering for Virtual and Augmented Reality Applications</article-title>
          .
          <source>PhD thesis</source>
          , TU Darmstadt (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Haringer</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Beckhaus</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Dynamic Visual Effects for Virtual Environments</article-title>
          . In:
          <string-name>
            <surname>WSCG (Full</surname>
            <given-names>Papers).</given-names>
          </string-name>
          (
          <year>2010</year>
          )
          <fpage>49</fpage>
          -
          <lpage>56</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>