Christofer Löf

Kom igång med Visual Studio 2010 Beta 2 och Windows Azure

chrislof — Sun, 20 Dec 2009 10:12:00 GMT

Nu när julen kommer farandes brukar en hel del människor ta några dagar ledigt. Vad kan då passa bättre än att passa på att kanske lära sig något nytt?

Visual Studio 2010 Beta 2 släpptes som bekant i oktober månad. Vid den tidpunkten vad den senaste versionen av Windows Azure verktygen för Visual Studio den version som släpptes i juli. Detta gjorde att Visual Studio teamet valde att inte skicka med verktygen för Windows Azure i Visual Studio 2010 Beta 2 då de visste att det kommer en ny version i samband med Windows Azure releasen på PDC. Men det är inte så illa som det kanske låter. De såg istället till att det fanns ett enkelt sätt att installera Windows Azure verktygen när de väl är släppta.

När du väljer att skapa ett nytt projekt av typen Windows Azure Cloud Service så kommer du första gången att skickas till webbsidan för nedladdning och installation av Visual Studio Tools for Windows Azure. En helt respektabel lösning på det hela tycker jag. När Visual Studio 2010 släpps någon gång i vår så kan vi nog vara ganska säkra på att de har synkat releaserna. (Detta gäller också ASP.NET MVC 2 men är en annan historia)

När jag har skapat mitt projekt får jag möjligheten att lägga till en eller flera sk Roller. En Roll är helt enkelt en viss typ av applikation som kan köras i Windows Azure. Några nyheter som vi kan se här är bland annat roller för WCF och ASP.NET MVC. Just nu kör jag på Visual Web Developer 2010 Express (gratisversionen av Visual Studio) vilket gör att jag inte får tillgång till den nya F# Worker-rollen.

Nu när min molntjänst har skapats har jag fått två projekt i Visual Studio. Det ena projektet är definitionen av min molntjänst (CloudService11) – denna innehåller, bland en hel del annat, information om vilka roller som ingår och antalet instanser av dessa roller.

Med Visual Studio 2010 kommer också .NET Framework 4 (eller om man nu ser på det åt andra hållet). Som standard när jag skapar ett nytt projekt i Visual Studio 2010 så är det förvalt att projektet skall köras på just .NET Framework 4. Vad jag måste ha i åtanke här är att Windows Azure inte, än, stöder .NET Framework 4 utan där är det .NET Framework 3.5 SP1 som gäller. Jag måste alltså ändra vilket ramverk min molntjänst skall baseras på för att kunna publicera den till Windows Azure. Med någon av betalversionerna av Visual Studio 2010 kan jag välja detta direkt när projektet skapas men iom att jag nu gör Express får jag ändra detta i efterhand. Detta gör jag genom att högerklicka på mitt webbprojekt och välja Properties. I denna vy ser jag sedan till att Target framework är satt till .NET Framework 3.5.

Vad jag också brukar göra är att ändra antalet instanser av varje roll. Det är nämligen så att man måste ha minst två instanser av varje roll för att fastställda SLA:er skall gälla. För att göra detta dubbelklickar jag på min roll Hello World och justerar därefter värdet på Instance count till 2. Vad som också kan vara värt att lägga märke till här är möjligheten att välja storlek på den virtuella maskin som min roll (webbapplikation i detta fall) kommer installeras och köras i. En Small är en burk med ca 2GB RAM och 1 processorkärna. För varje storlek dubblas kapaciteten, vilket gör att en ExtraLarge är på ca 16GB RAM och 8 processorkärnor.

Jag har nu knåpat på min webbapplikation och vill prova den i Windows Azure. Jag skulle kunna publicera den till molnet och testa där men ett mycket snabbare sätt är att köra den i den lokala simuleringsmiljön Windows Azure Simulation Environment. Genom att starta debuggern (F5) startas också simuleringsmiljön och min molntjänst publiceras dit.

Genom att öppna Development Fabric kan jag nu se att jag har två instanser av min Hello World webbapplikation rullandes.

Nu när jag känner mig nöjd med min molntjänst högerklickar jag på mitt molntjänstprojekt och väljer Publish. Visual Studio skapar då ett paket som är redo att laddas upp till Windows Azure.

Lycka till i molnet och God Jul!

Mer läsning

CRUDing with “ActiveRecord for Azure”

chrislof — Sat, 19 Dec 2009 10:24:49 GMT

In my previous blog post I introduced you to my little experiment – a sample implementation of the ActiveRecord pattern for the Windows Azure Storage system which I call “ActiveRecord for Azure”. (It’s easier to refer to something it it has a name – right?). In this post I want to elaborate a little bit further on the features previously mentioned. Since most of us associate the ActiveRecord pattern with MVC style apps I’m going to show the Create, Read, Update and Delete (CRUD) support by implementing a simple Task List application using ASP.NET MVC.

Wire it up

First I’ve to set up the “ActiveRecord for Azure” environment – that’s; create tables, wire up configuration change handlers etc. I’ve put all this kind of logic into the ActiveRecordEnvironment class. All I have to do is to call its Start-method. Probably the best place to do this is in the RoleInstance startup event. To do that I just create a class which derives from RoleEntryPoint and overrides its OnStart –method.

public class WebRole : RoleEntryPoint
{
    public override bool OnStart()
    {
        //start the ActiveRecord environment
        ActiveRecordEnvironment.Start(this);

        return base.OnStart();
    }
}

The Model

I’m now ready to implement my Model. Since it’s a Task List application I’m building the Model at least needs to have a Task entity. To store an entity in Windows Azure Tables it has to have three properties called RowKey, PartitionKey and Timestamp. You could certainly write these yourself (or derive from TableServiceEntity) but you have to handle the generation and associations of RowKeys and PartitionKeys “manually”. The ActiveRecord base class takes care of this for me and also equips the entity with the CRUD operations.

public class Task : ActiveRecord<Task>
{
    [Required]
    public string Title { get; set; }
    
    public DateTime Due { get; set; }

    public bool Complete { get; set; }
}

As you probably already recognized I’m using the validation attribute Required from the System.ComponentModel.DataAnnotations namespace to mark the Title property as mandatory. ASP.NET MVC 2 now knows how to handle these validation attributes. (No more validation logic scattered through out the app – yay!).

