However, we find interesting to have this intermediate step, because it’ll make easier for us to update and migrate stuff. The client would know the registry URI to ask stuff and some very basic information like the name of the service and the client’s version. The registry would answer with the URI of the service and possibly some configuration parameters that we want to update on the client (we will provide the client for all Java applications).

At first glance it may seem that putting the registry in the middle is not necessary, but our current architecture (Java contract with EJBs) has a very tough problem with old client applications that are no longer maintained.

Introducing the registry and the service versioning will give us flexibility to keep avaiable several different versions of the same service. The older applications can keep using their legacy versions. The newer applications can update their services as needed. With our legacy Java client this was not possible in a clean way, and this is a much desired feature.

Well, that’s about it. I appreaciate your feedback, and will surely consider these discussions to decide the best way to design our architecture.

Regards,

Bruno

First I question the very registry itself. If I have to know the resource I want by its name (”/repository/login/v2.0″) I can’t really think of any big benefit in adding just some intermediate step to get to the resource. As the client already knows an Id to the service it wants, I would prefer it to know where to find it. Changing URIs in RESTful architectures is a big deal in spite of using a Registry or not so I would expect those to not change that often. When that happens it wouldn’t be a problem to return an HTTP 301 to tell the new location to the clients. I think that would be enough for most cases I’ve ever faced.

That said, I understand that sometimes functional or nonfunctional (i.e. sysadmins) requirements make it hard to not have a centralised point that knows all services in the ecosystem. In this case I would recommend that instead of going for a specialised solution you apply the same RESTful principle. In the end your Registry is just a RESTful webservice that manages a catalogue of other webservices. It’s probably a very simple CRUD-like implementation.

cheers

I’m Glen Daniels, Director of Java Platforms at WSO2 - noticed your post, and had a few quick comments.

First off, we’ve had several discussions within WSO2 about how to make the Registry directly support URLs. Although we don’t have any special tooling for this, you can do it now by either using text/plain documents or coming up with your own media type. If you go this route, you’ll just get back a URL as follows:

request - GET /wso2registry/resources/someURL

response - “http://whatever.is.stored/here”

We’ve also talked about being able to store a URL in such a way that a GET of the Registry URL will redirect your browser to the stored URL - we’ve got a number of potential uses for that sort of thing.

The other important point I’d like to make is that our Registry is very much a true open source project. All the code is Apache-licensed (hence usable without encumbrance), and we would be delighted if you felt like swinging by registry-dev@wso2.com to comment or better yet, help us make it better! We don’t want to dissuade you from doing your own thing (let many flowers bloom!) but it sounds to me like we’re already pretty far down the road you’re about to travel, and we might be able to get there faster together.

Thanks,
–Glen