Ivan Krivyakov's Blog

I have finally bought a modern OOA/D book: Craig Larman, “Applying UML and Patterns”). Martin Fowler recommends it as a good OO book in his “Patterns of Enterprise Applications Architecture“, and I tend to trust Martin’s opinion on this one.

The last full textbook I read on the subject of OOA/D was “Object-oriented analysis with applications” by Grady Booch, published circa 1994, which is quite old by now, even pre-UML. Of course, I don’t count the GoF , and many other books and articles, I am talking textbook level here.

This may be embarrassing, but that’s the truth: if you are doing real project development, you often don’t have time for textbooks. I will comment on the Larman’s book in this blog as I go – I found this as a best way to remember what I read and my thoughts around it.

I really like the book so far: e.g. it explains the difference between the A and the D right away, which is a good thing. It also has many catchy phrases like do the right thing (analysis) and do the thing right (design) which, while may be being obscure, help to remember the essence of the material.

So, more posts to come…

I ran into an interesting problem when I was brushing up my web site lately. Let’s say I had a static HTML page named http://www.ikriv.com/page.html.

Now, I decided to use some kind of cool technology (PHP, ASP, JSP, CGI, SSI, FBI, CIA, USA, well, you get the picture). This would work only if I rename page.html to page.php (.asp, .jsp, .fbi, …). This is how the web server knows what technology to apply when rendering the page. This, however, has at least two downsides:

• The URL will change and external links will break. Not all external links are under my control.
• People, including Evil Hacker People, will now know what technology I use to generate the page.

In the end I decided to use Apache URL rewrite feature to keep old URLs intact. It is quite easy to define in an .htaccess file in each web directory, but if you do something wrong, the rewriter quirks could be really annoying.

Here’s a couple of examples:

RewriteEngine on
RewriteRule ^foo\.html$ foo.php

RewriteEngine on
RewriteRule ^(.*)\.html$ $1.shtml

The people outside your server keep going to the old .html URL and the server does all the mapping seamlessly. A lot of rewrite rules will, of course, slow down a heavy loaded server, but a couple of rules here and there don't seem to hurt that much.

WCF comes with a very handy configuration language that allows you to define bindings, end point properties and the like. Doing the same in code is a) tedious, b) inflexible: any minuscule change would require recompilation and redeployment.

The trouble is, the configuration information is read from the .NET configuration file, which is unconditionally set to calling_executable.exe.config, at least for the primary app domain. This is true even if the calling executable is not a .NET application.

This inflexible rule stands in a way of self-contained libraries that use WCF. It is not possible to define WCF configuration on a per library basis, it must be done at the application level. Not only we have a leaking abstraction here, this abstraction may leak into very interesting places. E.g. if you are writing a COM+ component, the configuration file it will use suddenly depends on whether it is in-proc or out-of-proc, and all out-of-proc components may as well end up reading dllhost.exe.config.

Modular application that load plugins dynamically (along the lines of CAB) face even bigger problem. It is not possible to know in advance what WCF settings will be used by a plug-in, so this information cannot be placed into the application config.

Reading a different configuration file should have been easy, but it is not. WCF is really hardwired to calling_exe.exe.config. Some redirection is possible, but it is quite verbose and complicated (see “Loading the WCF configuration from different files on the client side“).

This is only one consequence of Microsoft’s decision to hardwire the configuration to a specific file. In the Java world this decision would probably be unthinkable. Almost everything in Java can be substituted to a different implementation. If it’s not an interface, it’s a system property. .NET, however, pursues a different philosophy (see “Is .NET Really a Java Clone?“).

In many cases it is fine, but the decision to hardwire the configuration path is unfortunate and it keeps biting us. Mr. Gates, thou shalt not hard code!