Now that the UDDI V2 specs have been published[1], and there are a number of implementations of clients and servers (both closed and open source)[2], I can see two or three projects that would be cool based on the technology.
1) An independent network cloud of UDDI compatible, replicating index servers to hold an index of web services. This cloud would be independent of the main UDDI registry run by IBM, MS, HP (unless they wanted to join of course). Call it GNUDDI (GNUDDI's Not UDDI ;-)
2) A PHP/MySQL/Apache implementation of the UDDI V2 Index Server spec. This would provide a very low entry point for people wanting to help run 1) Call it PHUDDI. Or PHUDDI-Server
3) PHP/Perl/etc implementations of the UDDI V2 client spec as a tool-kit for people wanting to access 1) and 2) from code. Call it PHUDDI-Client.
I've been unable to find anything in the usual source code project repositories[3] and no real mention of anyone considering these sorts of approaches. I can see real benefit to the SOAP Web services community of having an index to SOAP based web services that is independent from the main UDDI servers. There is an inevitable problem of course, which is that I can't think of a revenue model!
Am I barking at the moon here or is anyone interested in trying to make this happen? Are there other forums in which to raise it?
[1]http://uddi.org/
[2]http://uddi.org/solutions.html http://www.juddi.org/
[3]http://www.newsforge.com/search.pl?query=uddi
http://freshmeat.net/search/?site=Freshmeat&q=uddi§ion=projects
http://www.hotscripts.com/search/?query=uddi&category=all
Postscript
I received this comment.
>Assuming that such an independent public UDDI network was running right now, how
>would you convince me that I should publish my business in it rather than
>(or in addition to) the UBR? Unless you can provide some extra value, I
>don't see why I would bother. It reminds me of various alternative "yellow
>pages"
>publishers that pop up from time to time, and then disappear because they
>can't make any money out of it.
To a certain extent I'm being provocative to brainstorm the issues and the one you raise makes sense. But think about DNS and how that's developed from a single registration point to multiple registration points and the occasional challenge from a complete independent. And in some respects UDDI was designed with DNS as a pattern.
There's a paper from IBM that talks about the different types of (hypothetical) servers. Let's say we have UDDI; ISPs and BigCos running local cache servers; BigCos running completely internal groups of servers. Even if they don't all replicate together initially, I can imagine most of these getting linked up over time. Now we get into the question of how many registration points there are. In principle any UDDI server can be a registration point into the cloud. But now we have a big data integrity and quality problem so several of these will only replicate outwards except to specific known servers that have similar data policies.
A couple of other data points.
SOAP (and XML-RPC) Web service interfaces are being built for all sorts of functions. For instance, someone has recently wrapped a dictionary to create a callable spell checker. Someone else has wrapped (GPL) Phorum to create a hosted web board discussion service. If and when SOAP really takes off we can expect to see such web service entry points all over the web for the most unlikely functions that have little or nothing to do with B2B trade. Now there's clearly a need for an index of such services but should this sort of data go into the main UDDI? If for any reason the main UDDI registration points reject it, we immediately get a need for an alternative cloud.
Then there's the increasing quantities of passive but XML formatted data on the net such as RSS headline feeds. There are various attempts to locate and index these. But the web spiders are not very good at finding them and the current index attempts are architected like Yahoo or DMOZ. This sort of information is perfect for UDDI, given that the readers and parsers of the data are already XML aware. But now we're stretching the UDDI paradigm even further away from B2B trade.
Microsoft recently demo-ed a link between the browser, RealNames and UDDI. It turned the browser address line into a UDDI search interface. Almost the first question asked by a journalist was "Will you be able to configure it to search alternate registries? Like an Intranet UDDI server for instance.".
In the real world we have Yellow pages. But in some countries it co- exists with several other index systems like Thompson Local Directories. On the net, Yahoo is not the only index. Even at the structural level DNS has had to mutate to accommodate multiple registration points.
With UDDI, we are still at first base and have a rare opportunity to learn from history, make some predictions and guide the development. And that's why I keep asking two questions so they can get answered now rather than breaking the whole system later.
- What are the limits to what is appropriate for a UDDI entry?
- Which servers replicate with which, and who gets to decide?
http://www-106.ibm.com/developerworks/webservices/library/ws-rpu1.html is an article about the different roles that UDDI server nodes may take. eg
1. UDDI Operator node
2. e-marketplace UDDI
3. Portal UDDI
4. Partner catalog UDDI (also known as Vetted partners or rolodex-like UDDI)
5. Internal Enterprise Application Integration UDDI
6. Test Bed UDDI.
So let's ask some questions:-
1. The article assumes that there should only be one Operator cloud. Why? Could there be >1? Should the model be a single Yahoo DBMS replicated in a few places, or should it be like DNS with a handful of registration points, but a V large number of more local copies?
2. I find it hard to understand why a public e-marketplace node would not simply use 1). Or at least replicate up and down with 1) if the e-marketplace is a major source of registrations, surely 1) will want a copy. What happens when there are two competing e-Marketplaces in one vertical niche. Do we really want to create a situation where they have to compete for their shared customers to get them to register twice?
3. Isn't this actually part of 1)? If 3) is a source of registrations about APIs published by the organization, why aren't they simply published in 1) Aren't we really talking about a local cached copy of 1)?
4. OK. So we put a local cached copy of data about our trading partners on a UDDI node inside the firewall. But if the data is also registered
in 1), 2) or 3) why not just go direct to those?
5. Implement a UDDI node or cloud purely internal to the organization for purely internal use. How long before some of these APIs are important enough to be published to the outside world as well?
6. Of, course, we all need test beds if we're going to test against something without hitting 1) with too many requests.
All of this looks to me as though plenty of competing sets of code that implement the UDDI server c/w replication would be a *good* thing. If
this occurs, it's up to the Big 3 to ensure that the Operator cloud grows responsibly. And if too many restrictions appear on who can
replicate or what can be registered, then an alternate cloud *will* appear.
[ << UDDI Scenarios ] [ Proper motorcycling attire >> ]
[ 0 comments ] [ G ] [ # ]
1) An independent network cloud of UDDI compatible, replicating index servers to hold an index of web services. This cloud would be independent of the main UDDI registry run by IBM, MS, HP (unless they wanted to join of course). Call it GNUDDI (GNUDDI's Not UDDI ;-)
2) A PHP/MySQL/Apache implementation of the UDDI V2 Index Server spec. This would provide a very low entry point for people wanting to help run 1) Call it PHUDDI. Or PHUDDI-Server
3) PHP/Perl/etc implementations of the UDDI V2 client spec as a tool-kit for people wanting to access 1) and 2) from code. Call it PHUDDI-Client.
I've been unable to find anything in the usual source code project repositories[3] and no real mention of anyone considering these sorts of approaches. I can see real benefit to the SOAP Web services community of having an index to SOAP based web services that is independent from the main UDDI servers. There is an inevitable problem of course, which is that I can't think of a revenue model!
Am I barking at the moon here or is anyone interested in trying to make this happen? Are there other forums in which to raise it?
[1]http://uddi.org/
[2]http://uddi.org/solutions.html http://www.juddi.org/
[3]http://www.newsforge.com/search.pl?query=uddi
http://freshmeat.net/search/?site=Freshmeat&q=uddi§ion=projects
http://www.hotscripts.com/search/?query=uddi&category=all
Postscript
I received this comment.
>Assuming that such an independent public UDDI network was running right now, how
>would you convince me that I should publish my business in it rather than
>(or in addition to) the UBR? Unless you can provide some extra value, I
>don't see why I would bother. It reminds me of various alternative "yellow
>pages"
>publishers that pop up from time to time, and then disappear because they
>can't make any money out of it.
To a certain extent I'm being provocative to brainstorm the issues and the one you raise makes sense. But think about DNS and how that's developed from a single registration point to multiple registration points and the occasional challenge from a complete independent. And in some respects UDDI was designed with DNS as a pattern.
There's a paper from IBM that talks about the different types of (hypothetical) servers. Let's say we have UDDI; ISPs and BigCos running local cache servers; BigCos running completely internal groups of servers. Even if they don't all replicate together initially, I can imagine most of these getting linked up over time. Now we get into the question of how many registration points there are. In principle any UDDI server can be a registration point into the cloud. But now we have a big data integrity and quality problem so several of these will only replicate outwards except to specific known servers that have similar data policies.
A couple of other data points.
SOAP (and XML-RPC) Web service interfaces are being built for all sorts of functions. For instance, someone has recently wrapped a dictionary to create a callable spell checker. Someone else has wrapped (GPL) Phorum to create a hosted web board discussion service. If and when SOAP really takes off we can expect to see such web service entry points all over the web for the most unlikely functions that have little or nothing to do with B2B trade. Now there's clearly a need for an index of such services but should this sort of data go into the main UDDI? If for any reason the main UDDI registration points reject it, we immediately get a need for an alternative cloud.
Then there's the increasing quantities of passive but XML formatted data on the net such as RSS headline feeds. There are various attempts to locate and index these. But the web spiders are not very good at finding them and the current index attempts are architected like Yahoo or DMOZ. This sort of information is perfect for UDDI, given that the readers and parsers of the data are already XML aware. But now we're stretching the UDDI paradigm even further away from B2B trade.
Microsoft recently demo-ed a link between the browser, RealNames and UDDI. It turned the browser address line into a UDDI search interface. Almost the first question asked by a journalist was "Will you be able to configure it to search alternate registries? Like an Intranet UDDI server for instance.".
In the real world we have Yellow pages. But in some countries it co- exists with several other index systems like Thompson Local Directories. On the net, Yahoo is not the only index. Even at the structural level DNS has had to mutate to accommodate multiple registration points.
With UDDI, we are still at first base and have a rare opportunity to learn from history, make some predictions and guide the development. And that's why I keep asking two questions so they can get answered now rather than breaking the whole system later.
- What are the limits to what is appropriate for a UDDI entry?
- Which servers replicate with which, and who gets to decide?
http://www-106.ibm.com/developerworks/webservices/library/ws-rpu1.html is an article about the different roles that UDDI server nodes may take. eg
1. UDDI Operator node
2. e-marketplace UDDI
3. Portal UDDI
4. Partner catalog UDDI (also known as Vetted partners or rolodex-like UDDI)
5. Internal Enterprise Application Integration UDDI
6. Test Bed UDDI.
So let's ask some questions:-
1. The article assumes that there should only be one Operator cloud. Why? Could there be >1? Should the model be a single Yahoo DBMS replicated in a few places, or should it be like DNS with a handful of registration points, but a V large number of more local copies?
2. I find it hard to understand why a public e-marketplace node would not simply use 1). Or at least replicate up and down with 1) if the e-marketplace is a major source of registrations, surely 1) will want a copy. What happens when there are two competing e-Marketplaces in one vertical niche. Do we really want to create a situation where they have to compete for their shared customers to get them to register twice?
3. Isn't this actually part of 1)? If 3) is a source of registrations about APIs published by the organization, why aren't they simply published in 1) Aren't we really talking about a local cached copy of 1)?
4. OK. So we put a local cached copy of data about our trading partners on a UDDI node inside the firewall. But if the data is also registered
in 1), 2) or 3) why not just go direct to those?
5. Implement a UDDI node or cloud purely internal to the organization for purely internal use. How long before some of these APIs are important enough to be published to the outside world as well?
6. Of, course, we all need test beds if we're going to test against something without hitting 1) with too many requests.
All of this looks to me as though plenty of competing sets of code that implement the UDDI server c/w replication would be a *good* thing. If
this occurs, it's up to the Big 3 to ensure that the Operator cloud grows responsibly. And if too many restrictions appear on who can
replicate or what can be registered, then an alternate cloud *will* appear.
[ << UDDI Scenarios ] [ Proper motorcycling attire >> ]
[ 0 comments ] [ G ] [ # ]