Also wir haben Personen, die eine Kontonummer haben und einen gewissen Betrag an Geld auf dem Konto. Für eine Überweisung (Transaktion) ist es also notwendig zwei Updates auf die Tabelle auszuführen. Die Erste um den Betrag bei einem Konto abzuziehen und die Zweite um denselben Betrag bei dem anderen Konto gutzuschreiben. Das Ganze muss eine Transaktion sein, denn wenn nach dem “Abbuchen” was schiefgeht und der Update mit der “Gutschrift” nicht mehr ausgeführt wird ist die Kohle weg. Oder besser gesagt die Bank hat es, aber das ist ja fast dasselbe .

Genutzt wird in allen Fällen im Prinzip eine Stored Procedure, die beide Updates ausführt. Für die Fall Nr.4 wird eine Stored Procedure verwendet die in T-SQL den Transaktionskontext direkt in der DB angelegt.

Noch ein Hinweis. Es geht hier nicht um die Performance des SQL Servers, sondern es geht um den Overhead den Datenbankzugriffstechnologien und die verschiedenen Aufrufarten beim Benutzen von Transaktionen erzeugen!

Als nächstes eine kurze Beschreibung der verwendeten technischen Komponenten um die Transaktion über die beiden Datenbankupdates auszuführen.

1. C++ OLE DB ATL COM+ Komponente
   In der Zeit vor .NET, ja die gab es wirklich, war C++ in Kombination mit OLE DB Templates in ATL (Active Template Library) so ziemlich die “schnellste” Datenbankzugriffstechnologie. Für den Transaktionskontext wird COM+ als Container benutzt. Da es sich auch um eine Serverprozess-Komponente handelt, wird der Transaktionskontext über den DTC (Distributed Transaction Coordinator) bereitgestellt. Im folgenden Bild ist die Konfiguration im COM+ Explorer abgebildet. Der Client ist ein .NET Client der also über COM-InterOp die in einer COM+ Applikation “gehostedete” COM-Komponente aufruft.
        
    
2. .NET Serviced Component also COM+ Komponente in C# .NET geschrieben mit COM+ Transaktionskontext
   Im Namespace System.EnterpriseServices wurden in .NET die Services von COM+ für die .NET Welt zugänglich gemacht. Diese Komponente ist also im Prinzip dasselbe wie in 1. nur jetzt mit .NET als Serviced Component implementiert. Also in C# und .NET entwickelt, aber in einem COM+ Container (Application) gehosted. Der Client ist derselbe .NET Client wie bei 1. der also in diesem Fall über COM-InterOp die in einer COM+ Application “gehostedete” .NET-Komponente aufruft.

1. .NET Serviced Component also COM+ Komponente in C# .NET geschrieben mit ADO.NET Transaktionskontext       
   Dasselbe Prinzip wie bei 2. bis auf den Unterschied, dass der Transaktionskontext nicht über COM+ bzw. den DTC bereitgestellt wird, sondern über die API welche über ADO.NET verfügbar ist.

1. .NET Serviced Component also COM+ Komponente in C# .NET geschrieben mit Transaktionskontext in Stored Procedure
   Im Prinzip auch wieder wie 2. und 3. nur das der Transaktionskontext direkt in der DB innerhalb der Stored Procedure erstellt wird.

1. ASMX Web Service der die .NET Komponente aus 4. benutzt.
   Vor .NET 2.0, also als es WCF (Windows Communication Foundation) usw. noch nicht gab war SMAX aus dem ASP.NET Namespace die gängigste Methode Web Services zu implementieren, die somit auch im IIS gehosted werden. Der Web Service benutzt die Komponente aus 4. die in COM+ liegt und eine Stored Procedure für die Transaction verwendet.

