A new kind of (SOA) Registry
So fundamentally the approach we have taken is to build a registry/repository based on REST concepts. And as we looked at the REST space, we kept noticing how close the Atom Publishing Protocol (APP) is to our needs, so we’ve made that the public remote API to access the repository. Of course, if you are just browsing the registry, you only need a browser - APP is mainly there to support updating resources.
The Systinet registry heavily relies on RESTful HTTP, too, but it’s still great to see this. If the road to acceptance of REST, Atom and AtomPub in hardcore SOA camps leads through the metadata use case first, that’s perfectly fine by me.
Funny thing .. I just did something quite similar .. I converted all the calls present in the UDDI Subscription API to use ATOM. Creating subscriptions, viewing , deleting etc. the whole thing.
Ofcourse me being a lowly student ,I couldn’t get the resources to test it all out/publish.
Other than that , has anyone actually seen a major advantage to this sort of work? Other than the simplicity that a new registry will bring (i.e it won’t inherit any of the UDDI cruft), what other advantage would this bring ? The question of network load is not that important over intranets imho, whereas over the internet every service will use HTTPS so no caching would exist.
So other than simplicity in design , exactly what advantage does this give ?
I know all the REST advantages and I am an advocate of REST , so don’t run me down with a list of the advantages REST provides in general. I am looking for a list of advantages specific to this use case (intranet registry for services). Using simple XML instead of SOAP falls in simplicity too.
I would argue that simplicity in itself is a great advantage, I don’t see why you’d discount it this easily. The major benefit is that Atom tooling - clients such as newsreaders or authoring tools, aggregators, pipe and filter tools such as Yahoo! pipes plus all of the HTTP tooling (e.g. wget, curl) can be used to access the registry. Every content item is a first class citizen of the Web. And I don’t see at all why everything would have to be HTTPS on the Internet, so caching would be a significant benefit, too.
But I find the question strange from someone who has taken a look at the UDDI API, which is so bad that even jotting down service names on pieces of toilet paper seems to be a superior solution.
Firstly I’m not sure I like being called a hardcore SOA camp :)
Secondly, I think there are big advantages in this being REST since fundamentally it is about Resource Management. I’m not convinced everything is Resource management but this usecase definitely IS. Secondly, why APP? Basically we needed to do lots of things that were very close to APP, and it would be really annoying to do all those things but differently, when there’s a perfectly good standard to help us. And making things available as feeds is definitely important - subscription is a key part of a registry. So it made lots of sense.
And finally Duryodhan… come and join the fun - you don’t need to do it on your own - you can join the Open Source project and have fun. We’d welcome you!
Paul