Webservice på Windows Azure
Jeg har lavet min første webservice på Windows Azure og her følger en beskrivelse, erfaringer og en lille introduktion til Windows Azure.
Windows Azure?
Azure Services Platform er Microsofts cloud platform. Det er først og fremmest en platform til udviklerne. Det betyder at mange af de funktionaliteter og komponenter man kender fra sit lokale Visual Studio udviklingsmiljø bliver tilgængelig i (u)begrænsede mængder i skyen.

Jeg har tidligere skrevet om en af komponenterne og sammenlignet Microsoft SQL Services, med en SQL server i skyen (Den miderste kasse af de øverste 5 komponenter). Bemærk!: Det tekniske indhold i artiklen om SQL Services er i øvrigt forældet og vil ikke blive realiseret når Windows Azure går i produktion i slutningen af 2009. I stedet vil SQL services få fuld SQL understøttelse, men dette er endnu ikke i preview.
I denne blogpost vil jeg koncentrerer mig om Windows Azure (altså den nederste del af the big picture).

Komponenter i Windows Azure er kort fortalt en abstraktion oven på en webserver med 3 dele:

Webrole ? en komponent, som er en applikations host med HTTP/HTTPS kommunikation ind og ud. For .Net gælder det at man kan køre et subset af hhv. ASP.Net (webapplikationer) og Windows Communication Foundation (webservices)
Workerrole ' en komponent til hosting af applikationer som skal lave 'heavyliftning?. Workerrole er tiltænkt en rolle som arbejdshest for webrole. Blandt andet derfor kan den kun kommunikere med HTTP/HTTPS ud af komponeneten.
2. Storage ? 3 måde at lagre data på:
a. en kø ? beregnet på kommunikation mellem applikations roller b. en blob ? ustruktureret lagring c. tabeller ? struktureret lagring dog ikke med relationelle egenskaber
3. Management ? administrativt værktøj til at f.eks skalere instanser, depolyment og konfiguration af applikationer
Hvis man vil have et yderligere overblik over Windows Azure kan man blandt andet læse Daniel Frosts blog eller høre denne super cast hvor Søren Spelling Lund har lavet et fedt interview med Nikolaj Winnes: Interviewet indeholder blandt andet en positionering af XaaS, som jeg kan tilslutte mig. Jeg mener at der nogle steder bliver byttet rundt på begreberne.
I det følgende vil jeg lave en 'Hello World' webservice til Webrole i Windows Azure ved hjælp af Windows Communication Foundation (WCF).
Lokal udvikling
Man kan udvikle til Windows Azure uden at have adgang til 'skyen'. Der er en række SDK'er til Azure Services Platform ' i denne forbindelse skal jeg bruge Windows Azure SDK og Windows Azure Tools for Microsoft Visual Studio (meget mundret ). Visual Studio (også Express edition) og enten Windows Vista eller Windows 7 kræves for at udvikle og køre servicen lokalt (læs mere om softwarekrav, her). IIS 7 webserver skal være installeret og hvis man som jeg vil lave webservices med WCF på IIS så skal man have associeret mime-types, http handlers osv med webserveren. Det kan gøres manuelt, men dette værktøj og denne parameter sikre at det sker:
'ServiceModelReg.exe 'i?.
Værktøjet findes i .Net Framework 3.0, typisk i 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation' folderen.
Opskrift ? WCF Webservice på Azure
Forudsat at de ovenstående krav er på plads (Win Vista/7, IIS 7 m WCF enabled, Azure SDK og tool til Visual Studio, version af SQL server (er dog ikke nødvendig i dette lille projekt) og en version af Visual Studio) laver jeg følgende for at få tingene til at spille: Opretter et nyt projekt i Visual Studio. Projektet er en 'Cloud service', som nu er til rådighed efter installation af Azure SDK og Azure Tools for Visual Studio.
Jeg vælger en 'Web Cloud Service' fordi jeg ved at min HelloWorld webservice skal modtage et navn over HTTP og skal returnere 'Hello 'navn'' over HTTP. Web Cloud Service implementerer WebRole supporterer HTTP ind og ud.

Hvis alt går godt åbnes en Visual Studio solution med to projekter. Et HelloCloud projekt med en konfigurationsfil og en definitionsfil, som vil fortælle hvordan man skal deploye og hvordan mange instanser der skal køre etc. dvs management og deployment til den applikationer der skal køre i skyen.

Det andet project i løsningen ligner til forveksling en traditional webapplikation, med config og aspx filer. Da jeg skal bruge applikationen til en webservice sletter jeg derfor 'Default.aspx' og højreklikker på HelloCloud-projektet og laver Add->New Item-> ...og vælger en WCF Service.

