<!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>The Future of the Internet is Coordination</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Stanford University</institution>
          ,
          <addr-line>Stanford, California 94305</addr-line>
          ,
          <country country="US">USA</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Web 2.0 to Semantic Web Services</institution>
        </aff>
      </contrib-group>
      <abstract>
        <p>The key functionality of a Coordinated Internet would be that the Internet actively watches what people do (analogous to search completion on desktops today), correlates these activities, and actively notifies people when and how their current tasks affect and are affected by the activities of other people. Such a Coordinated Internet would provide revolutionary functionality. Some solutions exist, notably in concurrent engineering such as the Redux solution, but foundational research remains to be done in Coordination Engineering.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>The Universe Doesn’t Run on Workflow</title>
      <p>
        Many technologies for the dynamic composition of web services have been
developed in the last 10 years. If we can discover and consume reusable services
with common descriptions, new processes may be dynamically constructed,
automatically, to achieve goals[
        <xref ref-type="bibr" rid="ref2 ref3">3</xref>
        ].
      </p>
      <p>Given a goal, for example, to be reimbursed for travel expense, a new process
can be created for this purpose, even just one time for one person and one set of
expenses. The processes would take into account all of the currently expressed
enterprise policies, such as, for instance, what amounts must be approved by
managers and the conditions that qualify to be a manager2.</p>
      <p>Individuals inside companies, and in cross-company projects, could
synthesize workflows and other processes as needed. Companies could manage such
processes by stating explicit policies and constraints that such processes would
respect, instead of trusting that programmers would properly interpret these
policies, and instead of waiting for new policies to be programmed. We call
this Enterprise Physics: the universe doesn’t run on workflow, so why should
enterprises?</p>
      <p>
        Such dynamic processes should, and could, allow for change: contingencies,
conflicts, opportunities, policy revisions, and outright failure. This is a further
advantage over static workflows.There are supply chain problems, resulting from
a needed change in suppliers, that could not be handled by today’s workflows
[
        <xref ref-type="bibr" rid="ref2 ref3">3</xref>
        ].
      </p>
      <p>This raises the question of how global dynamic processes could be managed.
3</p>
    </sec>
    <sec id="sec-2">
      <title>The Coordinated Internet</title>
      <p>Should we achieve the vision of dynamic processes, there is an even more radical
future Internet that will then be necessary,: the “Coordinated Internet”. This is
a vision of a pro-active Internet that not only facilitates sharing and
collaboration, but which actively coordinates humans, as well as various programs, most
notably services.</p>
      <p>The key functionality functionality for coordination, beyond passive
information sharing, is the notification of changes and their effects to the right people,
and programs, at the right time. Example notifications are that a conflict has
occurred and who is involved, safe and consistent solution options upon request,
thrashing warnings, opportunities for synergy, and that some tasks are no longer
necessary.</p>
      <p>A Coordinated Internet must actively watch what people do (analogous to
search completion on desktops today), correlate these activities, and actively
notify people when and how their current tasks affect and are affected by the
2 “Web services”, as in the Dagstuhl definition, http://tinyurl.com/webservdef,
need not have anything to do with the web but semantics are required even if the
implementation is in, say, “apps”.
activities of other people. The trick is to do this in a useful way, so that
coordination is increased, but people are not annoyed by a “big brother paper
clip”.</p>
      <p>
        The effects of such future Internet could be world changing, revolutionizing
