Welcome to the Xholon Project

The Xholon project explores: software as systems of linked nodes, organized hierarchically. The Xholon toolkit supports this back-to-basics approach, and demonstrates practical benefits through examples from numerous domains.

The main development effort (as of mid 2014) is going into the Google Web Toolkit (GWT) version of Xholon. Almost all of the example apps now run using HTML5, JavaScript, Scalable Vector Graphics (SVG), and canvas directly in all modern browsers.

Please visit the new location of the Xholon wiki.

I've developed an online workbook, originally to take notes while watching a Khan Academy video. The notes are in the form of text, simple Python and JavaScript code, and Xholon Chameleon apps. The Xholon Workbook provided a way of actively engaging with the material that Sal Khan presents. I now use the workbooks to create Xholon GWT apps.

Many sample Xholon applications are available online. Run them using Java Web Start.

The Xholon Collaborative Apps pages, previously a WordPress blog, are now part of the main Xholon wiki.

The earlier mockup of the Xholon Collaborative Apps pages are still available.

Xholon is a flexible open source tool for multi-paradigm (UML 2, ABM, SBML, NN, GP, PSys, CA, ...) modeling, simulation, design, execution, and transformation. Generic Java and XML building blocks are extended into multiple domains, and woven into loosely organized systems.

Xholon is especially appropriate for event-driven systems, or any system in which objects move around, are regularly created, destroyed and modified, need to change their class at runtime, or even need to dynamically create new classes and new instances of those classes. While some Xholon applications, such as the example elevator controller, have very deterministic behavior and can be statically validated, the tool is especially designed to allow very open-ended systems that organize themselves at runtime and cannot be completely pinned down to a specific UML metamodel or XML schema. The goal of the Xholon project is to enable building of systems that approach the complexity of biological systems, using many of the same principles that have made biological systems so adaptable, successful and long-lived. The Xholon tool can itself be specified in terms of its own core generic building block.

ABM Agent Based Modeling

FSM Finite State Machine - Simulation

PSystems Membrane Computing

SBML Systems Biology Markup Language

UML Unified Modeling Language

While this ambitious goal is still a work in progress, the Xholon tool currently supports a lot of practical features, and has a defined architecture. Not only can the following capabilities be used on their own, but they can also be combined and can interact within the same application.

Xholon is released under the LGPL.

Modeling

• UML 2.0 class, component and composite structure models, including structured classifiers, ports, parts, roles, connectors, signals, messages, and required and provided interfaces.

• UML 2.0 behavior and finite state machine models, including simple states, composite states, orthogonal states, final states, pseudostates (initial, choice, junction, fork, join, entry point, exit point, terminate), regions, transitions, triggers, guards, events, completion events, one-time and repetitive timer events, submachine states, activities on transitions, do activities, entry and exit activities, and Java transition code.

• SysML blocks, internal block diagrams, and most other features that SysML inherits from UML 2.

• Optionally model directly in XML and Java.

• Over 10 MagicDraw UML sample models, that can be viewed using the free MagicDraw reader, or edited using the MagicDraw commercial version.

• One Poseidon UML sample model.

• Agent based models and turtle geometry using an optional NetLogo-like syntax.

• 1D cellular automata.

• Membrane computing or p-systems, including super cells, environment, membranes, regions, objects, rule sets, and rules.

• Numerous other sample models from a wide range of domains, including biology, biochemistry, statistical modeling, controllers, and other embedded systems.

• Initial support for dynamical systems and system dynamics models, with Euler-type numerical integration.

• Rectangular Moore and Van Neumann neighborhoods, hexagonal neighborhoods, and various regular graphs as sibling neighborhoods.

• Sample DTDs for validation of XML files when editing these using third-party tools.

• Continuous Time Recurrent Neural Networks (CTRNN).

• XInclude to allow nested XML files to be loaded at runtime.

• Several types of ports, including direct one-way and two-way references between objects, and indirect references through port objects.

• Asynchronous messaging and synchronous function calls between port-connected objects.

• An application can contain any number of grids, unlike many agent-based modeling systems.

• Creation of grid agent-based models in MagicDraw UML.

• Active objects, passive objects, containers, and any combination of these three.

• Aggregators that can sum up the number of instances of other objects.

• Observer pattern.

• Initial support for SCXML state machines.

• Real-Time Object-Oriented Modeling (ROOM), as implemented in IBM Rational Rose Real-Time and ObjecTime Developer.

Transformation

• Transforms MagicDraw and Poseidon UML models into XML structure and executable Java code, including classes, inheritance hierarchies, composite structure hierarchies, Java attributes and operations, interactions through ports, and state machines.

