Matevž Gačnik's Weblog

While doing some serious Indigo development I noticed that a process was up and running for a long period of time after any errors in the Indigo runtime occured.

It was dw20.exe. Doctor Watson.

Thank you Doctor, but I only read the brutal stack trace.

So, if you're like me and don't care about sending specific self-induced pre-beta technology error traces to Microsoft, do this:

1. Open Control Panel/System
2. Goto Advanced tab
3. Click Error Reporting button
4. Disable error reporting
5. Disable critical error notifications

Indigo develoment is a lot more enjoyable now.

I normally disable this anyway, but this was inside a Virtual Server image, and as it goes, you learn it the hard way.

I was in Brussels on Wednesday the previous week, spending time at the European Parliament. We had meetings with our 7 MEPs (Member of the European Parliament). I can only agree with the general points Clemens made in his blog entry and with the fact that MEPs have a hard time deciding on this.

We did, however, manage to present our opinions on the CII directive successfully. There is still a strong pressure inside some of the EP groups not to support the directive. And there are still groups which are deciding on whether to only support it with certain amendments.

The problem is that, as it seems, this directive will not be voted by MEPs individually. All groups will decide internally and then go for a group vote. It is therefore of much importance that anybody with access to their MEPs voices his/her opinion. Anybody can do it. Here's the link.

CII should be supported in its current form, without any "force of nature" or "interoperability" amendments. They will make things much worse over time and help paralyzing the patent system in EU.

Our viewpoint on this is available in English on my download site: http://downloads.request-response.com/cii.zip (118KB).

I strongly believe that the majority of opponents seem to think this issue is one of large vs. small companies. It is not. It has nothing to do with an impact on the bureaucracy work too. The CII directive only helps - is a first step toward - harmonizing the patent system throughout 25 member states. And again, it does not allow software patents per se. It makes me quite sad to see that most of the arguments are strongly voiced having only a populistic stance over the CII directive. It is a good thing to have, a good thing to support innovation and a good thing to enforce ones rights over his/her invention.

I have also included the draft version of CII in the above ZIP file.

For those of you (especially in our land), who didn't manage to get to TechEd 2005 Orlando, there's a two step process to get insight and up-to-date:

1. Download a Podcast client (see this site to find out how)
2. Use this endpoint for TechEd 2005 Orlando podcasts

Have fun. I attended, but am still scraping through the content. It's brilliant.

Congratulations go to System.Xml team.

This is fabulous! It's kicking buts, that's what it is.

Oh my god.

Have to admit. We own this and this and she loves it.

Steve Jobs (Apple):

“Our goal is to provide our customers with the best personal computers in the world, and looking ahead Intel has the strongest processor roadmap by far. It’s been ten years since our transition to the PowerPC, and we think Intel’s technology will help us create the best personal computers for the next ten years.”

Roz Ho (Microsoft):

“We plan to create future versions of Microsoft Office for the Mac that support both PowerPC and Intel processors. We have a strong relationship with Apple and will work closely with them to continue our long tradition of making great applications for a great platform.”

Glad they agree. Join the teams. Passion and market penetration always resonates.

A few days ago, Indigo + Avalon RC Beta 1 went live on MSDN.

There are three packages to download, if you want to check out what's new in MSMQ integration scenarios and especially queued channels.

1. Indigo Runtime RC Beta 1
2. WinFX SDK RC Beta 1
3. MSMQ 3.5 Beta for Indigo

While I don't want to get into a discussion on naming schemes (and yes, I do understand that genuine Beta 1 is reserved for Longhorn Beta 1, but this is too much), these three will give you an option to review what's been hidden on the MSMQ story.

Things to consider:

• Try and install MSMQ 3.5 after native MSMQ support in Add/Remove Programs. It will make your life easier.
• Indigo RC Beta 1 will only work on official .NET Framework Beta 2. It will not work on any previous CTPs.

Having that installed, we can write some MSMQ Indigo code. A simple calculator service has a simple service contract:

[ServiceContract]
public interface ICanCalculate
{
  [OperationContract(IsOneWay=true)]
  void CalcOp(Operation enmOp, int intA, int intB);
}

public enum Operation
{
  Add,
  Subtract,
  Multiply,
  Divide
}

