XING: https://www.xing.com/profile/Holger_SirtlLinkedIn: http://de.linkedin.com/in/hsirtl
Spätestens mit Veröffentlichung von Windows Azure wird deutlich, mit welcher Entschiedenheit Microsoft den Weg in Richtung Cloud Computing einschlägt. Neben dem Outsourcing von Infrastruktur verfolgen Unternehmen, die auf Cloud Computing setzen, ein zentrales Ziel: Skalierung von Anwendungen durch Nutzung der Infrastruktur eines Service Providers, die ebenfalls massiv skaliert.
Grundsätzlich gibt es zwei Ansätze, um Anwendungen zu skalieren
Windows Azure setzt intern klar auf den zweiten Ansatz, Scale-out, und unterstützt auch für Anwendungen, die auf Windows Azure betrieben werden, diesen Ansatz.
Aufbau skalierbarer Services
Die Windows Azure Services Plattform bietet mit SQL Services und .NET Services Dienste, die nahelegen, selbstgeschriebene Services, die auf Windows Azure betrieben werden sollen, in entsprechende Tiers zu unterteilen. Folgende Unterteilung empfiehlt sich:
Durch eine klare Trennung dieser Tiers wird eine Skalierbarkeit auf einzelnen Schichten ermöglicht, d.h. Skalierung kann pro Tier entschieden, geplant und umgesetzt werden.
Ein paar Definitionen...
Wird nun eine dieser Schichten auf mehrere Server verteilt, stellt sich die Frage, wie die einzelnen Server konsistent gehalten werden. Hierbei lassen sich drei Level für die Konsistenzherstellung (Consistency Level) unterscheiden:
Um die einzelnen Instanzen abzugleichen, müssen Nachrichten ausgetauscht werden. Hierbei stellt sich die Frage, welche Anforderungen an die Nachrichtenzustellung (Message Assurance) gestellt werden. Dabei gibt es vier grundlegende Anforderungsstufen:
Infrastrukturoptionen
Die letztgenannte Option vereint die Vorteile von Load Balancing und Ausfallsicherheit, stellt an die Software und die Infrastruktur allerdings auch die höchsten Anforderungen: die einzelnen Maschinen müssen sich synchronisieren, im Fall des Ausfalls einer Maschine muss ein Umleiten von Anfragen an die ausgefallene Maschine erfolgen.
Architekturtipps
Für die Architektur einer hoch skalierbaren Anwendung können folgende Empfehlungen gegeben werden:
Tip 1: Auswahl eines high-level-Frameworks
"the higher level the framework you use, the more portable your service will get"
So simpel dieser Satz ist, so groß ist doch auch seine Bedeutung. Bei Einsatz eines Frameworks wie der Azure Services, wird die Entscheidung für ein Hostingmodell (vor-Ort, beim Hoster, bei Microsoft) zu einer Entscheidung, die zum Deploymentzeitpunkt getroffen werden kann. Deshalb empfiehlt sich der Einsatz eines high-level-Frameworks (low-level-Frameworks treffen häufig zu viele Annahmen über die Umgebung, in der sie eingesetzt werden).
Tip 2: Separierung von Service- und Hosting-Codes
Infrastruktur-Code sollte in Konfigurationsdaten und dedizierte, pro Umgebung verwaltbare Konfigurationskomponenten ausgelagert werden. Damit sind bei einem Transfer in eine andere (skalierbarere) Umgebung nur die Hosting-Codes anzupassen.
Tip 3: Partitionierung des Codes (horizontal in Tiers, vertikal z.B. in Schemata)
Schichtenbildung in der Software erlaubt, wie oben bereits beschrieben, Skalierungsmaßnahmen auf den einzelnen Schichten durchzuführen. Wird in der Datenschicht hohe Skalierung gewünscht, so kann diese beispielsweise auf SQL Data Services betrieben werden.
Designtipps
Tip 1: Einsatz loser Koppelung
Lose Kopplung und die Einhaltung von Prinzipien serviceorientierter Architektur schafft die Mobilität von Services und z,B. auch die Voraussetzung, Services auf eine skalierbare Umgebung zu verschieben. Wo die Datenschicht beispielsweise zunächst lokal betrieben werden kann, kann diese bei entsprechend loser Kopplung auch auf SQL Data Services verschoben werden. Solange die Schnittstelle konstant bleibt, bekommen die anderen Schichten hiervon nichts mit.
Tip 2: Verwendung von Caches und "stale" Data
Caches können den Ausfall von Schichten abfangen, indem sie Daten solange bereithalten, solange der "Live" Speicher unverfügbar ist.
Tip 3: Implementierung einiger zentraler "recovery paths"
Nachdem der Ausfall einzelner Serverkomponenten möglich ist, muss es möglich sein, nach Ersatz der fehlerhaften Komponente wieder einen konsistenten Systemzustand herzustellen. Hierfür sollten entsprechende Funktionalitäten bereitgestellt werden.
Tip 4: Vermeidung von Shutdown-Code
Insbesondere im Falle von Cloud Computing sollte immer damit gerechnet werden, dass die Hardware, auf der eine Instanz der Software läuft, (ohne Zeitverzögerung) ausfällt.
Tip 5: Unabhängigkeit von der zugrundeliegenden Topologie
Es sollte vermieden werden, sich Informationen zu verlassen, die vom Administrator, d.h. dem Betreiber der Software zur Laufzeit geändert werden könnten. Also: keine hardcodierten Servernamen, IP-Adressen etc. Diese Informationen sollten, wenn sie benötigt werden, in Konfigurationsdateien ausgelagert werden.
Heute, am dritten PDC-Tag stand „Research in the 21st Century“ auf dem Programm der Keynote.. Was vielen vielleicht nicht bekannt ist: Microsoft unterhält eine der größten kommerziellen Forschungs- und Entwicklungsabteilungen weltweit mit Niederlassungen rund um den Globus. MS Research, gegründet 1991 – damals hatte Microsoft „erst“ 1 Milliarde US$ Umsatz und „nur“ 5000 Mitarbeiter, geht dabei über die Grenzen des Microsoft Technologiespektrums hinaus, um neueste Innovationen für Microsoft zu entwickeln bzw. zugänglich zu machen.
Rick Rashid, Senior Vice President Microsoft Research, gab uns heute einen Einblick in verschiedene Fakten zu MS Research und einige interessante Forschungsergebnisse.
MS Research setzt bei der Forschung einige Schwerpunkte:
Die wichtigsten Forschungsergebnisse, von denen Rick sprach, waren:
Zumindest, was die Keynote anbelangt, war heute nocht nicht allzu viel für Softwarearchitekten dabei. Die Forschungsergebnisse, waren aber durchaus sehenswert.
Heute war wieder ein äußerst spannender PDC-Tag. Wo gestern der Hauptfokus auf der Transformation unseres Businesses in Richtung Cloud Computing und der Bekanntgabe des Cloud Betriebssystems Windows Azure lag, stand heute der Client mit dem „Personal Computing“ und der Brückenschlag in Richtung Web im Vordergrund. Auch hier stand also alles unter dem Motto „Software + Services“. Für Endanwender bietet sich eine durchgängige User Experience über all die verschiedenen Endgeräte und –Anwendung wie PC, Browser, SmartPhones.
Zentrale Bekanntmachungen waren heute:
Zu Windows 7 werden derzeit sicherlich genug Blogs (mit verschiedenen Schwerpunkten)geschrieben. Für Architekten ist letztlich die Idee, die letztlich dahinter steckt, interessant: Konbination einer leistungsfähigen Client-Plattform (mit WPF-Grafik, Multitouch, etc.) mit Online-Diensten, die über Azure bereitgestellt werden.
Live Services stellen Funktionalitäten bereit, die in eigenen Anwendungen Funktionen für
bereitstellen. Der Zugriff erfolgt jeweils über standardkonforme Webservice-Schnittstellen. Live Services basieren auf Windows Azure und werden damit in Microsoft Rechenzentren gehostet.
Mit Office Web Applications (OWA) stellt Microsoft abgespeckte Versionen der bekannten Office Client-Anwendungen bereit. Anwender können hierüber über eine ihnen bekannte Oberfläche nahezu genauso mit Office-Dokumenten arbeiten wie über die lokalen Office-Anwendungen. Für Endkunden stehen diese Anwendungen in einer werbebasierten Form über Office Live zur Verfügung. Unternehmenskunden können diese Anwendungen als Abonnement im Rahmen bestehender Volumentlizenzen nutzen. Microsoft stellt OWA Ende des Jahres in einer „technical preview“ zur Verfügung. Interessierte können sich bereits jetzt unter http://workspace.officelive.com anmelden, um die Anwendungen zu nutzen und weitere Informationen zu erhalten.
In weiteren Sessions des heutigen Tages kamen dann noch weitere Themen, die für Architekten interessant sind. Hier ein paar Highlights:
Weitere Informationen, wie gehabt auf der Website der PDC sowie unter http://www.azure.com/.
Stay tuned!
PS: Übrigens: Viele dieser Infos werden meine Kollegen und ich auch noch ausführlich auf den beiden deutschen Web- und Entwicklerkonferenzen Xtopia und Techsummit vorstellen. Dort gibt's also brandheiße Infos!!! - Also unbedingt noch schnell anmelden!
Wow. Heute morgen war es soweit: Ray Ozzie hat auf seiner Keynote der PDC2008 Microsofts Cloud Plattform vorgestellt (er selbst hat es sogar als "our cloud operating system") bezeichnet:
Was zeichnet Windows Azure aus?
Was bedeutet Windows Azure für Microsoft?
Microsoft stellt selbst alle seine Services auf eben dieser Plattform bereit. Mit Services wie Windows Live Hotmail, MSDN, MSN etc. kann Microsoft hier auf einen umfangreichen Erfahrungsschatz im Zusammenhang mit der Bereitstellung hochskalierbarer Webdienste aufbauen. Alle zukünftigen Dienste werden ebenfalls auf Windows Azure aufsetzen.
Was ist Inhalt der Azure Services Platform?
Was bedeutet das für Microsofts klassische Client- und Serveranwendungen?
Microsoft wird nach und nach alle Serveranwendungen auch in einer Service-Version anbieten. Diese Services werden dann auf Windows Azure aufsetzen. Ziel ist die, wie es Ray Ozzie bezeichnet hat, vollständige Symmetrie der On-premises Produkte (Software, die vor Ort beim Kunden betrieben wird) und der entsprechenden Cloud Services. Dies wird durch folgende Abbildung verdeutlicht:
Damit wird es möglich, mit den gleichen Programmiermodellen Software sowohl für einen Vor-Ort-Betrieb als auch für einen Betrieb auf Windows Azure zu erstellen. Vorhandenes Entwickler-Know-How kann also weiterhin genutzt werden.
Dazu sage ich "Wow"!!!
Weitere Informationen
Weitere Infos zu Windows Azure können unter http://www.azure.com/ abgerufen werden.
Vor knapp einem Jahr habe ich ein einem meiner Blog-Einträge ("Die Microsoft Plattform...") die verschiedenen Plattformen, die sich innerhalb der gesamten Microsoft Plattform befinden, zueinander in Beziehung gesetzt und ein Gesamtbild skizziert. Nun, in einem Jahr ist viel passiert, so dass meine damaligen Ausführungen wohl nicht falsch, aber doch leider nicht mehr ganz vollständig sind. Deshalb möchte ich hier eine Aktualisierung vornehmen
Mit der "Software-plus-Services" Strategie schlägt Microsoft ein neues Kapitel in der Evolution seiner Plattform auf. "Software-plus-Services" geht ja davon aus, dass Unternehmen in Zukunft für ihre IT-Anforderungen eine Kombination aus Internetservices und lokal betriebenen Client- und Server-Anwendungen einsetzen. D.h. Unternehmen sollen von Fall zu Fall entscheiden können, welche Teile ihres IT-Portfolios lokal und welche in der "Cloud" betrieben werden. Diese Entscheidung soll sowohl für ganze Anwendungen, für einzelne Services bis hin zu Anwendungskomponenten möglich sein. Dies hat natürlich tiefgreifende Auswirkungen auf die Plattform, für die ja der Anspruch gilt, dass die Entscheidung für ein Deploymentmodell erst nachgelagert getroffen werden kann.
Mit folgender Abbildung möchte ich die Darstellung der verschiedenen Plattformbegriffe aktualisieren:
Abbildung: Die Microsoft Plattform(en) im Zeitalter von Software-plus-Services
Wer meinen ersten Blog-Artikel gelesen hat, wird folgende Änderungen bemerken:
Vier verschiedene Deploymentoptionen in der Infrastrukturschicht
Grundsätzlich stehen Unternehmen für den Betrieb von Softwarekomponenten vier Deploymentoptionen zur Auswahl:
Anstelle des Begriffes "Hardware Plattform" bevorzuge ich jetzt den Begriff "Infrastruktur Plattform". Letzterer ist allgemeiner gehalten und bringt zum Ausdruck, dass die zugrundeliegende Hardware und deren Standort zunehmend irrelevant wird.
Die Services Plattform von Microsoft
Die neu eingeführte Services Plattform von Microsoft erfüllt die hohen Anforderungen an Skalierbarkeit, Stabilität und Funktionalität. Die Funktionalitäten umfassen Unterstützung für Multimandanten-Szenarien, Scale-out (im Unterschied zu Scale-up), Virtualisierung und Virtualisierungsmanagement, verschiedene Abrechnungsszenarien, Überwachung und Management, Verknüpfung von Services und schließlich auch Entwickler-Werkzeuge, die diese Funktionalitäten unterstützen.
Microsoft stellt verschiedene Dienste für Anwender (sogenannte Finished Services) und Entwickler (Building Block Services) zur Verfügung. Für alle Serverprodukte von Microsoft werden in Zukunft entsprechende Services bereitgestellt. Im Falle von Exchange, SharePoint und Dynamics CRM wird es für den Endanwender keinen Unterschied machen, welches Betriebsmodell gewählt wird. Anpassungen und Zugriffe erfolgen in jedem Modell gleich. Daneben gibt es noch sogenannte „native“, d.h. eigens für den Betrieb in der Cloud entwickelter Services. Office Live Meeting, Exchange Hosted Services und Virtual Earth sind alles Beispiele für Services, die nur über die Cloud zugreifbar sind.
Weitere Details zur Services Plattform auf den Konferenzen PDC, Xtopia und Technical Summit
Leider kann ich zum aktuellen Zeitpunkt noch nicht viel mehr zur Services Plattform ausführen. Die gute Nachricht ist aber: Das Warten auf mehr Details hat bald ein Ende: kommende Woche findet in Los Angeles die diesjährige Professional Developer Conference (PDC) statt. Diese Veranstaltung wird es absolut in sich haben. Neben einer Unmenge an Neuigkeiten rund um das Thema "Software + Services" wird es auch Neuigkeiten zu diversen Microsoft-Produkten und -Technologien geben.
Wer es im Oktober nicht nach Los Angeles schafft, dem seien zwei deutsche Veranstaltungen ans Herz gelegt, auf denen sich viele Inhalte der PDC wiederfinden:
Xtopia 2008 und Technical Summit 2008, 16.-21.11.2008 in Berlin
Die Entwickler-Konferenz "Technical Summit 2008" findet vom 19. bis 21. November im Berliner ICC statt; drei Tage vorher – vom 16. bis 18. November – öffnet die Web-Konferenz "Xtopia 08" ebenfalls im Berliner ICC ihre Tore. Die Terminierung dieser beiden Veranstaltungen ca. 3 Wochen nach der PDC ist nicht zufällig gewählt !!! - Besucher können sich sicher sein, all die interessanten Neuigkeiten der PDC in lokalisierter Form mitgeteilt zu bekommen.
Die SQL Server Data Services (SSDS) sind in Microsofts "Software + Services" Strategie im Bereich der Entwickler-Services angesiedelt. In diesem mehrteiligen Blog möchte ich beschreiben, wie dieser Service zur Datenspeicherung genutzt werden kann. In Teil 1 bin ich bereits auf Registrierung und das Datenmodell eingegangen und in Teil 2.1 habe ich beschrieben, wie mittels SOAP-Webservices Authoritys angelegt werden können.
In diesem zweiten Teil dieses zweiten Teils möchte ich beschreiben, wie mittels des Simple Object Access Protocols (SOAP) auf SSDS zugegriffen werden kann, um Container und Entitys anzulegen, auszulesen und zu löschen.
Schritt 4: Anlegen eines Containers
Das Anlegen eines Containers geschieht im Grunde genommen analog zum Anlegen einer Authority. Signifikanter Unterschied ist natürlich, dass als Scope nun nicht der Service selbst sondern die Authority, in der der Container angelegt werden soll, verwendet wird. In folgendem Listing, welches ebenfalls analog zum Programm zur Authority-Anlage geschrieben ist, findet die Anlage des Containers in der Methode createContainer(string , string) statt.
...
partial class MySsdsProgram
{
private static string userName;
private static string password;
private const string sampleAuthorityId = "hsirtl-demo-auth";
private const string sampleContainerId = "demo-container";
static void Main(string[] args)
getUserCredentials();
createContainer(sampleAuthorityId, sampleContainerId);
Console.WriteLine("Press any key.");
Console.ReadKey(true);
}
private static void createContainer(string authorityId, string containerId)
using (SitkaSoapServiceClient proxy =
new SitkaSoapServiceClient("SitkaSoapEndpoint"))
proxy.ClientCredentials.UserName.UserName = userName;
proxy.ClientCredentials.UserName.Password = password;
Scope myAuthorityScope = new Scope();
myAuthorityScope.AuthorityId = authorityId;
Container c1 = new Container();
c1.Id = containerId;
proxy.Create(myAuthorityScope, c1);
Console.WriteLine("Container {0} created!", c1.Id);
Im Service-Proxy-Objekt werden wieder die Credentials gesetzt. Anschließend wird der Scope gesetzt. Im Scope wird die ID der Authority gesetzt. Damit ist festgelegt, dass der Container in dieser Authority angelegt wird. Der Container selbst wird als Objekt instanziiert, die ID wie gewünscht gesetzt und die Service-Methode Create aufgerufen. Aus Gründen der Übersichtlichkeit wurde hier auf ein Exception-Handling verzichtet. Im Projektcode, den ich noch anfügen werde, ist dieses Handling enthalten.
Ausführung des Programms führt dann zur folgenden Ausgabe:
Container demo-container created!Press any key.
Um später die Authority wieder "aufräumen" zu können, als nächstes nun das Löschen eines Containers. Im Prinzip läuft wieder alles analog, d.h. Anlegen des Proxy-Objekts für den Service, Definition des Scopes und Auführen der Lösch-Operation.
private static void deleteContainer(string authorityId, string containerId)
Scope myContainerScope = new Scope();
myContainerScope.AuthorityId = authorityId;
myContainerScope.ContainerId = containerId;
proxy.Delete(myContainerScope);
Console.WriteLine("Container {0} deleted!", containerId);
}...
Man beachte, dass in diesem Fall im Scope neben der Authority-ID auch die Container-ID gesetzt werden muss (denn schließlich will man hier den Container und nicht die Authority löschen). Auch hier habe ich aus Gründen der Übersichtlichkeit Exception-Handling ausgelassen.
Container demo-container deleted!Press any key.
Damit stehen die wichtigsten Operationen zum Strukturieren der Daten (genauer der Entitys) zur Verfügung: das Anlegen von Authoritys und das Anlegen und Löschen von Containern. Nachdem wir in SSDS aber natürlich auch irgendwann mal Daten ablegen wollen, wird es nun interessant: das Anlegen, Ändern und Löschen von Entitys.
Zunächst also das Anlegen von Entitys. Und wieder geht alles nach der bewährten Vorgehensweise
Hier das entsprechende Listing einer createEntity-Methode:
private static void createEntity(string authorityId, string containerId, string entityId)
Entity e1 = new Entity();
e1.Id = entityId;
e1.Kind = "UsedBookKind";
e1.Properties = new Dictionary<string, object>();
e1.Properties["Name"] = "My Book";
e1.Properties["Address"] = "1-57880-066-36";
e1.Properties["Birthday"] = DateTime.Parse("27.01.2004");
proxy.Create(myContainerScope, e1);
Console.WriteLine("Entity {0} created!", e1.Id);
Im Wesentlichen sollte der Code nahezu selbsterklärend sein. Auf ein paar Details möchte ich hinweisen: Als Scope wird hier der Container angegeben, in dem die Entity angelegt werden soll. Die Definition der Entity geschieht in folgenden Code-Zeilen:
e1.Properties["Name"] = "Max Mustermann";
e1.Properties["Address"] = "Musterstrasse 1, 12345 Musterort";
e1.Properties["Birthday"] = DateTime.Parse("01.01.1980");
Analog zu Authoritys und Containern wird zunächst ein Entity-Objekt instanziiert. Anschließend werden die Pflichtattribute "ID" und "Kind" gesetzt. Dem folgt die Definition der "flexible Properties" (d.h. der frei definierbaren Schlüssel/Wert-Paare). Man beachte hier, dass verschiedene Werttypen (String und DateTime) eingetragen werden.
Nachdem es so einfach ist, nun gleich zum Ändern von Entitys:
private static void updateEntity(string authorityId, string containerId, string entityId)
Scope myEntityScope = new Scope();
myEntityScope.AuthorityId = authorityId;
myEntityScope.ContainerId = containerId;
myEntityScope.EntityId = sampleEntityId;
Entity myBook = proxy.Get(myEntityScope);
// 1) Einfuegen einer neuen flex property
string newPropName = "NewProp";
myBook.Properties[newPropName] = "New Prop Value";
// 2) Aendern einer bestehenden flex property
if (myBook.Properties.ContainsKey("Name"))
myBook.Properties["Name"] = "Tina Testfrau";
proxy.Update(myEntityScope, myBook);
Console.WriteLine("Entity {0} updated!", myEntityScope.EntityId);
Ich denke, auch hier ist der Code im Großen und Ganzen selbsterklärend. Der Scope wird jetzt bis zur Entity definiert, d.h. es werden Authority-, Container- und Entity-ID angegeben. Letztere muss man natürlich kennen. In unserem Beispiel ist dies natürlich gegeben. Im "echten Leben" würde man die ID häufig über Suchoperationen herausfinden. Suche werde ich in einem späteren Blog behandeln.
Das Beispiel oben zeigt, dass ohne Schwierigkeiten bestehende Propertys hinzugefügt und bestehende geändert werden können. Der Aufruf der Update-Methode überschreibt dann die alte Entity in SSDS.
Abschließend noch zum Löschen von Entitys. Es ist keine Überraschung, dass dies wieder analog den anderen Operationen geschieht, d.h. Proxy-Objekt definieren, Scope (bis zur Entity!) festlegen, Delete-Operation aufrufen...
private static void deleteEntity(string authorityId, string containerId, string entityId)
// The scope must be set to the entity you want to update
proxy.Delete(myEntityScope);
Console.WriteLine("Entity {0} deleted!", myEntityScope.EntityId);
Damit stehen im Grunde alle wichtigen Methoden zum Anlegen, Ändern und Löschen von SSDS-Inhalten zur Verfügung. Obige Beispiele sind natürlich sehr einfach gehalten und enthalten noch keine Fehlerbehandlung. Dies sollte für echte Anwendungen natürlich geändert werden.
In weiteren Teilen dieser Blog-Reihe gehe ich unter anderem noch auf folgende Themen ein:
Die SQL Server Data Services (SSDS) sind in Microsofts "Software + Services" Strategie im Bereich der Entwickler-Services angesiedelt. In diesem mehrteiligen Blog möchte ich beschreiben, wie dieser Service zur Datenspeicherung genutzt werden kann. In Teil 1 bin ich bereits auf Registrierung und das Datenmodell eingegangen.
In diesem zweiten Teil möchte ich beschreiben, wie mittels des Simple Object Access Protocols (SOAP) auf SSDS zugegriffen werden kann. Dabe werde ich folgende Schritte beschreiben:
Schritt 1: Registrieren des SSDS Service
Um per SOAP-Webservices auf SSDS zugreifen zu können, muss der entsprechende Service im VisualStudio-Projekt registriert werden. Hierzu sind folgende Aktionen erforderlich:
Das Grundgerüst des Hauptprogramms sollte nun inklusive aller Referenzen auf Namespaces wie folgt aussehen:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using ssdsDemo.ssdsClient;
namespace ssdsDemo
class Program
Schritt 2: Wahl des Übertragungsprotokolls (HTTP vs. HTTPS)
Grundsätzlich unterstützt SSDS beide Übertragungsprotokolle. In der Standardkonfiguration, die beim Setup wie oben beschrieben eingerichtet wird, wird HTTP gewählt. Nachdem in den folgenden Schritten User-Credentials (Benutzername und Passwort) übertragen werden müssen, empfiehlt sich allerdings eine Umkonfiguration zur Verwendung von HTTPS. Dies geschieht durch entsprechende Einträge in der Datei app.config, die sich im Projektverzeichnis befindet. In dieser Datei müssen die hervorgehobenen Zeilen in der Ursprungsdatei...
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="SitkaSoapEndpoint" ... > ...
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://data.beta.mssds.com/soap/v1"
binding="basicHttpBinding"
bindingConfiguration="SitkaSoapEndpoint"
contract="ssdsClient.ISitkaSoapService"
name="SitkaSoapEndpoint" /> ...
</client>
</system.serviceModel>
</configuration>
zu folgender Version geändert werden...
<security mode="Transport">
<endpoint address="https://data.beta.mssds.com/soap/v1"
Damit ist die Grundkonfiguration des Projekts schon abgeschlossen. Jetzt kann's mit den Webservice-Zugriffen losgehen.
Schritt 3: Anlegen einer Authority
Wie in meinem ersten Blog der Reihe beschrieben, stellt eine Authority das oberste Strukturierungselement für Daten in SSDS dar. Container und Entitys werden in jeweils einer bestimmten Authority angelegt. Zum Anlegen einer Authority ist zunächst die Definition des übergeordneten Scopes, in dem die Authority angelegt wird, erforderlich. Da die Authority das oberste Element des Hierarchiebaums ist, ist der Scope in diesem Fall der Service selbst. Formal wird hierzu ein leerer Scope angelegt. In diesem Scope kann dann die Authority angelegt werden. Hier das Gesamtlisting zum Anlegen einer Authority. Erklärungen zu einzelnen Codezeilen schließen sich an:
createAuthority();
private static void createAuthority()
using (SitkaSoapServiceClient proxy = new SitkaSoapServiceClient("SitkaSoapEndpoint"))
Scope serviceScope = new Scope();
Authority auth = new Authority();
auth.Id = sampleAuthorityId;
try
proxy.Create(serviceScope, auth);
Console.WriteLine("Authority {0} created!", auth.Id);
catch (FaultException<Error> e)
if (e.Detail.StatusCode != ErrorCodes.EntityExists)
Console.WriteLine("Error: {0}:{1}", e.Detail.StatusCode, e.Detail.Message);
Console.WriteLine(e);
return;
Console.WriteLine("Authority {0} already existed", auth.Id);
catch (Exception e)
Console.WriteLine("General exception: {0}", e.ToString());
Im Folgenden nun also Erläuterungen zu den einzelnen Codezeilen:
Die Definition der Namespaces wie bereits oben beschrieben. Die Klasse selbst habe ich umdefiniert zu "MySsdsProgram" und habe sie in der Hauptdatei als partial definiert. Grund hierfür ist, dass ich ein paar Hilfsmethoden (z.B. zum Erfassen von Benutzernamen und Passwort) ausgelagert habe.
Hier sind weren globale Variablen definiert, die in den später folgenden Beispielen noch verwendet werden. Hierzu gehören Benutzername und Passwort. Daneben noch die ID der Authority, die angelegt werden soll. Wichtig: In der aktuellen Version ist es nicht möglich, Authoritys zu löschen. Aus diesem Grund sollte die Authority sorgfältig festgelegt werden.
Dies ist letztlich das Hauptprogramm. Es wird die Hilfsmethode getUserCredentials() aufgerufen. Diese setzt die oben definierten globalen Variablen userName und password, ruft die Methode zum Anlegen der Authority auf und wartet dann darauf, dass der Anwender eine Taste drückt.
Hier wird nun Bezug auf den in Schritt 1 registrierten Webservice genommen. Da oben bereits der Namespace ssdsClient angemeldet wurde kann hier direkt der Webservice SitkaSoapServiceClient angesprochen werden. Im Service werden dann der Benutzername und das Passwort als Credentials gesetzt.
Diese eine Zeile ist entscheidend. Hier wird ein "leerer" Scope gesetzt. Dieser ist später für den Service-Aufruf erforderlich. Da eine Authority angelegt werden soll, die keinen eigenen Scope (außer dem Service-Scope) besitzt, bleibt der Scope ansonsten leer.
Eine neue Authority wird zunächst definiert. Dabei wird die ID der Authority auf den entsprechenden Wert der oben definierten globalen Variable gesetzt.
Hier erfolgt der Service-Aufruf. Im Service wird die Methode Create aufgerufen. Im Fehlerfall wird eine Exception geworfen, die in den Catch-Abschnitten (s.u.) behandelt wird. Im Falle des Anlegens einer Authority sind die häufigsten Fehler, dass entweder die Credentials falsch gesetzt wurden oder die Authority bereits existiert. Im Erfolgsfall erhält der Anwender eine positive Rückmeldung.
Hier werden Fehler des Webservices behandelt. Im Beispiel wird nur der Fall, dass die Authority bereits existiert, behandelt. Andere Service-Fehler werden generisch einfach ausgegeben.
Diese Exception-Behandlung erfolgt bei allen anderen Fehlern des Service-Aufrufs. Bei fehlerhaften Credentials (Benutzername und/oder Passwort falsch) wird dieser Zweig der Fehlerbehandlung durchlaufen.
Ausführen dieses Programms führt nun, nachdem wir alles richtig gemacht haben, zu folgender, zugegebenermaßen recht unspektakulären Ausgabe:
Authority hsirtl-demo-auth created!Press any key.
Im nächsten Teil werde ich auf das Anlegen und Bearbeiten weiterer Objekte (Container, Entitys) eingehen. Stay tuned!