• XSLT for transformation from UML models to Xholon XML and Java.

• Integrates with ECJ, an evolutionary computation tool, to evolve usable behaviors using genetic programming.

• Transforms System Biology Markup Language (SBML) models into XML and executable code, including compartments, species, functions, MathML, reactions, and rules.

• Automatically creates new projects from templates, complete with all XML and Java files, ready for execution and ready for addition of application specific details.

Simulation and Execution

• Executes any model that can be specified in the Xholon Java + XML format, and any model that can be transformed into that format.

• Runs all sample applications from either the Xholon GUI, or from the Linux or DOS command line.

• Is compatible with both the Java Standard Edition (1.4.2 and higher) and Java Micro Edition (MIDP) libraries.

• Enables each XML-specified class to indicate which Java class implements it.

• Makes flexible use of XPath 1.0 to locate potential interaction partners, and internally uses the JAXP standard API.

• Has a basic runtime GUI with model, view and control aspects, that can Start, Pause/unPause, Step, Stop, and Refresh the view of the currently running Xholon application.

• Shows detailed runtime information about each object, by clicking on nodes in the GUI tree.

• Uses either of two small footprint XML pull parsers, one for JavaSE systems and the other for JavaME.

• Runs under Linux and Windows, and should run under other operating systems that support Java.

• Has numerous startup parameters, configurable as XML.

• Displays 2D graphical grids for models that require these.

• Aligns itself with the XML DOM Node interface and DOM Java binding, when manipulating its internal tree structure.

• Includes a runtime framework that handles most runtime details, allowing developers to concentrate on the domain they are modeling.

• Allows overriding of most functionality in the framework.

• Initializes values of scalar and array variables from XML files, on a class or individual object basis.

Runtime Viewers

• Creates gnuplot line charting scripts, and statistical data files in csv format that can be charted by gnuplot or most spreadsheet programs.

• Creates JFreeChart line charts.

• Creates JUNG network and tree graphs.

• Captures object interactions at runtime, and creates UML 2.0 sequence diagrams using UMLGraph and plotutils.

• Saves complete structural snapshots of an executing model, at regular intervals, or at user's request, in either XML or YAML format.

• Saves models in VRML format, for 3D display in third-party browsers.

• Displays user written help information on each application, in a Web browser, selectable from the GUI menu.

• Displays basic "getting started" information when the GUI starts.

The Xholon project needs your help. You can download and try the tool, run some of the many examples that come with the download, create your own applications, create new plugins, or help to develop or test the core software. If you would like to get more involved, take a look at the lists of feature requests and bugs. Use the project forum or contact the project administrator directly.

To get started, read or actively work through the basic HelloWorld tutorial. It's a very simple application, but it demonstrates many of the main concepts. There are also related tutorials:

A tutorial on how to create an executable Xholon application using the open-source Topcased UML modeling tool.

A tutorial on using the MagicDraw UML modeling tool.

A tutorial on how to create an executable Xholon application using the open-source ArgoUML modeling tool. There's a sample model for this tutorial, but Xholon does not yet fully transform and execute it.

A tutorial on how to create an executable Xholon application using the open-source Topcased SysML modeling tool. SysML is the Systems Modeling Language.

Also have a look at the sample applications that are included with the Xholon software. These give an idea of the range of applications that can be supported by the Xholon runtime framework. These have been employed as use cases to determine what functionality is most important in Xholon. The digital watch simulation is a good example of a Xholon application with a hierarchical state machine, developed using a UML modeling tool.

Many successful systems exhibit the following six characteristics:

1. There is a generic building block from which applications in that domain can be constructed.

2. Blocks are of various types that have an inheritance relationship.

3. Blocks can take on active, passive and/or containment roles.

4. Blocks can be organized into composite structure trees.

5. Blocks can interact with other blocks, in domain-specific ways.

6. Interacting blocks organize into networks overlaid on top of trees.

As a familiar example, a cell in a spreadsheet is a generic building block. Any application you build with a spreadsheet tool is constructed out of cells. Cells come in numerous types. Some represent numeric or textual data, while others contain one of many types of function. Thus, some cells are active while others are passive. The tree in this domain is flat. The spreadsheet or root node has a potentially large number of cell children. The active function cells interact with the passive data cells to produce results. The connections between the interacting cells map out a network overlaid on the rectangular grid.

