Rhea

25 Jun 2012

MidPoint version 2.0 code-named Rhea was released last week. This is the first midPoint release that has features and quality appropriate for production use. It is a result of more than two years of development therefore the code is mature enough to enter that stage. The major changes include:

• Repository based on relational database. Hibernate is used as a mapping layer and also for SQL dialect abstraction. The mapping is implemented efficiently therefore even relatively large datasets can be stored (we have tested 500k users with good results). The efficient data storage applies also to run-time schema extensions which was quite a difficult thing to do.
• Brand new GUI. It has new look&feel and ease of use is also improved. But the most significant change is change in technology. We have moved from JSF to Apache Wicket which was an excellent choice.
• All midPoint code is now based on Prism Objects. We had enough of all the problems of XML and JSON which makes them almost unusable for any serious software development. Therefore we have created a data abstraction that takes the good features of the data formats but otherwise is independent of them and avoids the critical pitfalls. The work has started in the previous two versions but it was fully integrated in this version. Although all the import/export formats of midPoint remain XML we can easily switch to JSON or other format if needed.
• Most schemas are stabilized and moved to version number 2. We expect only a compatible changes to the schema in next few releases, maintaining backwards compatibility and making upgrades easier.
• Extensible schema. MidPoint schema can now be extended at startup time by placing a XSD file in midPoint's home directory. GUI forms take this schema into consideration therefore the forms will show new fields from the schema. There is also a couple of new annotations to control how are the form fields displayed.
• PolyString is an unusual kind of animal. It is a built-in data type for polymorphic string. This string maintains extra values in addition to its original value. The extra values are derived from the original value automatically using a normalization code. It is currently used to support national characters in strings. The PolyString contains both the original value (with national characters) and normalized value (without national characters). This can be used in expressions e.g. to generate username that does not contain national characters or is a transliteration of the national characters. It deprecates the need to use custom conversion routines and each expression and therefore it brings some consistency into the integration code. But the most important reason is data storage. All the values are stored in the repository therefore they can be used to look for the object. Search that ignores the difference in diacritics or search by transliterated value can be used even if the repository itself does not support that feature explicitly. PolyString does not have its full potential yet, but it makes the system more useful now and it will be improved in later versions.
• Support for Groovy and ECMAScript/JavaScript expressions in addition to existing XPath2 support. Expressions have the same variables and definition and all work well with PolyStrings, some languages support them almost transparently. Expressions in different languages can be combined in a single configuration.
• Provisioning robustness. MidPoint can now handle provisioning to resources that are not available during the provisioning operation. MidPoint will queue that operation in the repository and it will replay it later when the resource becomes available. Also some other resource failures are handled in quite an intelligent way. This mechanism is a part of a greater and much more powerful consistency effort. It is a result of Katka Valalikova's diploma thesis work which will be published shortly. Although the whole mechanism is complete even now it still needs a bit of polishing to become a part of the product and will become fully available in the next midPoint version.

MidPoint is shaping up pretty well. We are successful in introducing a lot of unique and useful features. And we still maintain a clean and simple architecture. MidPoint is maturing. And I think it is now pretty clean that this development path was the right one.