Matevž Gačnik's Weblog

I just received an email from Stylus Studio creators asking me to sign a petition on the lack of XQuery support in .NET Framework 2.0.

I'm sorry. I cannot do that. It's just the rule I have.

Implementing a working draft version of an XML-based technology in a wide-spread product, like .NET Framework 2.0 is just out of the question. It has been done before with the XSL implementation in IE5, which then split to XSLT and XSL-FO, causing havoc for Microsoft.

On the other hand, implementing a stable subset of XQuery in SQL Server 2005 is another thing. While I don't necessarily agree with the necessity, I do agree that SQL 2005 and .NET Framework are two completely different beasts having different life cycle characteristics and flop-survival methods.

I'm wondering why the XQuery spec isn't moving anywhere. Maybe the lack of Microsoft editor in the editor list, helps ignoring the importance of this technology in the soon-to-be-released products. Current editors don't seem to be bothered with the decisions Microsoft has to take. I'm sure though, that Jonathan Robie (DataDirect Technologies) is pushing hard on Microsoft's behalf.

In any case, it's too late anyway.

Having spent the last two weeks tweaking my diagrams and pictures with a book designer, I learned quite a lot about differences in a design and development environment. To get facts straight, they live in a DPI-based world, which is nasty. And since my designer uses MacOS X platform to do the design stuff, a lot of interesting issues arrised. Again.

What I wanted to convey is: The book is finally done.

Title (in Slovene): Arhitektura sodobnih rešitev Microsoft .NET - Načrtovalski vzorci

Its physical incarnation should be available to general developer/architect public in a few weeks, but most definitely here.

Everyone who managed to send me an email after my previous blog post, will be getting a copy in his/her mailbox today.

If you would like a copy (electronic one, that is), drop me an email using this link.

Here's the TOC, up to level 3, (in Slovene):

1    PREDGOVOR
2    UVOD
3    OZADJE
3.1    O PLATFORMI
3.2    O PROGRAMSKIH JEZIKIH
3.3    O NAČRTOVALSKIH VZORCIH
3.3.1    Začetniki koncepta načrtovalskih vzorcev
3.3.2    Načrtovalski vzorci v informacijski tehnologiji
3.3.3    Načrtovalski vzorec: Windows DNA
3.3.4    Porazdeljene transakcije
3.4    SPLOŠNO O PORAZDELJENIH STORITVAH
3.4.1    Strateški pomen Enterprise Services
3.4.2    Prihodnost Enterprise Services
3.4.3    Hitrost COM+
3.4.4    O .NET Enteprise Services
3.4.5    O porazdeljenem transakcijskem koordinatorju (MSDTC)
3.5    KJE SMO?
4    NAČRTOVALSKI VZORCI
4.1    NAČRTOVALSKI VZOREC PORAZDELJENE APLIKACIJE
4.1.1    Ideja
4.1.2    Porazdeljena aplikacija potrebuje nivo fasade
4.1.3    Porazdeljena aplikacija potrebuje nivo dostopa do podatkov
4.1.4    Objekti entitetnih storitev validirajo poslovna pravila
4.1.5    Ločeno upravljanje transakcij
4.1.6    Procesi
4.1.7    Kje smo?
4.2    NAČRTOVALSKI VZOREC SPLETNE APLIKACIJE
4.2.1    Namen
4.2.2    Struktura
4.2.3    Stran začasnih naročil
4.2.4    Objekt DataSet
4.2.5    DataSet <> DataTable <> DataAdapter
4.2.6    Kje smo?
4.3    NAČRTOVALSKI VZOREC PODATKOVNEGA DOSTOPA
4.3.1    Namen
4.3.2    Struktura
4.3.3    Razredi
4.3.4    Dodajanje novega naročila
4.3.5    Kaj pa transakcije?
4.3.6    Dostop do podatkov
4.3.7    Kje smo?
4.4    NAČRTOVALSKI VZOREC ENTITETNIH STORITEV
4.4.1    Namen
4.4.2    Struktura
4.4.3    Primer poslovnega pravila
4.4.4    Nivo dostopa do podatkov
4.4.5    Validacija poslovnih pravil
4.4.6    Naprednejši koncepti validacije poslovnih pravil
4.4.7    Kje smo?
4.5    NAČRTOVALSKI VZOREC POSLOVNE FASADE
4.5.1    Namen
4.5.2    Struktura
4.5.3    Kdaj uporabiti?
4.5.4    Razmislite o spletnih storitvah
4.5.5    Kje smo?
4.6    NAČRTOVALSKI VZOREC TRANSAKCIJSKIH STORITEV
4.6.1    Transakcije in .NET v splošnem
4.6.2    Namen
4.6.3    Struktura
4.6.4    Kako deluje?
4.6.5    Kdaj uporabiti?
4.6.6    Kako uporabiti?
4.6.7    Kje smo?
5    .NET ENTEPRISE SERVICES
5.1    KAKO UPORABLJATI .NET ENTERPRISE SERVICES?
5.1.1    Načrtovanje komponent
5.1.2    Razredni in članski atributi
5.2    NAMESTITEV KOMPONENT
5.3    KJE SMO?
6    UNIČEVANJE VIROV
6.1    METODA FINALIZE
6.1.1    Dedovanje iz System.Object
6.1.2    O finalizaciji
6.1.3    Kdaj uporabiti finalizacijo?
6.1.4    Oživljanje
6.2    METODA DISPOSE
6.2.1    Kdaj klicati metodo Dispose?
6.3    BREZ UPORABE .NET ENTERPRISE SERVICES
6.3.1    Podatkovni nivo – osnovna komponenta
6.3.2    Podatkovni nivo – ostale komponente
6.3.3    Komponente drugih nivojev
6.4    UPORABA V .NET ENTERPRISE SERVICES
6.4.1    Podatkovni nivo – osnovna komponenta
6.4.2    Podatkovni nivo – ostale komponente
6.4.3    Komponente drugih nivojev
6.5    KJE SMO?
7    VIRI

