Friday, July 12, 2002

Mark Baker writes about UDDI v3 and complains that the concept of UDDI is flawed, because he seems to see it as (in my words) some sort of big-brother-in-the-sky centralized thing in a anarchic distributed environment. I don't really know whether that's the core flaw of UDDI. I think the core flaw of UDDI is that there is nothing worth registering in it. The whole point of having a central registry is like that of the yellow pages. Your kitchen sink leaks, you look up a plumber, call him and he comes and fixes it. The UDDI equivalent for this is: Your kitchen sink leaks, you look up somebody who might be someone like a plumber but you really don't know what to look for, you call him and he's going to bring all the wrong wrenches. UDDI would make perfect sense to me if there was also a big WSDL-base-interface-definition-big-brother-in-the-sky who'd define common interfaces for web services that we'd all happily implement, maybe extend a little, but otherwise we'd all just stick to these standards and will compete on implementation and quality of service. Sort of like all the beauty of EDIFACT (but working this time and with functional semantics).  The problem is... it won't happen. If that doesn't happen, the usefulness of UDDI for public web services is on the same level as Yahoo! Minus pictures. However, the whole story changes in a controlled environment like a large enterprise network with some central control. Here is someone who's got the power to standardize and organize and make services discoverable across the whole "enterprise business logic web services bus". I guess moves like putting UDDI in .NET Server make a lot of sense for that, but any of the public clouds are more marketing than anything else. (Methinks) 3:39:44 PM      comment []

The license for my WS-Security & Transaction stuff is now EMACS friendly. We dropped the "may not be used with" clause from section (4). Also, yesterday's security source archive unintentionally and accidentially included some files from the WSSPI library by Tomas Restrepo. His "Authentication the SSPI way" article & code helped me a lot to understand SSPI; however, the files aren't used in any projects and I ended up rewriting the whole thing for Kerberos. Excuse me (!) and thank you a lot, Tomas!  .NET Enterprise Services fact of the day:  System.Runtime.Remoting.Messaing.CallContext actually gets propagated across COM+/ServicedComponent process boundaries into packages activated as server. Still, there is an unfortunate bug that spoils all the fun right now. That KB Article actually states "You cannot take advantage of the CallContext feature in ServicedComponent applications." By all I've seen, that's wrong. I've been told that the design didn't really mean to make that work, but it somehow "just happened". There is no elegant workaround for this bug, unfortunately. I my session extensions, I have created a ILogicalThreadAffinative hash table wrapper, which serves as my replacement for the CallContext lookup table. That wrapper I stick into a well-known slot in the CallContext. Whenever a serviced component needs to be created, it must be created through a helper function like < object CreateServicedComponent(Type t) >, which will hold on to the current hash table from the CallContext slot, create the component instance, restore the table back into the call context and return the component instance. I guess I've heard this will be fixed in V1.1. RTFM of the day: ICOMAdminCatalog2::CreateServiceForApplication 11:10:26 AM      comment []

Damn Legalese! Sam Ruby thinks that Peter Drayton can't use EMACS to work with or look at my WS-Security and Transaction extensions, because of our license. The thought isn't entirely warped (following the words of the license), but this isn't the intent, at all. This is no crusade against all GPL software, but shall only protect our source to become GPL'ed directly or indirectly through incorporation into GPL'ed code or redistribution along with GPL'ed code. If there's a better way to express that, tell me. Loud and clear: Use EMACS! 2:15:13 AM      comment []

© Copyright 2002 Clemens Vasters.