Jakub, one of the project members on my current project pointed me to this blog entry explaining a threading issue with Directory<K,V> in .NET: Hashtable and Dictionary thread safety considerations. I know that I earlier have written code exactly like the one in the blog entry, so this was a bit of an eye-opener.
I was at a presentation about Windows CardSpace a couple of days ago. Beautiful technology it might be, but I cannot help questioning the adoption of CardSpace in the real world. I cannot say I have ever come across any site that supports it. Have you? (If so, please let me know). On the other hand, OpenId seems to get quite a bit of momentum being supported by some of the big Internet companies out there (Yahoo!, Google, AOL to name a few).
OK, CardSpace and OpenId do not offer exactly the same solution, and are in some respects not comparable. Biggest difference would be OpenId’s reliance of passwords as authentication mechanism (which is one of the reasons for its lack of phishing attack protection), while CardSpace solves this problem using cryptography. However, there are a lot of similarities:
- Both offer a distributed model that accepts various Identity providers (the user can choose from a number of IdPs)
- Both address the challenge with maintaining several user account/password for different Internet services
“OpenId is no good because it isn’t secure”
When asking the presenter about the adoption of CardSpace versus the adoption of OpenId, this was his response. I think that this is a gross oversimplification that serves no other purpose than spreading FUD about security.
First of all, if OpenId is good enough for Yahoo! and the like, it will probably be good enough for 80% of the Internet sites out there. I can think of a lot more sites out there that require “less security” than Yahoo! out there, than sites that require a higher security level.
Secondly, security is not binary (secure – not secure). There are different levels of security. Saying that one solution is secure and another one isn’t, is being ignorant towards the field of security. Basically, security (as everything else) come at a cost. In the case of CardSpace, the cost is maintenance of your cards and the corresponding public/private key infrastructure. I do not know CardSpace in detail, but a main challenge here I suspect will be exactly the same as for other public/private key based solutions: how do you bring your keys with you? For instance, if you created a card in a CardSpace on your workstation at work, how do you bring them with you when you want to log in from your home computer or from an Internet café? Having them on a USB stick would probably be a choice, but even that limits the usage quite a lot. Passwords, on the other hand, you carry with you in your head (at least, that’s the idea ;)).
On NDC a couple of days ago, I went to a session where David Chappell talked about Microsoft’s forthcoming “Oslo”. He went to great lengths to not reveal too much, as Microsoft is keeping everything very secret. In fact, he spent more time explaining what “Oslo” is not than what it actually is.
Figuring actually what is intended to be is not easy. However, from the presentation, we know that “Oslo” is more of a “technology” or “platform” rather than a product. It will consists of the following parts:
- The Repository. It is a storage space that has schemas that defines its data types. Actually what type of information it is supposed to or limited to, is not known. However, examples include things such as process definitions, workflow definitions, IT infrastructure information, and SLAs.
- The Visual Editor. This is a general purpose tool that allows for editing of content in the repository. General purpose meaning that it can be used for different types of data. However, not all communication with the repository need to go through this tool. Special purpose applications or tools can connect and interact with the repository directly.
- Extensions to Windows Workflow Foundation (WF). I am not sure exactly what kind of extensions we will see, but I can guess that it would mean extra activity components.
- The process server. Basically, the WF does not define any host process for running workflow, and the way I figure, the process server implement such a process. It will contain a component called Lifecycle manager that can manage many process host instances (I guess for Load balancing, failover, etc.). The process server will also contain the ability to run BizTalk stuff. A question that comes to mind is whether the process server is “Biztalk for managed code” – built with the capabilities of WF and WCF? Time will show.
So what is the common denominator for all this? I am not sure. I can’t help it, but one word that keeps popping up in my mind is “governance”. Will this be “Microsoft’s tool for IT governance”?
Anyways, the time perspective of this is not known. When will this be available? All we know, is that Microsoft is planning to deliver this in three releases. Will it be in 2009?
I attended a session with Mary Poppendieck at NDC today where the topic was trashing in projects. I was a very interesting talk. One of the things that I got out of it, was the notion of churning, which basically is about two things:
- If you have requirements churn, you are specifying requirements too early. Basically, this means that after you write the requirements, the customer changes his or her mind, and the requirements need to be changed before implementation starts.
- If you have test and fix cycles, you are testing too late. In general, testing should be done earlier, and preferably automated
Furthermore, Poppendieck made a few references to classic queuing theory, saying that if the utiliziation of a resource is too high (saturated), the handling time will be lower and result in trashing. Hence, one should no plan for a 100% utilized project resource. The main thing is to optimize on throughput, and not on utilization.
Not being sexist at all, I found this blog entry to be quite good: How I explained REST to my wife.
I found this very interesting blog entry: 13 reasons for UML’s decent into darkness.