not only how companies are managed, but how any large enterprise is done,
especially ad hoc ones, such as global relief efforts for catastrophes[
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Some of
this technology has long existed in the field of concurrent engineering [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ].
4
      </p>
    </sec>
    <sec id="sec-3">
      <title>One Mechanism for Coordination: Redux</title>
      <p>The Coordinated Internet can be viewed as a the management of a configuration
or planning problem worked on by distributed actors. When there are multiple
objectives and no single objective function, as there is in the case of large projects
with many engineers, the best we can do in terms of optimality is to ensure that
no single objective solution can be improved without harming the solution of
another: Pareto optimality .</p>
      <p>
        The Redux model of design, as implemented in a subset called Redux’[
        <xref ref-type="bibr" rid="ref10">10</xref>
        ],
implements the use of Pareto optimality within a model of design[
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. Given a
conflict (either a constraint violation or a goal block) and a solution (the revision
of some design decision), using a justification-based truth maintenance system
(JTMS), Redux constructs justifications for revisions resulting from the
resolution of conflicts using Dependency-directed backtracking (DDB) that become
invalid if the conflict would not obtain if ever there is another way of
resolving the conflict, thus enforcing pareto optimality. This justification should not
introduce any unsatisfiable circularity into the JTMS network.
      </p>
      <p>Notable characteristics of the Redux model include distinguishing between
goals that need to be achieved, and constraints that should not be violated;
distinguishing between conditions that affect the optimality of a design decision
and its validity; and identifying opportunities, resulting from loss of pareto
optimality, as well as conflicts. A set of notifications useful for active coordination
is provided in this system. The simplest example is when a subtask has become
redundant because the method of achievement of the supertask has changed.</p>
      <p>Redux also guarantees no thrashing and identifies safe solutions to conflicts
and goal blocks in a distributed environment by management of decision
rationales and the justifications produced by conflict resolution.
5</p>
    </sec>
    <sec id="sec-4">
      <title>Coordination Engineering</title>
      <p>
        There are other coordination models besides Redux, as well as outstanding
issues not solved by Redux. There is a need for much more research in the field
of coordination engineering. Topics include the proper technologies for detecting
and understanding tasks and filtering notifications so that they are more
useful to people, than not. Understanding how to combine constraint satisfaction
techniques with DDB is a major issue[
        <xref ref-type="bibr" rid="ref11">11</xref>
        ].
      </p>
      <p>Better algorithms for underlying justification graph control as well as better
representations of committed actions and sunk costs, and providing appropriate
transparency of information in supply chains, are known research issues.</p>
      <p>
        Internet implementation questions involve what part of the coordination
functionality to embed in what Internet layers. For instance, could the message
notification could be handled by smart routers and distributed servers? How
should the “watching” function be implemented in browser plug-ins and mobile
device apps? In Next-Link[
        <xref ref-type="bibr" rid="ref9">9</xref>
        ], we hand-inserted code in standard engineering
programs. Is there a more scalable approach?
      </p>
      <p>The Coordinated Internet also has deep issues in common with Internet of
Things, such authorization to change descriptions of products and services.</p>
      <p>The Coordinated Internet provides a rich new topic of research for computer
science as well as the potential to radically improves mankind’s ability to manage
complex projects.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Emergent Collectives for Work and Play</article-title>
          . Socite' de Strategie, AGIR Revue Generale de Stratagie, Nos.
          <volume>20</volume>
          :
          <issue>21</issue>
          ,
          <string-name>
            <surname>Jan</surname>
          </string-name>
          (
          <year>2005</year>
          ); http://www-cdr.stanford.edu/∼petrie/revue.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Plenty of Room Outside the Firm</article-title>
          . IEEE Internet Computing, Peering, ,
          <volume>92</volume>
          -
          <fpage>96</fpage>
          ,
          <string-name>
            <surname>Jan-Feb</surname>
          </string-name>
          (
          <year>2010</year>
          ); http://www-cdr.stanford.edu/∼petrie/online/peer2peer/vision2010.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Planning Process Instances with Web Services</article-title>
          .
          <source>Proc. ICEIS</source>
          ,
          <string-name>
            <surname>May</surname>
          </string-name>
          (
          <year>2009</year>
          ); http://logic.stanford.edu/sharing/papers/IVIS09-serviceplanning.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bussler</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>The Myth of Open Web Services - The Rise of the Service Parks</article-title>
          .
          <source>IEEE Internet Computing, Peering</source>
          ,
          <fpage>80</fpage>
          -82 May/Jun (
          <year>2008</year>
          ); http://www-cdr.stanford.edu/∼petrie/online/peer2peer/serviceparks.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Practical Web Services. IEEE Internet</surname>
            <given-names>Computing</given-names>
          </string-name>
          , Peering, ,
          <volume>93</volume>
          -
          <fpage>96</fpage>
          ,
          <fpage>N0v</fpage>
          -Dec (
          <year>2009</year>
          ); http://www-cdr.stanford.edu/∼petrie/online/peer2peer/practicalws.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Berners-Lee</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hendler</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Lassila</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          :
          <article-title>The Semantic Web</article-title>
          .
          <source>Scientific American</source>
          vol.
          <volume>184</volume>
          , no. 5 pp.
          <fpage>34</fpage>
          -
          <lpage>43</lpage>
          May (
          <year>2001</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          : Collective Work,.
          <source>IEEE Internet Computing, Peering</source>
          ,
          <fpage>80</fpage>
          -82
          <string-name>
            <surname>Mar-Apr</surname>
          </string-name>
          (
          <year>2008</year>
          ); http://www-cdr.stanford.edu/∼petrie/online/peer2peer/collectivework.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Goldmann</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Raquet</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <source>Agent-Based Project Management. Lecture Notes in AI 1600</source>
          , Springer-Verlag,
          <article-title>(</article-title>
          <year>1999</year>
          ); http://www-cdr.stanford.edu/ProcessLink/papers/DPM/dpm.html.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Webster</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Cutkosky</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Using Pareto Optimality to Coordinate Distributed Agents</article-title>
          .
          <source>AIEDAM 9</source>
          ,
          <fpage>269</fpage>
          -
          <lpage>281</lpage>
          (
          <year>1995</year>
          ); http://www-cdr.stanford.edu/NextLink/papers/pareto/pareto.html.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>The Redux' Server</article-title>
          .
          <source>Proc. Internat. Conf. on Intelligent and Cooperative Information Systems (ICICIS)</source>
          , Rotterdam, May, (
          <year>1993</year>
          ); http://www-cdr.stanford.edu/ProcessLink/papers/redux-prime.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Petrie</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jeon</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Cutkosky</surname>
            ,
            <given-names>M. :</given-names>
          </string-name>
          <article-title>Combining Constraint Propagation and Backtracking for Distributed Engineering</article-title>
          .
          <source>Proc. AAAI'97 Workshop on Constraints and Agents</source>
          , AAAI Press,
          <source>Technical Report WS-97-05</source>
          ,
          <string-name>
            <surname>August</surname>
          </string-name>
          (
          <year>1997</year>
          ).
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>