As another familiar example, an element or tag in an HTML document is a generic building block. Any application you build with an HTML editing tool is constructed out of elements. Elements come in numerous types. Some represent static markup, while other elements may contain one of many types of functions expressed in scripting languages such as javascript. Thus, some elements may be active content while others are passive, and some are just containers for other elements. The tree in the HTML domain can be deeply nested. The <html> or root element is a container for <head> and <body> elements. The optional active script elements interact with each other and with passive markup elements to produce dynamic HTML. Some elements typically function as hypertext links to other elements which may be in the same HTML document or in a document at some other location. The links between elements map out a network overlaid on the HTML tree structure. The world wide web is the sum of all these trees and networks.

Similarly, a biological cell in an organism is a generic building block. Any organism found in the natural world is constructed out of cells. Cells come in numerous types, all of which develop from initial stem cells. Some such as red blood cells transport chemicals such as oxygen, carbon dioxide and glucose, while others such as neurons more actively process something like information. Thus, some cells are relatively active while others are relatively passive. The organism's tree can be quite deeply nested. The organism or root node may have a small number of immediate children that are cells, or it may contain various organs and tissues that are made out of cells. Active and passive cells interact with each other to provide what the organisms needs to stay alive and to reproduce. The connections between cells map out a network overlaid on the overall tree structure.

Other examples of generic building blocks include organisms in an ecosystem, turtles and patches in NetLogo and StarLogo, encapsulated classifiers in UML 2, atomic models in DEVS, states in a state machine, biochemicals in a biochemical network, etc. Xholon extracts ideas from all these areas, and integrates them into a tool that supports modeling, transformation, simulation, and execution.

The Xholon project explores and exploits the concept of generic building blocks, by doing research and by building tools. Xholon is a tool for building applications from generic building blocks (xholons), expressed in XML with Java behaviors. The Xholon tool is itself a composite structure built out of xholons, and supports plugins that are composed the same way.

The following table shows the names for an individual and a composite, in a variety of domains. All of the individuals are generic building blocks. The composites can be building blocks in their own right.

The basic generic building block in the Xholon tool is called a xholon. A xholon is technically defined as any class that implements the IXholon Java interface. Most classes that make up the Xholon runtime framework are xholons by this definition.

A xholon has (at any point in time):

• A unique sequentially assigned ID. This makes the xholon's identity unambiguous within the current runtime.

• A class that it's an instance of. The xholon class is itself a xholon. It implements a specifiable Java class, and provides a lot of defaults for xholon instances.

• A single parent. This is the whole of which it's a part. If the xholon is a root node, then it has no parent.

• Zero or more children. These are it's parts.

• Zero or more siblings. These are all children of the same parent, and are quite likely to interact with each other at runtime.

• An optional named role. This is a role that it performs within the context of its parent.

• Zero or more attributes. Attributes can be represented in at least three ways.

  • An optional single attribute with a value. This could be an int, double, String, other Java builtin type, or an instance of some Java class. The initial value can be specified using XML.

  • Zero or more additional domain-specific Java attributes. Initial values for these can be specified as XML on a class or instance basis.

  • Zero or more children that contain attributes.

• Zero or more ports. These enable cross relationships with other xholons in arbitrary parts of the composite structure tree.

• Standard public Java functions. It can override these with its own snippets. Standard functions include act(), preAct(), postAct(), configure(), preConfigure(), postConfigure(), etc.

• Zero or more domain-specific public, protected or private Java functions.

• Zero or more instances of children that are mechanisms or plugins.

  • Zero or more state machines, which are themselves made up of xholons.

  • Zero or more other machines, such as UML activity diagrams.

• A scheduling algorithm. Each xholon can determine how its own children are scheduled or invoked. The default algorithm is for each xholon to sequentially invoke the act() function of each of its children, at each time step.

Any of these properties can change while the model is executing. A xholon can move and become a child of a different parent. Its children and siblings can come and go and change internally, which may cause it to behave differently. It can take on a new role within the same parent or within the context of a new parent. It's value can change. Even its type or class can change, and it might even become an instance of a class that's just been created dynamically. This might cause it to change the Java class that implements it.

An individual xholon does have an initial configuration that can be specified in XML. But even this could vary stochastically from one run to the next, through use of probabilities.

An individual xholon can't be defined just in terms of itself. A xholon, as a holon (the philosophy term), intrinsically depends on the xholons that it is associated with.

Xholon provides complete independence of:

• the context in which an object is used; where it is in the composite structure tree

• the code that it executes at runtime

Both of these can vary independently. In fact, an object could change everything about itself at runtime, and still be identifiably the same xholon because of its unique ID.

The following are typical steps in the process of developing a Xholon application:

1. Specify a set of generic building block (object) types to be used.

2. Specify an inheritance hierarchy for those object types.

3. Specify a composite structure for instances of those types.