The Controller

Listing all Tasks is as simple as calling the All-method on the Task class (provided by the ActiveRecord base class)

public ActionResult Index() {
    return View(Task.All());
}

As you can see in the below Edit Action Method the data access code is minimal. Allowing you to focus on the business problem while leveraging the performance of Windows Azure Table Storage. The “ActiveRecord for Azure” specific code rows are commented with “AR4A” – all other rows are just plain vanilla ASP.NET MVC.

[HttpPost]
public ActionResult Edit(string id, Task task) {
    var existingTask = Task.Find(id); //AR4A

    try {
        UpdateModel(existingTask);
        existingTask.Save(); //AR4A

        return RedirectToAction("Index");
    }catch {
        return View(task);
    }
}

To delete an entity I just call (you probably already figured this one out – didn’t you?) – Delete.

[HttpPost]
public ActionResult Delete(string id) {
    Task.Delete(id); //AR4A
    return RedirectToAction("Index");
}

In the above example I called the static Delete-method and passed in the Id (RowId) of the Task to delete. I could also have called the Delete method on the specific Task instance to delete it.

Wrapping it up

So in just a few minutes I built myself a Task List application using Windows Azure and ASP.NET MVC 2. It’s so nice not having to spend hours on infrastructure code that in itself doesn’t provide any business value – isn’t it?

You can download the full example below. Please remember – this comes as-is and should be considered example code only.

Introducing “ActiveRecord for Azure”

chrislof — Thu, 17 Dec 2009 12:48:54 GMT

DISCLAIMER: This is a personal spare time experiment.

The Windows Azure Storage system is very capable and will probably fit your and your application needs in a lot of scenarios. I feel that, especially Windows Azure Tables, is far too often forgotten when considering object persistence in the cloud. This post was supposed to show off Windows Azure Tables together with the WCF Data Services client in order to try to change the perception of "SQL Azure is the only option".

But the accompanying code examples evolved, so..

Please say welcome to “ActiveRecord for Azure”

“ActiveRecord for Azure” (or just AR4A) is what its name implies; a sample implementation of the ActiveRecord pattern for the Windows Azure Storage system. Its main objective is to make Windows Azure data access really easy, yet powerful.

AR4A is built on top of the WCF Data Services client and the managed Windows Azure Storage API - utilizing the great work that's already been put into those libraries. AR4A just adds more simplicity to them.

To get started you inherit your entities from the ActiveRecord base class followed by telling the ActiveRecord environment to create the required tables. AR4A then handles the persistence of entities, retrieval of entities, continuation tokens, table partitions, among other things for you.

Feature overview (at the point of writing this)

CRUD operations
Partition management
Table generation
Id generation
Stubs

To give you a peek of what it looks like, I've revamped the RdChat application that comes with the Windows Azure Training Kit using AR4A.

“ActiveRecord for Azure” sneak peek

List all messages

Training Kit style

var account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
var context = new MessageDataServiceContext(account.TableEndpoint.ToString(), account.Credentials);

... (non-relevant code)

this.messageList.DataSource = context.Messages;
this.messageList.DataBind();

AR4A style

this.messageList.DataSource = Message.All();
this.messageList.DataBind();

Add message

Training Kit style

var account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
var context = new MessageDataServiceContext(account.TableEndpoint.ToString(), account.Credentials);

context.AddMessage(this.nameBox.Text, this.messageBox.Text);

public void AddMessage(string name, string body)
{
    this.AddObject("Messages", new Message { Name = name, Body = body });
    this.SaveChanges();
}

AR4A style

//just create the message..
var message = new Message() {
    Body = messageBox.Text,
    Name = nameBox.Text,
};

//..and save it
message.Save();

Entity

Training Kit style

public class Message : TableServiceEntity
{
    public string Name { get; set; }
    public string Body { get; set; }

    public Message()
    {
        PartitionKey = "a";
        RowKey = string.Format("{0:10}_{1}", DateTime.MaxValue.Ticks - DateTime.Now.Ticks, Guid.NewGuid());
    }
}

AR4A style

public class Message : ActiveRecord<Message> {

    public string Name { get; set; }
    public string Body { get; set; }

}

Startup

Training Kit style

First about ten lines of configuration change handling code. Then:

var account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

// dynamically create the tables
CloudTableClient.CreateTablesFromModel(typeof(MessageDataServiceContext),
                                       account.TableEndpoint.AbsoluteUri, account.Credentials);

AR4A style

//initialize the AR4A environment
ActiveRecordEnvironment.Start(this);

Windows Azure SDK November 2009 ute nu!

chrislof — Sun, 15 Nov 2009 11:32:38 GMT

I går släppte vi Windows Azure Software Development Kit (November 2009) och Windows Azure Tools for Microsoft Visual Studio (November 2009) samt tillhörande exempel.

Vad är det då som är nytt? Det första vi kan lägga märke till är att förkortningen CTP inte längre finns med i namnen vilket skvallrar som production quality. Bland funktioner som är nya eller förädlade kan nämnas;

Möjlighet till kommunikation mellan rollinstanser (SDK)
Nya API:er för loggning och hälsokontroll. (SDK)
Hantering av SSL certifikat (SDK)
Välj vilken typ av virtuell maskin du vill deploya din rollinstans på (SDK)
Externa ändpunkter på Worker Roles (SDK)
Skriv information till lokalt lagringsutrymme utan att riskera att informationen är borta när rollen startas om (SDK)
Ett “riktigt” Storage Client bibliotek för åtkomst till Azure Storage (Tables, Queues och Blobs) (SDK)
Förbättrat Development Storage. Inget mer “generate tables” (SDK) – whoho!
Nya rolltyper: F# Worker, ASP.NET MVC 2, WCF Service (VSTools)
Stöd för Visual Studio 2010 Beta 2. Även Express. (VSTools) - sweet!
Användargränssnitt för hantering av tjänstemodellen (VSTools)

Så nu är det bara att tanka ned, installera, labba, titta på PDC dragningar nästa vecka för att till slut husera production appar på Windows Azure.

Kom igång med PHP på Windows Azure

chrislof — Wed, 11 Nov 2009 20:32:46 GMT