If you still don't have my previous book, Arhitektura spletnih storitev - Usmeritve za načrtovanje, you can write to me using this link.

Thanks again to all the reviewers and especially to Microsoft gals who had to read this technical, unreadable text during the proof reading process. Thanks to Mateja from Alten, for doing a fantastic design work.

Well, it's a well known fact that dog owners and their companions act similar in lots of situations.

It seems to be true for me too. I just took a quiz at http://gone2thedogs.com and I came out as a Great Dane.

This is the result:

Dog Name: Great Dane
Origins: Germany

Amongst the tallest of dog breeds, the Great Dane is known in its native Germany as the Deutsche Dogge (German Mastiff). Often referred to as the Apollo of the dog world, this statuesque dog has existed in Britain for many centuries and is said to be descended from the Molossus hounds of ancient time Rome. In the middle Ages it was used to hunt wild boar, fight bulls and event employed as a bodyguard.

Just take a look at this fella. He pulls unreasonable stunts on me. While he definitely wouldn't like to fight a bull, he's taking his bodyguard job pretty seriously.

There is a furious discussion going on (again) on the XML-DEV mailing list about the necessity of binary XML representation format. Tons of press ink has also been spilled on this issue.

In essence, the XML data model consists of three layers:

1. XML Serialization Syntax (often called XML 1.0, XML 1.1)
2. XML Infoset (abstract data model)
3. PSVI (Post Schema Validation Infoset), (typed data model, brought by XML Schema)

The problem lies in number 1. XML serialization stacks produce nasty angle bracket wire serialization format which needs to be parsed into the XML Infoset before it can be exposed by any programmatic XML-exposing technology, like a DOM, SAX or what have you. In the reverse things get done in the opposite direction.

If we rule schema out of the view temporarily, there are currently two ways to encode a single XML document. One being the ordinary XML 1.0 + Namespaces 1.0 wire syntax, represented in XML Infoset 1.0 form by the parsers/stacks. The second one is XML 1.1 + Namespaces 1.1 wire syntax, represented in XML Infoset 1.1 form, which didn't gain enough momentum and it's a question whether it will in the future.

Question still remains about whether the XML industry has reached a sweet spot in the (non)complexity of the serialization syntax to allow fast processing in the future. It is my belief that we will not see a great adoption of any binary XML serialization format, like XOP or BinaryXML outside the MTOM area, which pushes XOP into SOAP. That stated, one should recognize the importance of main vendors not reaching the agreement for quite some time. Even if they do reach it some time in the future, the processing time gap will long be gone, squashed by the Moore's law. This will essentially kill the push behind binary serialization advantages outside the transport mechanisms (read SOAP). Actually, having a 33% penalty on base64 encoded data is not something the industry could really be concerned about.

There are numerous limiting factors in designing an interoperable serialization syntax for binary XML. It all comes down to optimization space. What do we want to optimize? Parsing speed? Transfer speed? Wire size? Generation speed? Even if those don't seem connected, it turns out that they are sometimes orthogonal. You cannot optimize for generation speed and expect small wire size.

We will, in contrary, see a lot more XML Infoset binary representations that are vendor-centric, being only compatible in intra-vendor-technology scenarios. Microsoft's Indigo is one such technology, which will allow proprietary binary XML encoding (see System.ServiceModel.Channels.BinaryMessageEncoderFactory class) for all SOAP envelopes traveling between Indigo endpoints being on the same or different machines.

It seems to me that either fuslogvw.exe or fusion.dll has a serious bug.

If you try to do some CLR assembly resolver logging using the above mentioned tehnology you can end up with an empty fuslogvw.exe window.

If that's the case and you have set ForceLog [1] registry key to 1 and LogFailures to 1 and still only get the empty window, try deleting temporary internet files directory. As it seems, Fusion has a problem when certain number of files exist in there.

After purging the internet temp files directory, things returned to normal.

[1] HCLM/Software/Microsoft/Fusion/ForceLog, DWORD