4. Specify ports through which objects can interact with other objects.

5. Specify connections between objects using ports.

6. Define the behavior of objects that will be active at runtime, using functions, finite state machines, or other mechanisms specified by plugins.

7. Write snippets of programming code that will be executed by these active objects at runtime.

8. Iterate.

The steps in this process can alternatively be thought of in the following terms. Identify parts and types of parts. Organize the part types. The final composite structure tree is “the sum of the parts”. Ports allow the application to potentially be more than just the sum of its parts. Connections enable the application to fulfill the potential.

As a project, Xholon is highly integrative. The tool is systematically incorporating new functionality from multiple domains and existing tools, initially as separate mechanisms. As these separate mechanisms become better understood, the Xholon architecture evolves to more naturally incorporate the new concept.

The Xholon tool, and its core concept of a generic building block, is itself being systematically developed using the following process. This is the way in which new Xholon plugins are developed.

• Identify an existing mechanism.

  • Identify existing formal mechanisms from technology domains, such as finite state machines, petri nets, system dynamics, and many more.

  • Identify mechanisms already formalized from the natural world, such as genetic algorithms, genetic programming, neural networks, membrane computing, and more.

  • Identify additional mechanisms from the natural world, especially those found in biology, and formalize these.

• Identify the core building block(s) of that existing mechanism.

• Incorporate those building blocks into the Xholon tool, initially by making them subclasses of an existing core Xholon class, all of which implement the IXholon interface.

• Through use, gain a better understanding of the new domain, and gradually generalize the new functionality and migrate it into the Xholon core, making it more readily usable as building blocks for other domains.

Using a biological metaphor, Xholon applications consist of XML-encoded phenotypes and Java-encoded genomes. When a biological cell is created through cell division, it contains a hierarchy of compartments and components (its phenome) that are essentially the same as those found in its parent(s), and a set of genes (its genome) that specify what behaviors its enzymes will be able to perform. When a Xholon application starts up, it contains a particular initial hierarchy of containers and active and passive objects (its phenome), and a set of potential behaviors (its genome). The phenome or scaffolding is modeled as XML, while the genome or potential behaviors are ultimately modeled and implemented as Java code snippets. A snippet is a named or uniquely IDed piece of functionality.

In Xholon there is no concept of a final complete fixed application. Instead, a Xholon application is just a particular lineup of XML-encoded scaffolding and Java-encoded behavior snippets. In the future, these will be stored in XML or other databases. Applications will be created or evolved at runtime by assembling and weaving together various fragments from the databases. Biologists are increasingly able to combine features from different organisms because of the common generic building blocks provided by nature. Xholon will be able to mix features from different domains because of its own common biologically-inspired generic building blocks.

For more detail on the concepts behind Xholon, you might want to read one of the papers that's been published. These describe how to model cells and other complex biological entities using tools designed for developing real-time and embedded systems. This earlier work used Rational Rose RealTime and C++, rather than the current Java. Xholon is intended to be a runtime framework that can execute the same types of systems described in those papers, plus many more traditional non-biological event-driven systems. Most of the features described in the published papers have been re-implemented as Xholon applications.

The basic architecture of a Xholon application is shown in the following diagram. For a higher-resolution version of this diagram, click here.

In mainstream computer science terms, a Xholon is a node in a tree. The node has a single parent, possibly one or more children, and possibly one or more siblings. A Xholon may also be an active agent able to interact in real-time with other Xholons in the tree.

The Xholon Project is inspired by biological concepts. A major incentive behind the project is to build a run-time environment that is equally adapted to running simulations of biological systems, and to running more traditional real-time, embedded and other event-driven reactive systems.

Xholon applications may contain structures that are highly mutable. A Xholon is an active agent that can modify the tree structure in which it lives. It can navigate the tree to interact with any other node, it can add, delete or modify other nodes, it can exchange messages with other nodes, and it can move itself to another position within the tree.

The Xholon Project incorporates many concepts of the Real-time Object-Oriented Modeling (ROOM) methodology, much of which has been incorporated into UML2. At the same time, Xholon removes some of the limitations of ROOM to allow for greater flexibility, mutability and mobility of active objects.

The Xholon run-time can serve as a target for a Model Driven Architecture (MDA) transformation pipeline. MDA stresses the importance of models, and the ability to transform those models, through a series of steps, into an executing target system. You can create your model using a UML tool such as Gentleware's Poseidon or NoMagic's MagicDraw, save the model as an XMI file, transform it using XSLT (or by some other MDA means) into a Xholon model and application, and then execute the model. For a higher-resolution version of this diagram, click here.