På senare tid har vi på Microsoft introducerat ett antal initiativ för ökad interoperabilitet med PHP. Det handlar bland annat om drivare för SQL Server, verktyg för att konsumera ADO.NET Data Services resurser och exekvering av PHP i Internet Information Services. Alla dessa är högst relevanta för PHP på Windows Azure men fungerar också lika bra på “vanliga” Windows. För utveckling ämnad Windows Azure har vi tillsammans med våra partners Soyatec och RealDolmen tagit fram två riktigt smaskiga bitar; Windows Azure SDK for PHP och Windows Azure Tools for Eclipse.

Windows Azure SDK for PHP

Windows Azure SDK for PHP är ett utvecklingspaket för Windows Azure och Windows Azure Storage – Blobs, Tables och Queues. Funktioner är bland andra;

Klasser för CRUD operationer på Blobs, Tables och Queues
Hjälpklasser för HTTP-transport, felhantering, REST och säkerhet
Instrumentering och loggning
Hantering av PHP sessioner i Tables.

Windows Azure Tools for Eclipse

Windows Azure Tools for Eclipse är ett tillägg till Eclipse vilket ger bra verktygsstöd för utveckling av PHP applikationer för Windows Azure. Funktionerna är bland andra;

Projektmallar och migrering av projekt
Hantering av Windows Azure specifika begrepp som Roller och Tjänstedefinitioner
Storage Explorer – Hantera dina Windows Azure Storage konton (inkl innehåll)
Windows Azure project deployment – paketering av ditt projekt och publicering till portal eller Windows Azure Development Fabric

Windows Azure Tools for Eclipse inkluderar även Windows Azure SDK for PHP, vilket gör att du endast behöver installera ett paket och är därmed snabbt igång.

(Klicka för större bild)

Om du är en PHP utvecklare som använder andra verktyg än Eclipse för att skriva din kod, (kanske Vim , Emacs eller Notepad) så är du inte portad från Windows Azure för det. Du kommer dock troligen få ägna lite mer tid åt att paketera och hantera dina Windows Azure projekt med CSPack, CSRun, DSInit och hålla tungan rätt i munnen än om du använder Windows Azure Tools for Eclipse.

Avslutningsvis

Bekanta dig med Windows Azure
Ladda ned Windows Azure SDK (July CTP)
Installera Windows Azure Tools for Eclipse
Ladda ned Windows Azure SDK for PHP
Läs mer om vårt arbete med PHP
Lär mig PHP

Att enhetstesta WCF-tjänster

chrislof — Sat, 07 Nov 2009 16:11:14 GMT

Jag möts gång på gång av tappra försök till att “enhetstesta” WCF tjänster där det i själva verket har resulterat i mer eller mindre komplexa integrationstester. Anledningarna till detta har oftast sin grund i att det man byggt nyttjar WCF:s OperationContext eller ServiceSecurityContext för att hämta information från inkommande meddelande eller anropande användare.

OperationContext och ServiceSecurityContext instansieras av WCF hosten och är således inte tillgängliga utanför WCF:s exekveringskontext. Lösningen på detta anses därför i många fall vara att helt enkelt bygga “enhetstester” som hostar aktuell WCF-tjänst för att på så vis få tillgång till OperationContext och ServiceSecurityContext instanserna. Jag säger inte att detta är fel. Däremot vill jag absolut kalla denna typ av tester för Integrationstester. Man testar helt enkelt sin tjänst tillsammans med övriga komponenter av vilka man inte har full kontroll över.

Låt mig visa ett exempel. Nedan operation returnerar ett klasiskt “Hello” med användarnamnet på anropande användare.

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public string Hello() {

    var user = ServiceSecurityContext.Current.WindowsIdentity.Name;
    return "Hello " + user;

}

Ur ett enhetstestperspektiv finns det två problem med ovan “enkla” operation.

ServiceSecurityContext.Current kommer vara null om operationen inte exekverar inom en WCF host.
Om man istället sätter upp ett integrationstest för att få fatt i en instans av ServiceSecurityContext så kommer WindowsIdentity.Name returnera användarnamnet på det konto som exekverar testet. Dvs synnerligen svårt att skriva ett test som alltid är sant.

Hur skall jag då göra för att verkligen kunna enhetstesta ovan operation? Som i många andra sammanhang med enhetstestning så får jag helt enkelt addera en abstraktion på, i detta fall, ServiceSecurityContext för att kunna ersätta implementationen med en Mock eller Stub. Det som kan röra till det hela i WCF':s fall är att ServiceSecurityContext inte implementerar något Interface eller basklass som jag kan utgå ifrån. Jag börjar således med att skapa ett Interface som ser likadant ut som ServiceSecurityContext.

namespace Chrislof.ServiceModel.Abstractions {
    
    public interface IServiceSecurityContext {

        AuthorizationContext AuthorizationContext { get; }

        ReadOnlyCollection<IAuthorizationPolicy> AuthorizationPolicies { get; }

        bool IsAnonymous { get; }

        IIdentity PrimaryIdentity { get; }

        IWindowsIdentity WindowsIdentity { get; }

    }
}

Detta Interface implementerar jag sedan i en sk Wrapper. Denna wrapper-implementation tar en referens till aktuellt ServiceSecurityContext och vidarebefordrar endast anropen till den “riktiga” ServiceSecurityContext instansen.

namespace Chrislof.ServiceModel.Abstractions {
    /// <summary>
    /// Decorates the <see cref="ServiceSecurityContext"/> for testability
    /// </summary>
    public class ServiceSecurityContextWrapper : IServiceSecurityContext
    {
        private readonly ServiceSecurityContext _context;

        public ServiceSecurityContextWrapper(ServiceSecurityContext context) {

            context.ArgumentNotNull("context");
            _context = context;
        }

        public AuthorizationContext AuthorizationContext {
            get { return _context.AuthorizationContext; }
        }

        public ReadOnlyCollection<IAuthorizationPolicy> AuthorizationPolicies {
            get { return _context.AuthorizationPolicies; }
        }

        public bool IsAnonymous {
            get { return _context.IsAnonymous; }
        }

        public IIdentity PrimaryIdentity {
            get { return _context.PrimaryIdentity; }
        }

        public IWindowsIdentity WindowsIdentity {
            get { return new WindowsIdentityWrapper(_context.WindowsIdentity); }
        }
    }
}

