Investigate Holons

[probablytom]

My notes so far (I'll put these into a little paper summary thing in the thesis, too, but maybe in some condensed form!)

Blair et al. propose using “holons” as building blocks for [nestably] composable systems of systems.

Blair et al. define holons by separately defining what a holon is composed of (it’s sub-holons), and what service it provides. Once that’s done, the holon’s requirements to be properly instantiated are defined; its rprop-s for properties required for instantiation, and its pprop-s which are used to define the properties it provides to other holons. Then, a developer can engineer a system of systems by defining a nested structure and making sure that requirements are fulfilled, without having to be aware of implementation details; besides what the developer actually needs to know, the holon can be a black box, simplifying system engineering.

They note that there’s some interesting work to be done using type theory to ensure composability during the engineering, as well as analysing privacy and developing DSLs for system definition & engineering using holons. A particularly interesting note though is that service composition is a hard problem to solve, and needs a lot more work done than their (short) paper provides for structure composition.

Holons are a nice step forward and seem like a promising idea. They solve some problems — particularly nested system composition, which is quite cleverly solved by them — but there’s a few things I’m not sure yet whether the solve properly, or could be extended to support. Particularly I’d be interested to look into:

• How do holons help to show emergent behaviour?
• Can a modification be made to show directionality of requirement?
  • There’s many ways a property can be required
    • Some holons might require things to be provided by the holons they’re composed of
    • Others require properties of horizontally composed holons
    • Some require properties from a vaguer environment
  • Horizontal requirements just vertical requirements of an overarching system, because we’re interested in the impact that the failure of one holon can have on another — not whether an overarching system fails, which indicates that something has failed.
    • Maybe I misunderstand the way that holons are arranged hierarchically. Perhaps two holons can require properties that they provide each other, at the same layer / level / size / whatever, rather than being nested underneath each other.

---

Paper: Holons: towards a systematic approach to composing systems of systems.pdf

[twsswt]

I wonder if there is a practical difference between what they describe as a holon and what software engineers call 'components' or 'services' (or micro-services)? The vision is essentially the same, as far as I can tell: assembling systems from readily available components with well defined interfaces. The problems are also the same: the difficulty of composing heterogeneous components with different interface expectations (both explicit and implicit).

[probablytom]

I think software systems are their primary focus too, in that I think they hint at that being the first easy application of their method — the difference is that the units specify what they need and what hey provide in terms of the properties, rather than the specific systems. e.g. a plant requires water, but not necessarily an irrigation system; the availability of water's what matters. Software systems tend to specify certain other components rather than the properties the components provide, right? So we might depend on a specific library for network stuff, rather than just relying on "any HTTP-providing library".

Do micro-service architectures allow that? They're definitely designed to be plugged together like lego, but there's an assumption that some architect's going to plug them together correctly, with an understanding of how they fit together and what they need to be connected to...holons in the paper aren't concerned with what specifically it is, just what they're provided by it.

[twsswt]

the difference is that the units specify what they need and what hey provide in terms of the properties, rather than the specific systems. e.g. a plant requires water, but not necessarily an irrigation system"

This is a good point. Some dependency management systems specifiy components (Apt-Get, Yum etc) whilst the web services and OSGi standards specify interfaces (which you can think of as properties). The problem is that the property language (typically a Java interface) isn't expressive enough. You can't specify lots of complex semantics in it, like methodcall ordering, or non-functional properties like throughput. Equally, even within the cruder interface spec languages you tend to find that its hard to work out an interface need/provision is compatible, such that you end up with only ever having 1 provider and 1 requirer of an interface (checking compatability between interfaces is effectively the same as the halting problem, so undecidable). The problem we have is that computers don't cope well with vague notions like 'plants need water' and we don't have languages for describing these 'good enough' compatabilities in a computational setting.