Xsemble Release 2.5: Component Parameterization + Ease of Getting Started + More

We are happy to present Xsemble release 2.5. It is an important milestone. The main improvements are in terms of ease of getting started and support for parameterization. We shall cover the changes at a conceptual level below, as well as some important points about migrating from a previous release.

Support for Parameterization

In this release, we introduce Parameterization. Parameterization is a very powerful concept. Parameters can be likened to the switches or knobs on appliances. Just like the switches and knobs can control the behavior of appliances, the parameters can be used to control the behavior of component instances or layers in a software application.

The way different radio boxes can tune to different radio stations, different parameter settings can control the behavior of each node separately — even when they are instances of the same component. The parameters are defined at the component level, and assigned values at the instance level.

Similarly, there are layer level parameters which are assigned values at the layer level, but are defined at the platform level.

There is also flexibility about where the parameter values are assigned. Within the Assembler’s Workbench, a designer may choose from among the following 3 options:

  1. BurnTime: Assign the value right away in the Assembler’s Workbench
  2. RunTime: Defer setting the value at runtime. These parameter values may be defined within pre-generated properties files at runtime. (The properties files have adequate comments to help one.) The utility is that these values can be changed without compiling.
  3. Any: Any of the two. The parameter could be defined at burn time but could be overridden at run time.

The platforms supported by Xsemble and the component libraries provided with Xsemble have been retrofitted to make use of parameters.

Ease of Getting Started

Ease of Onboarding

Xsemble 2.5 distribution can be downloaded directly from the Get Started page and installed. It was not so straightforward before. One needed to download an executable, create a key request, send it to us for creating the key, and then finally download Xsemble based on the instructions you received along with your product key.

What about the key? The key file is not needed anymore. Instead, your product key is a text string that’s unique to you. When you run Xsemble for the first time, it shows you a registration window to enter your information. This information is sent to Xsemble cloud and it generates your key. The key is automatically saved to your xsemble.properties file (with the installation).

Next time onwards, your application can log in to the Xsemble cloud successfully with your key, and you can proceed to the Xsemble application. (This login is automatic, so there is no extra step for the user.) The following figure shows the flowchart of this process.

Flowchart depicting how Xsemble starts

The Get Started page has been updated with detailed steps.

Ease of Running

We removed tomcat installation from the pre-requisites. Most programs will have a single deployable layer (unless you are dealing with microservices), and it is far easier to run those applications with an embedded server.

Xsemble release 2.5 makes use of the gretty plugin in its automatically generated gradle script. This plugin lets you run your application in embedded Jetty server or embedded tomcat server, without having to install these application.

Of course, if you already have a server installation on your machine, that can still be used. A new layer level parameter lets you specify where to copy the generated deployable.

The User Guide (bundled with Xsemble) has the detailed instructions.

Migration from Earlier Releases

Xsemble 2.5 uses JSON format for storing its metadata instead of the earlier XML format. This metadata includes the definitions of components, their repositories, nodes and projects. These files have now become compact and easier to read. They are typically managed with a version control system like git.

Xsemble converts the XML files to JSON automatically when you open an old repository or project. The user has no role to play. However, in case you see the possibility of going back to an older release, then make sure that the older metadata is stored in a way that it can be retrieved.

Another incompatibility is introduced in terms of component implementations. Xsemble 2.5 passes more data to the components (one of them is the parameter name-value pairs) and accordingly the method signatures in the Java implementations should change. Xsemble supplies a script that can automatically make this conversion happen. Again, in case you see the possibility of going back to a previous release, then make sure that a copy of the older implementations are saved somewhere before running this script.

Others

Many other improvements have gone into this release of Xsemble.

  • Notably, the Health check dialog in Developer’s Workbench has become stronger.
  • The automatic merging of template code is also retrofitted.
  • The documentation has been updated corresponding to the feature changes.
  • Many bug fixes have also been done.

Leave a Reply

Your email address will not be published. Required fields are marked *