För att nyttja ovan ServiceSecurityContextWrapper i min tjänsteimplementation adderar jag en constructor och ett privat fält som håller referensen till wrappern.

public Service(IServiceSecurityContext securityContext) {
    _securityContext = securityContext;
}

Hello-operationen justeras till följande.

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public string Hello() {

    var user = _securityContext.WindowsIdentity.Name;
    return "Hello " + user;

}

Detta gör att jag nu kan tilldela min tjänst med ett ServiceSecurityContext som jag har full kontroll över inom ramen av mitt enhetstest. Jag använder i nedan exempel ramverket Moq för att skapa en ServiceSecurityContext-stub som returnerar mitt användarnamn.

[TestMethod]
public void Hello_WhenCalled_ReturnsHelloWithCurrentUser() {

    const string user = "Chrislof";

    var securityContext = new Mock<IServiceSecurityContext>();
    securityContext.SetupGet(x => x.WindowsIdentity.Name).Returns(user);
    
    var service = new Service(securityContext.Object);

    var response = service.Hello();

    Assert.AreEqual("Hello Chrislof",response);

}

Ovan konstruktor som kräver en parameter är inget som WCF diggar alls som standard. (Se tidigare artikel ang detta) Jag behöver dessutom få WCF att ge mig en instans av min ServiceSecurityContextWrapper. Det absolut enklaste sättet att lösa detta är att infoga en defaultkonstruktor utan parametrar och i den instansiera ServiceSecurityContextWrapper.

public Service() : 
    this(new ServiceSecurityContextWrapper(ServiceSecurityContext.Current)) {}

Ovan exempel finns att ladda ned här nedan. Projektet inkluderar även ett mer avancerat scenario med en ServiceAuthorizationManager. Använd gärna mina Abstraktions-klasser men kom ihåg – de kommer as-is utan någon som helst garanti eller support.

Happy testing!

Routing med WCF 4

chrislof — Mon, 02 Nov 2009 22:17:21 GMT

Att införa en eller flera sk Message Routers i sin tjänsteorienterade lösning görs av olika anledningar. Vanligtvis rör det sig om mer avancerade behov som att kunna brygga mellan protokoll och transport sätt, versionshantera kontrakt, centraliserad säkerhetshantering med mera. Den grundläggande förmågan som Routern har för att möjliggöra allt detta är att inspektera inkommande meddelande och sedan skicka det vidare till definierad mottagare baserat på ett regelverk.

WCF 4 tillhandahåller en färdig Routing-tjänst - Det du behöver göra är att konfigurera den efter dina behov.

Content Based Routing

Som jag skrev ovan bygger Routerns förmågor på att kunna skicka vidare ett inkommande meddelande till en definierad måltjänst. I mitt exempel denna gång visar jag vad som kallas för Content Based Routing – dvs inspektera meddlandekroppen (läs Body) och skicka sedan vidare meddelandet baserat på meddelandeinnehåll.

Konsumenten (C) har en Proxy baserad på en ordertjänsts kontrakt (S). Istället för att ansluta till ordertjänstens ändpunkt så ansluter konsumenten till Routern (R). Routern kontrollerar om meddelandet kommer från en Premiumkund och skickar i sådant fall meddelandet vidare till en ordertjänst specifik för just Premiumkunder - 15% rabatt!. (I ett mer “riktigt” scenario skulle det kanske snarare röra sig om SLA-nivå eller liknande istället för en så enkel sak som rabatt.)

Det första som behöver göras är naturligtvis att exponera Routing-tjänsten. Det finns ett par olika kontrakt att välja på beroende på det kommunikationsmönster du önskar – Message Exchange Pattern. I detta fall använder jag IRequestReplyRouter. Implementationen RoutingService är densamma för alla tillgängliga kontrakt.

<services>
  <service behaviorConfiguration="routing" name="System.ServiceModel.Routing.RoutingService">
    <host>
      <baseAddresses>
        <add baseAddress="http://localhost:8080/router"/>
      </baseAddresses>
    </host>
    <endpoint
      name="basic"
      address="basic-request-reply"
      binding="basicHttpBinding"
      contract="System.ServiceModel.Routing.IRequestReplyRouter"/>
  </service>
</services>

Nästa steg är att definiera de ändpunkter som Routern skall kunna skicka vidare meddelanden till.

<client>
  <endpoint
    name="premiumCustomer"
    address="net.tcp://localhost:8091/orders/premium-customer"
    binding="netTcpBinding"
    contract="*"/>
  <endpoint
    name="ordinaryCustomer"
    address="http://localhost:8090/orders/ordinary-customer"
    binding="basicHttpBinding"
    contract="*"/>
</client>

Så långt är det inga konstigheter – Det är nu det balla börjar på riktigt.

Hjärtat i Routing-tjänsten är vad som kallas Filter Tables och Filters. Det är helt enkelt där jag definierar regelverket för hur meddelanden skall tolkas och skickas vidare. Jag vill i mitt exempel genomsöka meddelandekroppen efter kundnamnet “VS2010” och agera därefter. För att göra det använder jag filtertypen XPath. Det finns även här ett antal alternativ.

<routing>
  <namespaceTable>
    <add prefix="c" namespace="urn:chrislof-examples"/>
  </namespaceTable>
  <filters>
    <filter name="ordinaryCustomerFilter" filterType="XPath" filterData="//c:customerName != 'VS2010'"/>
    <filter name="premiumCustomerFilter" filterType="XPath" filterData="//c:customerName = 'VS2010'"/>
  </filters>
  <filterTables>
    <filterTable name="filterTable">
      <add filterName="ordinaryCustomerFilter" endpointName="ordinaryCustomer"/>
      <add filterName="premiumCustomerFilter" endpointName="premiumCustomer"/>
    </filterTable>
  </filterTables>
</routing>

I filtertabellen definierar jag vilken ändpunkt meddelandet skall skickas vidare till om specificerat filter returnerar en match.

Dags att provköra!

Jag tycker mig behöva en ny Laptop och lägger därmed en order på en ny.

Routern anser inte att jag är en Premiumkund och skickar således ordern vidare till OrdinaryOrderService.

När jag istället beställer en Server i namnet VS2010 skickar Routern beställningen till PremiumOrderService och ger mig därmed 15% rabatt.

