Thursday, October 16, 2008
Extending WSO2 Registry with handlers
WSO2 Registry can be considered as a smart resource store, which allows you to put any resource and manage it according to you organization's requirements. But there are many more things you can do, in addition to using the built-in features of the Registry. You can define your own resource types and apply specific processing for certain resources using its extension mechanisms. My article on Registry handlers describes more about its handler based extension framework with an example.
Monday, July 14, 2008
SOA governance basics - building the structure for SOA resources
What is the best way to use WSO2 Registry for SOA governance? How to structure your SOA resources? How should you model certain SOA resources? These might be some questions that comes to your mind when you first starts to use WSO2 Registry. Well... the simple answer for all above questions is that it is all up to you. And it depends on your requirements. In other words, WSO2 Registry gives you complete flexibility to build your SOA deployment in the most suitable way.
First, you can decide what are the top level categorizations of your deployment. This may be based on departments of your organization, different businesses you operate, your clients, suppliers, etc. Once you have a basic categorization, you can start mapping them to collections of WSO2 Registry. Note that you don't have to identify complete categorization at this point. If you have top level collections, to which you want complete control, that is what you need.
Next step is to identify the users of the SOA deployment. Possible candidates are developers, server administrators, managers of departments, representatives of clients, etc. Among these you should identify roles (e.g. HR department managers) and users (e.g. Chamith). And these can be mapped in to users and roles of WSO2 Registry.
Now you have identified possible users and top level collections. Then you should make sure that your users are not going to mess up with others' stuff. Authorizations are there to help you in this. Go to created collections and give and block required permissions.
Ok, next is modeling resources. Some of your resources can be a collection of resources. For example, a SOA service can be a collection of documents, WSDL files and binary files containing the actual service implementation. In that case, you can model a service using a collection. Some other resources can be just a single file. An example would be a configuration file of a server. Such resources can be modeled by a resource in WSO2 Registry. Now, these are the basics. There are more elegant ways to model resources in the way you want. You can define a media type for your SOA resources. These can be either a standard media type or a custom media type. Then you can write handlers in WSO2 Registry to apply custom processing to such resources. Below are few things you can do for modeling SOA resources.
* Restrict allowed child resource types for a particular collection type
* Extract some values from a text file content and set them as properties or tags
* Validate the resource content and block invalid resources
* Provide custom view (UI) for certain resource types
There is very little limitation on what you can do with this plug in mechanism. And more features are on the list, which will be available for plug in authors. I will cover more on handlers later. But for now, this gives you an idea of what options are available for modeling SOA resources in WSO2 Registry.
Making up the structure of SOA resources is just a basic step towards SOA governance. There is lot more to come for making it complete, which I will cover later.
First, you can decide what are the top level categorizations of your deployment. This may be based on departments of your organization, different businesses you operate, your clients, suppliers, etc. Once you have a basic categorization, you can start mapping them to collections of WSO2 Registry. Note that you don't have to identify complete categorization at this point. If you have top level collections, to which you want complete control, that is what you need.
Next step is to identify the users of the SOA deployment. Possible candidates are developers, server administrators, managers of departments, representatives of clients, etc. Among these you should identify roles (e.g. HR department managers) and users (e.g. Chamith). And these can be mapped in to users and roles of WSO2 Registry.
Now you have identified possible users and top level collections. Then you should make sure that your users are not going to mess up with others' stuff. Authorizations are there to help you in this. Go to created collections and give and block required permissions.
Ok, next is modeling resources. Some of your resources can be a collection of resources. For example, a SOA service can be a collection of documents, WSDL files and binary files containing the actual service implementation. In that case, you can model a service using a collection. Some other resources can be just a single file. An example would be a configuration file of a server. Such resources can be modeled by a resource in WSO2 Registry. Now, these are the basics. There are more elegant ways to model resources in the way you want. You can define a media type for your SOA resources. These can be either a standard media type or a custom media type. Then you can write handlers in WSO2 Registry to apply custom processing to such resources. Below are few things you can do for modeling SOA resources.
* Restrict allowed child resource types for a particular collection type
* Extract some values from a text file content and set them as properties or tags
* Validate the resource content and block invalid resources
* Provide custom view (UI) for certain resource types
There is very little limitation on what you can do with this plug in mechanism. And more features are on the list, which will be available for plug in authors. I will cover more on handlers later. But for now, this gives you an idea of what options are available for modeling SOA resources in WSO2 Registry.
Making up the structure of SOA resources is just a basic step towards SOA governance. There is lot more to come for making it complete, which I will cover later.
Thursday, July 10, 2008
WSO2 Registry custom UIs - an example
I though it would be useful to give a quick sample of custom UIs, since this is a new concept for SOA registries. So our sample here is an Axis2 module configuration file. Usually, if a custom UI is not provided, WSO2 Registry will give a download link to download the resource content. But we would like to view the module configuration, without downloading it. And also, we prefer to edit some parameters on the fly, from the UI. So, here are the results of using WSO2 Registry custom UI functionality to achieve above requirements.
Custom UI to view Axis2 module configuration:
Custom UI for editing Axis2 module configurations:
(sorry that images are not very clear after uploading them to blogger. I have to find a better way to add images)
Thus, you can generate UIs to match exact requirements of your SOA artifacts. You may highlight certain values, make some values immutable, add descriptions, etc. Magic behind this is the handler mechanism of WSO2 Registry (in fact, generating custom UIs is just a one application of handlers). And WSO2 Registry makes it more convenient to write custom UIs for XML content. You can just write XSLTs to generate view and edit UIs for XML content. That's exactly what we have done in this sample. You can browse the view and edit XSLTs for this sample from WSO2 Registry svn. All the resources for this sample can be browsed here.
Custom UI to view Axis2 module configuration:
Custom UI for editing Axis2 module configurations:
(sorry that images are not very clear after uploading them to blogger. I have to find a better way to add images)Thus, you can generate UIs to match exact requirements of your SOA artifacts. You may highlight certain values, make some values immutable, add descriptions, etc. Magic behind this is the handler mechanism of WSO2 Registry (in fact, generating custom UIs is just a one application of handlers). And WSO2 Registry makes it more convenient to write custom UIs for XML content. You can just write XSLTs to generate view and edit UIs for XML content. That's exactly what we have done in this sample. You can browse the view and edit XSLTs for this sample from WSO2 Registry svn. All the resources for this sample can be browsed here.
Tuesday, July 8, 2008
Custom UIs for SOA artifacts
Major step towards SOA governance is the visibility you get about the SOA deployment. Visibility has to cover many sections such as resource structure, users, privileges, dependencies between resources, etc. And we should not forget about the visualization of contents of SOA resources. But the resources in SOA deployments have different contents including WSDL, XSD and other application specific XML formats as well as other text and binary formats. So there is a challenge to provide the best view for all resource types.
WSO2 Registry addresses this problem by introducing custom UIs for SOA resources. That means the UIs for resources can be written by users and plugged in to the registry. Thus, each resource type gets the best possible UI. This is done by the handler mechanism implemented in the registry. Handler authors get the flexibility to provide UIs for both viewing and editing their resource types. Of course, WSO2 Registry will eventually provide built in UIs for many common resource types. So the end result is that the users of the WSO2 Registry gets a detailed and nicely tailored view of their SOA resources.
This feature is currently in the development stage. You can take an early look from the svn. Just build the registry and try out the custom-ui-sample1. This is still taking shape. More stuff will come in to this soon. So, stay tuned to WSO2 Registry to find out how make SOA governance easier.
WSO2 Registry addresses this problem by introducing custom UIs for SOA resources. That means the UIs for resources can be written by users and plugged in to the registry. Thus, each resource type gets the best possible UI. This is done by the handler mechanism implemented in the registry. Handler authors get the flexibility to provide UIs for both viewing and editing their resource types. Of course, WSO2 Registry will eventually provide built in UIs for many common resource types. So the end result is that the users of the WSO2 Registry gets a detailed and nicely tailored view of their SOA resources.
This feature is currently in the development stage. You can take an early look from the svn. Just build the registry and try out the custom-ui-sample1. This is still taking shape. More stuff will come in to this soon. So, stay tuned to WSO2 Registry to find out how make SOA governance easier.
Friday, January 11, 2008
More uses WSO2 Registry
I discussed about main methods of using the WSO2 Registry here. We can combine those methods of individual usages to achieve more interesting deployments of the Registry.
Let's consider the combination of Registry server deployment and the remote Registry deployments. In this scenario, you can start with deploying the Registry war file in an application server. To start with, create the initial users and roles to whom you are expecting to give some level of administrative privileges. Then you can define the initial categorizations of the Registry by creating the top level collection structure. These collections may include sub-collections for each of your departments, partners, suppliers, clients, etc. Then you can give the desired permission levels for the users who are supposed to manage each of those sub-collections. Once this is done, managers/heads of each sub-collection can use the Registry to store all the resources needed for their sections. These include the employee records (word documents), accounts (excel sheets), business plans (presentations), product details (pdf files), etc.
But that's not all. All the SOA related resources for each department can also be stored in the sub-collection tree of corresponding department. IT managers can store WSDLs for their services, jars/aars for pluggable components or services, configuration files used by department's servers, etc in the sub-collection tree of their department. Once you setup the resources for your SOA deployments in the Registry, you can point your web services servers, ESBs, application servers, etc to the Registry. Any server, that is completely unaware about the Registry or its APP based protocol can use it to fetch resource. Because simple HTTP GET requests are all you need to fetch resources from the WSO2 Registry. But if you want to access all the features provided by the Registry, you can embed the Registry APP client to your Java servers and call the Registry API though it. In this way, you can manage your organization's general resources as well as resources for driving the SOA deployments of your organization around the WSO2 Registry.
Let's consider the combination of Registry server deployment and the remote Registry deployments. In this scenario, you can start with deploying the Registry war file in an application server. To start with, create the initial users and roles to whom you are expecting to give some level of administrative privileges. Then you can define the initial categorizations of the Registry by creating the top level collection structure. These collections may include sub-collections for each of your departments, partners, suppliers, clients, etc. Then you can give the desired permission levels for the users who are supposed to manage each of those sub-collections. Once this is done, managers/heads of each sub-collection can use the Registry to store all the resources needed for their sections. These include the employee records (word documents), accounts (excel sheets), business plans (presentations), product details (pdf files), etc.
But that's not all. All the SOA related resources for each department can also be stored in the sub-collection tree of corresponding department. IT managers can store WSDLs for their services, jars/aars for pluggable components or services, configuration files used by department's servers, etc in the sub-collection tree of their department. Once you setup the resources for your SOA deployments in the Registry, you can point your web services servers, ESBs, application servers, etc to the Registry. Any server, that is completely unaware about the Registry or its APP based protocol can use it to fetch resource. Because simple HTTP GET requests are all you need to fetch resources from the WSO2 Registry. But if you want to access all the features provided by the Registry, you can embed the Registry APP client to your Java servers and call the Registry API though it. In this way, you can manage your organization's general resources as well as resources for driving the SOA deployments of your organization around the WSO2 Registry.
Three ways of using WSO2 Registry
In my previous post, I blogged about the 0.1 release of WSO2 Registry. Below are three simple ways of putting it in use.
Registry server with the cool web UI
This mode of usage is targeted at end users who want to organize and manage their enterprise/organization around the Registry. You can start this with virtually zero steps. Just drop the wso2registry.war file in to an application server and you are done! Now point your web browser to the URL http://localhost:8080/wso2registry (you have to use the port of your application server). You will get the web UI of the Registry, from which you can perform all the operations supported by the Registry.
Now you can keep on adding resources, categorizing them using collection, creating users/roles, granting permissions for users to access only the required operations on required resources, etc. So that is the initial administration step. Once you create necessary administrative users and roles, you can open up the Registry to your organization (and probably to your partners as well). Then sit back and watch how your enterprise's registry grows as users fill in content, tag them, comment on them, rate resources.... Basically Registry provides the infrastructure for building a community from your organization's members (and partners) who collaboratively builds and manages the resources of your enterprise.
Registry as a Java library for building content oriented applications
Core of the Registry can be embedded in Java application as a jar file. It provides an API through which all the features provided by the Registry can be accessed. So what is the use case of this... It serves as the back end to build applications that need to store and manage any content. In addition, your application automatically gets all the tagging, commenting, rating, versioning,... features. Plus, the comprehensive permission scheme on all the resources stored in the Registry. We, at WSO2 has used this Registry core to build the community site for WSO2 Mashup server. You can find a perfect example of building a Web 2.0 style community site using the WSO2 Registry library in the Mashup community site.
Registry to host remote content for applications
WSO2 Registry provides a remote API using APP. Currently it provides a Java APP client for the Registry API. You can embed this client in your Java applications and use WSO2 Registry as a remote content repository for your applications. This can serve as a great method for clustered deployment of content oriented applications, where all applications can be pointed to the same Registry for synchronizing the content among all nodes. Then all your applications get the community features mentioned above as well. As the Registry is running in the server mode in this case, you can simply use the web UI to administer the content of distributed applications.
As it uses the APP as the wire protocol, it is not restricted to Java. Programs written in any language can process the APP based protocol mentioned here and access the Registry remotely.
This is very high level overview of the uses of WSO2 Registry. Each of the scenarios mentioned above has more application specific usages. Start playing around and discover how it suits your organization or the application.
Registry server with the cool web UI
This mode of usage is targeted at end users who want to organize and manage their enterprise/organization around the Registry. You can start this with virtually zero steps. Just drop the wso2registry.war file in to an application server and you are done! Now point your web browser to the URL http://localhost:8080/wso2registry (you have to use the port of your application server). You will get the web UI of the Registry, from which you can perform all the operations supported by the Registry.
Now you can keep on adding resources, categorizing them using collection, creating users/roles, granting permissions for users to access only the required operations on required resources, etc. So that is the initial administration step. Once you create necessary administrative users and roles, you can open up the Registry to your organization (and probably to your partners as well). Then sit back and watch how your enterprise's registry grows as users fill in content, tag them, comment on them, rate resources.... Basically Registry provides the infrastructure for building a community from your organization's members (and partners) who collaboratively builds and manages the resources of your enterprise.
Registry as a Java library for building content oriented applications
Core of the Registry can be embedded in Java application as a jar file. It provides an API through which all the features provided by the Registry can be accessed. So what is the use case of this... It serves as the back end to build applications that need to store and manage any content. In addition, your application automatically gets all the tagging, commenting, rating, versioning,... features. Plus, the comprehensive permission scheme on all the resources stored in the Registry. We, at WSO2 has used this Registry core to build the community site for WSO2 Mashup server. You can find a perfect example of building a Web 2.0 style community site using the WSO2 Registry library in the Mashup community site.
Registry to host remote content for applications
WSO2 Registry provides a remote API using APP. Currently it provides a Java APP client for the Registry API. You can embed this client in your Java applications and use WSO2 Registry as a remote content repository for your applications. This can serve as a great method for clustered deployment of content oriented applications, where all applications can be pointed to the same Registry for synchronizing the content among all nodes. Then all your applications get the community features mentioned above as well. As the Registry is running in the server mode in this case, you can simply use the web UI to administer the content of distributed applications.
As it uses the APP as the wire protocol, it is not restricted to Java. Programs written in any language can process the APP based protocol mentioned here and access the Registry remotely.
This is very high level overview of the uses of WSO2 Registry. Each of the scenarios mentioned above has more application specific usages. Start playing around and discover how it suits your organization or the application.
Friday, December 28, 2007
WSO2 Registry 0.1 Released
WSO2 Registry enables you to store, catalog, index and manage
your enterprise meta data in a simple, scalable and easy-to-use
model. It is designed around community concepts such as
tags, comments, ratings, users and roles. Think of the registry
as a structured wiki designed to help you manage your
meta-data in a simple business-friendly system.
In addition, the registry allows you to store more unstructured
data such as Word documents, Excel spreadsheets and text
formats. Using these approaches, you can build a catalog of
enterprise information ranging from services, service descriptions
to employee data and on going projects.
WSO2 Registry can be deployed in Application Servers and
access using the Web UI or the APP interface. It can also be
used as a Java library inside other Java programs as
a resource store with all community features and versioning.
WSO2 Registry is released under the Apache License v2.0
Check out the project home page at
http://www.wso2.org/projects/registry
for additional information.
Enjoy the new way of managing resources over the web!!!
Features List
* Storing and managing resources and collections
Add, edit, delete and retrieve resources
Categorize resources using collections
* Tagging, commenting and rating resources
Tag resources and browse other's tags
Identify validity/weight of tags using tag clouds
Comment on resources and see what others have to say about your resources
Rate resources and see how the community has rated resources
* Managing users and roles
Create, edit and delete users
Add roles and assign users to roles
* Authentication and authorization
Protect resources/collections by controlling the authorization based on
users and roles
* Resource / collection versioning
Browse previous versions of resources/collections
Restore any resource/collection to previous versions
* Tag based search
Search resources by tags applied by you and others
* Advanced search
Search resources based on advanced criteria
* Activity log and filtering support for the activity logs
Browse all activities performed on the Registry with date, time and the
user who performed the activity.
* APP based Remote Registry
Embed remote Registry inside Java programs and make Java programs
interact with hosted Registry servers.
* Media type handling support (experimental)
* Web based user interface with Web 2.0 look and feel
Subscribe to:
Posts (Atom)
