Video Externalized Rules introduction commentary

Hello. I'm Ondra Žižka, and I will introduce the latest feature of WindRide - which is a tool for migrating the configuration of JBoss Enterprise Application Platform (or EAP) from version 5 to version 6. (Support for other servers will be added later.)

The latest feature is that the migration logic is externalized into XML files. Let's see how it works.

The big picture is:

1. Query the source server for collection of information,
2. Iterate over these collections,
3. Take the actions based on what is found.

Now let's see how to define that.

The XML file contains a definition of so-called migrator, which is a logical group of actions covering certain configuration area, for example, datasources.

Migrator has a name which is then used by the program to refer to it.

It contains JAXB beans declarations, queries, and actions.

JAXB beans declarations tell the program what classes will be used for unmarshalling of the configuration. Since all of the application servers store their configuration in XML files, JAXB is a natural choice.

Then comes an example of a query; in this case, it's an XML query. There are more types, for example, properties file query. Different types target different ways of how configuration is stored in the source server. More details about queries can be found in the project's wiki pages.

All queries have an ID, by which their result is referred in the actions. Subject label is used in user interface, and for the HTML reports and error messages. Other query attributes are type-specific.

Actions define the actual steps taken during migration. Again, there different types, specified by the type attribute. Few types are built in, like CLI command action, XSLT, file copy, etc. Custom actions may be implemented either in Java or Groovy. See the documentation for details.

A reference to the action may be stored in a variable. If you are familiar with Ant, you can think of the action as an Ant task.

Typically, you need to migrate multiple configuration items. These items are stored in collections returned by the aforementioned queries. To iterate over the collections, the element is used. You refer the query, and declare the name of variable to store the item for each iteration step.

Inside this loop, you may declare another loop, or action. This way, in cobination with queries, you have quite powerful tools at hand.

As you probably noticed, there are expressions inside the values. The syntax used is Java Expression Language 2.0. The values available for the expression language are documented, but generally, you can use:

• application's configuration
• application's arguments
• JAXB beans
• Any parent in the nested constructs (like and )

The element is a condition in a form of a Groovy expression which controls whether given construct will be processed for the current iteration. The same variables are available for the script as for the expressions.

An action nested in another action creates an action which is dependency of the parent action. In effect, this means that it will be performed prior to the parent action, and if it fails, parent action also fails.

Lastly, the warning element attaches a warning to an action. Each action may have a list of text messages, which are used when user's manual intervention is needed. Typically, in these cases:

• Migration of certain configration item is not supported (yet)
• Migration is not possible (for example, there's no equivalent in the target server)
• Certain discrepancy or inconsistency were discovered in the source server configuration.

This are the externalized rules in a nutshell. As you can see, the combination of instruments gives you quite powerful tool. Please refer to the project's documentation to find out about all the implemented JAXB beans, queries, actions, and also how to implement your own, which will be also covered by the upcoming videos.

See you soon!