Avslutningsvis

Precis som med Discovery är ovan möjligt att implementera med WCF 3.x. Ett lysande exempel på det är Managed Services Engine. Det är dock nu med WCF 4 betydligt enklare att implementera flera av dessa förmågor som MSE:n besitter på egen hand.

Exemplet kan du ladda ned här. (Kräver VS2010 Beta 2)

Förändringar mellan WF4 Beta 1 och Beta 2

chrislof — Tue, 20 Oct 2009 18:11:46 GMT

Få har nog missat att Visual Studio 2010 Beta 2 och .NET Framework 4 Beta 2 släpptes till MSDN prenumeranter igår.

Beta 2 innehåller en hel del förändringar baserade på kommentarer från er Betatestare världen över. Förändringar gällande Windows Workflow Foundation (WF) har Matt Winkler beskrivit i två alldeles strålande artiklar. Den första beskriver generellt om förändringar i ramverket medans den andra fokuserar på förändringar gjorda i designern (tack).

Tycker du som jag ? – Det är en spännande tid just nu :)

Jag vet.. Det är för enkelt att bara länka vidare.

WS-Discovery med WCF 4

chrislof — Wed, 14 Oct 2009 14:30:09 GMT

Att WCF 4 nu kommer med stöd för WS-Discovery protokollet tycker jag är en riktig höjdare. Protokollet i sig är ingen nyhet men det är först i .NET 4.0 som WCF-stacken levereras med detta direkt "från fabrik".

Med hjälp av WS-Discovery kan tjänster och konsumenter kommunicera och hitta varandra utan något behov av tjänsteregister eller liknande.

Hur fungerar det då?

I mitt exempel (som jag lånat från WS-Discovery specifikationsdokumentet) har jag en konsument som söker efter en skrivare. Förfrågan skickas ut på nätverket och till svar får jag en lista med Endpoints som påstår sig implementera det kontrakt jag specificerat i min förfrågan (Probe).

Det första jag måste göra för att få fart i detta är att skapa två sk DiscoveryEndpoints; en på konsumentsidan och en på tjänstesidan. Denna typ av Endpoint finns med i WCF 4's uppsättning av sk Standard Endpoints varför jag endast behöver lägga till ett Endpoint-element och sätta dess nytillkomna Kind egenskap i konfiguration. Adresser , Bindningar och Kontrakt (som vi är vana vid att definiera på en Endpoint) hanterar WCF åt oss på Standard Endpoints.

<endpoint kind="udpDiscoveryEndpoint" />

Ovan: Endpoint-definition tjänst.

var discoClient = new DiscoveryClient(new UdpDiscoveryEndpoint());
var criteria = new FindCriteria(typeof(IPrintService));
var result = discoClient.Find(criteria);

var numberOfPrintersFound = result.Endpoints.Count;

Ovan: Konsument skickar förfrågan efter en skrivare

Oftast är det ju också som så att jag söker efter en mer specifik skrivare. Vi har trots allt sju våningsplan på vårat kontor i Kista och det vore ju angenämt om min utskrift kunde hamna på en skrivare på det våningsplan jag anger. Ibland söker jag även efter en skrivare som klarar att skriva ut i färg.

Denna typ av sökkriterier definieras i form av Scopes och Extensions. Dessa egenskaper kan tjänsterna exponera och när jag skickar en förfrågan om tjänst som uppfyller mina ställda kriterier så kommer jag endast få svar från tjänster som har matchande egenskaper definierade.

I nedan exempel påstår skrivaren att den är lokaliserad på plan 3...

<endpointBehaviors>
  <behavior>
    <endpointDiscovery>
      <scopes>
        <add scope="ldap:///ou=floor3,ou=kista,o=chrislof-example,c=local"/>
      </scopes>
    </endpointDiscovery>
  </behavior>
</endpointBehaviors>

... Och konsumenten adderar ett Scope med samma värde i sin förfrågan.

var criteria = new FindCriteria(typeof(IPrintService));
criteria.Scopes.Add(new Uri("ldap:///ou=floor3,ou=kista,o=chrislof-example,c=local"));

I WS-Discovery finns det också funktionalitet definierad så att tjänster kan notifiera varandra om sin existens (Announce). Det handlar i praktiken om att skicka ut notifiering om "Hej! Jag har startat upp nu - och jag finns på denna adress" alternativt "Vill bara tala om att jag stängs ned nu...". Även detta är i WCF 4 implementerat med Standard Endpoints, vilket gör det väldigt enkelt att anamma.

Den lilla detaljen som jag måste beaktas är att Announcement-Endpointen måste definieras genom ett ServiceDiscovery-behavior. Men detta är allt som jag behöver göra på tjänstesidan.

<serviceBehaviors>
  <behavior>
    <serviceDiscovery>
      <announcementEndpoints>
        <endpoint kind="udpAnnouncementEndpoint" />
      </announcementEndpoints>
    </serviceDiscovery>
  </behavior>
</serviceBehaviors>

På konsumentsidan behöver jag instansiera AnnouncementService och lyssna på dess Events OnlineAnnouncementReceived och OfflineAnnouncementReceived för att kunna agera därefter. Jag behöver även exponera denna tjänst med en Announcement Standard Endpoint.

Konsument och Tjänst - och nu en Konsument som exponerar en Tjänst? Nja - Tjänster kan också vara konsumenter samt vice versa.

var announcementService = new AnnouncementService();

announcementService.OfflineAnnouncementReceived += (o, e) => 
    Console.WriteLine("Bye {0}", e.AnnouncementMessage.EndpointDiscoveryMetadata.Address);

announcementService.OnlineAnnouncementReceived += (o, e) =>
    Console.WriteLine("Hi! {0}", e.AnnouncementMessage.EndpointDiscoveryMetadata.Address);

Så om jag knyter an till mitt tidigare exempel med skrivaren - så får jag i detta fall en notifiering om att skrivaren stängs av.

Hela tiden i ovan exempel är det sk Ad Hoc Discovery (utan mellanhand) som används. Detta begränsar användandet till det lokala nätet då det är baserat på multicast meddelanden. För att möjliggöra Discovery över t ex Internet måste en sk Discovery Proxy Service implementeras. Denna tjänst är inget som vid skrivandets stund levereras färdigt utan måste implementeras manuellt med utgångspunkt från DiscoveryProxyBase. När man använder denna modell, med en Discovery Proxy , kallas det för Managed Discovery.

