Export registry contents of one carbon node to another using WSO2 Greg check-in client

Overview

WSO2 governance registry can be introduced as a product which provides you with a rich set of functionalities to accomplish your registry and repository related needs. Including WSO2 Greg, each and every carbon based product uses the registry kernel which offers basic registry and repository functionalities to store data and configurations associated with each product. For example, it's being often used to store various resource entities such as carbon datasource configurations, WSDLs, Schemas, endpoints, etc under various environments such as standalone environments, clustered environments etc in numerous  occasions.

Delving further into the functionality of the registry kernel, its storage space can be divided into three main partitions namely,

1. Local registry

2. Configuration registry

3. Governance registry

Out of those three aforementioned types of partitions, local registry is often used to store configurations and data that are local to a particular instance of a carbon product. Also this particular registry space is not shared among any other nodes by its nature. In contrast, the configuration registry can be used to share configurations common to multiple nodes of the same product. For example, if you consider a cluster of WSO2 Data Service Server nodes storing dbs files or any other configuration data in their configuration registry space, those data can be shared across all the nodes in the WSO2 Data Service Server cluster. Unlike both local registry and configuration registry, the governance registry can be used to store configurations and data that need to be shared across many nodes of different carbon products.

Back to the topic..

Having had a brief, yet comprehensive overview about the registry kernal, let's get ourselves back to the main subject of this blog post which is exporting registry contents of one carbon node to another using the check-in client introduced by WSO2 Governance Registry.

As explained earlier, you may come across this requirement of migrating or exporting data and configurations stored in the registry of one carbon product to another. One way of achieving this would be to get a database dump and restore it in the carbon node that exists in the other end of the migration process which is a pretty much tedious task. To address this problem, WSO2 Governance Registry introduces this mechanism called registry check-in client which provides you with means to get a registry dump and restore it in another  carbon node easily. Although this mechanism is only shipped with WSO2 Governance Registry by default, it's quite possible to adopt it into other carbon products as well. The rest of the content of this blog post would bring you the steps that are necessary in making use of the registry check-in client in other carbon products (For example, WSO2 Data Services Server).

Step 1:

Download WSO2 Governance Registry distribution and locate the checkin-client.sh in its GREG_HOME/bin directory.

Step 2:

Change the working directory to DSS_HOME/bin and place the checkin-client.sh there.

Step 3:

Execute "ant" command inside DSS_HOME/bin directory which would create the DSS_HOME/repository/lib directory (if it does not already exist) and copy some required dependency jars to that particular directory.

Step 4:

Change the working directory to GREG_HOME/repository/lib and locate checkin-client-x.x.x.jar (x.x.x represents the version of the product being used)

Step 5:

Change the working directory back to DSS_HOME/repository/lib and place checkin-client-x.x.x.jar there.

Step 6:

Restart WSO2 Data Service Server instance.

Step 7:

Change the working directory to DSS_HOME/bin in the command line and run the checkout command "checkin-client.sh co https://hostname:9443/registry/ -u admin -p admin -f registry_checkout". This will create a registry dump file of the root collection, called "registry_checkout" inside DSS_HOME/bin directory. (Modify the paths and the hostname to match your environment)

Step 8:

To check in the data to a different DSS node (or any other carbon node), execute the following command. "./checkin-client.sh ci https://hostname:9443/registry/ -u admin -p admin -f $DSS_HOME/bin/registry_checkout". (Modify the paths and hostname to match your environment)

Further information on various ways of obtaining a registry dump of a particular collection can be located at [1].

References:

[1] http://wso2.org/project/registry/4.0.0/docs/user_guide/checkin_client.html#check-in-client

[2] http://wso2.org/project/registry/4.0.0/docs/index.html

How secure your data in the cloud?

It's been not so long since the concept of cloud computing started emerging. But the huge hype it has generated within such a short period of time suggests the amount of interest people have already gotten at it. And yes, it has to be of such strength to make such a solid impression on world-wide technical experts, that quickly. The business advantages may have been the reason for most organizations to adapt the cloud or it could be the huge hype which forced them towards the adaption. However, it's not quite clear how many of them have really thought about the pros and cons of it and made the best suited solutions for their organizations. This article is intended to provide an insight into some of the risks that are associated with the cloud which may be hidden yet important to be mindful of, within the scope of data.

First and the foremost, have you or your business organization ever thought about how secure your data to be stored in some storage space offered to you by your cloud service provider and located at some unseen data center? In other words, your cloud service provider may have its data distributed in several data centers established in various parts of the world. To which content do they provide a guarantee on the security of your data (maybe sensitive or maybe not) stored in such geographically parted locations? If you've ever thought about the data security, these questions would have naturally come up to your mind. To  address this concern, some cloud service providers are now in the process of offering encrypted data storage mechanisms restricting the room for any security vulnerabilities. But that too has got some bad implications like performance bottlenecks, etc which would reduce the performance and other measurements of the data manipulative processes associated with the business.

Another important concern would be, the various laws, rules and regulations and acts that are imposed upon data by different countries. For example, if your cloud service provider is based on some European country and if you, as the service consumer, are located at some Asian country, the variations of such laws imposed on data may restrict you from manipulating your own data freely according to your real requirements. Though this risk is not clearly visible, it can be of such high impact on the legality of your business.

For highly data intensive businesses, the high availability of data plays a vital role. Thus, for such businesses that have gotten themselves into the cloud must have a strong guarantee from the service provider that the high availability is constantly ensured. The recent power outages took place in Amazon, one of the popular service providers in the cloud space, is one of the best examples to show how risky it could be, if it's not handled properly. Most of the time this type of service interruptions due to Power outages, natural disasters, etc take place unexpectedly. Yet it is a must that the cloud service provider has the ability to mitigate such risks and provide the service consumers with an uninterrupted service. On the other hand, there should be a guarantee on the time that the service provider would  take in order to restore the system back to normal conditions. Not only that, in case of a natural disaster, the cloud service provider should have the ability to recover your data from any data loss that could possibly occur.

These would be somewhat obvious questions if you are really mindful about the data security. Yet, it is always important that all individuals and organizations who are into cloud, take them into account if they're to select the best suited cloud service provider for their business in terms of data.

Nowadays, most of the people who are dealing with sensitive data manipulative activities and concerned about data security, thus, prefer the concept of private cloud ahead of the services offered by the public cloud in which they can have the total control over each and every aspect of the data manipulations that are involved in their business activities. The good news is that, WSO2 offers its private cloud solutions (apart from its public cloud solutions) to help such people get going with their business who are doubtful about the data security, which enables the users to obtain the complete control over their data manipulative needs. Further, WSO2's private cloud offerings too expose you to its complete product stack as-Services including Data-as-a-Service, ESB-as-a-Service, etc. Visit wso2.org or wso2.com for more details, tutorials and articles which would provide you with a comprehensive understanding about WSO2's cloud offerings and how you can adapt them into your businesses.