Alternative registry implementations

[kconner]

We have had a number of requests to provide an alternative to scout/juddi as our registry.

What issue would you want to see addressed by alternative registries? Which technologies would you wish us to support?

Kev

[bernd.koecke]

Hi Kev,

I'm working on such a small registry at the moment. I have the following reasons for doing this:

The combination of scout/juddi is slow. This slows down the shutdown process of JBossAS. And this let our scripts kill the JBoss-Process. But then some of the services were not removed from the registry and at the next startup the ESB doesn't remove them, too. After some time you have a lot of dead EPRs in the registry, which again slows down the Insertion and Removement of EPRs. And it slows down calling a service, too.

Newer versions of the ESB doesn't store any services in the registry. I think it is because only non gateway listeners were stored and the new default is an InVM-EPR which is not callable from outside the VM. But we used the registry to call a service from an external client. I learned that this was a bad idea, because we used ESB-Classes to send an ESB-Aware message to a non gateway EPR. But it is a nice feature to move a service from one cluster to another and the clients can call it without any changes, as long as the registry knows the new location. This is usefull for EJB- and WS-Calls, too.

You must configure a lot when you want to call a service through the registry. You have to set a system property, put a lot of JARs on the classpath only to find the location of a service. During this process a lot of XML-Data is moved. But the only dynamic thing in calling an JMS-EPR is the JNDI-Lookup-URL of the cluster nodes. So i would like to have a very easy interface for finding an EPR. It should be very easy to call it from Java and non Java languages.

We would like to use version numbers. For this we added the version to the service name to make the name unique. Lets say we use version x.y.z. We can't ask the ServiceInvoker for the newest version x.y of a service.

To meet these issues I'm building the following system:

The system is build out of some (minimum is 4) JMX-Managed-Beans. The data is stored into two SQL-Tables, but this is hidden by a persister bean (first MBean). For every deployable artifact a special MBean (one additional MBean, will be more in future) catches the JMX-Notification at deploy and undeploy time. These special MBeans will register itself to a Master (second MBean) and use the persister to store the information for calling a deployment. And there is an additonal MBean for handling version numbers. The first version will have a MBean to handle data for calling ESB-Servcies with a JMS-EPR. The internal data structure will have services, these are running on a cluster and this cluster is build out of several nodes. All of these items have properties and are combined by internal keys (Strings). When a node comes up he can check if the currently stored information about himself is valid.
The minimal information is the service name. You can set the EPR-Type, e.g. JMS and the version or part of a version to narrow down the EPR you are interested in. To make the interface as easy as possible, I want to use RESTeasy. All this is packed into a SAR an can be deployed on any of our JBoss-Nodes. All these nodes use the same database. You only have to know one node to find services which may run on another cluster. With REST you can encode all information in the URL and get back only a line with hostname and port in a csv list. By setting HTTP-Headers you can switch easily to a JSON-, XML- or HTML-Response.

This can be used by everybody without using SOAP-Stacks, JAXR etc. But it is very technical. This is no replacement for a repository.

Sorry for the long posting. I don't know if this is what you expected, but I hope it helps.

Bernd