Not sure how popular UDDI is in the private sector with the Fortune companies (as I've been working in the government sector for almost a couple years now), but UDDI is alive and well in the federal government, especially in the Department of Defense. The DoD is so large and the amount of money they spend on this stuff is so much that even if they were the only ones using UDDI, that would be enough to sustain it for a very long time. The various Agencies and Services in the DoD already or are planning to have UDDI registries.
In fact so many different organizations are rolling out UDDI registries that they need to start looking at how to federate all these registries. To that regard, there's been a lot of talk that the UDDI specs don't adequately support federation. Admittedly, I'm no expert in UDDI federation but I did take a quick look at the UDDI 3.0 specs the other day and to me it looked like there was decent support for federation in there. You can create a federation by setting up a root registry and a bunch of afiliate registries that get blocks of keys allocated to them from the root registry so that there are no ID collisions in the registry. Then there are also the Replication and Subscription APIs. So if you don't like the affiliates model they have, then you can set up your own federation model and use these APIs to synchronize the data among all the instances. So what else is missing?
soa, uddi
Subscribe to:
Post Comments (Atom)
Posts
No comments:
Post a Comment