All messages are processed asynchronously, therefore IsOneWay should be set to true on all operations. Any processing is not done at invocation time, but rather at service processing time, which decouples your client from your service. Service implementation, which implements ICanCalculate does the obvious:

public class CalculatorService : ICanCalculate
{
  [OperationBehavior(AutoEnlistTransaction=true, AutoCompleteTransaction=true)]
  public void CalcOp(Operation enmOp, int intA, int intB)
  {
    int intResult = 0;
    switch (enmOp)
    {
      case Operation.Add:
        intResult = intA + intB;
        break;
      case Operation.Subtract:
        intResult = intA - intB;
        break;
      case Operation.Multiply:
        intResult = intA * intB;
        break;
      case Operation.Divide:
        intResult = intA / intB;
        break;
      default:
        throw new Exception("Invalid operation.");
    }
    Console.WriteLine("Received {0}({1}, {2}) - result: {3}", enmOp.ToString(), intA, intB, intResult);
}

There's a AutoCompleteTransaction property set to true in OperationBehaviour attribute, which automatically commits the transaction if no exceptions are thrown.

Up till now, nothing is different from any basic Indigo service. What's beautiful about Indigo architecture is that every single binding detail can be done via configuration. MSMQ endpoint is therefore configured using the following config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
 <system.serviceModel>
  <bindings>
   <netProfileMsmqBinding>
    <binding configurationName = "MSMQBinding"
       msmqAuthenticationMode = "None"
       msmqProtectionLevel = "None"/>
   </netProfileMsmqBinding>
  </bindings>
  <services>
   <service serviceType = "Indigo.Demos.CalculatorService">
    <endpoint address = "net.msmq://./private$/CalcQueue"
        bindingSectionName = "netProfileMsmqBinding"
        bindingConfiguration = "MSMQBinding"
        contractType = "Indigo.Demos.CalculatorService, MSMQService"/>
   </service>
  </services>
 </system.serviceModel>
</configuration>

Setting netProfileMsmqBinding binding to this Indigo service will cause the infrastructure to listen on the specified queue (localhost/private$/CalcQueue). You must set authentication mode and protection level to none, if you're running in MSMQ workgroup mode, since by default it uses an internal certificate (from AD) - and therefore fails on other default security settings.

We can use transaction semantics on the client which will cause to submit all-or-no messages into the service queue:

ChannelFactory<IChannel> cf = new ChannelFactory<IChannel>("EndpointConfig");
ICanCalculate channel = cf.CreateChannel();
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.RequiresNew))
{
  int intA = 10;
  int intB = 7;
  channel.CalcOp(Operation.Add, intA, intB);
  channel.CalcOp(Operation.Subtract, intA, intB);
  channel.CalcOp(Operation.Multiply, intA, intB);
  channel.CalcOp(Operation.Divide, intA, intB);
  scope.Complete();
}

Client configuration should look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
 <system.serviceModel>
  <bindings>
   <netProfileMsmqBinding>
    <binding configurationName="MSMQBinding"
       msmqAuthenticationMode = "None"
       msmqProtectionLevel = "None"/>
   </netProfileMsmqBinding>
  </bindings>

  <client>
   <endpoint address="net.msmq://./private$/CalcQueue"
                      bindingSectionName="netProfileMsmqBinding"
                      bindingConfiguration="MSMQBinding"
       contractType="Indigo.Demos.ICanCalculate"
       configurationName="EndpointConfig"/>
        </client>
 </system.serviceModel>
</configuration>

Client and service are now totally independent. You can send arbitrary number of requests to the service side and they will land in the MSMQ queue. Your service does not need to be running at the same time your client is. When it gets back up, all existing messages will get processed automatically.

A bunch of you wrote emails to get my new book. And that's great. Love it.
If you missed it, you can do it again.

I also got some strange feedback:

• "Why do you distribute it for free?"
• "I'd love it, by why do you distribute it for free?"
• "I would buy it, if you are selling it."
• "I'm gonna make sure I buy it."
• "I'm gonna make sure we buy it."
• "I can't believe that you believe in open source."

<rant mode="on">
   I'm not doing it for the money. I'm doing it to distribute thought, knowledge and/or religion. This book is free, as long you are not making direct profit from it without making me a part of it. You can, though, contribute to local general religion awareness anytime.
</rant>

There's another line of thought happening:

• "I have a problem with chapter X.Y.Z. I can't believe you believe this is the right way to go. In any case, I would chose B over A anytime."
• "Second paragraph in chapter X is just too general. I can't relate to that."
• "Having spent the last two months on this technology, this just can't be the best way to go."
• "There's a specific problem with X in chapter Y if you want to do it in our environment."

Over these, I have no control whatsoever. I strongly believe that scenarios are different in everyones lives.

I have to stress again that English reading/speaking audience can NOT benefit from it, since it's written in Slovene.

Based on my previous post about Stylus Studio's XQuery support petition, Jonathan Robie writes:

Does Matevz really believe that the lack of a Microsoft editor on the XQuery spec is the reason it's taken so long?

No (that's why there's a 'maybe' and 'helps' in there). But it doesn't help either. From my point of view there are three real limiting factors for limping with XQuery for more than 6 years (1998 workshop, 1999 working group gathered):

1. Competitive corporate agendas
2. Becoming tightly coupled with other XML specs
3. Ambitious spec in the first place

In that order. Microsoft's reasons right now are completely transparent. They would be more than thankful if the spec reached Recommendation status. Including partial support in SQL Server 2005 is a bit of a gamble with development dollars. But holding it back, on the contrary, can backfire too.

Going back to my statement:

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.

From Jonathan's response I believe he doesn't agree with the editor part and not him pushing on Microsoft's behalf.

From my perception, major mainstream platform support for XQuery would do well both for the vendors and the XQuery in general. It's been cooking so long that it needs solid support, before becoming overcooked, like XML Schema. And yes, I agree that there are some wonderful implementations out in the wild already. Developer penetration is what this technology still has to achieve.

I'm sure, Jonathan, that Paul Cotton & Co, would be more than willing to wrap up, if things aligned. Looking forward to your viewpoint on why it's taking so long. The last one found is already a bit stale.

Goran wrote a thumbs up review of my second book. I'm glad you find it interesting. Thank you.

Too bad your blog comments are disabled.

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

This weblog is now only available on the following RSS URL:

http://www.request-response.com/blog/SyndicationService.asmx/GetRss

It's been a year since the address was changed, and now the time has come to retire the old RSS feed redirect.

Update: Upgrade to dasBlog 1.7.5016.2 was really smooth (read simple), due to excellent docs from Omar and this wiki.

The following service will allow you to check how Indigo instancing behaviour works:

using System;
using System.ServiceModel;

[ServiceContract]
interface ICanRandom
{
 [OperationContract]
 int Randomize(int intLow, int intHigh);

 [OperationContract]
 int GetLastNumber();
}

[ServiceBehavior(InstanceMode = InstanceMode.Singleton, ConcurrencyMode = ConcurrencyMode.Multiple)]
public class RandomizerService : ICanRandom
{
 private int intLastNumber;
 private Random r = new Random(DateTime.Now.Millisecond);

 public int Randomize(int intLow, int intHigh)
 {
  System.Threading.Thread.Sleep(5000);
  int intRandomNumber = r.Next(intLow, intHigh);
  intLastNumber = intRandomNumber;
  return intRandomNumber;
 }

 public int GetLastNumber()
 {
  return intLastNumber;
 }
}

This service will return a random number for multiple clients. Try simulating it with the following client code:

using System;
using System.Threading;

class Program
{
 static void Main(string[] args)
 {
  Thread t1 = new Thread(new ParameterizedThreadStart(Program.CallService));
  Thread t2 = new Thread(new ParameterizedThreadStart(Program.CallService));
  Console.WriteLine("Threads running.");
  t1.Start(1);
  t2.Start(2);
 }

 static void CallService(object intThread)
 {
  CanRandomProxy objWS = new CanRandomProxy("ICanRandom");
  Console.WriteLine("Thread {0} - Method call.", intThread);
  Console.WriteLine("Thread {0} - Random number: {1}", intThread, objWS.Randomize(10, 110));
  Console.WriteLine("Thread {0} - Last random number: {1}", intThread, objWS.GetLastNumber());
  Console.WriteLine("Thread {0} - Done.", intThread);
 }
}

Singleton services process all requests using a single service instance. Try changing the ConcurrencyMode property of ServiceBehaviour attribute to obtain different instancing semantics. Having InstanceMode set to PerCall (current default) will disable ConcurrencyMode.Multiple behaviour, which is expected.