Att visa hur man implementerar en Discovery Proxy är utanför omfattningen av denna artikel.

Ladda ned ovan exempel här:

Introduktion till SOA Advanced Application Blocks

chrislof — Tue, 06 Oct 2009 21:19:32 GMT

SOA Advanced Application Blocks är en samling av applikationsblock (á la Enterprise Library) som är baserade på mönster som vi konsulter har samlat på oss, tillsammans med partners och kunder, genom engagemang vid framtagandet av tjänsteorienterade lösningar.

Applikationsblocken ämnar att hjälpa den enskilda utvecklaren vid implementeringen av applikationer som skall ingå i en tjänsteorienterad arkitektur genom att bidra med byggstenar för förmågor som ofta efterfrågas. Applikationsblocken kan användas tillsammans eller var för sig. Undantaget är Service Agent applikationsblocket som är beroende av Directory Service applikationsblocket.

Följande applikationsblock är del av SOA Advanced Application Blocks

Requestor Side Caching Application Block

Detta applikationsblock möjliggör caching av responsmeddelanden från tjänster och har stöd för både offline och online scenarion.

Directory Service Application Block

Detta applikationsblock möjliggör dynamisk namnupplösning av ändpunktsadresser från en central tjänstekatalog, vilket medför en lös koppling mellan klientapplikationen och den faktiska platsen för en ändpunkt.

Policy Service Application Block

Detta block möjliggör en centraliserad hantering av regler (läs Policy) som är associerade med tjänster. Dessa regler kan hanteras och appliceras på tjänster i runtime.

Service Agent Application Block

Tjänsteagenten (läs Service Agent) utökar det sk Proxy-mönstret genom att tillföra ytterligare förmågor med hjälp av de övriga applikationsblocken. Det gör det t ex möjligt för klienten att dynamiskt hitta platsen för en ändpunkt och därefter konfigurera bindningarna att möta kraven som ställs av tjänstens definierade regler.

Jag kommer i en artikelserie framöver gå in mer i detalj på varje enskilt applikationsblock.

Förenklad konfiguration med WCF 4

chrislof — Fri, 02 Oct 2009 21:43:00 GMT

När jag med WCF 3.x väljer att generera en Proxy med hjälp av svcutil eller Add Service Reference i Visual Studio så läggs det till en hel del konfiguration i .config-filen. Mycket av denna information kan jag, som oftast, ta bort. Det som minst måste vara kvar är definitionerna av den adress, binding och det kontrakt som tjänsten jag skall konsumera använder - vilket kan rymmas på tre rader. Men även dessa tre rader konfiguration är något som jag upplever som hinder för många för att vilja ta till sig WCF.

En glädjande nyhet för alla, oavsett om du hoppat på WCF tåget eller inte, är att vi med WCF 4 inte behöver ha ens ett system.serviceModel element i vår .config-fil för att göra en tjänst åtkomlig för konsumtion. Det är lite som med XP Mode i Windows 7 - det finns ingen anledning längre att inte uppgradera.

Default Endpoints

Grunden till detta är något som kallas för Default Endpoints - baserat på mitt val av protokollschema bygger WCF-stacken upp mina Endpoints automatiskt.

Titta på nedan exempel. Förutom tjänstekontraktet MotorbikeService är detta allt som min applikation nu består av. Ingen app.config för att definiera tjänsten eller dess Endpoints , och allt jag behöver göra i koden är att ange de URI:er där jag vill ha tjänsten exponerad.

static void Main(string[] args) {

    var host = new ServiceHost(typeof(MotorbikeService),
        new Uri("http://localhost:8080/bikeStore"),
        new Uri("net.tcp://localhost:8081/bikeStore"));
    host.Open();

    foreach (var endpoint in host.Description.Endpoints) {
        Console.WriteLine(string.Format("{0} - {1}", endpoint.Address, endpoint.Binding.Name));
    }

    Console.Read();
    host.Close();
}

När jag väljer att köra applikationen så ser vi också vilka Bindings WCF-stacken har valt åt mig, baserat på ändpunkternas protokollscheman.

Mappningarna mellan protokollschema och Binding är definierade i machine.config. Vill du t ex ändra standard Binding för http-schemat till en Binding med stöd för WS-* protokollen så kan du göra det på maskin nivå men också på applikationsnivå i app.config.

Nu, när jag går ifrån WCF:s standardkonventioner, behöver jag lägga till system.serviceModel-elementet i min app.config. Därefter ändrar jag mappningen från BasicHttpBinding till WS2007Binding i protocolMappings-elementet.

<system.serviceModel>
  <!-- ändra default binding för http-schemat till ws2007HttpBinding -->
  <protocolMapping>
    <add scheme="http" binding="ws2007HttpBinding"/>
  </protocolMapping>
</system.serviceModel>

Kör jag applikationen igen så ser vi att WCF-stacken nu bygger upp en WS2007Binding åt mig istället.

Alla mina tjänster som är exponerade över en HTTP-Endpoint kommer nu att använda WS2007Binding:en med dess standardinställningar. För att göra justeringar i dessa standardinställningar behövde jag i WCF 3.x överrida dem med en explicit Binding-konfiguration per Endpoint. Med WCF 4 kan jag nu överrida standardinställningarna på en Binding genom att definiera en namnlös Binding-konfiguration.

<system.serviceModel>
  <!-- ändra default binding för http-schemat till ws2007HttpBinding -->
  <protocolMapping>
    <add scheme="http" binding="ws2007HttpBinding"/>
  </protocolMapping>
  <bindings>
    <ws2007HttpBinding>
       <!-- flödande transaktioner som default -->
      <binding transactionFlow="true"/>
    </ws2007HttpBinding>
  </bindings>
</system.serviceModel>

Förenklad IIS hosting

För att husera WCF-tjänster i IIS:en så är vi vana vid att skapa en .svc-fil som pekar ut vilken tjänst som skall hantera förfrågan. Med WCF 3.x räckte det inte att skapa denna fil – vi var även tvungen att definiera minst en Endpoint i web.config. Detta är med WCF 4 historia - jag lägger dit min .svc-fil och är därmed klar att erbjuda tjänsten för konsumtion.