Dette betyder at de rigtige referencer til WCF bliver oprettet i projektet og at configurationsfilen bliver opdateret:


HelloService.svc er det endpoint som hostes. Så skal man implmentere forretningsfunktionalitet og denne gøres simpel (vi skal jo bare have hul igennem):

Hvis man kører programmet med debugging i Visual Studio, så får man applikationen op lokalt og man kan teste med klienter etc. However! Der er pt en bug(') i udvikling af SOAP baserede services i Windows Azure; Der er ingen automatisk opdagelse af metadata ' helt konkret betyder det at endpoint til WSDL ikke angives korrekt. Jeg er ikke helt sikker på hvorfor det sker, men lokalt kan jeg se at Azure Projekter i Visual Studio vil over IIS 7, mens studiet gerne vil eksponere over developer webserveren. Den samme fejl er også til stede når servicen er deployet, men i dette tilfælde er det DNS mapping problemer.
Bottomline : Man kan ikke på adgang til de rigtige metadata i deployment. Betyder det så at man ikke kan bygge en klient' Nope! Hvis man downloader de metadata (WSDL'en) man kan få adgang til er det kun et spørgsmål om at ændre dns navnet i WSDL'en til det site man har deployt til. F.eks fra http://78asdf7987asdf987989:5100/HelloService.svc til http://renescloud.cloudapp.net/HelloService.svc. Herefter kan man pege sit klientværktøj til WSDL'en (f.eks Svcutil.exe på .Net) og automatisk generere den kode, som er nødvendig for at lave en klient.
Deployment
Deployment er et simpelt højreklik på HelloCloud-projektet og vælg 'Publish'. Herefter vil der ske to ting. For det første vil hele løsningen blive pakket til en fil + en konfigurationsfil. Disse to filer vil blive placeret i projektets debug folder. For det andet vil 'Publish' processen forsøge at starte en browser instans af Developer portalen på Windows Azure. Hvis ikke man er logget ind i WindowsLive vil man blive redirected til login siden for LiveId.
Hvis alt går godt er man nu inde i Azure Services Developer Portal. Her er det muligt at oprette et nyt projekt (forudsat at man har fulgt processen nedenfor om adgang til Azure). Ved projekt oprettelse er der en række stamdata som skal angives bl.a. projektnavn og lokation for datacenter som servicen skal køres i (pt kun centre i US).
Ved succesfuld oprettelse af projekt har man adgang til deployment af en hosted service:


Herefter er det muligt at se den servicen i staging miljøet og det er muligt at starte den. Opstart, allokering ... etc. tager ca 5-10 minutter og herefter kan man få adgang til servicen på det bestemt endpoint.
Note! Da det er en WCF service burde vi have mulighed for at konfigurere endpoint adressen. Dette er ikke tilfældet på Azure. Azure vil som det er tilfældet i denne preview ignorere adresse information i weg.config. Dvs en lokal service på http://localhost/cloudapp.net/test/2009/HelloService.svc, som man forventer ville deploye til: http://renesazure.cloudapp.net/test/2009/HelloService.svc, vil i stedet blive til http://renesazure/cloudapp.net/test/2009/HelloService.svc .

That?s it. Nu har jeg prøvet webservices på Windows Azure Tech Preview i et stykke tid.
Erfaringer so far? Cool: Udviklingsoplevelsen fra lokalt til cloud er super. De samme kompetencer og teknologier applies. Not so cool: Metadata discovery, suk (forhåbentlig bliver det bedre snarest)
Adgang til Azure
For at få adgang til at prøve preview af Windows Azure, skal man ansøge. Det er en lidt omstændelig proces, men det kan begrænses til følgende:
1. Ansøgning om adgang til Windows Azure (kræver et Windows LiveId)
2. Når man har fået adgang bliver der fremsendt et Id-nummer, som skal omsættes til et 'token' på Windows Azure Developer Portal (under account settings)
3. Herefter har man adgang til at oprettet et hosted projekt (compute) og to databaser (storage) på samme token
Kommentarer (2)
Hej René,
Nu har jeg længe siddet og prøve, at konfigurere mine endpoints så den rigtige adresse blev vist i wsdl'en. Af en eller anden grund faldt det mig aldrig ind, at ændre dem manuelt, men nu har jeg da fået det til at virke.
Ellers en god tutorial
Mvh
Nicolai
Hej Nicolai,
Tak!
Godt at høre at du har hul igennem. Det er noget skidt hvis man ikke kender til den bug og ikke laver en work-a-round! Nu beklager jeg kun, at jeg ikke fik posted indlægget noget før, så jeg havde måske sparret dig nogle timer.
-René

