Wenn man von BizTalk spricht, denken viele direkt an den BizTalk Server von Microsoft. Das ist aber ein trugschluß. Denn BizTalk und der BizTalk Server sind zwar nicht grundverschiedene Produkte aber auch nicht die gleichen Produkte. Mit BizTalk bezeichnet Microsoft seine proprietären Komponenten und Bibliotheken für verteilte Anwendungen/Services und Enterprise Application Integration (EAI). Der BizTalk Server hingegen ist ein Application Server der das Enterprise Service Bus Pattern (ESB, http://de.wikipedia.org/wiki/Enterprise_Service_Bus) implementiert. Der BizTalk Server bedient sich der BizTalk Services, die aber nun im Zuge des Cloud Computing und der Azure Plattform als .NET-Services bezeichnet werden.

Many people guess BizTalk and BizTalk Server are the same product. But that´s not correct because BizTalk describes all Services and Components by Microsoft to develop distributed systems, services and components. BizTalk Server is an Application Server which implements the Enterprise Service Bus Pattern to integrate systems, services and applications (e.g. Enterprise Application Integration EAI). BizTalk Server uses the BizTalk libraries to operate. Within the announcement of the Azure Platform Microsoft renamed BizTalk Services into .NET Services.

In anderen Profilen, speziell bei XING (www.xing.com), lese ich immer öfter über Kenntnisse in HTML-Programmierung. Diese Leute muss ich an dieser Stelle fragen, was ist denn HTML-Programmierung? Es ist vom Grund weg falsch, die Erstellung einer Webseite mittels HTML als Programmierung zu bezeichnen. HTML steht für Hypertext Markup Language und ist eine reine Beschreibungssprache. Schleifenkonstrukte, Variablen, Nachrichtenaustausch wie bei OO z.B. und andere Konzepte die eine Programmiersprache ausmachen, sind nicht vorhanden. Aus diesem Grund Leute, schreibt bitte nicht HTML-Programmierung in euer Profil oder sonstigen Dokumente.

In meinem derzeitigen Projekt geht es um die Erstellung von verteilten Windows Services. Die Fehlersuche bei Windows Services gestaltet sich jedoch als äußerst schwierig bzw. aufwändig. Da die Anzahl der Quellcodedateien an zwei Händen abgezählt werden können, dachte ich mir ein "selbstgestricktes" Logging würde mich ausreichend bei der Fehlersuche unterstützen. PUSTEKUCHEN!!! Sehr weit gefehlt (und noch ein Stück weiter), ehrlich gesagt ist man damit irgendwann mehr beschäftigt als mit dem eigentlichen aufspüren und beseitigen der Fehler. Darum habe ich nun ein Loggingframework in den Diensten implementiert. Der Aufwand ist so gering, dass dieser in keinem Verhältnis steht. Genauer gesagt, benutze ich nun NLog (www.nlog-project.org), ein sehr einfaches und stabiles Framework. Meine Fehlersuche gestaltet sich nun erheblich einfacher und mit viel weniger Zeitaufwand. Schön geschmeidig den Loglevel an zentraler Stelle einstellen und ab gehts und nicht wie bei dem selbstgestrickten Logging die Zeilen auskommentieren wo man kein Logging mehr möchte!! *aaaah*. Für mich steht fest, ein Loggingframework wird jetzt immer eingeplant, egal wie groß das Projekt ist.

Für mein neues kleines Entwicklungsprojekt, dass ich nach derzeitigen Stand der Dinge alleine durchführen werde, habe ich mir folgendes überlegt. Das Projekt ist ein .NET-Projekt und wird mit dem Framework 3.5 SP1 umgesetzt. Als IDE dient Visual Studio 2008. Auch wenn ich alleine Entwickle, werde ich mir einen Continous Integration Server (CI) aufsetzen. Was ich mir davon verspreche ist eine weniger aufwändige Integration und ein Testen der Softwarebestandteile. Nach jedem Checkin der Sourcen in das lokale SVN, holt der CI diese ab und führt die Unit-Tests aus. So spar ich mir die Klickerei in der IDE und/oder das Erstellen einer Build-Datei. Einige werden sich nun Fragen warum ein lokales SVN, der entwickelt doch alleine. Das stimmt, aber ich möchte keine Quellcodedateien wovon 1500 Zeilen auskommentiert sind, nur weil eine andere Implementierung evtl. lesbarer und besser ist, die alte Implementierung aber nicht weggeworfen werden soll. Hier kann ich dann ganz komfortabel den alten Stand aus dem SVN wiederherstellen, falls die neue Implementierung doch nicht tut was sie soll. Schöner Nebeneffekt sind die schlanken Codedateien, welche viel schöner zu lesen und zu verstehen sind *Finde ich*. Als CI Server benutze ich Hudson (https://hudson.dev.java.net/). Dieser steht als Open Source zur Verfügung und kann nicht nur Java-Projekte bauen, sondern auch .NET-Projekte. Ich habe mich für Hudson entschieden, weil alle Einstellungen über eine Weboberfläche vorgenommen werden können. Diese ist intuitiv gestaltet, so dass man sich schnell zurecht findet. Keine XML-Konfiguration per Hand stricken :-) Enorme Zeitersparnis :-)

Ja das soll es für jetzt erst einmal gewesen sein... Meine weiteren Erfahrungen mit dieser Vorgehensweise werde ich natürlich hier posten!

Bis dahin