4 comments (leave a reply)

1. 

   Shaun Forgie (December 15, 2010)
   

   Great Stuff. A very innovative and timely re-introduction of components into the software engineering debate.

   I would like to see the concepts and techniques surrounding Evolve applied to the key practices of reuse, wiring and assembly, configuration, and deployment.

   Engineering has focused for too long on creating and not re-using existing work. Components need to have nobs and dials that allow behaviour to be modified at run time.

2. 

   Andrew (December 15, 2010)
   

   > Great Stuff. A very innovative and timely re-introduction of components into the software engineering debate.

   Thanks Shaun!

   > I would like to see the concepts and techniques surrounding Evolve applied to the key practices
   > of reuse, wiring and assembly, configuration, and deployment.

   Definitely. As you know, Evolve already allows reuse of wiring and assembly and works directly on Java classes. In other words, you can use it for Java reuse today. However, as you note, there is nothing limiting the concepts just to components, and the practices can be more widely applied.

   One of our banking clients has been looking at applying the concepts to reuse grid worflows. Use in this way, the component structures and wiring represent nested workflows, rather than Java classes. Evolution and resemblance can then be used to extend workflows in a powerful way.

   > Engineering has focused for too long on creating and not re-using existing work.

   That’s true at a very deep level. Software development has focussed so much on creation, that we tend not to even develop the tools for addressing the reuse concerns.

   > Components need to have nobs and dials that allow behaviour to be modified at run time.

   Reuse in Evolve works via allowing the internal wiring (as well as the knobs and dials) to be adjusted in a non-destructive way when making an extension. The “inside wiring” adjustment part is vital, because otherwise you have to propagate all of the parameters (knobs and dials) of the inside parts up to the top level, causing a combinatorial explosion of parameters just to foster reuse.

   Cheers,
   Andrew

3. 

   Shaun Forgie (December 16, 2010)
   

   1. How do components manifest themselves in the world….as code structures, compilation units, deployment units? This is a key point for me.
   We already have a myriad of ways of extending and modifying behaviour right? Meta-object frameworks, dependency injection, aspects with different weaving semantics (compile time, run-time), inheritance, parameterisation, etc…
   2. Where are these nobs and dials to be found in components?

   All these options but no constraints…perhaps we need to understand what constraints are relevant and how they bound the run-time considerations associated with deploying, upgrading and replacing components. OSGi does have something to say in this regard.

   In this regard top level run-time containers and the environmental services they deliver provide a starting point for understanding what a component can and can not do.

   to be continued….

4. 

   Andrew (December 16, 2010)
   

   > 1. How do components manifest themselves in the world….as code structures,
   > compilation units, deployment units? This is a key point for me.

   (The concepts behind Evolve can be mapped onto any technology, but we have chosen to map it onto Java for our first product)

   In Evolve, a leaf component is always associated with a POJO — basically a plain Java class with setters and getters. You write the class, and then import it into Evolve. Here’s an example showing the code and the graphics together: http://www.intrinsarc.com/wp-content/uploads/2010/08/leaf21.png

   Then, when you wire up instances of leaf components to form a “composite” component, you are wiring up instances of POJOS. An example of this is: http://intrinsarc.com/wp-content/uploads/2010/08/composite.png
   We can then use this component as an instance when we are wiring up another component and so on.

   Now, this is where it gets interesting. Composite components doesn’t need a Java representation. All they are is a convenient way to describe wiring to humans. When a set of components are executed, the system simply works out the wiring and joins all the POJO instances together.

   (if you haven’t done so already, I would strongly recommend working through tutorial A in the manual. It’s a small example – 10 pages or so – but it gives a really concrete introduction to creating programs in Evolve)

   > We already have a myriad of ways of extending and modifying behaviour right?

   Yes, we do 😉

   > Meta-object frameworks, dependency injection, aspects with different weaving semantics (compile time, run-time)
   > inheritance, parameterisation, etc…

   Evolve covers *all* of the above, but without some of their disadvantages. So, with the three constructs in Evolve of composition, resemblance and evolution you can:

   a. wire up complex structures like in DI, and switch in and out components for testing
   — unlike in DI though, the wiring and components can be far more sophisticated.

   b. use an extension to wire in components to handle cross cutting behaviour
   — unlike with aspects though, this is explicit and creation and extension have the same power
   (one common critique of aspects is that aspects are a secondary axis with less power)
   — unlike with aspects, extensions in Evolve can refer to each other, and conflicts can be resolved explicitly

   c. resemblance is a more powerful form of inheritance
   — at the leaf component level, it simply maps onto class inheritance, giving all the advantages of that
   — at the wiring level, it allows an extension to replace or remake any part of the structure

   I’ll be publishing a set of articles/posts in the coming months explaining these in more detail.

   > 2. Where are these nobs and dials to be found in components?

   The “knobs and dials” are the public attributes of each POJO (via setters), that control how it is parameterised. Now, in conventional OO, these knobs and dials only work at one level. i.e. if you have the dials on class B, and then you make class A which contains a private instance of class B, then you lose the ability (when using A) of adjusting the dials on B. This tends to force people to push all the dials of the private instances of a class into the top level class, causing an explosion of parameters just to give flexibility. This tends to cause great pain, and eventually lead to a generic mess with dozens of parameters which cannot easily be understood.

   Evolve avoids this need to propagate the parameters upwards by allowing them to stay in context (as a part of a component) but allowing that component’s structure to be remodelled in an extension, to meet any new requirements.

   > All these options but no constraints…perhaps we need to understand what constraints are
   > relevant and how they bound the run-time considerations associated with deploying, upgrading
   > and replacing components.

   You are right. Explaining this has been my biggest challenge to date. I’m still working on it 😉

   > OSGi does have something to say in this regard.

   Yes, OSGi has a strong runtime model. Evolve currently requires a complete restart of a system to apply changes, although we are considering adding runtime evolution support also.

   > In this regard top level run-time containers and the environmental services they deliver provide a
   > starting point for understanding what a component can and can not do.

   Like Spring, Evolve is more or less agnostic about the technology you apply it to. The output of using the sophisticated Evolve reuse facilities is simply a set of POJOs which can be connected up. As an example of how it can easily map onto a sophisticated environment, the manual presents a case study of using Evolve to create a GWT/Hibernate system: see tutorial D of the manual: http://intrinsarc.com/downloads/evolve-manual.pdf

   > to be continued….