Elepar's goal is to make
Distributed Resource Cooperatives (DRCs) into useful tools, rather than
obstacles to be overcome. But our efforts will also benefit those who have
no apparent use for DRCs. That's because the goal includes providing
tools for building and running software of any size which is tolerant of
a large number of platforms (including uniprocessor, parallel, distributed,
and wireless), runtime conditions (including spontaneous resource availability
and withdrawal/failure), and user requirements (including mission-critical
and real-time). For enterprises already embracing DRCs, our goal
also includes providing ways to easily and efficiently buy and sell time
on distributed resources.
This goal comprises many
challenges, but experience shows that using a loose-knit, committee-based
approach to addressing them doesn't work: It instead results in a
set of partial "solutions" that, when taken together, are too complex to
be easily grasped by the intended user, whose expertise is in their original
problem domain, rather than in some particular set of tools. That's
why Elepar follows a more holistic approach, where commonalities between
challenges are identified by a small team, and synergistic constructs are
developed for addressing them, leading to an overall solution with fewer
rules and less complexity. It is similar to ergonomic and functional
structural design, where the designer is able to develop a simplified utilitarian
view of the big-picture "forest" for end users, but only by recognizing
and understanding the inter-relationships of the individual technical challenge
"trees".
A good example of this
principle at work is Elepar's Software Cabling technology. Consider
the many challenges in programming a DRC.
-
In any large system,
there is value in seeing, understanding, and controlling the scope of effects--i.e.
how actions in one part of the program can affect other parts. This
helps the programmer to reason about composing modules and reign in complexity.
-
In any distributed system,
there is value in understanding where information will be needed next,
as long as possible before it is needed there. This allows information
to be forwarded to its source before it is needed there, to mask latency.
-
In any concurrent system,
there is value in considering actions in bite-sized, atomic pieces (or
transactions) that can be reasoned about independently, and data elements
that restrict the sorts of actions that can/will happen to them next.
This allows the programmer/analyst to regard the execution one step at
a time, with his/her one brain, and manage the state explosion.
-
In any high-performance system,
there is value in keeping overhead (e.g. in intermodule communication)
to an absolute minimum, and using the latest in optimizing compilers.
-
In any high-reliability system,
there is value in permitting failed parts of the system to restart in a
well-known state.
-
In any mission-critical system,
there is value in understanding the precise mathematical transforms applied
to each input to yield each output. This allows verification of the
program behavior against the real-world requirements.
Through its holistic approach,
Elepar has recognized a common theme in these challenges: As a whole,
they can largely be addressed by atomic transactions with well-defined,
visible, easy-to-grasp data and control relationships, while relying on
existing languages and compilers whenever possible. Instead of a
large rigid structure, a program becomes more like water, constructed of
many small transaction "molecules" tied together by data and control "bonds",
thereby making it very fluid and adaptable to a wide variety of environments.
Of course, there's a long road from gaining an insight to developing
an effective solution while recognizing and avoiding the potential pitfalls.
Elepar is unique in having traveled that road already, to provide the tools
you need to create your own solutions.
Copyright 2003 Elepar.
All rights reserved.
