Table of Contents
- Ability to Embed it in Other Applications
- Resource Organization and Management
- Resource Versioning
- Resource Viewing and Web UI
- Resource Metadata
- Resource Searching
- Dependency Management
- Resource Logs and Activity Monitoring
- Resource Indexing
- Support for APP (Atom Publishing Protocol)
- Lifecycle Management
- WSDL Validation and WSI Validation Support
- Community Features
Competition all around us. It doesn't matter whether it is a commercial product or an open source product - vendors will always compete with others. Not just within domains but across too. For e.g., if we look at Apache there are two popular Web service frameworks - Apache Axis2 and CXF, and, two Enterprises Services Bus (ESB) projects - Apache Synapse and ServiceMix. Those are just simple examples of competition there exists within a single domain. As I've written here in my blog, open source is a social activity. Better the quality of the product, better the chances for that product to be more useful to the the end user. So it is my view, that healthy competition among vedors, is a good thing - including open source vendors.
Having said that, let us then look at two exciting releases from two of the widely known open source vendors who've announced their latest registry releases recently. Both companies are attempting to solve the same problem domain, but they follow two different approaches in doing so. Both try to address an important - yet missing - key components in the SOA world - the registry (repository) product.
In the old days, we had something called a UDDI registry. Nowadays, not many people use it since the complexity of the project . In addition to that recently UDDI committees was close. Therefore there is a vacuum for a registry product in the industry.
Mule Galaxy is mainly focused on the SOA and SOA governance, whereas the WSO2 product, is a more generic registry product with has support for SOA and SOA Governance. In order to gain a clearer picture of the two implementations, let's compare some of the key features made available in these two products.
A key functionality people look for, when they search for a registry product, is its ability to be embedded inside another application. In other words, users want registries to be used, to be able to build other applications on. If we look at this from a Web services' perspective, we see the need to embed the registry as a back end store for services. However , Mule 's Galaxy does not have a simple and easy approach to embed its registry within other applications. Compared to this, WSO2 Registry has better support for embedding, and it also comes with a Java API as well as an Atom Publishing Protocol (AP)P API
In terms of resource organization and management, both these products have a similar approach. Mule Galaxy has the concept of “workspaces”, whereas WSO2 Registry has the concept of “collections". So we can use either as a way of managing and categorizing a resource. However, in the WSO2 Registry, there is the option to add custom code in order to perform various custom tasks such as handling custom media types and validating newly added resources.
Both implementations support resource versioning. In Mule Galaxy, if you need to create a version of an artifact, then you are expected to provide a version number and then add the new resource. With the WSO2 Registry ,you get the luxury of automatic resource version management. In addition to that WSO2 registry has support for creating checkpoints for a collection. Those checkpoints can be used to for example rollback to previous state of a resource. We cannot find these features in Mule Galaxy..
When it comes displaying resource or simple the user interface, I'd easily say that the WSO2 Registry is richer. If you download the two products and take a look at both, I'm sure you will see that for yourself. With the WSO2 registry UI , even a non-IT person could easily find his/her way around to do things. In addition, the WSO2 Registry has support for pagination that helps simplify the UI and view resources easily. However, in my opinion, I do consider the user interface of a registry to be a big deal anyway!
When it comes to a registry/repository, resource meta data is of utmost importance. This is because, the primary use of a registry is for storing resources. As a result of this, the ability to perform activities on resource meta data becomes crucial. As I know, Mule Galaxy is SOA oriented and the WSO2 Registry is very generic. Irrespective of these differences both registries have similar capability to extract resource meta data when adding resources. This holds true especially for artifacts such as WSDLs and XSDs.
Searching is not just yet another feature that people looking for , rather, it is one of the key feature that everyone one needs. It is a key capability that everyone demands for in a registry. Therefore, a registry must provide an excellent search mechanism. In both the registry products one can search based on the resource name, resource description, creation date , properties etc. Mule Galaxy has a way of writing SQL like queries for searching, whereas WSO2 registry has the ability to write custom SQL for resource searching.
Dependencies arising among resources is inevitable. Therefore, support for dependency management is an extremely useful feature for a registry product to have. In the WSO2 Registry, when we upload a WSDL with imports to some other WSDLs or XSDs, it imports all of those WSDLs and XSDs and adds them as dependencies. Mule Galaxy does not do this. In addition to this capability, the WSO2 Registry supports the concept of association, in which, dependency is a just one type. In the WSO2 registry, two resources could have multiple associations.
Both registry implementations have very good support for resource activity monitoring. The WSO2 Registry even supports searches based on resource activities. None of the implementations have pagination support for resource activity listing.
Indexing resources is an important feature for a registry to have. Here the indexing is somewhat similar to indexing section in a book. The registry index the resources using their content. Mule Galaxy has better support for indexing compared to the WSO2 Registry. With the handler architecture in the WSO2 Registry, one can implement resource indexing, although by default, it does not have support for indexing. This feature is already listed in the Registry Road Map document to be implemented in future releases.
Both implementations of the registries support APP, however, the WSO2 Registry support is richer in this domain. Each and every operation performed on the Web UI, can also performed using the APP. The API for all operations are made available on a public wiki. Although Mule Galaxy supports APP, it does not support all operations you perform on Galaxy.
Both implementations have support for resource life cycle management. However, WSO2 Registry comes with the ability to add custom code in addition to default life cycle support.
This can be a very specific requirement for WSDLs, although, it may not be so much for other kinds of artifacts. Both of the implementations are said to have support for WSDL and WS-I validation. Mule Galaxy has developed their own approach for validating WSDLs .However WSO2 Registry uses well known Eclipse validator , which I consider as one of the best validators.
Both implementations have support for community features like commenting, tagging and rating. One of the coolest features made available on the Mule product, is that you are able to comment on top of a comment. This although we cannot do with the WSO2 Registry, it offers better support for resource tagging and ratings. In my view, it would be nice to have lots of community features within a registry product.
In addition to all of the above, the WSO2 Registry product also supports adding handlers to any media type or URL. This helps you deal with any media type or resource URL within your applications.
All the of the above conclusions I have arrived at, are based on my personal experiences on the two implementations. Your opinion could be different indeed. Therefore, if you haven't tried already, please go ahead and download the two products and see for yourself how they work. With both the implementations made available to you, in source code format, this would be the ideal way for you to figure it out yourself. With the source code available, you can even look at how they actually work.And What's more? You could modify the code to meet your very specific requirements too!
Deepal Jayasinghe is a Technical Lead at WSO2. deepal at wso2 dot com