IDG.se skrev för ett litet tag sedan en artikel om kopplingen mellan virtualisering och SOA som jag antar byggde på den här artikeln i eWeek.com. Den följdes upp av ett antal kommentarer som visar på god SOA-förståelse i landet. Här är lite citat som är viktiga för förståelsen av en SOA.
"SOA kan jämföras med hårdvaruvirtualisering eftersom (som zixleg säger) båda teknikerna klipper beroendet till underliggande "lager"."
"Hypervisorn virtualiserar över hårdvaran, CLR & JRE virtualiserar över OS och SOA virtualiserar (något filosofiskt, men ändå) över applikationer."
"Det får samma fördelar med SOA som det ger med hårdvaruvirtualisering:
1. hög användingsgrad av resurserna
2. hög återanvändning av resurserna
3. hög managerbarhet över resurserna
4. hög förändringsbarhet av resursanvändningen"
"Det är ingen poäng att hosta soa lösningar i virtualiserade miljöer mer än det skulle vara för någon annan arkitektur ... dvs att hårdvaruvirtualisering inte är en möjliggörare för soa"
Jämförelsen mellan virtualisering och SOA pekade jag på tidigare i tre inlägg och anser att tillsammans (inte beroende av varandra dock) bidrar de tungt till en god Execution Foundation i en EA.
torsdag, juli 26, 2007
onsdag, juli 25, 2007
Fler definitioner på SOA
Det pratas mer och mer SOA och ju mer det pratas SOA desto fler definitioner av SOA blir det.
Här är Microsofts syn på SOA i ett rykande färskt dokument.
Jag tycker nog min arbetsgivares definition är korrekt:
A loosely-coupled architecture designed to meet the business needs of the organization.
Och att min egen från 2005 (Vägen till tjänstebaserad arkitektur) inte är helt fel ute, än så länge:
En arkitektur som bygger på samverkan mellan små självfungerande tjänster som är definierade av verksamhetsprocesser och baserade på standardiserad teknologi.
Här är Microsofts syn på SOA i ett rykande färskt dokument.
Jag tycker nog min arbetsgivares definition är korrekt:
A loosely-coupled architecture designed to meet the business needs of the organization.
Och att min egen från 2005 (Vägen till tjänstebaserad arkitektur) inte är helt fel ute, än så länge:
En arkitektur som bygger på samverkan mellan små självfungerande tjänster som är definierade av verksamhetsprocesser och baserade på standardiserad teknologi.
torsdag, juli 19, 2007
Pattern-ister och GPSer
Jag skaffade en HTC 3300 för några veckor sedan. Den är utrustad med en GPS som jag var tvungen att pröva så fort som möjligt. Jag brukar köra inne i stan (Stockholm) som jag bott i i nu snart 15 år. Jag kan de flesta gator i centrum, men eftersom jag nu köpt en GPS så måste den ju användas.
En gång skulle jag åka mellan Kaptensgatan och Floragatan en vanlig vardagseftermiddag runt 4-tiden. GPSen föreslog att jag skulle åka ned på Strandvägen, ta Birgerjarlsgatan till Stureplan och sedan Sturegatan, Karlavägen, Floragatan. Öhh ... den vägen kändes inte rätt, varför valde den den mest trafikerade vägen så här dags. Den var inte ens kortast och definitivt inte snabbast. Jag körde istället upp direkt på Karlavägen bort till Floragatan och tjänade säkert en kvart på det.
Det slog mej senare att precis så här används Design Patterns i utvecklingsprojekt.
Istället för att tänka själva så kör man pattern-bingo bland utvecklarna. Istället för att tänka själv så name droppas det patterns som resulterar i omvägar, felsatsningar och tidsförluster. I många fall knuffas talang och erfarenhet undan till fördel för pattern-ister.
Det är viktigt att tänkande individer som kan programmering får det utrymme de förtjänar och att utvecklarnas GPSer (patterns) används sparsamt och inte blir till en överdrift.
En gång skulle jag åka mellan Kaptensgatan och Floragatan en vanlig vardagseftermiddag runt 4-tiden. GPSen föreslog att jag skulle åka ned på Strandvägen, ta Birgerjarlsgatan till Stureplan och sedan Sturegatan, Karlavägen, Floragatan. Öhh ... den vägen kändes inte rätt, varför valde den den mest trafikerade vägen så här dags. Den var inte ens kortast och definitivt inte snabbast. Jag körde istället upp direkt på Karlavägen bort till Floragatan och tjänade säkert en kvart på det.
Det slog mej senare att precis så här används Design Patterns i utvecklingsprojekt.
Istället för att tänka själva så kör man pattern-bingo bland utvecklarna. Istället för att tänka själv så name droppas det patterns som resulterar i omvägar, felsatsningar och tidsförluster. I många fall knuffas talang och erfarenhet undan till fördel för pattern-ister.
Det är viktigt att tänkande individer som kan programmering får det utrymme de förtjänar och att utvecklarnas GPSer (patterns) används sparsamt och inte blir till en överdrift.
tisdag, juli 10, 2007
BPEL4People bjuder in människor
BPEL4People är en specification som gör det möjligt att dela ut Tasks till personer i en arbetsprocess implementerad i WS-BPEL. Jag har prövat ActiveEndpoints Enterprise plugin för BPEL4People och visst skapar det möjligheter med utökningen av språket.
Vad det går ut på är att någonstans i processen så ska en aktivitet utföras av en person. Personen ingår i en grupp av personer som har samma roll. Det kan vara en låneutgivare på en bank som ska utföra en kreditkontroll (aktiviteten) i en låneansökan (processen). När aktiviteten exekveras så notifieras gruppen (rollen) att en ny uppgift har skickats.
Sedan loggar valfri låneutgivare in och får mer information om uppgiften och kanske därefter antar uppgiften. När uppgiften är utförd så matar låneutgivaren in eventuell respons och skickar tillbaka kontrollen till processen. Självfallet kan BPEL4People även ta hand om undantag och felhantering.
Vad det går ut på är att någonstans i processen så ska en aktivitet utföras av en person. Personen ingår i en grupp av personer som har samma roll. Det kan vara en låneutgivare på en bank som ska utföra en kreditkontroll (aktiviteten) i en låneansökan (processen). När aktiviteten exekveras så notifieras gruppen (rollen) att en ny uppgift har skickats.
Sedan loggar valfri låneutgivare in och får mer information om uppgiften och kanske därefter antar uppgiften. När uppgiften är utförd så matar låneutgivaren in eventuell respons och skickar tillbaka kontrollen till processen. Självfallet kan BPEL4People även ta hand om undantag och felhantering.
tisdag, juli 03, 2007
Processorienterad design
Jag hade en diskussion med Fredrik Normén idag där en intressant fråga kom upp. Antag en inköpsprocess där en av aktiviteterna ska notifiera chefen om att en ny order ska attesteras. Notifieringen skall ske via email, men en kodare känner igen diskussionen och vet att inom kort ska kanske ett annat sätt hantera notifieringen som exempelvis via SMS-meddelande. Frågan vi ställde oss var om man 1) ska skapa en specifik aktivitet för varje scenario som man i processen byter ut när kraven ändras eller 2) en generell aktivitet som kan hantera notifiering rent allmänt så att implementationen av processen alltid förblir densamma.
Det självklara svaret kan anses vara att man borde skriva en generell aktivitet som kan hantera olika transportsätt. Men eftersom processmotorer är byggda för att just kunna modifera processerna så borde det första alternativet inte ge något overhead vid förändring. Det kan till och med vara tydligare att i processen kunna se hur meddelandet ska skickas.
Jag skulle nog i alla fall vilja påstå att just styrkan med kombinationen av tjänster och process hantering skapar den bästa lösningen. Nedan så implementeras processen med en generell notifieringsaktivitet. Självfallet ska inte implementationen av aktiviteten köras inne i processmotorn utan skickas som ett service anrop via ett Mediation Layer, en Enterprise Service Bus (ESB). Däri ligger ansvaret för att hantera hur meddelandet ska nå användaren vilket kontrolleras genom policies för notifieringstjänsten.
För processen finns det inga fysiska tjänster att tillgå, utan enbart virtuella tjänster som exponeras genom ESB:n. Inne i bussen routas meddelandet beroende på innehåll och yttre omständigheter samt transformeras för att passa just det transportsättet och den mottagaren av den fysiska implementationen av notifieringstjänsten. Det här är en klassisk kombination av Business Process Management och Service Oriented Architecture som visar vad som ligger inom respektive arkitekturs ansvarsområde.
Det självklara svaret kan anses vara att man borde skriva en generell aktivitet som kan hantera olika transportsätt. Men eftersom processmotorer är byggda för att just kunna modifera processerna så borde det första alternativet inte ge något overhead vid förändring. Det kan till och med vara tydligare att i processen kunna se hur meddelandet ska skickas.
Jag skulle nog i alla fall vilja påstå att just styrkan med kombinationen av tjänster och process hantering skapar den bästa lösningen. Nedan så implementeras processen med en generell notifieringsaktivitet. Självfallet ska inte implementationen av aktiviteten köras inne i processmotorn utan skickas som ett service anrop via ett Mediation Layer, en Enterprise Service Bus (ESB). Däri ligger ansvaret för att hantera hur meddelandet ska nå användaren vilket kontrolleras genom policies för notifieringstjänsten.
För processen finns det inga fysiska tjänster att tillgå, utan enbart virtuella tjänster som exponeras genom ESB:n. Inne i bussen routas meddelandet beroende på innehåll och yttre omständigheter samt transformeras för att passa just det transportsättet och den mottagaren av den fysiska implementationen av notifieringstjänsten. Det här är en klassisk kombination av Business Process Management och Service Oriented Architecture som visar vad som ligger inom respektive arkitekturs ansvarsområde.
Varför blogga?
För ett lite tag sedan på .NET Rocks kunde man lyssna till Don Box och Chris Sells när dom diskuterade lärande med Carl and Richard. Både Don och Chris är bloggare som många andra, även undertecknad. I samtalet kom frågan upp varför man överhuvudtaget skriver, oavsett arena (bok, tidning, blog, etc). Jag funderade på några anledningar till varför folk bloggar.
1. Du lär dig saker genom att skriva
2. Du vill dela med dig av din kunskap
3. Du vill dokumentera dina tankar som en öppen dagbok
4. Du vill skapa debatt
5. Du vill göra avtryck i historien
6. Du vill använda det i ditt CV
7. Du är upprörd och vill berätta din åsikt
8. Du vill framföra dina åsikter genom att provocera
9. Du har något att berätta men kan inte utttrycka dig verbalt
10. Du har något att berätta men vill inte skriva en bok
11. Du "tycker om att skriva"
12. Du vill få ett kvitto på dina åsikter
13. Du vill "skriva av dig" så du kan glömma och gå vidare (terrapi)
14. Du skapar material som du vill ha kommentarer på och som senare kan användas i en bok du vill skriva
15. Tjäna pengar på bl a Google Ads
16. Imponera på din arbetsgivare
17. Du har en narcissistisk störning och vill synas
Även om de flesta punktern handlar om lärande och självförverkligande så finns det en stor mängd bloggar som skapar debatt och leder till diskussion. Det tycker jag blogging är bäst på och det är där bloggen skiljer sig från boken.
1. Du lär dig saker genom att skriva
2. Du vill dela med dig av din kunskap
3. Du vill dokumentera dina tankar som en öppen dagbok
4. Du vill skapa debatt
5. Du vill göra avtryck i historien
6. Du vill använda det i ditt CV
7. Du är upprörd och vill berätta din åsikt
8. Du vill framföra dina åsikter genom att provocera
9. Du har något att berätta men kan inte utttrycka dig verbalt
10. Du har något att berätta men vill inte skriva en bok
11. Du "tycker om att skriva"
12. Du vill få ett kvitto på dina åsikter
13. Du vill "skriva av dig" så du kan glömma och gå vidare (terrapi)
14. Du skapar material som du vill ha kommentarer på och som senare kan användas i en bok du vill skriva
15. Tjäna pengar på bl a Google Ads
16. Imponera på din arbetsgivare
17. Du har en narcissistisk störning och vill synas
Även om de flesta punktern handlar om lärande och självförverkligande så finns det en stor mängd bloggar som skapar debatt och leder till diskussion. Det tycker jag blogging är bäst på och det är där bloggen skiljer sig från boken.
Prenumerera på:
Inlägg (Atom)