2008-05-04, by John Ringland
Before joining the conversation, please read and accept this Invitation to a Conversation.
Excerpts from earlier brainstorming notes that
are still relevant
For more information on SMN see SMN
on Anandavala.
In the matrix/vector view the
designer can click on any matrix or vector element or any matrix row
to receive a dialogue presenting a range of ways that they can
interact with that element. E.g. Change an SVElement's data value or
define a rowOp or select a pre-made virtual system from a palette and
deploy that within the model.
There is a palette on the side of the
interface – when you click on an SVElement the palette displays the
list of all known components that can usefully go into this element.
When selecting a row it shows all the predefined rowOps. If some
element is already selected the designer can click onto the object
within the palette to insert it into the element. There will be some
means of selecting multiple elements and then clicking on a palette
object.
When the object is inserted into the element the designer can
click on the object to set its properties and attributes. There is
some means to select and deselect systems for viewing. The matrix
and vector adapt accordingly with rows and columns appearing or
disappearing. This gives control over what is shown in the limited
viewing space of the matrix/vector view. For a large model you
couldn't fit it all comfortably into a web browser window and having
to scroll over the whole flat model would be cumbersome and
disorienting. Instead have it so that the view registers with various
systems and synchronises with their state. Only when registered is
there a row/column and vector element for this system.
These
viewer-objects (row/col/svElem) can be arranged in any manner that
suits the designer – they can be moved around easily – just right-click
on a view-object (i.e. element, row or column) and then click “move
to” and then click the view object that is in the destination
location and the selected view-object is inserted in the destination
location. The other view-objects adjust around it. In this way the
designer has a controllable view into the model through which they
can edit the model.
As described so far it has no allowance for
coding of new systems but only the reuse and re-configuration of
pre-made sub-systems presented in a context sensitive palette for
insertion into the model and then customisation. If the application is developed as an IDE plugin (e.g. Eclipse, Netbeans, etc) then the IDE allows the designer to code the atomic systems in various programming languages and the SMN plugin can incorporate these into its system palette.
We start with very
simple systems and using these we build more complex systems, which are then added to the palette. Then from these we make even more complex systems and
so on.
If the palette can draw on any web repository of SMN systems
then the range of available sub-systems can grow rapidly through
collective development. www.Anandavala.info can provide an initial open
virtual space and open system repository. People can create and play
with systems in the open virtual space and they can save their
creations to the repository so that other people can reuse them. This
could become an open-system development community (rather than
open-source).
In general a vSystem cannot directly
influence the state of another vSystem, they can only influence each
other through the system logic – however, using wrappers in a pure
virtual context a vSystem can use a wrapper to represent itself
differently. A pure vSystem's state can only change through the
system logic, but a wrappers state can also be externally influenced
– this is the core difference.
The object model is produced by
distilling out the whole of SMN and leave behind only the abstract
system – this is what is stored and operated on as the model –
only for visualisation and so on will it be cast into an SMN like
form. So each 'system' entity class contains the state data
(SVElement) and the output interface (SMCol). The input interface and
the sub/super class/system relations are all separate metadata that
can be merged with the system to cast it into an SMN like form –
this is a flow model where each system experiences the flow of
information from the common SV data space. Each system can only
control its own state, and external clients interact with the virtual
systems by influencing the state of wrapper systems. The influence
that the system wields in the virtual space arises due to other
systems observing its state data and responding.
This system object-model can be
distilled from the SMN model and it makes the interaction channels
between systems direct. Rather than SMElement data being mediated via
the SMN algorithm there are direct references between Java objects.
SMN takes the REST principle
all the way! Below is a quote from Building
Web Services the REST Way
(http://www.xfront.com/REST-Web-Services.html):
“Here
are the characteristics of REST:
Client-Server:
a pull-based interaction style: consuming components pull
representations.
Stateless:
each request from client to server must contain all the information
necessary to understand the request, and cannot take advantage of
any stored context on the server.
Cache:
to improve network efficiency responses must be capable of being
labeled as cacheable or non-cacheable.
Uniform
interface: all resources are accessed with a generic interface
(e.g., HTTP GET, POST, PUT, DELETE).
Named
resources - the system is comprised of resources which are named
using a URL.
Interconnected
resource representations - the representations of the resources are
interconnected using URLs, thereby enabling a client to progress
from one state to another.
Layered components -
intermediaries, such as proxy servers, cache servers, gateways, etc,
can be inserted between clients and resources to support
performance, security, etc.
”
Each vSystem is a client and the
server is the network of vSystems, the collective. Each client has a
particular connection from the server (input interface) through which
it receives data and a particular connection to the server
(SVElement) through its data flows on to others. Each SVElement is
read-only to all systems but the associated system, so it can only
influence the collective by changing its state in the SVELement. An
SVElement is a piece of state data that represents some systems state
within the virtual space – the system that is represented may be a
vSystem or a physical system (I.e. A wrapper) – so long as it can
synchronise some of its state with the SVElement.
Each system only has access to the
information flowing in through its input interface and cannot use any
other state, hence the systems are stateless.
Some states are static and can be
cached – is this effectively implemented by energy flow?
The uniform interface is SMN itself,
which provides a unified mathematical framework.
All systems have URIs.
SMN excels at representing
interconnected resources.
Layered components can be inserted
into the modular process.
Input not fundamental to EFSMN –
output is.
If a system object only had its
input interface explicitly defined, then it has references to other
systems from which it draws data and then uses this to change its own
state – but what then? There is no EF process to recognise which
systems depend on this state and need to be reprocessed. Hence each
system needs to have an output interface, which sends a signal down
each output channel to wake the dependent system up so that it can
process its inputs then change state then wake up downstream systems
and so on... So its a receive then nudge approach. Receive all
required data, change state then nudge any systems that are
registered as observing that state. Systems can register with other
systems to be notified of changes of state – they are then placed
in that systems output interface and they place that system in their
own input interface.
In the object model, once a system
has received some new data due to a state change followed by a change
notification, the system either (case A) pulls the other state data
that it needs via its input interface, or (case B) if no change
notice is received the state stays as before so no data is pulled.
The system then changes state, then sends its new state to all
systems in its output interface. With case B this is a push only
model where system states are cached by each system and only change
due to a change notification. Case B is good for systems that are
remote – in distant servers – and case A works best for systems
in the same memory space. Hence there is a distinction between local
and remote systems that parallels un-cachable and cachable.
The object model represents the pure
connectivity between systems whereas the SMN model also stores things
such as matrix or vector indexes which are really SMN specific. The
pure connectivity is the actual model and SMN is just a useful view
on it. SMN is a view through which systems can be comprehended via a
compact matrix interface. The actual model has no view specific data
of any kind. Each vSystem can be identified by a URI like a standard
REST system.
The SMN view can read in
interconnected networks and present them in a matrix or network view,
making it available for simulation and testing – that is the main
role of the SMN application – as a view! That means that the core
is more general. The core is a network of objects within some
computational space, whether Java objects or C objects or whatever
– the actual model is the pattern of connectivity – they could be
documents or OWL classes or whatever but they have some pattern of
connectivity. SMN is a view that can operate on the pattern
regardless of what the data is! That is a computer.
XML can represent the pure pattern
and this can be unserialised into any kind of instantiated object.
Meanwhile SMN can read and write XML, visualise the pattern and
provide design access to the pattern and the data embedded in it. The
actual instantiation or unserialisation of any objects is done is
some computational space such as a Java virtual machine. Lets call
this computational space the instantiator. SMN only operates on the
pattern of data, it is up to the instantiator to actually instantiate
the objects. In this sense SMN is like a general IDE for any network
of systems. It allows one to create or analyse complex networks of
any kind – it allows one to work on the network structure – the
pattern itself – separate from the actual objects that comprise the
pattern.
A new method of software development
could be to build abstract system models in SMN and produce XML
specifications of whole programs or modules. Then in any
computational environment such as Java one can unserialise the XML
and produce actual Java objects that represent the full object model
defined in the XML specification. This object model functions as the
model system – I.e. The software product. Hence it was designed as
an abstract model, stored as XML and then instantiated into any
XML-to-object enabled computational space.
I could create virtual web services
as XML models then instantiate them within JSP and PHP pages to
implement the web service. I could also create simple programs and
then instantiate them in various OO environments such as Java and
C . They would be identical systems with identical specifications
but operating within different computational environments.
Before joining the conversation, please read and accept this Invitation to a Conversation.
|