I’m starting to work on the 2nd edition of Java Web Services, and I’m wondering what to do with the UDDI chapter. Does anyone out there actually use UDDI, or have plans to? I haven’t heard much noise about it in a while…either from industry buzz or from customers for that matter….
I’m thinking about putting it more towards the back of the book, or maybe even getting rid of it as a separate chapter. What’s your view on the subject?
I’m looking for feedback from the readership. Please respond.
UDDI
David, For what it's worth, I'm askign myself (and others) the same question. I'm nearly done with my own web-services book (strategy, not technology), and I'm going back and forth about whether to include a UDDI chapter or not. Let me know if you have the answer! :-)
...doug kaye
doug@rds.com
www.rds.com
Please include WSIL.
I know exactly what you mean Dave. The only people I discussion I'm hearing is from vendors developing UDDI products. I guess stick it in the back just in case?
Please do include Web Service Inspection Language (WSIL). Don't forget about REST Web services either.
UDDI-SchmooDDI
Whew, I'm with you brother. I think my subject line speaks for itself.
Keep up the great work Dave, I love your stuff!
Jack Murphy
jmurphy@microsoft.com
Focus on Private UDDI
There doesn't seem to be a big demand for deep UDDI knowledge in the developer world. Although I enjoyed Java Web Services 1st edition, the 41 pages of UDDI was overkill. I think you should brush the surface of the core technologies/APIs, talk about UDDI vs. ebXML Registry/Repository, and focus on practical uses of registries within an enterprise.
Let's face it--dynamic agents aren't going to search UDDI registries, find a service, auto-negotiate, and invoke methods with no human intervention. You made a good point in your 1st edition about how it is most likely that business analysts will take care of the searching and negotiating.
Public UDDI won't fly.
Recommendations and Google will still be the main source for finding any kind of product or service. (It would be nice if Google started a public UDDI registry. It would be even nicer if they added a "UDDI" tab to their main page and organized it like their Web Directory. That way you can search based on relevance and not worry about Microsoft, HP, or IBM always ranking first.)
Last but not least, the topic of Private UDDI registries within an enterprise or amongst partners. Most likely, this is how UDDI will be deployed anyway. A company will publish all of its services in an internal registry to maintain an organized repository. That way they can easily integrate new Web Services into their private portal or have a standard way for all the departments to use each others services.
The funny thing is I'm using UDDI for something it wasn't really intended for. Web Service client programs will usually know the URL Endpoint of the service they wish to invoke. There are many ways of specifying the service to invoke: they can either go through the trouble of querying a UDDI registry and obtaining the URL, obtaining it through input from a user interface, or just hard coding it into the code just to name a few. Since web services are similar to web servers in that they must learn to deal with traffic, web services clients must also learn how to deal with responses from web services. No one wants to see a 404 page or a SOAP Fault. There are many methods for server mirroring, failover, fault tolerance, backup, redundancy, or whatever you want to call it, that should ensure uptime. My point is that I'm using UDDI to query for backup services. For example, the client program tries to connect to a web service, the client doesn't receive a response, receives a certain response, or a SOAP Fault that triggers it to disconnect from the current service, query a registry for backups to the service, and connect to that service using the Endpoint provided from the registry. Of course, this assumes that the backup web services are replicas of the one that went down, hosted on different servers, or that they are services that are written by third parties who adhere to the same standard naming convention.
Just an idea of how to use UDDI for something practical. So my final advice is to get rid of it as separate chapter and include it in a "Web Services Issues" chapter or in the case of my last example it can fit in with SOAP Faults, handling responses, or some kind of chapter that discusses deploying mission critical web services and how to ensure uptime with web services clusters.
Hope that helps,
Nasseam
http://www.myspotter.com/
UDDI
Novell recently released a UDDI server as part of it's web services push.