To UDDI or not to UDDI

So here is my first official post to my blog and unfortunately its not a happy one....

In June and most of July I was involved in designing and building a prototype, at HQ, for Oracle's next generation of Fusion Applications. I was tasked with designing the new Security Framework that Fusion Applications will use and a big chunk of the architecture involved using the 11G SOA Suite (apologies but I can't divulge more architectural details)

Being a big proponent of standards we chose to use Systinet's UDDI as the WebService registry for publishing and looking up our wsdl endpoints to make our BPEL processes and partnerlinks dynamic. The use case was simple, publish a WebService (BPEL processes or otherwise) to the UDDI registry and then look it up using the service name (and not the registryServiceKey as shown here by Clemens). We could not use the serviceKey since all we had at design time was the service name and not the key, think about this lookup as a JNDI lookup of a resource based on a JNDI name. UDDI experts will argue that its a bad idea to use a service name as the lookup parameter since a service name is not unique, and what happens when you have multiple versions of that same service. Well for this prototype we made an assumption that there will always be one service with that name and hence unique. We would tackle the version issue down the road...you know one step at a time.

So instead of using the registryServiceKey we had to use the UDDI/Systinet API to look up a service, I mean how hard can that be, right?? So we followed the Systinet examples that ship with the product, made sure that we could use them and then extend/change them to our needs.

So the first thing that hit me were the poor (read non-existent) JavaDocs and lack of examples on the Web. The irony of this exercise was that the Systinet UI had support for what we wanted to do (give me an endpoint based on a name) but there was no way to figure out what the underlying code looked like. I tried some reverse engineering but that lead to some more frustration and hair pulling and eventually lead us nowhere. Anyway after 12 days of looking, decompiling, posting questions on the Systinet forum (for which I still have not received a response) we had something that we could use, even though it still did not give us the functionality we needed.

And here comes the killer....let me ask you all you nice Java Developers, how many jar files do you need to run a single Java class? 1, 2, 3, 4, 5 jars..?? Hmm that's what I thought...ummm but not in this case...we needed a total of 28 jar files!! (that's after trimming from an initial count of 42). So to run a single class file  I need 28 jar files?? Hmmm talk about modularization!! Well, keeping faith we kept moving forward, and I looked at how we could add versioning and that brought along another aspect - publishing, which is just another can of beans...

So after 15 days of this, we realized the amount of complexity involved for such a simple use case, was just not worth it and relented. So UDDI gave way to the invincible and simple "Database 2 column Table". Yes, we are going to store our endpoints in the DB, and look them up using service names, all we want is the endpoint to be called dynamically (Dynamic endpoints, I will cover in my next blog posting). I wish it wasn't this way, but I guess some times you just can't beat the good ol' DB. I know that I won't be going close to a UDDI registry for a while....

Take care!

DA