<%@ ServiceHost Service="ByeAsmx.MotorbikeService" %>

Om du minns min förra artikel om WCF 4 så har jag nu också ett frestande val att lägga till system.serviceModel-elementet i web.config och därmed slopa .svc-filen.

<system.serviceModel>
  <serviceHostingEnvironment>
    <serviceActivations>
      <add relativeAddress="/BikeStore" service="ByeAsmx.MotorbikeService"/>
    </serviceActivations>
  </serviceHostingEnvironment>
</system.serviceModel>

.svc-fil eller Address Activation för dina asmx-ersättare?

Exempelkod finns att ladda ned här.

Principer för tjänstedesign

chrislof — Sun, 27 Sep 2009 22:40:11 GMT

Nyttan med Tjänster är som störst när de återanvänds om och om igen. Detta är en av anledningarna till varför Webbtjänster (oftast SOAP/HTTP) är ett populärt sätt att implementera dessa Tjänster - det ger oss nåbarhet från många olika plattformar. Med nåbarheten kommer också möjligheten till återanvändning.

Allt för sällan finns det ett gemensamt register över tillgängliga tjänster. Men även om det skulle finnas ett register krävs det att man förhåller sig till ett antal principer för att hjälpa konsumenterna att hitta rätt tjänst och slutligen rätt operation(er) i detta register.

Jag har i denna artikel sammanställt de principer som jag anser är de viktigaste att anamma för att maximera återanvändningen av enskilda tjänster.

Namnge för konsumtion

Använd namn och begrepp som är bekanta för de som skall konsumera tjänsterna. Oftast är begrepp från den aktuella domänen mer meningsfulla för konsumenten än tekniska begrepp.

En tumregel kan också vara att använda substantiv till tjänstenamn och verb till operationsnamn.

public interface IManageMotorbikeData
{
    int InsertMotorbikeRecord();

    bool UpdateMotorbikeRecord();
}

Ovan: Tjänstedefinition som använder verb och IT-begrepp.

Nedan: Tjänstedefinition som använder substantiv och verb från verksamhetsdomänen.

public interface IMotorbikeService
{
    Motorbike CreateNewMotorbike();

    Parts UpgradeBikeWithCarbonParts(Motorbike motorbike);
}

Balansera antalet operationer per tjänst

Hitta en bra balans mellan antal tjänster och antal operationer per tjänst.

En tjänst blir ofta den enhet som testas och till slut släpps för konsumtion, vilket gör att tjänster med stort antal operationer kan påverka många konsumenter samt att de tar längre tid att testa och kvalitetssäkra. Har man istället många tjänster med få operationer per tjänst kan det bli svårare att hitta tjänsten med önskad operation.

Tjänsterna skall vara sammanhängande

Detta hänger till viss del ihop med föregående princip. Designa tjänsterna på så vis att dess operationer hör ihop. Vad som gör att de hänger ihop kan dock variera. Det kan t ex röra sig om;

Operationerna skall täcka de funktioner som behövs för att uppfylla ett scenario
Operationer som skall täcka de funktioner som kan utföras på en viss typ av entitet
En konsument har efterfrågat en tjänst med en specifik uppsättning operationer

Använd grovkorniga parametrar

Att definiera "grovkorniga" parametrar för en operation medför flera fördelar. För det första blir den enklare att använda. För det andra underlättare det kommande versionshantering av tjänstekontraktet då en förändring i datastrukturen inte behöver förändra signaturen på operationen.

int CreateNewMotorbike(string name, string brand, string color, double price);

Ovan: Finkorniga parametrar

Nedan: Grovkorniga parametrar

Motorbike CreateNewMotorbike(MotorbikeDetails newMotorbike);

Men tänk på..

När många i din organisation tycker att det fungerar kanon med Webbtjänster och vill ha mer och antalet konsumenter ökar - det är då problemen med konsumtion brukar uppenbara sig. Hur avvecklar vi en tjänst? Hur uppgraderar vi en tjänst från v1 till v2 utan att behöva uppdatera 20 konsumerande system? Rekommendationen är att samtidigt som du tar till dig ovan principer överväger att implementera ett virtualieringslager. Why Service Virtualization Matters är ett utmärkt whitepaper som introducerar dig till just detta.

Kom och prata Azure med mig på Microsoft Summit

chrislof — Mon, 07 Sep 2009 16:28:31 GMT

Den 1:a oktober huserar vi Microsoft Summit på Kistamässan.

Jag kommer finnas på plats under dagen för att diskutera dina tekniska frågor rörande Azure Services Platform.

- Hur migrerar vi bäst applikation x till Windows Azure?
- Skulle .NET Service Bus kunna hjälpa oss i sammanhang y?
- SQL Azure eller Windows Azure Storage?

Vill du vara helt säker på att få en pratstund med mig så rekommenderar jag att du bokar en tid.

REST med WCF 4 Beta 1

chrislof — Tue, 01 Sep 2009 18:07:00 GMT

Med WCF 4 introduceras en hel del nyheter. Denna artikel fortsätter på det REST-tema jag påbörjade tidigare och fokuserar specifikt på vad som är nytt i WCF 4 Beta 1 som hjälper oss i byggandet av REST-tjänster. Inte helt oväntat är det till stor del funktionalitet som vi känner igen från REST Starter Kit som nu hittat in i själva ramverket. Någonting säger mig att så kommer det också fortsatt vara vid Beta 2 lanseringen men, det är bara en personlig gissning.

Hjälpsida

Hjälpsidan är i själva verket en Atom Feed. De flesta Web Browsers har dock någon form av Feed läsare i sig, vilket du kan se i nedan exempel där Internet Explorer visar Feed:en i ett läsbart format, vilket gör att du väldigt enkelt kan se tjänstens exponerade resurser. Vidare ger hjälpsidan information om URI-format, responsformat, exempel på responstyper etc. Skriv in “help” efter tjänstens basadress för att visa hjälpsidan.

Då hjälpsidan är en Atom Feed innebär det också att du har möjlighet att programmatiskt prenumerera på hjälpsidans innehåll om du så önskar.

Men hur aktiverar man det då?