1. WCF Komponente “hosted” im IIS (auto-enlist) aufgerufen über HTTP Web Service
   Hier kommt zum ersten Mal WCF zu Einsatz, also auch kein COM+ mehr irgendwie beteiligt. Der Namespace in .NET WCF für Transaktionen heißt : System.ServiceModel gesteuert wir das Verhalten hier über Attribute gesteuert z.B. wird das Isolation Level so eingestellt:
   [ServiceBehavior(TransactionIsolationLevel = System.Transactions.IsolationLevel.Serializable ]
   Der Aufruf geht über HTTP und die Komponente wird im IIS bereitgestellt.
2. WCF Komponente “hosted” in eigenem Prozess aufgerufen über TCP Web Service
   Jetzt wird nicht der IIS benutzt sondern eine eigene klein App, die den Web Service über TCP bereitstellt. Damit wird der Web Service natürlich über TCP aufgerufen, wobei nicht der XML Serializer benutzt wird sondern ein Binary Serializer.

1. WCF Komponente “hosted” in IIS über WAS Hosting aufgerufen über TCP Web Service
   Dieselbe Komponente wie bei 7. jetzt aber mit WAS Hosting  (Windows Activation Services) im IIS, Dies erlaubt es die Komponente im IIS zu hosten und per TCP aufzurufen, was wie bei 7. den XML Serializer vermeidet.

1. WCF Komponente mit Entity Framework als OO Mapper ohne Stored Procedure WAS Hosting TCP Web Service
   In diesem Fall wird das Entity Framework so eingesetzt, wie man es typischerweise ohne besondere weitere Programmierung tun würde. Das heisst es wird dem Framework überlassen die entsprechenden SQL Statements zusammenzubauen und auszuführen. Dies bedeutet natürlich einen Nachteil gegenüber der Verwendung  von einer Stored Procedure, die vorkompiliert im SQL Server bereitgestellt ist.

1. WCF Komponente mit Entity Framework als OO Mapper mit Stored Procedure WAS Hosting TCP Web Service         
   Im zweiten Beispiel mit dem Entity Framework wird jetzt ebenfalls die Stored Procedure verwendet, um zu sehen welchen Overhead das Entity Framework als OO Mapper dann noch erzeugt. 

Die Ergebnisse:

Erläuterungen zu den Ergebnissen:

Als erstes möchte ich anmerken, dass in den ersten Versionen von .NET also 1.0.und 2.0 die C++ ATL Variante schneller war als .NET in COM+. Das hat sich deutlich geändert. Man sieht also, dass die .NET DB Provider im Sinne von Performance deutlich besser sind als die “alte” OLE DB Welt. Weiterhin ist wie zu erwarten Nummer 3 schneller als Nummer 2, da der Transaktionskontext nicht global über den DTC bereitgestellt werden muss sondern nur vom Client zur DB über ADO.NET aufgebaut werden muss. Die Nummer 4 ist dann logischerweise noch etwas flotter unterwegs, da der Transaktionskontext direkt im SQL Server für eine Stored Procedure erstellt wird.

Jetzt kommen wir zu den Web Service Technologien, wobei natürlich sofort ins Auge sticht wie schlecht die ASMX Web Service Implementierung im Vergleich zu WCF abschneidet. Erwartungsgemäß ist auch so, dass die Verwendung von TCP als Protokoll und den Binary Serializer eine deutliche Verbessrung gegenüber der Verwendung von HTTP und dem XML Serializer bringt. Man sieht auch dass man den IIS als Host nutzt und mit TCP und WAS Hosting arbeitet, die Vorteile vom IIS nutzen kann ohne hier Nachteile in der Performance zu bekommen, sogar im Gegenteil.

Die Verwendung des Entity Framework macht den Zugriff auf die Datenbank zwar komfortabel, aber man bezahlt einen Preis dafür. Aber auch hier kann man für immer wieder kehrende Aufgaben Stored Procedures verwenden, um die Performance deutlich zu verbessern.

Viele Grüße

Euer Martin

Jetzt muss ich wohl definieren was man denn unter einem Applikationsserver oder auch Anwendungsserver versteht. Dazu kurz Wikipedia konsultiert und dort findet man folgende Definition: “Ein Anwendungsserver (engl. application server) ist im Allgemeinen ein Server in einem Computernetzwerk, auf dem Anwendungsprogramme ausgeführt werden. Im engeren Sinne bezeichnet der Begriff eine Software, die spezielle Dienste zur Verfügung stellt, wie beispielsweise Transaktionen, Authentifizierung oder den Zugriff auf Verzeichnisdienste und Datenbanken über definierte Schnittstellen.”

Damit ist auch schon erklärt warum ich die Anwendungsserver in einer eigenen Folge meiner Blogreihe erklären möchte. Denn üblicherweise bietet ein Applikationsserver auch eine Schnittstelle um Transaktionen für die Anwendung auf einer höheren Abstraktionsebene zur Verfügung zu stellen.

Im Falle von Microsoft war das erste Release eines “Application Servers” das Windows NT 4.0 Option Pack, welches als Ergänzung zum Windows NT Server 4.0 kostenlos heruntergeladen werden konnte. Es war dann aber so , dass der Markt dies nicht so wahrgenommen hat,  weil dies eben nicht als “Application Server” vermarktet und beworben wurde. Wenn man damals von Application Servern redete, haben die meisten Leute an IBM WebSphere, BEA bzw. Oracle Weblogic, JBOSS usw. gedacht. Also war eigentlich fast automatisch J2EE  oder heute nur JEE bezeichnet (Java Enterprise Edition) im Spiel.

Aber zurück zur Microsoft bzw. Windows Plattform. Teil des Windows NT 4.0 Option Packs war auch der “Microsoft Transaction Server” (MTS), der das erste Mal Transaktionsdienste auf der Windows Plattform zur Verfügung stellte. Mit Windows 2000 war dies dann alles Bestandteil von COM+ in Kombination mit dem “Internet Information Server” (IIS) war dann ein Application Server komplett in Windows mitgeliefert.

Mit dem Applikationsserver änderte sich auch die gängige Architektur einer Business Anwendung. Bis dahin war Client-Server oder auch 2-Tier Architektur das vorherrschende Architekturmodell. Mit dem Einzug der Applikationsserver änderte sich dies zum 3-Tier Modell, wobei der “Middle-Tier” die Geschäftslogik implementiert in Komponenten für den Applikationsserver, darstellt. Ein Bild aus dieser Zeit, welches dies vereinfacht darstellt:

Diese Unterteilung hat sich im Prinzip bis heute nicht geändert. Allerdings haben sich natürlich die Technologien und die Kommunikationsmechanismen zwischen den einzelnen Schichten verändert. Früher war hier CORBA, Java RMI und COM+ sowie später .NET Remoting im Spiel. Aber da es sich um proprietäre Protokolle handelt, war es sehr schwierig hier plattformübergreifende Lösungen zu bauen. Erst mit SOAP und den damit verbundenen Web Services hat sich dies so geändert, dass man relativ einfach z.B. einen .NET Client für eine JEE Anwendung implementieren kann.

Hier noch ein Schaubild aus dem noch aktuellen .NET Application Architecture Guide (2nd Edition):

Wobei hier der “Middle Tier” nochmal in Service Layer, Business Layer und Data Layer unterteilt. wird. Aber auch in .NET wird eigentlich nie von einem Application Server gesprochen, obwohl alle Services von COM+ auch in .NET verfügbar sind und mit Windows Workflow Foundation (WF) und Windows Communication Foundation (WCF) noch weitere Services dazugekommen sind. Nichtsdestotrotz hat .NET in Kombination mit dem Windows Server also auch dem Internet Information Server alle Services eines Application Servers. Seit einigen Windows Server Versionen, gibt es im Server Setup auch die Möglichkeit die Server Rolle festzulegen und hier taucht dann auch offiziell der Begriff Application Server auf. Hier ein Screenshot von Windows Server 2008 R2:

Bevor ich dann im nächsten Blogpost meine bescheidenen Ergebnisse beim Testen der Transaktionsmethoden auf der Windows Plattform präsentieren möchte, will ich doch auch auf die offiziellen Tests des Transaktionsdurchsatzes einer Datenbank in Kombination mit einem Transaktionssystem hinweisen. Das Transaction Processing Council gibt solche Tests vor, die dann Datenbankhersteller in Zusammenarbeit mit Hardwareherstellern durchführen und die Ergebnisse dann dort zur Veröffentlichung einreichen können. Wenn es um Datenbaken geht sind eigentlich nur 2 Tests erwähnenswert.

1. TPC-C ist der ältere Test wo es auch viele Einreichungen gibt. Interessant finde ich hier, dass man keinen einzigen Java Application Server in der Spalte TP Monitor findet. (Ausnahme: Websphere Enterprise Edition 3, aber wenn man im Test nachschaut wurde dann doch Encina verwendet. Also der TP Monitor auf Unix den IBM gekauft hat und daraus dann CICS entwickelt hat). Dagegen findet man sehr oft COM+ !! Sogar bei Tests von IBM und Oracle. Das treibt mich zu der Schlussfolgerung, dass wenn es um Performance geht, COM+ nicht so schlecht sein kann .

2. TPC-E ist ein neuerer Test, wo Microsoft SQL Server auch an der Spitze steht, was allerdings keine große Kunst ist, da es bis heute keine Einreichung eines anderen Datenbankherstellers zu diesem Test gibt. Microsoft hat sich entschlossen diesen Test zu verwenden, da er realistischer heutige Szenarien modelliert, als dies mit TPC-C der Fall ist. Wenn die Unterschiede genau interessieren kann das hier nachlesen.

Viele Grüße

Euer Martin

Als Microsoft 1989 die erste Version des SQL Servers veröffentlichte gab es nur eine Programmierschnittstelle die auch als “Call-Level” API bezeichnete DB-Library. Diese beinhaltete ca. 150 Funktionen für MS-DOS und OS/2 Konsole sowie für OS/2 und Windows GUI Applikationen. Außerdem gab es noch Embedded SQL for C oder die Kurzform ESQL for C. Dabei handelt es sich um einen Precompiler der es ermöglichte SQL Statements direkt im Source Code zu verwenden. Für andere Datenbanksysteme von anderen Herstellern gab es natürlich auch ähnliche APIs, aber eben jede API speziell für eine Datenbank.

1992 kam mit Open Database Connectivity kurz ODBC die erste Schnittstelle auf den Markt, wo man versucht hat die darunter liegende Datenbank zu abstrahieren. Es sollte damit möglich sein Programme zu schreiben die mit unterschiedlichen Datenbanksystemen arbeiten konnten. Dabei gab es noch die Unterscheidung ob der ODBC Zugriff über die proprietäre Datenbank API erfolgt oder über einen nativen ODBC Treiber. Außerdem gab es noch verschiedene Level ODBC Treibern, wobei das Level den Umfang der unterstützten Funktionen angibt. Die Level waren mit Core, Level 1 und Level 2 bezeichnet. ODBC wird auch heute noch in vielen Applikationen ausgiebig genutzt.

Als dann COM mit Visual Basic immer populärer wurde gab es eine Objektschicht über ODBC um auf Datenbanken zugreifen zu können. Da war zunächst Data Access Objects (DAO) und dann etwas später Remote Data Objects (RDO).

Die nächste Entwicklung war mit OLE DB eine Objektorientierte COM basierte Basistechnologie, die ODBC vollständig ersetzt. Auch gab es die Möglichkeit die OLE DB auf Basis der proprietären DB API zu implementieren oder einen nativen OLE DB Provider zu entwickeln. OLE DB war aber nur für Programmiersprachen ausgelegt, welche über Pointer verfügten also Wesentlichen C und C++, damit waren aber VB uns alle Scriptsprachen in Internetanwendungen ausgenommen. Dazu wurden dann die ActiveX Data Objects (ADO) entwickelt. Für C++ gab es in der Active Template Library (ATL) OLE DB Templates, die es dem C++ Programmierer etwas einfacher machten mit OLE DB auf Datenbanken zuzugreifen. Diese Methode des Datenbankzugriffs ist die älteste die in meine Sample verwendet wird, weil dies auch die schnellste Zugriffstechnologie war bevor .NET auf den Markt kam. Etwas später wurde noch ein OLE DB Provider für ODBC fertiggestellt, womit man dann auch Zugriff auf alle ODBC Datenquellen mit ADO oder OLE DB bekommen konnte. Im folgenden Bild ist auch noch ADO Multi-Dimensional (ADOMD) eingezeichnet, dabei handelt es sich um eine ADO Erweiterung für den Analysis Server den “Data Warehouse” Server im SQL Server. Heute sind diese Technologien und Komponenten zusammengefasst in den Microsoft Data Access Components (MDAC) oder den Windows Data Access Components (WDAC), und sind Teil des Windows SDK.

Als dann .NET im Jahre 2000 das Licht der Welt erblickte, war es wieder Zeit für eine neue .NET basierte Zugrifftechnologie. ADO.NET benutzt als Datenbankzugriffsschicht einen .NET Framework Provider. Microsoft lieferte einen nativen Provider für den SQL Server, sowie weitere Provider für OLE DB und ODBC. ADO.NET war so designed, dass man mit dieser Technologie konsequent auf Snapshots gesetzt hat, um so datenbankschonende Applikationen zu forcieren. Die Phiolosophie ist die. Datenbankverbindung so spät wie möglich öffnen, das SQL Statement abzusetzen und dann die Verbindung so früh wie möglich wieder zu schließen. Geöffnete Verbindungen verbleiben in einem “Connection Pool” und können so wiederverwendet werden ohne eine neue “teure” Verbindung zu öffnen.

ADO.NET hat dann natürlich auch Weiterentwicklungen erfahren und es gab auch einige Erweiterungen. Mit der Spracherweiterung Language Integrated Query (LINQ) gab es auch eine Implementierung für den SQL Server LINQ2SQL.  Dies war wenn man so will der erste Ansatz für einen objektrelationalen Mapper für .NET. Genau dies stellt dann das Entity Framework dar, der intern wieder einen Entity Data Provider, der auf dem ADO.NET Data Provider aufsetzt, benutzt um alle Features nutzen zu können.

Mit der immer mehr voranschreitenden Nutzen der “Cloud” wurden auch andere Technologien immer wichtiger. Hier ist in erster Linie Representational State Transfer (REST) zu nennen. Im .NET Framework wurde  die Windows Communication Foundation (WCF). Um die WCF Data Services (vorher bekannt als ADO.NET Data Services und Code Name “Astoria”) erweitert, um es einfach zu machen RESTful Services in .NET zu entwickeln.

Für die Zukunft wird wohl das REST basierte Open Data Protocol oder kurz OData immer wichtiger. Siehe auch http://www.odata.org .

Microsoft investiert in die Zukunft im Bereich Entity Framework und WCF Data Services. Für weitere Informationen hierzu gibt es diese beiden Links :

• Entity Framework Futures
• Data Servcies Futures

Wer das Ganze noch ausführlicher behandelt haben möchte kann dies in mit folgenden MSDN Artikel haben .
Dort wird auch noch ausführlich auf die Analysis Services eingegangen, die ich hier nicht mit abgehandelt habe.

Schöne Grüße

- Martin

“Eine Transaktion bezeichnet eine Menge von Datenbankänderungen, die zusammen ausgeführt werden (müssen). So ist beispielsweise die Buchung (als Transaktion) eines Geldbetrags durch zwei atomare Datenbankoperationen „Abbuchen des Geldbetrages von Konto A“ und „Buchung des Geldbetrages auf Konto B“ gekennzeichnet. Kann die vollständige Abarbeitung der elementaren Datenbankoperationen der Transaktion nicht durchgeführt werden (z. B. aufgrund eines Fehlers), müssen alle durchgeführten Änderungen an dem Datenbestand auf den Ausgangszustand zurückgesetzt werden.

Der Vorgang, der alle Änderungen einer Transaktion zurücksetzt, wird als Rollback bezeichnet. Der Begriff Commit bezeichnet das Ausführen einer Transaktion. Transaktionen sind eine Möglichkeit, die Konsistenz des Datenbestandes zu sichern. Im Beispiel der doppelten Kontenführung wird durch das Verhindern von ungültigen Teilbuchungen eine ausgeglichene Kontobilanz gewährleistet.”

Man könnte also auch sagen, dass man mehrere Operationen zu einer atomaren Ausführung zusammenfassen kann, damit entweder alle Änderungen bzw. Operationen durchgeführt werden oder gar keine. Das bedeutet, dass bei einem Rollback zwischenzeitlich durchgeführte Änderungen wieder rückgängig gemacht werden müssen.

Was oft auch benutzt wird ist der Begriff ACID, wobei hier nicht irgendwelche bewusstseinserweiternde Stoffe gemeint sind, sondern ACID als Abkürzung für:

• Atomicity - eine Transaktion wird entweder "comitted" oder "aborted". Wenn eine Transaktion ein Commit ausführt, bleiben alle ihre Änderungen erhalten; Wenn eine Transaktion abgebrochen wird, werden alle Änderungen rückgängig gemacht.
• Consistency - eine Transaktion ist eine korrekte Transformation des Systemstatus; Sie stellt sicher, dass das System in einem konsistenten Zustand bleibt. Beispielsweise wenn man in einer doppelt verknüpften Liste ein Element hinzufügt, werden alle vier vorwärts- und Rückwärts-Zeiger aktualisiert.
• Isolation - gleichzeitige Transaktionen sind isoliert von den Updates der anderen unvollständigen Transaktionen; Diese Updates stellen keinen konsistenten Zustand dar. Diese Eigenschaft wird oft Serialisierbarkeit genannt. Zum Beispiel wenn eine zweite Transaktion auf die doppelt verknüpfte Liste aus dem vorigen Consistency Beispiel zugreift, sieht entweder den Zustand vor den Änderungen, oder den Zustand nachdem alle Änderungen durchgeführt sind, also niemals einen Zustand dazwischen.
• Durability - sobald eine Transaktion ein Commit ausgeführt hat, bleibt der Zustand bestehen, auch wenn es Systemausfälle geben sollte.

In manchen Anwendungsfällen wird aber nicht der volle “Schutz” einer Transaktion benötigt. Dafür gibt es im SQL Standard verschiedene Einstellungen um verschiedene Isolation Level zu definieren.

So jetzt muss ich natürlich noch erklären was die Begriffe Dirty Read, Nonrepeadable Read und Phantom Rows bedeuten.

Dirty Read - Wenn eine Transaktion „uncommitted“ Änderungen einer anderen Transaktion lesen kann.

Nonrepeadable Read - Wenn von Transaktion A bereits gelesene Daten von Transaktion B modifiziert werden, bevor Transaktion A abgeschlossen ist.

Phantom Rows - Wenn Transaktion A das Resultat einer Abfrage auswertet und dann Transaktion B eine Zeile einfügt, welche die Kriterien erfüllt, um in das Resultat der Abfrage von Transaktion A zu gehören, bevor Transaktion A abgeschlossen ist.

Der Ausdruck kommt daher, wenn Transaktion A die Abfrage ein zweites mal ausführen würde, wäre eine neue Zeile wie ein Phantom im Resultat aufgetaucht.

So das war es fürs Erste. In der nächsten Folge möchte ich mich dann mit APIs auseinandersetzen, die es dem Entwickler ermöglichen Transaktionen in eigenen Anwendungen zu verwenden.

Bis demnächst Euer Martin

Im Screencast wird gezeigt, wie Visual Studio 2012 mit Team Foundation Server benutzt werden kann um direkt Windows Azure Applikationen mit dem Build Server in TFS zu erstellen und durch eine spezielle, bereits mitgelieferte „Build-Rule“ auf Windows Azure deployed werden kann. Außerdem wird gezeigt, wie die lokale Entwicklung von Cloud Services in der Windows Azure Emulationsumgebung inklusive Debugging durchgeführt wird.

Visual Studio 2012  - Team Foundation Server Deployment zu Azure | Microsoft from Visual Studio [Microsoft] on Vimeo.

1. Man braucht natürlich einen Azure Account über den man seine Cloud Services anlegen, verwalten und deployen kann. Es reicht auch ein Windows Azure Test Account den man sich auf der Windows Azure Webseite holen kann.

2. Eine Visual Studio Version mindestens Visual Studio 2010 oder Visual Studio 2012, es reicht auch die Express Version oder Visual Studio Web Developer 2010.

3. Das entsprechende Azure SDK das man im Windows Azure Develoer Center herunterladen kann. Wenn Visual Studio 2010 verwendet wird sollte man noch APS.NET MVC 4 nachinstallieren.

Im Weiteren verwende ich Visual Studio 2012 sowie die Applikation aus dem Tutorial: „.NET Multi-Tier Application Using Service Bus Queues“. Dort wird auch nochmal beschrieben wie man die Tools und das SDK installiert.

Wenn man also diese App lokal mit ServiceBus fertig hat dann sind folgende Schritte notwendig um das Debuggen in der Cloud zu ermöglichen.

1. Im neuen Management Portal einen neuen Cloud Service anlegen:  

2. Namen des Dienstes angeben und das Datacenter auswählen wo der Cloud Dienst betrieben werden soll.  

3. Um den Netzwerkzugriff für das Remote Debuggen zu ermöglichen, ist es notwendig Windows Azure Connect zu verwenden, wenn man auf den doch größeren Aufwand für eine Virtuelle VPN Umgebung vermeiden möchte. Windows Azure Connect wird leider im Moment vom neuen Management Portal (noch) nicht unterstützt. Also muss man auf die Vorgängerversion des Portals umschalten:  

4. Im alten Management Portal dann auf Verbinden klicken um Windows Azure Connect anzuschalten:  

5. Auf der dann angezeigten Seite findet man die Ressourcen rund um Windows Azure Connect. Der nächste Schritt zum Verwenden von Windows Azure Connect ist. Den Windows Azure Account unter Verbinden im Menü links auszuwählen und dann das Aktivierungstoken herunterladen.

6. In der folgenden Box dann auf „Token in Zwischenablage kopieren“ klicken und dann mit Ok beenden.

7. Das Aktivierungstoken muss man dann noch in die Konfiguration der zu debuggenden Rolle übernehmen. Dazu in Visual Studio bei den Rollen mit rechtem Mausklick auf die Rolle in den Properties bzw. Eigenschaften unter Virtual Network das Aktivierungstoken übernehmen. Dies erzeugt die nötigen Einträge in der Datei ServiceDefinition.csdef. Hier kann man auch weitere Einstellungen für die Rollen vornehmen, aber für mein Beispiel reichen die Default Einstellungen.

8. Jetzt kann man das Package direkt von Visual Studio aus veröffentlichen. Dazu bei den Rollen auf Publish bzw. Veröffentlichen klicken.

9. Wenn man dies das erste Mal macht muss man zunächst über den Link „Sign In“ mit seinem Microsoft Account eine Datei mit „Publish Settings“ herunterladen und diese dann über den Import Button in Visual Studio übernehmen. Dann einen Storage Account anlegen und nach Möglichkeit dieselbe Region für alle Komponenten verwenden. Also auch Northern Europe. Dann unter Cloud Service den im Portal angelegten Dienst auswählen. Build Configuration ist klar, muss natürlich Debug sein. Dann unbedingt Remote Desktop für die Rollen einschalten, da wir die Remote Debugging Komponenten von Visual Studio auf die VMs bekommen müssen. Also mit Settings einen Account zum Remote Access auf die VMs einrichten. Wenn man dann auf Next klickt bekommt man nochmals eine Übersicht aller Settings und kann mit Publish das Apllikationspaket zu Azure hochladen. Bis die Applikation dann bereit ist kann es schon einige Minuten dauern.

10. Um Connect mit der VM-Rolle zu verwenden, müssen Sie die Connect Endpoint-Software auf dem Computer, der zum Erstellen des VM-Image verwendet wird, über den folgenden Link installieren: http://waconnect.blob.core.windows.net/client/latest/x64/wacendpointpackagefull.exe . Oder man klickt im alten Portal einfach auf „Lokalen Endpunkt installieren“ klicken. Damit wird dann gleich das richtige Token mitübergeben.

11. Im folgenden Dialog dann den Link kopieren und im Browser eingeben und die Software installieren. Nach der Installation erscheint das Connect Symbol in der Taskleiste und nach einigen Sekunden zeigt das Symbol auch an dass man mit Windows Azure Connect verbunden ist.

12. Jetzt muss man noch eine Servergruppe anlegen um die Verbindung zu ermöglichen.

13. Im nachfolgenden Dialog die lokale Maschine auswählen und die entsprechende Rolle asuwählen zu der man die Verbindung ermöglichen möchte. Die Check Box nicht vergessen damit man die Verbindung auch zulässt.

14. Wenn dies erfolgreich abgeschlossen wurde muss man noch im Windows Azure Connect Client auf „Richtlinie aktuakisieren“ klicken, damit die Änderungen von Azure übernommen werden. Nach einigen Minuten kann man dann den Netzwerkzugriff auf die VM z.B. mittels ping testen. Wenn dies funktioniert hat man Windows Azure Connect erfolgreich eingerichtet.

15. Zum weiteren Vorgehen ist es einfacher wieder in das neue Management von Windows Azure zu wechseln. Dazu in der Statuszeile auf den Link „Zum neuen Portal“ klicken. Dann den entsprechenden Clouddienst anklicken. Auf „Wird bereitgestellt“ klicken, da wir in die Staging Umgebung deployed haben. Dann in der oberen Zeile auf Instanzen klicken. Die Worker Rolle anklicken und dann in der Statuszeile auf verbinden klicken.

16. Die RDP auf dem lokalen PC z.B. auf dem Desktop abspeichern. Danach mit rechter Maustaste anklicken und Context Menü dann „Edit“ bzw. „Bearbeiten“ auswählen. Dann denn Reiter Local Resources anklicken und auf den More Button klicken.

17. Dann hier den Zugriff auf die lokale Platte ermöglichen, damit man die Remote Debugging Komponenten auf die VM der Worker Role kopieren kann.

18. Dann mit „Connect“ die Remote Desktop Verbindung starten und mit den im Schritt 9 angelegten Account anmelden . In der Virtuellen Maschine dann den Explorer starten und über die eingebundene lokale Platte zu den Remote Debug Komponenten von Visual Studio navigieren. Diese befinden sich bei einer Standardinstallation im Verzeichnis: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger Dort gibt es dann zumindest zwei Unterverzeichnisse X86 und x64. Am einfachsten ist es das Verzeichnis x64 auf die VM zu kopieren. Dann auf der virtuellen Maschine das Verzeichnis öffnen und die Datei msvsmon.exe lokalisieren und diese dann starten.

19. Beim ersten Start wird folgende Dialogbox angezeigt. Damit wird die Firewall automatisch für das Remote Debuggen konfiguriert.

20. Dass die Virtuelle Maschine zum Debuggen bereit ist sieht man an dem anschließend angezeigten Fenster, wo dann steht, dass auf eingehende Verbindungen gewartet wird.

21. Jetzt zurück zu Visual Studio wo man jetzt im Debug Menü unter „Attach to Process“ den Dialog startet, um den Debugger mit dem Remote Debugger zu verbinden. Dazu den Rechnernamen der VM mit :portnummer eingeben also z.B.: RD0015D520D9D:4016 eingebe, dann muss man sich wiederum mit seinem Account anmelden und dann in der Prozessliste den Prozess WaWorkerHost.exe auswählen und auf Attach klicken.

22. In Visual Studio z.B. die Source Datei WorkerRole.cs im Projekt OrderProcessingRole öffnen und einen Breakpoint setzen.

23. Dann im Management Portal auf Dashboard klicken und die SiteURL im rechten Bereich anklicken damit die Site im Browser gestartet wird.

24. Dann in der App eine Eingabe machen und auf Create klicken, dann sollte nach einigen Sekunden der Debugger am vorher gesetzten Breakpoint anhalten.

25. Im Visual Studio Debugger kann man, wie sonst auch, auf die Variablen und alle Debugging Features zugreifen.

BINGO!

Das Sharepoint Easy Setup Script einfach herunterladen und die Instruktionen beachten. Wenn man anpassen möchte welche zusätzlichen Tools installiert werden sollen, dann kann man dies in der Datei ..\SharePoint2010EasySetup\Labs\EasySetup\Source\config.xml anpassen.

Noch ein kleiner Tipp. Falls man die Installation auf einem HyperV Image von Windows 7 64Bit ausführen möchte gehen die Downloads der Installationsdateien schief. ein einfacher Workaround ist das Script auf einer Windows 7 Maschine bis zur Beendigung der Downloads ausführen und dann abbrechen. Dann kann man das Ganze Verzeichnis in ein ISO Image packen und dann an die HyperV Maschine mounten und das Script dort erneut ausführen und Bingo, man hat Sharepoint Foundation auf dem HyperV Image von Windows 7 (64Bit) installiert und konfiguriert.

seit einiger Zeit gibt es nämlich Windows Sharepoint Foundation im Web Platform Installer 2.0 zum Download und zwar so dass gleich alles installiert und konfiguriert wird. Also einfach den Web Platform Installer 2.0 runterladen, dann die Management Console des Internet Information Servers starten.

Hier links eine beliebige neue Website oder auch die Default Web Site auswählen und dann links unten auf “Anwendung über Katalog installieren” klicken.

Dann Optionen anklicken damit man dort die Enterprise Features mitangezeigt bekommt Siehe nächstes Bild:

Nach dem Klick auf Ok wird dann auch Sharepoint bei den Enterprise Downloads angezeigt:

Zum Schluss noch ein beherzter Klick auf “Installieren” und los geht es ….

Viele Grüße

Martin Vollmer

Viele Grüße

Martin

Komplettes Projekt mit WCF Services nach Microsoft Consulting Services
http://www.microsoft.com/germany/msdn/knowhow/VisualStudioTemplateProjekte/templates.mspx 

Als zweites wird im Webcast gezeigt, wie man eine beliebige Datenquelle, die irgendwie mit .NET Code zugreifbar ist, angebunden werden kann. Zu guter Letzt natürlich der Link zum Webcast auf MSDN:

http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032468935

Viele Grüße

Martin Vollmer