Vidar’s Musings

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.

Today, I attended Scott Hanselman’s opening keynote at Norwegian Developers Conference. He went through some of the emerging .NET related technologies from Microsoft, such as Linq (to SQL), Entity Framework, and Dynamic Data. Really a comprehensive introduction that gave a nice overview.

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.

Just moved my blog to a new blog engine, which introduces new functionalities such as comments. A new design is also part of the package.

The DSAPI is a very powerful feature of the Domino server where you can create filters that modifies the Domino web server’s behaviour when processing web requests. However, being a C/C++ API it is somewhat unaccessible to web developers like myself. (Personally, I haven’t done any C++ for 10 years). However, my experience is that the biggest hurdle is acutally to set up the development environment, not the development itself. After a bit of struggle, I  was finally able to set up a project in Visual Studio 2005 so that I could develop my desired DSAPI filter. In order to (hopefully) save anyone else from having to waste precious development time struggling Vicious Studio, I have set up a project that you can download here. (Note that I have removed all Lotus C++ API header and library files from the project in order not to violate any copyright legislation. You need to download the Lotus C++ API Toolkit for Notes/Domino 7.0a package and then copy the necessary files into the Visual Studio project).

Basically what I did was creating a new Visual C++/Win32 Console application where I during the project creation wizard set application type to ‘DLL’ and checked the option to ‘export symbols’. Then I created a subdirectory on the file system which I named ‘dsapi’. I then copied the header files and the ‘notes.lib’ file from the Lotus C++ API Toolkit for Notes/Domino 7.0a distribution into two subdirectories of the ‘dsapi’ directory, ‘Includes’ and ‘Lib’, respectively. Furthremore, there was a lot of configuration properties that needed to be changed:

• C/C++ -> Code Generation -> Runtime Library: Set it to ‘Multi-threaded (/MT)’.
• C/C++ -> General -> Additional Include Directories: Added ‘$(ProjectDir)\dsapi\Include’.
• C/C++ -> Precompiled headers -> Create/User precompiled Header: Set it to ‘Not Using Precompiled Headers’.
• C/C++ -> Preprocessor -> Preprocessor Defintions: Added ‘W32′ to the list of definitions.
• Linker -> Input -> Additional Dependencies: Added ‘$(ProjectDir)\dsapi\Lib\notes.lib’.

Once these steps have been done, the DSAPI module finally worked!

Earlier, I blogged about running JavaScript tests from Visual Studio 2005 where I automate Internet Explorer to load the HTML tests files directly from disk (file:/// protocol). One hurdle in this approach is the Windows XP SP2 local machine zone lockdown which restricts running scripts in local files. (More info here).

The easiest fix to this problem seemed to be the Mark of the web. Fair enough, I went on to add the mark to my JavaScript html test files, like so:

<!-- saved from url=(0019)http://www.foo.com/ -->

Alas, no luck. I still got the annoying message that I had to tick off the warning message each time Internet Explorer started. The trick here is that the line with the code above must en with CR LF (as mentioned here). Yikes. This problem was caused by Visual Studio not using the “Microsoft/Windows/MS-DOS” standard CR LF, but Unix style line delimiters! I opened up the file in Notepad++, selected Format–>Convert to Windows format, and lo it worked like a charm!

In my current project, we see an increasing use of JavaScript in our web application. Web 2.0, ya know. Hence, we have a growing need for being able to create automated JavaScript tests. A colleague of mine, Aslak Hellesøy, suggested that we should have a look at script.aculo.us’s unit test framework.

Fair enough, the script.aculo.us unit test framework seemed to do the trick. We use both prototype and script.aculo.us in our project, so the script.aculo.us unit test framework seemed to fit in nicely. My next concern would be to make it as easy as possible for the developers to run the tests as well as integrating
it into our continuous integration builds (we use TFS). The test results should somehow be made available in the test run report. The steps needed to achieve this would be something like
this:

1. Write the JavaScript unit tests and place them in an HTML file
2. From a Visual Studio Team System test method, fire up a browser that loads the HTML file and runs the test
3. Fetch the result of the JavaScript unit tests and incorporate them into the test report

script.aculo.us provides the pieces for 1 and 2 above out of the box. It also supports POSTing the results back to a web server using Ajax. That could be an approach that would be a part of the solution for point 3 above. However, I felt that this approach is not an optimal solution. First of all because you would have to to
make the tests available thru a web server, the web server would need to receive the results, and store them somewhere. Then, the Visual Studio test would have to fetch the results and incorporate them. It all adds up to seem quite fragile. It is important that a test run has as few external dependencies as possible. Hence, I
wanted a separate approach. The browser should be able to load the JavaScript tests directly from the file system (file:///…). Then, after running the tests we should be able to traverse the DOM of
the HTML page directly to fetch the results.

As a result, we ended up with this approach:

• Fire up Internet Explorer from .NET via its COM interface (Internet Explorer Object, SHDocVw.dll). You can find code for this here.
• Load the file directly from the file system (file:///…) and execute the tests
• Traverse the HMTL DOM to fetch the test results (using Microsoft HTML Object Library, mshtml.dll)
• Report any error messages back using Assert.fail(”…message…”)