Saken är den att funktionen är aktiverad som standard. Det är webHttpBehavior som har begåvats med ytterligare en egenskap - enableHelp, vilken är satt till “true” som standard av WebServiceHost.

<endpointBehaviors>
  <behavior name="HelpBehavior">
    <webHttp enableHelp="true" />
  </behavior>
</endpointBehaviors>

WAS aktivering av tjänster utan .svc-fil.

RESTafarier kan inte tolerera URL:er som inte "ser snygga ut", eller är RESTfulla. De kommer gilla detta.

Med WCF 3.5 sker WAS aktivering av en tjänst mha en .svc fil, vilket i detta fall genererar en URI enligt nedan.

I WCF 4 kommer möjligheten att göra denna aktivering baserat på en relativ adress. I följande exempel har jag angivit att den relativa adressen "/Customers" skall aktivera min tjänst “CustomerService”. På så vis kan jag nu tydligare få till exponeringen av min kollektion av kunder.

Så, kasta din .svc fil och lägg till detta i web.config istället:

<serviceHostingEnvironment>
  <serviceActivations>
    <add relativeAddress="Customers" service="NoSvcFile.CustomerService" 
         factory="System.ServiceModel.Activation.WebServiceHostFactory"/>
  </serviceActivations>
</serviceHostingEnvironment>

HTTP Caching

En av fördelarna med REST är att du kan dra nytta av HTTP infrastruktur för Caching, t ex IIS:ens output cache. Detta sker i WCF 4 med en integration gjord till ASP.NET:s Caching förmågor. Med det nya attributet AspNetCacheProfile kan du ange vilken Cache Profile du vill använda för specifik operation.

[OperationContract]
[WebGet]
[AspNetCacheProfile("defaultCacheProfile")]
public List<Customer> GetCustomers() {

Definiera sedan Cache Profilen i web.config som vanligt.

<system.web>
  <compilation debug="true" targetFrameworkMoniker=".NETFramework,Version=v4.0"/>
  <caching>
    <outputCacheSettings>
      <outputCacheProfiles>
        <add name="defaultCacheProfile" duration="10" varyByParam="*"/>
      </outputCacheProfiles>
    </outputCacheSettings>
  </caching>
</system.web>

Exempelkod

Ladda ned exempel för ovan här:

Kanban med Team Foundation Server på 15 minuter

chrislof — Wed, 12 Aug 2009 00:46:00 GMT

Det börjar ploppa upp en del verktyg på nätet för att hålla koll på sina projekt med hjälp av ett sk Kanban Board. Idén i sig härstammar från Taiichi Ohno's produktionssystem med ursprung hos Toyota. Jag dyker inte in djupare än så i historien och mina tankarna kring Kanban och Lean. Med denna artikel vill jag bara påvisa att man kan tillämpa detta även med Team Foundation Server. Jag visar här hur du med enkla sätt kan skapa er ett Kanban Board utan att behöva bygga processmallar och liknande. Allt som krävs är lite Reporting Services kunskap.

-Ett Kanban Board tack.
-15 minuter en kvart kompis.

Go!

0 min

Teamprojekt baserat på processmallen MSF for Agile Software Development 5.0 finns skapat sedan tidigare. Jag är även med i nödvändiga SQL roller.

1 min

Jag sätter upp Areas och Iterations för att använda som processteg och User Story status.

Siffran innan namnet på processteget är endast till för sorteringens skull i rapporten. Siffran inom parantes anger gränsvärdet för maximalt antal User Stories för det steget. Stegen och gränsvärdena är helt plockade ur luften för denna demonstrations skull!

2 min

Jag skapar ett Report Server projekt ...

... och en rapport.

2:30 min

Jag lägger till en datakälla till rapporten...

... och ett Dataset.

Som fråga för Dataset:et anger jag SQL utrycket:

SELECT 
    System_Id, 
    System_Title,
    IterationName,
    AreaName,
    System_AssignedTo,
    Microsoft_VSTS_Scheduling_StoryPoints,
    Microsoft_VSTS_Common_StackRank
FROM
    CurrentWorkItemView
WHERE
    System_WorkItemType = 'User Story' AND
    System_State = 'Active'
ORDER BY
    ISNULL(Microsoft_VSTS_Common_StackRank,9999),
    System_Id

4 min

Dags att bygga rapporten!

Jag släpar först ut en List-kontroll från verktygslådan. Sedan tar jag bort ev Row Group och lägger till fältet IterationName som en Column Group.

Jag släpar sedan ut ytterligare en List-kontrol som jag lägger i detaljarean på den första listan. Denna skall lista alla User Stories för aktuellt processteg.

I listan lägger jag sedan en Rectangle-kontroll för som skall agera Story Card. I denna Rectangle-kontroll lägger jag fälten System_Id, System_Title, Assigned_To och Microsoft_VSTS_Scheduling_StoryPoints. Jag har nu en rapport som i designern ser ut på följande sätt:

7 min

Att illustrera statusen på en User Story väljer jag att göra genom att sätta bakgrundsfärgen på Rectangle-kontrollen. Är Story:n Blocked, dvs ingen gör något annat än att försöka lösa problemet, skall bakgrunden vara röd. Är Story:n Ready, dvs någon kan ta Story:n vidare till "sitt" steg, skall bakgrunden vara grön. I övriga skall bakgrunden vara gul.

Detta löser jag genom att ange ett utryck för Rectangle-kontrollens bakgrundsfärg.

=IIf(Fields!AreaName.Value = "Blocked", "Firebrick", IIf(Fields!AreaName.Value = "Ready", "PaleGreen", "Khaki"))

9 min

Sätter lite kantfärger och fontstilar.

För att kunna klicka på en User Story och därmed få fram aktuellt Work Item, sätter jag Action egenskapen på System_Title textboxen till Go to URL. URL:en jag anger är till TFS Web Access Work Item Editor.

="javascript:void(window.open('http://tfs/sites/DefaultCollection/project/_layouts/tswa/UI/Pages/WorkItems/WorkItemEdit.aspx?id=" & Fields!System_Id.Value & "'))"

11 min

Deploy till Reporting Services. Inga konstigheter.

13 min

Jag möblerar om på projektets standard Dashboard.

15 min

Klart!

TFS måste vara det bästa sedan skivat bröd?