WSO2 Governance Registry 4.5.0 is scheduled to be released this summer. This version of Governance Registry has many new features(some are carbon core features) and lots of improvements as well. In this release we have concentrated more in improving the overall performance of the product. There are few areas that we have focused our attention on and this post focuses more in one of those areas which is performance related to governance artifacts.
Governance Metadata and RXT
"Governance Metadata" and "RXT", these keywords can be considered as the base of governance in WSO2 G-Reg. Lets look at what these keywords describe.
- Governance Metadata - We have used the term "Governance Metadata" to describe basic governance artifacts like "Services","WSDL","Schema" and "Policy". We have used this term because we store metadata related to web services. Metadata of a web service is what a client needs to know to interact with it.
- RXT - We use the term RXT or Registry Extension Type to describe configurable governance artifacts. A configurable governance artifact is a new feature that we introduced in WSO2 G-Reg 4.1.1 and with that, users have the capability of defining their own asset model in G-Reg. Configurable governance artifacts are defined using a XML configuration language and those can be added from the management console.
All of these artifact types are called governance artifacts. WSO2 G-Reg exposes an API called the Governance API which can be used to handle these governance artifacts using external code. We have done a significant improvement in performance when handling these governance artifacts using the Governance API.
Artifact ID
The people who have worked with the WSO2 G-Reg's Governance API will know that, each governance artifact has a unique ID called the Artifact ID. The artifact ID is there to identify a governance artifact even after its unique properties get changed.
Before G-Reg 4.5.0, we used a resource to keep track of all these artifact IDs. We had a resource called the artifact index where we stored all the artifact IDs and the corresponding paths as properties of that resource. This was a bottleneck when it came to highly concurrent scenarios.
In G-Reg 4.5.0, we have identified that the artifact ID should be something unique to all the resources. Therefore we have introduced a new column in the registry database (REG_RESOURCE.REG_UUID) to track these IDs. Now each resource in G-Reg 4.5.0 has a UUID and this gave us the ability to remove the usage of artifact index resource. We have noticed a significant improvement of performance when handling governance artifacts in G-Reg 4.5.0.
So my final conclusion is that G-Reg 4.5.0 has far better performance than its predecessors when it comes to handling governance artifacts.
