Service Oriented Architecture is fundamentally based on metadata descriptions, schemas, URIs and policies. The key to a successful SOA deployment is to manage this data in a structured repository. WSO2 Registry is an open source product that enables you to store, catalog, index and manage your enterprise metadata in a simple, scalable and easy-to-use model. In fact, the WSO2 Registry can not only store such metadata but any other kind of data and maintain it in a versioned and URI-accessible manner. Think of the registry as a structured wiki designed to help you manage your metadata in a simple business-friendly system. Registry allows the storage of unstructured data such as Word documents, Excel spreadsheets and text formats. Using these approaches, you can build a catalog of services and service descriptions. A simple, RESTful programming API allows any and all resources stored in the WSO2 Registry to become a part of your dynamic SOA infrastructure- for example, by storing policies in the registry and using them for runtime policy enforcement. Built in community features allow WSO2 Registry users to comment on, tag and rate resources stored in the registry. Registry can be navigated using the given Web application, via an AtomPub API or via Java API (for both local and remote registries via AtomPub).
This document applies to version 1.0 of the WSO2 Registry.
Installing the WSO2 registry is a matter of copying wso2resgistry.war file into a servlet container such as Apache Tomcat. We recommend you use the latest version of Tomcat, version 6.* but it should work with version 5.*s as well. In Apache Tomcat, drop the .war file into webapps directory. (We assume that you have Java v1.5 at least.)
By default, data you store in the registry will be saved in a database embedded in the WAR file and the files themselves will be located within the exploded WAR directory. It is recommended to configure an external data source or a JDBC connection as explained in the section below using Apache Derby or MySQL databases. If your application server does not automatically unpack the WAR file (e.g., JBossAS), then the built in database may not work. In such cases, you must always use a external database.
In both scenarios, you need to create database tables using scripts bundled in the source distribution. After deploying the .war file, start the application server, if it has not already.
Below are the steps for configuring WSO2 Registry with Apache Derby database. Note that the following database commands are for linux platform. Please replace file paths to match Windows, if you are using this in Windows platform.
<wso2regsitry>
<currentConfig>derby-db</currentConfig>
<dbconfig name="in-memory">
</dbconfig>
<dbconfig name="sample">
</dbconfig>
<dbconfig name="derby-db">
<url>jdbc:derby:/home/user1/wso2registry/db</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>org.apache.derby.jdbc.EmbeddedDriver</driverName>
</dbconfig>
......
......
</wso2registry>
11. Restart the servlet container. Now WSO2 Registry is running using the Apache Derby database!
After successfully deploying the WSO2 Registry webapp, launch a Web browser and point it to the the following URL:http://localhost:8080/wso2registry(you may need to change the port if your servlet runtime is listening on a different port).
This takes you to the welcome page of the registry console as given below:
Figure: Welcome page on WSO2 Registry's UI console
Note: By default the welcome screen displays the resources page of the root folder. Please Refer the 'Resources' section of this documentation for details on features provided on this page.
The option to sign in is available as a link on the top right hand corner of the welcome screen.
User will be logged in upon entering valid credentials.
The default system has an administrator configured with username/password combination as 'admin'/'admin'.
Navigation bar on the top right hand corner consists of the following options:
We will now discuss each of these menu options in detail:
This is the default option activated upon log-in.
In the left hand side column of the resources page you'll find three blocks, namely, Information, Entries and Permissions.
Information block includes details of a chosen resource including the creation date and time under the 'Created' label with 'Author' information, 'Last Updated' date and time with author information related to the update as 'By', link to different versions available through 'Versions' label and ratings for resources including current user rating and average rating. A 'Description' for the selected resource is also available.
Upon selecting "Edit Description" command button, an editor will be provided to insert a description for the chosen resource. Users can type a description and select the "Save" button to save updates.
Adding a resource could be done for a collection of resources or for an individual resource. To add a collection or directory, click on the button provided and a page will be presented to fill in the required information. Optionally, a description can be included for the resource in question.
Note : Adding and and deleting resources within the registry are considered version operations. Therefore, provision is made to rollback or restore a resource to any previous version. Refer Versions for additional information on this topic.
To delete a resource , click on the cylindric icon provided. However, upon doing so a resource will not be removed from the database but instead marked as deleted. This provides the opportunity to restore a previously deleted resource.
Using the 'entries' block, users are able to add additional resources and collections to the active folder.
To add a new resource:
1. Select the add resource icon provided on the top right hand corner of the entries block as illustrated in the diagram below
2. To add a file in the local machine as a resource, select "import content from file" option and browse and select the file. To import a remote resource, select the "Import content from URL" option and give the URL.
3. Change the name of the resource, media type and the description, if required.
4. Click "Add" button to add the new resource.
To add a new collection
1. Select the add collection icon in the entries block.
2. Type the name of the new collection.
3. Select a media type for the collection and type a description, if necessary. Note that the normal collections have the "default" media type.
4. Click "Add" button to add the new collection.
Using the following screen, WSO2 Registry permissions can be assigned to different roles and individual users.
The top half of the permission's screen is used to define user roles and the bottom half for defining role permissions.
To assign permissions to users or roles follow the steps given below:
1. select user/role from User/Role drop down
2. choose an action from the 'Action' drop down menu
3. select permission type. users are able to choose 'Allow' or 'Deny' by selecting appropriate option button.
4. Click 'Add Permission' to apply selection
Existing permissions can be changed by selecting and clearing the check boxes for required permissions and clicking the "Apply All Permissions" button.
Note: 'User permissions' have higher priority over 'role permissions'. 'Deny' permissions have higher priority over 'allow' priorities. Essentially, this means that permissions assigned to users overrides permissions assigned for a role and that a deny permission always overrides an 'allow' permission assigned to a user.
The right side of the resources page houses 3 additional blocks, namely: Tags, Comments and Versions.
Provides space to enter tags for a given resource. These tags can be used when searching for a resource as key words for search criteria.
Users can enter as many tags as they like provided individual tags are separated by commas and a given tag is not used by the same author to identify the same resource repeatedly.
Users can either comment or refer comments made by others using the comments block.
To add a new comment:
1. select the "ADD" icon located on the title of the bar of the comments block
2. enter comment in the text box provided
3. click the 'Add' button to continue.
Versions block provides version-specific information including different versions of a given resource. These include last modified date & time and By(username). Links are provided to visit a resource's specific version page, together with provision to rollback back to a chosen version of a resource.
Selecting "People" option on the navigation menu opens up the following screen. Authorized users could manage users and roles using options given.
A list of "users" with details including User name, Name and Action appears on the left side column of the window together with a list of "roles" including Role Name and Action available on the right side column.
"Username" column lists the username assigned for users with the "Name" column providing the friendly name. Under the "Actions" column action delete is indicated as an icon that provides the facility to delete chosen users from the users list.
To add new users:
1. select "Add New user" icon from the title bar of the users window
2. enter user details including Username, Password, Confirm Password and Role type in the space provided
3. upon completion selection a user role for the new user and click "Add" button to continue.
4. the newly created user will be listed as the last item in the users list.
Note:If an attempt is made by unauthorized users to create new users, the system will not allow this and will respond displaying the following error message: "User is unauthorized to perform the action". Sign in with valid credentials before attempting this activity.
Note:Icon next to add new user/add new role icon is an expand/collapse icon to switch between the two views.
The 'Activity' options presents the user with a search facility for searching activities performed on the Registry. The block titled "Search Activities" consists of space to enter search criteria such as Username, Path, Date and Filter by drop down in searching for recent activities. A screen shot of Search Activities block is given below. Notice the list of sample activities provided at the bottom of the block for the given Username.
This toggle option provides the ability to sign in into WSO2 registry or sign out of WSO2 Register, as needed.
WSO2 Registry can be embedded inside other Java applications as a library to provide resource/community oriented features. Once embedded, Java applications can access all the features of the registry using the Registry API (org.wso2.registry.Registry). If you want to use all the resource/community features (exposed in the WSO2 Registry web application), you should embed both WSO2 Registry and WSO2 User Manager libraries in your application. To start with, first place the WSO2 Registry jar and the WSO2 User Manager jar files in the class path of your application. There are many combinations in which you can use the embedded registry. We will discuss each scenario below.
You can just instantiate and use in-memory registry as shown below. In this mode, Registry uses an in-memory database and any data stored in the registry will not be persisted. Note that this mode is recommended only for testing and functional evaluation and not recommended for production deployments.
Registry registry = new InMemoryJDBCRegistry();
Now you can call API methods of the registry to access the registry features.
You can create a RegistryRealm and pass it to the constructor of the InMemoryRegistry to create a authorization aware registry. Note that it is highly recommended to use in-memory realm with the in-memory registry. Otherwise it may cause unexpected behaviors as only a part (users or resources) of the data get persisted.
Ream realm = new InMemoryRegistryRealm();
Registry registry = new InMemoryJDBCRegistry(realm);
Upon the instantiation of the RegistryRealm, registry user store will be populated with predefined set of users and permissions. Then you can create a SecureRegistry instance for the admin user (pre-populated) and use it to add initial set of users and resources to the registry.
SecureRegistry adminRegistry = new SecureRegistry("admin", "admin", registry, realm);
Use the realm of the adminRegistry to add initial set of user, roles and permissions.
Realm adminRealm = adminRegistry.getUserRealm();
Once all initial users/resources are added, you can create SecureRegistry instances for each user and use those instances to access the registry. When the registry is accessed via a SecureRegistry instance, all the actions are authorized. That is, only the actions permitted for the user of the SecureRegistry are allowed.
If a DataSource is available for your application, you can simply create a non-secure persistence registry by providing a DataSource instance for the JDBCRegistry constructor.
Registry registry = new JDBCRegistry(datasource);
If a DataSource is not available, you can use the RegistryDataSource constructed using database attributes.
DataSource datasource = new RegistryDataSource("jdbc:derby:/home/reguser/db/registryDB", "org.apache.derby.jdbc.EmbeddedDriver", "user1", "user1password");Registry registry = new JDBCRegistry(datasource);
Now you can use this registry instance as before. All your data will be persisted to the given database.
First create a persistence realm using a datasource.
Realm realm = new RegistryRealm(datasource);
Then create a JDBCRegistry instance using the above realm and a datasource.
Registry registry = new JDBCRegistry(datasource, realm);
Then you can create SecureRegistry instances and access the registry with authorizations as mentioned in the second scenario. All your data about the resources and users will be persisted to the given database.
In simple words, the RemoteRegistry is a Java API for interacting with a Registry instance. Regardless of where a given Registry instance is located, either locally or remotely, we can still talk to it using RemoteRegistry. The RemoteRegistry is yet another implementation of org.wso2.registry.Registry interface. However, the difference between the RemoteRegistry and a standard Registry is that, the RemoteRegistry is not an actual registry but a client for interacting with a registry instance.
Communication between the Registry and the RemoteRegistry takes place using the Atom Publishing Protocol (APP). When we deploy registry files (registry.war) in an application server, an atom feed is generated . Thereafter, if you browse http://localhost:8080/wso2registry/atom (this address changes depending on your application server settings), you'd be able to see the atom feed from the registry. The structure and format of the feed is described in the following location: http://www.wso2.org/wiki/display/registry/Registry+Protocol.
To create an instance of the RemoteRegistry, what we need first is the URL of a registry. If the root of the registry is http://foo.com/, the URL for the RemoteRegistry instance would be http://foo.com/atom. Once we have the URL figured out, we can create an instance of the RemoteRegistry using the following code:
RemoteRegistry remote_registry = new RemoteRegistry(new
URL("http://localhost:8080/wso2registry"));Creating an instance of the RemoteRegistry in this manner, is similar to accessing a registry without login into it with communication taking place as an anonymous user.
If you have a user name and password for the registry, you can pass them along when creating the remote_registry instance. At that point, all permissions granted for the particular username/password pair will apply to the owner of the remote_registry instance. Creating the remote_registry with user name and the password can be done using:
RemoteRegistry remote_registry = new RemoteRegistry(new
URL("http://localhost:8080/wso2registry"), "admin", "admin");In this example, we have created the remote_registry instance with username="admin" and the password as also "admin".
Once we have the registry instance in place, navigation is straightforward. It is the same as working with the Registry API. Say we have a resource called "/foo/c1" in the Registry and you can access it using the remote_registry instance as given below:
Resource resource = remote_registry.get("/foo/c1");The resource object will represent the actual resource object in the Registry. But if the resource is a collection, then the object will, of course, represent the collection.
As you can see in the code sample above, once we have a remote_registry instance we do not need to pass a complete URL for all invocations. It is adequate to pass only a relative path to a resource.
To add a resource to the remote_registry instance, first thing we need to do is to create a Resource object and then to call its put method:
First let's try to cerate a collection called "/foo/c2"
Resource resource = new Resource();
remote_registry.put("resource", resource);If you call the get method then you'd be able to access that resource created.
Now let's try to add a resource with content. For that, we need to first create a Resource object and then set content.
Resource r1 = new Resource();
String str = "My Content";
r1.setContent(str.getBytes());
remote_registry.put("/c1/c2/r1", r1);We can use the following code to confirm whether the resource exists:
boolean value =remote_registry.resourceExists("/c1/c2/r1");If the resource does exist, a boolean value of true will be returned, else false.
Additionally, we can use the remote_registry instance to delete resources. Deleting a resource is a matter of calling the delete method of the remote_registry. Let's just say we want to delete "/c1/c2/r1". Then we can use the following code:
RemoteRegistry.delete("/c1/c2/r1");
We can rename individual resources but but we cannot rename collections. To rename a resource, use the following lines of code.
remote_registry.rename("/c1/c2/r1" ,
"/c1/c2/r2");Above line of code renames "/c1/c2/r1" to "/c1/c2/r2"
Retrieving different Versions of a Given Resource
We can list all of the versions of a given resource using the code given below. The result would be an array of String, containing links to the different versions of the resource.
String [] versions = remote_registry.getVersions("/c1/c2");Since the Registry comes with versioning, we can restore a resource to any of its versions. This can be done using the remote_registry as well. In the previous section, we discussed how to retrieve versions for a give resource. The following line of code demonstrates we can restore back an old version of the remote_registry instance.
remote_registry.restoreVersion (versions[2]);
We can perform tagging operations using the remote_registry. To tag a resource, we need the resource path and the tagging words. Let's say we need to tag a resource named "/c1/c2/r2" as "rename resource". We can do this as:
remote_registry.applyTag("/c1/c2/r2" , "rename
resource");
We can use the remote_registry to retrieve tags for a give resource. It will return an array of Tag type and we can iterate the array to see the content.
Tag[] tags = remote_registry.getTags("/c1/c2/r2");We can remove a tag using the tag name. Use the following code:
remote_registry.removeTag("/c1/c2/r2","rename
resource");We can also comment on a resource using the remote_registry. Here, we will create a comment object and call the remote_registry instance. Following lines of code illustrates how we can achieve this:
Comment c1 = new Comment();
c1.setText("This is my comment");
String commentpath = remote_registry.addComment("/c1/c2/r2", c1);The above lines of code will add a comment to the resource named: "c1/c2/r2 ".
We can also make changes to comments we have already made using the remote_registry instance. Here, we need the path and new text for the comment we are adding. Say we want to change from "This is my comment" to "This is cool", For that, we can do the following:
remote_registry.editComment(commentpath,"This is cool")
In order to rate a resource based on our judgment, we can again use the remote_registry instance. Rating a resource can be done using following line of code:
remote_registry.rateResource("c1/c2/r2 " , 4);In addition to the above operations, there are a number of others that we can perform using the remote_registry instance. In this document we have discussed only the most commonly used operations.
We can use the RemoteRegistry to export our entire local file system into the Registry. What we need to do is to give the location of the file system and the location where we want to put them in the Registry. Once we do that, inside the registry it will create the same structure as the file system and upload all files into the Registry. We can consider this as any check-in operation on any kind of version management system. Following code demonstrates how to import a local file system into the Registry:
File file = new File("Path of the file");
RemoteRegistry remote_registry = new RemoteRegistry(new
URL("http://localhost:8080/wso2registry"), "admin", "admin");
RegistryClientUtils.importToRegistry(file ,
"/myfile/filesystem" ,remote_registry);In the previous section, we discussed how to import a local file system into the Registry. There is another way round of this and it is to check-out the Registry to a local file system. To export, we can select either the entire Registry or a selected node. Depending on the node we select, the remote_registry instance will create the same structure within the file system. Even if we have the resource with binary data, then it will create all of the necessary files in the file system.
Let's say we want to export "/myfile/filesystem" into my local file system then we can use the following code:
File toFile = new File("Path of the new file");
RemoteRegistry remote_registry = new RemoteRegistry(new
URL("http://localhost:8080/wso2registry"), "admin", "admin");
RegistryClientUtils.importToRegistry( toFile,
"/myfile/filesystem" ,remote_registry);We need to keep in mind when exporting the Registry to a file system, that it will only export the resources but not the comments, tags and any rating associated.