Today my team started a new Sprint, with several very interesting technical stories. We are progressively migrating an architecture that uses EJB 2.1 for client-server communication and also for transaction control. Our new architecture uses RESTFul services (currently with Jersey 0.7) for communication and Spring + Ibatis underneath.
One of the main issues with the old architecture is the tight coupling between the server and the clients. The way it was designed, our server platform is limited by the oldest client’s platform. To have more flexibility and loose coupling between server and clients, we decided to have an XML contract in the communication.
In this Sprint we must finish the implementation of a Java client to be distributed to the client applications. We have some optimization and refactoring tasks for this Sprint, and one of them includes a RESTFul registry. We don’t want the clients to have our URIs configured via properties files. This approach limits our flexibility to manage URIs, so a different approach is desirable.
Our client will access a repository to ASK FOR the URI corresponding to a given service AND version. That means: the client willing to access the login service will ask the repository for the URI of this service, in the client’s version. The client could ask for /repository/login/v2.0 and then receive back the URI http://login.globo.com/login/v2.0.
We could have several different versions of the same services, each of them with different contracts. Introducing the repository as an extra layer of indirection, we also have the flexibility to take down several server machines for a while and even update URIs if desired (although that’s unlikely).
I checked Mule Galaxy and WSO2 Registry, but unfortunately they don’t give me what I need. They’re both open source registries, but they index SOAP services and some other things, but not RESTFul URIs. They offer a REST API to interact with their registries (unlike UDDI, which uses SOAP), but don’t index RESTFul URIs at this moment.
After this analysis of both, i decided to implement my own RESTFul registry. It shouldn’t be too sofisticated for this first release, but since it’s a frequent need in my team, I’m probably going to take some off-time to develop a nice registry that might be useful for a wider range of applications. My goal with this post is to gather some requirements for this registry and also its client. Features that would be useful for other people too.
The initial set of requirements that I wanna deliver in this Sprint is:
- Must have a RESTFul API to search for services
- Should be possible to browse published services with a web browser (even IE, if you call it a browser)
- Ajax clients should be able to access the registry easily
- Java client must run on JDK 1.4 and above
- Java client should require as few libraries as possible
- Registry should access the database through a JDBC datasource
- Offer an authenticated user interface to publish the services (probably with Java EE authentication)
An extra list of desirable features (not for this Sprint) is:
- Import service URIs from WADL document
- Allow database access without a JDBC datasource
- Show history of modifications in the registry
- Registry should be distributed as .war
- Offer other ways of authentication
Well, that’s the first ideas that come to my mind. My intention is to implement a nice registry and offer it for everyone to use it. If you think of some other features that would be nice in the registry, please let me know. The idea of this post is to be an asynchronous brainstorm, so please help! 
Hi Bruno!
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
I’m not sure if I understood your problem.
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
Hi Phillip, you’re right about the simplicity. Our requirements are not complicated, and something CRUD-like will do it just fine.
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