torsdag, augusti 31, 2006
In english
Jag har skapat en blog på engelska med samma innehåll för att kunna nå en större publik från 3 stycken personer till förhoppnings fler :|
onsdag, augusti 16, 2006
Virtualisering III
Vad man vill sträva efter är att virtualisera till den grad att det är hanterbart, vilket det inte riktigt är på objektnivån som virtualiseras i JVM eller CLR.
En annan virtualiseringsnivå än den JVM och CLR bidrar till är Web Services (WS). WS har en mycket speciell förmåga att virtualisera eftersom oberoendet är implementerat i det som kopplar samman WS i arkitekturen. Oberoendet finns i protokollet som binder samman Web Services istället för en runtime som WMware, Virtual Server, CLR och JVM baseras på.
Web Services sägs även kunna virtualisera funktioner i ett företag, dvs tjänster som ingår i en SOA. Genom SOA blir nyttjandegraden av funktioner i en IT-miljö väldigt hög samtidigt som rörligheten och möjligheten att hantera Web Service är i fokus.
En annan virtualiseringsnivå än den JVM och CLR bidrar till är Web Services (WS). WS har en mycket speciell förmåga att virtualisera eftersom oberoendet är implementerat i det som kopplar samman WS i arkitekturen. Oberoendet finns i protokollet som binder samman Web Services istället för en runtime som WMware, Virtual Server, CLR och JVM baseras på.
Web Services sägs även kunna virtualisera funktioner i ett företag, dvs tjänster som ingår i en SOA. Genom SOA blir nyttjandegraden av funktioner i en IT-miljö väldigt hög samtidigt som rörligheten och möjligheten att hantera Web Service är i fokus.
Virtualisering II
Från förra bloggen om virtualisering så kan man ta med sig att virtualisering skapar ett oberoende till underliggande arkitektur som ger bättre rörlighet och resursutnyttjande genom metoder och verktyg för hantering av instanser som nyttjar de virtualiserade resurserna.
Frågan är nu på vilken nivå man ska virtualisera för att uppnå bättre rörlighet och resursutnyttjande?
Det finns flera nivåer av virtualisering och den enda förmågan en virtualiseringnivå måste ha är att den skapar ett oberoende till underliggande arkitektur. Det som de sedan skiljer dem åt är förmågan att låta sig hanteras. Operativsystem som kan köras i virtuella miljöer är en nivå där man kan uppnå ett högt resursutnyttjande av hårdvaran, men ett lågt resursutnyttjande av funktioner i operativsystemet. De olika s k gästerna i en hårdvaruvirtualiserad miljö är helt isolerade från varandra och delar inget annat än den underliggande hårdvaran.
Hårdvaruvirtualisering används främst då man inte vill röra de applikationer som kör på ett operativsystem. Har man däremot möjlighet att virtualisera på en högre nivå så ska man göra det eftersom det ger ett ännu bättre resursutnyttjande. Bättre resursutnyttjande är positivt i många bemärkelser, men kan ställa till problem i andra. Önskar man isolerade miljöer så ska man antingen inte virtualisera eller göra det på en hög nivå.
Frågan är nu på vilken nivå man ska virtualisera för att uppnå bättre rörlighet och resursutnyttjande?
Det finns flera nivåer av virtualisering och den enda förmågan en virtualiseringnivå måste ha är att den skapar ett oberoende till underliggande arkitektur. Det som de sedan skiljer dem åt är förmågan att låta sig hanteras. Operativsystem som kan köras i virtuella miljöer är en nivå där man kan uppnå ett högt resursutnyttjande av hårdvaran, men ett lågt resursutnyttjande av funktioner i operativsystemet. De olika s k gästerna i en hårdvaruvirtualiserad miljö är helt isolerade från varandra och delar inget annat än den underliggande hårdvaran.
Hårdvaruvirtualisering används främst då man inte vill röra de applikationer som kör på ett operativsystem. Har man däremot möjlighet att virtualisera på en högre nivå så ska man göra det eftersom det ger ett ännu bättre resursutnyttjande. Bättre resursutnyttjande är positivt i många bemärkelser, men kan ställa till problem i andra. Önskar man isolerade miljöer så ska man antingen inte virtualisera eller göra det på en hög nivå.
Virtualisering I
En IT-guy förknippar virtualization med produkter som VMware och MS Virtual Server medan en utvecklare främst tänker på JVM eller CLR. Vad båda försöker uppnå är att abstrahera bort ett beroende mellan två nivåer i arkitekturen. IT-killen virtualiserar för att på en operativsystemnivå skapa ett oberoende till underliggande hårdvara, medan kodaren skapar ett oberoende till underliggande operativsystem.
Oberoendet till underliggande arkitektur gör att man dels skapar än bättre rörlighet men även möjligheten till bättre resursutnyttjande. Rörligheten får man på grund av den lösa kopplingen som en instans eller objekt har till den underliggande arkitekturen. Graden av resursuttnyttjandet förbättras genom möjligheten att hantera den virtualiserade arkitekturen.
Hårdvara är inte en bristvara idag och det är inte dyrt att köpa. Men kostnaden för att hantera nyttjandet av hårdvaran är dyr samt att det är ett problem att migrera från äldre hårdvara till nyare. Virtualisering kopplar loss beroendet men bidrar även tillsammans med metoder och verktyg till en flexiblare hantering av resurserna.
Metoderna och verktygen handlar om att skapa en brygga mellan det IT-killen gör om dagarna och det utvecklarna hade i tanken med sin programvara. Microsoft kallar det för Managing Dynamic Systems och bygger upp ett förhållningssätt kring det som kallas Dynamic Systems Initiative (DSI). Till DSI kopplas ett antal modeller som ska supportera DSI beroende på vad som ska hanteras i en IT-miljö. En av modellerna är System Definition Model (SDM) som ska bidra till DSI för hantering av applikationer i distribuerade miljöer. En annan modell är Service Modeling Language (SML) som avser hantering av WS-* tjänster. Verktyg som bidrar till hanteringen är Microsoft Operations Manager och Virtual Machine Manager.
Oberoendet till underliggande arkitektur gör att man dels skapar än bättre rörlighet men även möjligheten till bättre resursutnyttjande. Rörligheten får man på grund av den lösa kopplingen som en instans eller objekt har till den underliggande arkitekturen. Graden av resursuttnyttjandet förbättras genom möjligheten att hantera den virtualiserade arkitekturen.
Hårdvara är inte en bristvara idag och det är inte dyrt att köpa. Men kostnaden för att hantera nyttjandet av hårdvaran är dyr samt att det är ett problem att migrera från äldre hårdvara till nyare. Virtualisering kopplar loss beroendet men bidrar även tillsammans med metoder och verktyg till en flexiblare hantering av resurserna.
Metoderna och verktygen handlar om att skapa en brygga mellan det IT-killen gör om dagarna och det utvecklarna hade i tanken med sin programvara. Microsoft kallar det för Managing Dynamic Systems och bygger upp ett förhållningssätt kring det som kallas Dynamic Systems Initiative (DSI). Till DSI kopplas ett antal modeller som ska supportera DSI beroende på vad som ska hanteras i en IT-miljö. En av modellerna är System Definition Model (SDM) som ska bidra till DSI för hantering av applikationer i distribuerade miljöer. En annan modell är Service Modeling Language (SML) som avser hantering av WS-* tjänster. Verktyg som bidrar till hanteringen är Microsoft Operations Manager och Virtual Machine Manager.
måndag, augusti 14, 2006
SOA möjliggör BPM
Ismael Ghalimi skrev för inte länge sedan en liten notis som jag snappade upp hur han ser på relationen mellan SOA och BPM. Nu utvecklar han sitt resonemang och det finns riktigt intressanta delar där för den som följer hur SOA och BPM växer fram som de två stora giganterna av buzzwords.
Värt att notera är att leverantörer av SOA-verktyg (ESB) ser BPM som en del av en SOA, medan BPM-folket ser SOA som en möjliggörare för BPM.
Värt att notera är att leverantörer av SOA-verktyg (ESB) ser BPM som en del av en SOA, medan BPM-folket ser SOA som en möjliggörare för BPM.
lördag, augusti 05, 2006
Det är A:et i SOA som gör det!
Om A:et i SOA står för den arkitektur som ger hanterbarheten av dina tjänster, innebär det då att enbart SO står för anarki? Ja, är det korta svaret jag har. Det långa är att SO har en historia, inte så lång, men väldigt ärorik. SO fick t o m ett antal lärosatser eller axiom som i många sammanhang fick alldeles för stor betydelse. SO slog på kort tid sönder och samman OO som programmeringsmodell för distribuerade system. Det gjordes så bra att OOA inte fick en chans att bekänna färg mot SOA. Men egentligen har SO S:et att tacka för framgångarna, eftersom S:et lade grunden till segern.
S står egentligen för WS. Normalt sätt är det ingen som pratar om S:et i någon annan bemärkelse än WS och är det någon som gör det så anses det vara av akademiskt betydelse. Ser man till WS historia så är det där man kan hitta svaret på framgången, nämligen W. Egentligen är det i W (som i Web eller i folkmun WWW) som vi hittar sanningen bakom framgångssagan. WWW har öppnat dörren för SO som programmeringsmodell och gjort den till vad den är idag. Det är WWW som SO bygger sitt fundament uppå.
WWW, ett virrvarr av hemsidor som slukat mängder av domänadresser, upptagit miljoner IP-adresser, konsumerat enorma mängder bandbredd, påverkat ungdomar negativt. Ja, listan kan göras lång för det är en anarki som råder där. WWW var en disruptiv teknologi som slog undan benen på allt och skapade en ny värld av möjligheter. Nu är vi på samma nivå med en teknik för distribuerade system som alla världens kritiska affärssystem och transaktionssystem ska använda in i framtiden. Är det så illa? Nej, är det korta svaret. Det långa är ja, om vi låter anarkin få fortsätta råda. Låt istället varje S vara en del av en SOA, tänk WWW när du bygger dina applikationer med SO men glöm aldrig att det är A:et i SOA som gör det.
S står egentligen för WS. Normalt sätt är det ingen som pratar om S:et i någon annan bemärkelse än WS och är det någon som gör det så anses det vara av akademiskt betydelse. Ser man till WS historia så är det där man kan hitta svaret på framgången, nämligen W. Egentligen är det i W (som i Web eller i folkmun WWW) som vi hittar sanningen bakom framgångssagan. WWW har öppnat dörren för SO som programmeringsmodell och gjort den till vad den är idag. Det är WWW som SO bygger sitt fundament uppå.
WWW, ett virrvarr av hemsidor som slukat mängder av domänadresser, upptagit miljoner IP-adresser, konsumerat enorma mängder bandbredd, påverkat ungdomar negativt. Ja, listan kan göras lång för det är en anarki som råder där. WWW var en disruptiv teknologi som slog undan benen på allt och skapade en ny värld av möjligheter. Nu är vi på samma nivå med en teknik för distribuerade system som alla världens kritiska affärssystem och transaktionssystem ska använda in i framtiden. Är det så illa? Nej, är det korta svaret. Det långa är ja, om vi låter anarkin få fortsätta råda. Låt istället varje S vara en del av en SOA, tänk WWW när du bygger dina applikationer med SO men glöm aldrig att det är A:et i SOA som gör det.
WCF - för bra för ditt eget bästa?
Windows Communication Foundation (WCF) kommer att vara den mest utbyggbara implementationen av en Web Service stack som sätt ljuset när den till slut släpps med .NET Framework 3.0. Med WCF är det möjligt att förändra hela sekvensen som ett meddelande går igenom, från början av en endpoint ned till implementationen.
Men bara för att det är möjligt så betyder det inte att man ska använda sig av den möjligheten. Har det varit något du intresserat dig av tidigare när du exempelvis programmerade COM-objekt? Det var inte ofta man behövde implementera custom marshalling för att på så vis kunna styra över serialisering, encoding, routing, säkerhet i DCOM. Lita på mej, det är inte något som bör intressera dig (som tjänsteutvecklare) nu heller, även om det är lika enkelt som att andas luft (jämfört med DCOM).
Vad som däremot är intressant när man har ett antal tjänster är att skapa en SOA som bygger på att man kan administrera sina tjänster på en högre nivå och då kommer fördelarna med WCF in i bilden. I en SOA är det viktigt att kunna skapa nya versioner (förändra address, binding, etc) av tjänster. Man vill även kunna skapa virtuella kontrakt som passar en grupp av konsumenter. Routing, för att kunna distribuera anropen baserat på policies eller andra villkor. Transformering, att kunna modifiera meddelandet på vägen genom WS-stacken. Det är mängder av olika anledningar (och jag ska återkomma till fler framöver) till att kunna hantera sina tjänster och det är det som är anledningen till att WCF är så flexibelt.
Motsatsen till en SOA är att ha lite tjänster här och lite tjänster där, vilket tillslut blir ohanterligt. Det betyder heller inte att man ska bygga administrativa verktyg genom möjligheterna med flexibiliteten i bl a WCF. Det finns sådana produkter och det är dessa man ska använda sig av. Amberpoint är en leverantör av administrativa produkter för en SOA som även kan skapa hooks till andra implementationer än WCF. På så sätt får man en central dashboard av funktioner för att administrera sina tjänster oavsett plattform. Tillskillnad från Amberpoint så finns det produkter (BizTalk, Enterprise Service Bus) som kräver att alla tjänster ska implementeras i verktyget för att kunna administrera dom, vilket inte är troligt att man önskar i en heterogen värld.
Så tipset är att bygga tjänster som är hanterbara och där kontrollen ligger i verktyg som administrerar dina tjänster och inte i genom hemmasnickrade hooks till WCF.
Men bara för att det är möjligt så betyder det inte att man ska använda sig av den möjligheten. Har det varit något du intresserat dig av tidigare när du exempelvis programmerade COM-objekt? Det var inte ofta man behövde implementera custom marshalling för att på så vis kunna styra över serialisering, encoding, routing, säkerhet i DCOM. Lita på mej, det är inte något som bör intressera dig (som tjänsteutvecklare) nu heller, även om det är lika enkelt som att andas luft (jämfört med DCOM).
Vad som däremot är intressant när man har ett antal tjänster är att skapa en SOA som bygger på att man kan administrera sina tjänster på en högre nivå och då kommer fördelarna med WCF in i bilden. I en SOA är det viktigt att kunna skapa nya versioner (förändra address, binding, etc) av tjänster. Man vill även kunna skapa virtuella kontrakt som passar en grupp av konsumenter. Routing, för att kunna distribuera anropen baserat på policies eller andra villkor. Transformering, att kunna modifiera meddelandet på vägen genom WS-stacken. Det är mängder av olika anledningar (och jag ska återkomma till fler framöver) till att kunna hantera sina tjänster och det är det som är anledningen till att WCF är så flexibelt.
Motsatsen till en SOA är att ha lite tjänster här och lite tjänster där, vilket tillslut blir ohanterligt. Det betyder heller inte att man ska bygga administrativa verktyg genom möjligheterna med flexibiliteten i bl a WCF. Det finns sådana produkter och det är dessa man ska använda sig av. Amberpoint är en leverantör av administrativa produkter för en SOA som även kan skapa hooks till andra implementationer än WCF. På så sätt får man en central dashboard av funktioner för att administrera sina tjänster oavsett plattform. Tillskillnad från Amberpoint så finns det produkter (BizTalk, Enterprise Service Bus) som kräver att alla tjänster ska implementeras i verktyget för att kunna administrera dom, vilket inte är troligt att man önskar i en heterogen värld.
Så tipset är att bygga tjänster som är hanterbara och där kontrollen ligger i verktyg som administrerar dina tjänster och inte i genom hemmasnickrade hooks till WCF.
torsdag, augusti 03, 2006
Är SOA vägen till instabilitet?
Jag tänkte säga emot mig själv i den här posten angående förträffligheten med en SOA.
SOA är arkitekturen som ska göra delarna i arkitekturen nåbara, återanvändbara och hanterbara. De två första målen är inte så nya inom mjukvaruindustrin eftersom alla typer av distribuerade teknologier har strävat efter att göra komponenter nåbara på ett nätverk eller mellan processer och återanvändbara för andra applikationer. Däremot så är hanterbarhet något som en SOA ska uppfylla och göra möjligt, men är det något gott eller kan det missbrukas?
Med hanterbarhet menas möjligheten att centralt kunna gruppera sina tjänster, versionshantera, styra om, ändra policy, binding, adress, etc baserat på meta-information för varje tjänst. Hanterbarhet eftersträvas för att få en lättrörlighet och god ordning av alla länkar mellan delarna i arkitekturen.
Hanterbarhet kan göras omöjligt genom hårdkodning, hårda kopplingar mellan komponenter och properitära format. Hårdkoda som att spara adressen till en COM komponent eller Connection String i koden. Hårda kopplingar som mellan två komponenter med samma typsystem. Properitära format som mellan två komponenter som pratar RMI över IIOP.
Web Service är en nödvändighet för en SOA eftersom det möjliggör hanterbarhet. Men är det hanterbarhet vi vill ha? Vem är det som kommer att hantera alla kopplingar som tidigare var gömda i en svart låda. Har man inte alltid sagt att "rör inte det som fungerar"?
Tänk dig en framtid där alla kopplingar mellan tjänster kan administreras från en punkt. Där ska då IT-gubbarna (kanske till och med affärsfolk) sitta och mecka runt med dina tjänster och byta policies on-the-fly. Är det överhuvudtaget mänskligt att kunna administrera IT på det här viset, eller är det bara en utopi som istället kommer visa vägen till instabilitet?
SOA är arkitekturen som ska göra delarna i arkitekturen nåbara, återanvändbara och hanterbara. De två första målen är inte så nya inom mjukvaruindustrin eftersom alla typer av distribuerade teknologier har strävat efter att göra komponenter nåbara på ett nätverk eller mellan processer och återanvändbara för andra applikationer. Däremot så är hanterbarhet något som en SOA ska uppfylla och göra möjligt, men är det något gott eller kan det missbrukas?
Med hanterbarhet menas möjligheten att centralt kunna gruppera sina tjänster, versionshantera, styra om, ändra policy, binding, adress, etc baserat på meta-information för varje tjänst. Hanterbarhet eftersträvas för att få en lättrörlighet och god ordning av alla länkar mellan delarna i arkitekturen.
Hanterbarhet kan göras omöjligt genom hårdkodning, hårda kopplingar mellan komponenter och properitära format. Hårdkoda som att spara adressen till en COM komponent eller Connection String i koden. Hårda kopplingar som mellan två komponenter med samma typsystem. Properitära format som mellan två komponenter som pratar RMI över IIOP.
Web Service är en nödvändighet för en SOA eftersom det möjliggör hanterbarhet. Men är det hanterbarhet vi vill ha? Vem är det som kommer att hantera alla kopplingar som tidigare var gömda i en svart låda. Har man inte alltid sagt att "rör inte det som fungerar"?
Tänk dig en framtid där alla kopplingar mellan tjänster kan administreras från en punkt. Där ska då IT-gubbarna (kanske till och med affärsfolk) sitta och mecka runt med dina tjänster och byta policies on-the-fly. Är det överhuvudtaget mänskligt att kunna administrera IT på det här viset, eller är det bara en utopi som istället kommer visa vägen till instabilitet?
onsdag, augusti 02, 2006
ORMen som kröp iväg
Innan jag skrev den här posten så stängde jag av mina Comments för att inte riskera att blir bränd på min egen blog ;) Nja, anledning till att jag knäppte av det beror på att det inte kom in några kommentarer ändå. Jag ska inte chockera på samma sätt som Ted Neward gjorde i sin jämförelse mellan Vietnamkriget och O/R-mappare i The Vietnam of Computer Science utan mer visa på vilken liten betydelse ORM spelar i den processorienterade världen.
ORM (Object Relational Mapping) som är en teknik för att länka den objektorienterade världen med relationsdatabaser har fått en rejäl uppmärksamhet bland applikationsutvecklare runt omi världen. O/R-mappare kallar man implementationen som hanterar den kopplingen och det finns mängder av sådan, mer eller mindre lyckosamma (många blev inte mer än betor men läs mer om det på Ted N blog). Det finns lika många förespråkare av O/R-mappare som det finns motståndare. Jag o andra sidan är motståndare till allt som delar upp åsikterna i två lika stor läger. Men det är inte det jag kommer att trycka på nu, utan den egentliga nyttan av O/R-mapparen i en applikation.
Jag skrev tidigare en post om hur data representeras och hanteras i processdriven utveckling (Processdriven utveckling IV – Data). Det viktiga att ta med sig därifrån var att processen skyddar datat, dvs att den information som direkt hör till en process skyddas av den samma. Det finns bara ett sätt att få åtkomst till datat och det är genom processen. System som definierar och hanterar processer kallas för BPMS (Business Process Management Systems) som har en speciell egenhet, de hanterar nämligen processens tillstånd och dess data under hela transaktionen (processens livstid) utan att man behöver implementera datalagring.
Det är inte O/R-mapparen som i första hand tappar sin betydelse utan objektlagret i ett transaktionssystem. Objektlagret bygger på att datat är centralt och åtkomligt av vem som helst, när som helst under en transaktion (LRT). Vissa begränsningar kan läggas in, men det implementeras i så fall inte i objektlagret eller i O/R-mapparen. Relationsdatabaser är också datacentriska och faller in under samma kategori av oordnad data access.
Men i processorienterad utveckling är datat sekundärt och följer bara med processen som här är central. Om och när processen serialiseras och persisteras är upp till varje BPMS. Visst kan processen (inkl data) persisteras till en relationsdatabas, men det är inte relevant eftersom man ändå inte har access till den informationen under processens livstid. Men när processen är klar så kan man självfallet lagra undan datat i en relationsdatabas, men då mer av historisk betydelse.
Jag skulle gissa att om inte lång tid framöver när WF, BPEL och andra BPM-verktyg slår igenom och processorienterad utveckling blir vanligare bland applikationsutvecklare så kommer intresset för O/R-mappare och relationsdatabaser att svalna rejält. Databaser blir mer av nytta för Data Warehousing än för transaktionssystem och objektlager får en mindre betydelse.
ORM (Object Relational Mapping) som är en teknik för att länka den objektorienterade världen med relationsdatabaser har fått en rejäl uppmärksamhet bland applikationsutvecklare runt omi världen. O/R-mappare kallar man implementationen som hanterar den kopplingen och det finns mängder av sådan, mer eller mindre lyckosamma (många blev inte mer än betor men läs mer om det på Ted N blog). Det finns lika många förespråkare av O/R-mappare som det finns motståndare. Jag o andra sidan är motståndare till allt som delar upp åsikterna i två lika stor läger. Men det är inte det jag kommer att trycka på nu, utan den egentliga nyttan av O/R-mapparen i en applikation.
Jag skrev tidigare en post om hur data representeras och hanteras i processdriven utveckling (Processdriven utveckling IV – Data). Det viktiga att ta med sig därifrån var att processen skyddar datat, dvs att den information som direkt hör till en process skyddas av den samma. Det finns bara ett sätt att få åtkomst till datat och det är genom processen. System som definierar och hanterar processer kallas för BPMS (Business Process Management Systems) som har en speciell egenhet, de hanterar nämligen processens tillstånd och dess data under hela transaktionen (processens livstid) utan att man behöver implementera datalagring.
Det är inte O/R-mapparen som i första hand tappar sin betydelse utan objektlagret i ett transaktionssystem. Objektlagret bygger på att datat är centralt och åtkomligt av vem som helst, när som helst under en transaktion (LRT). Vissa begränsningar kan läggas in, men det implementeras i så fall inte i objektlagret eller i O/R-mapparen. Relationsdatabaser är också datacentriska och faller in under samma kategori av oordnad data access.
Men i processorienterad utveckling är datat sekundärt och följer bara med processen som här är central. Om och när processen serialiseras och persisteras är upp till varje BPMS. Visst kan processen (inkl data) persisteras till en relationsdatabas, men det är inte relevant eftersom man ändå inte har access till den informationen under processens livstid. Men när processen är klar så kan man självfallet lagra undan datat i en relationsdatabas, men då mer av historisk betydelse.
Jag skulle gissa att om inte lång tid framöver när WF, BPEL och andra BPM-verktyg slår igenom och processorienterad utveckling blir vanligare bland applikationsutvecklare så kommer intresset för O/R-mappare och relationsdatabaser att svalna rejält. Databaser blir mer av nytta för Data Warehousing än för transaktionssystem och objektlager får en mindre betydelse.
BAM - att se in i en transaktion
Ett problem med Business Intelligence (BI) och OLAP är att man inte har tillgång till den färskaste information för analys. I en verksamhet görs många beslut baserat på olika analyser av den information och data som förekommer i diverse databaser och system. Det kan vara beslut som förändrar exempelvis en affärsprocesser därför att den visat sig vara ineffektiv. Det kan även vara kostnadsbesparingar baserat på analys som visar att vissa resurser inte nyttjas fullt ut. Den informationen som används för att dra dessa slutsatser bygger på data från OLTP-system i verksamheten. Data hämtas in (ETL) till ett OLAP-system från bland annat dessa OLTP-system där informationen aggregeras in i OLAP-kuber. Analysen bygger på datat som finns i dessa kuber och presenteras på olika sätt i olika verktyg.
BI baseras på information som skapats av avslutade transaktioner. Den mest färska information som finns att tillgå finns inom transaktionerna. Informationen som befinner sig mitt i en transaktion är ofta inte tillgänglig för hämtning för att man inte vill vill störa transaktionerna. Vi pratar då inte om ACID transaktioner utan om långa transaktioner (Long Running Transactions). Det kan exempelvis vara en faktureringsprocess där den avslutade transaktionen ger uppgift om hur faktureringen gick efter det att den avslutats för en viss kund. Den informationen kan då komma att bli underlag för BI. Men vad man inte får är uppgifter om faktureringen under själva transaktionen.
Business Activity Monitoring (BAM) kallas det för när man analyserar tillståndet inom en transaktion. BAM ska analysera information som behövs snabbt för att hinna göra snabba förändringar. Det kan exempelvis visa sig att orderingången ökar kraftigt så att man därför snabbt behöver beställa nödvändiga varor från leverantörerna. BAM förknippas med BPMS (Business Process Management Systems) som exempelvis BizTalk. Dessa system bygger upp processbeskrivning mha aktiviteter som i runtime sedan kan monitoreras genom BAM. BAM kommer i dessa system som en komponent och är en av de mest dramatiska förbättringar man får med processorienterad utveckling och BPMS.
BI baseras på information som skapats av avslutade transaktioner. Den mest färska information som finns att tillgå finns inom transaktionerna. Informationen som befinner sig mitt i en transaktion är ofta inte tillgänglig för hämtning för att man inte vill vill störa transaktionerna. Vi pratar då inte om ACID transaktioner utan om långa transaktioner (Long Running Transactions). Det kan exempelvis vara en faktureringsprocess där den avslutade transaktionen ger uppgift om hur faktureringen gick efter det att den avslutats för en viss kund. Den informationen kan då komma att bli underlag för BI. Men vad man inte får är uppgifter om faktureringen under själva transaktionen.
Business Activity Monitoring (BAM) kallas det för när man analyserar tillståndet inom en transaktion. BAM ska analysera information som behövs snabbt för att hinna göra snabba förändringar. Det kan exempelvis visa sig att orderingången ökar kraftigt så att man därför snabbt behöver beställa nödvändiga varor från leverantörerna. BAM förknippas med BPMS (Business Process Management Systems) som exempelvis BizTalk. Dessa system bygger upp processbeskrivning mha aktiviteter som i runtime sedan kan monitoreras genom BAM. BAM kommer i dessa system som en komponent och är en av de mest dramatiska förbättringar man får med processorienterad utveckling och BPMS.
Ajax - Del II
Så vilka krav ställer SOA på Ajax om det nu ska vara en frälsare som kommer med något nytt till den krampaktiga ställning webben befunnit sig i sedan sent 90-tal?
De första Ajax-applikationerna använder säkert den nya tekniken för att dra fördelar av den asynkrona kommunikationen. Detta är ju knappast något nytt eftersom man har kunnat göra det i vilken .NET, Java eller Win32 applikation som helst innan. Ett stort steg för webben dock.
Ajax implementeras alltså som ramverk som anropar Web Services från Javascript i browsern. Anropen mellan browsern och ramverket är asynkrona, vilket betyder att man får hantera resultatet från anropet i en event handler. Vad Ajax däremot inte supporterar är asynkron kommunikation mellan ramverket och servern eftersom Ajax inte själv kan sätta upp en endpoint och därmed finns ingen väg tillbaka från servern.
Bristen på en asynkron kommunikation mellan ramverket och en Web Service omöjliggör vissa scenarios som är vanliga i en SOA.
Scenario 1 - Callbacks
Callbacks används vid asynkron kommunikation mellan 2 parter. En part gör ett tjänsteanrop till en annan part som tar lång tid på sig att utföra jobbet och därför erbjuder sig att göra ett anrop tillbaka till den anropande parten då den är klar. För det krävs att bägge parter kan kommunicera med den andra.
Scenario 2 - Events
Events avser kommunikation från en part till en annan då specifika händelser inträffar som ska notifieras (ex. genom WS-Eventing). Om en part ska kunna prenumurera på händelser som inträffar hos en annan part så måste händelserna kunna kommuniceras till en service endpoint.
I och med att Ajax inte kan sätta upp en Web Service endpoint så kommer webbapplikationerna fortfarande att leva utan dessa scenarios. Ska Ajax spela en större roll i framtiden så måste dessa supporteras. Idag finns det omvägar för den som önskar 2-vägskommunikation. Man kan använda sig av protokoll som stödjer full duplex för att kommunicera fram och tillbaka eller pollning där man frågar servern om något nytt hänt vid jämna intervall. Det finns även ramverk som sköter pollningen åt dig (Periodic Refresh).
Men så länge Ajax inte stödjer service endpoints så är det inte att betrakta som varken en disruptiv teknologi eller något stort teknikskifte för webben.
De första Ajax-applikationerna använder säkert den nya tekniken för att dra fördelar av den asynkrona kommunikationen. Detta är ju knappast något nytt eftersom man har kunnat göra det i vilken .NET, Java eller Win32 applikation som helst innan. Ett stort steg för webben dock.
Ajax implementeras alltså som ramverk som anropar Web Services från Javascript i browsern. Anropen mellan browsern och ramverket är asynkrona, vilket betyder att man får hantera resultatet från anropet i en event handler. Vad Ajax däremot inte supporterar är asynkron kommunikation mellan ramverket och servern eftersom Ajax inte själv kan sätta upp en endpoint och därmed finns ingen väg tillbaka från servern.
Bristen på en asynkron kommunikation mellan ramverket och en Web Service omöjliggör vissa scenarios som är vanliga i en SOA.
Scenario 1 - Callbacks
Callbacks används vid asynkron kommunikation mellan 2 parter. En part gör ett tjänsteanrop till en annan part som tar lång tid på sig att utföra jobbet och därför erbjuder sig att göra ett anrop tillbaka till den anropande parten då den är klar. För det krävs att bägge parter kan kommunicera med den andra.
Scenario 2 - Events
Events avser kommunikation från en part till en annan då specifika händelser inträffar som ska notifieras (ex. genom WS-Eventing). Om en part ska kunna prenumurera på händelser som inträffar hos en annan part så måste händelserna kunna kommuniceras till en service endpoint.
I och med att Ajax inte kan sätta upp en Web Service endpoint så kommer webbapplikationerna fortfarande att leva utan dessa scenarios. Ska Ajax spela en större roll i framtiden så måste dessa supporteras. Idag finns det omvägar för den som önskar 2-vägskommunikation. Man kan använda sig av protokoll som stödjer full duplex för att kommunicera fram och tillbaka eller pollning där man frågar servern om något nytt hänt vid jämna intervall. Det finns även ramverk som sköter pollningen åt dig (Periodic Refresh).
Men så länge Ajax inte stödjer service endpoints så är det inte att betrakta som varken en disruptiv teknologi eller något stort teknikskifte för webben.
tisdag, augusti 01, 2006
Funktioner jag vill ha i min Zune
Efter att ha använt en iPod Video under en tid så skulle jag önska följande funktioner för min Zune:
- WiFi - jobbigt med synkronisering från PC/USB
- RSS Reader - saknas i iPod men något man använder dagligen
- Mail - saknas i iPod och borde klara sync med Exchange
- GPS Navigator - en feature som borde byggas in
- Podcasts - finns i iPod och blir allt vanligare
- Videocasts - finns i iPod och på nätet men mest i ostrukturerad form (ex. Channel9)
- Media Player - mp3, mpeg, etc
- Recorder - för audio, video, photo
- Phone - antar att Skype inte installeras men något liknande alla fall
- Spel - det ultimata tidsfördrivet
Prenumerera på:
Inlägg (Atom)