SOA reflektioner: May 2005 Archives
Jeg har på det sidste gået og reflekteret over om Webservices er "moden" nok til large scale produktion
I mine samtaler har jeg opnået noget som jeg synes kunne tyde på en afklaring af spørgsmålet.
Og det må være at - ja - webservices er klar til stordrift. True - der kan være problemer når man pakker xml'en med en masse binær data som kort eller musik, men ren xml bliver så effektivt pakket ved forsendelse og udbuddet af bandwidth er så stort at der i dag stadig er masser af plads.
Jeg har været ude og besøge lægemiddelstyrelsen som kører noget der hedder "Det Centrale Tilskudsregister" CTR som er indberetning af medicin omkostning således at tilskud kan uddeles som følge heraf. Da systemet blev lavet i starten af 2000 anskaffede man sig ISDN linier ud til hver apotek - det var 64kbit - og i dag bruger man stadig ikke mere end 20% af kapaciteten.
Den 12. september 2003 var i alt 4.114.542 personers køb af tilskudsberettigede lægemidler registreret i CTR.
Der er gennemsnitligt ca. 300.000 transaktioner om dagen, fordelt på godt 3.000 kasseterminaler på de i alt ca. 280 danske apoteker. Systemet skal levere svartider på under 2 sekunder i 95% af tilfældene og i gennemsnit er svartiden under 0,5 sekund. I spidsbelastningssituationer håndteres flere end 70 transaktioner per sekund.
Så jeg er efterhånden blevet overbevist om at kan lade gøre at bruge WS til sine mere krævende applikationer - spørgsmålet kommer dog om man så også kan køre SOA i large scale. Ovenstående eksempel er en god indikator.
I mine samtaler har jeg opnået noget som jeg synes kunne tyde på en afklaring af spørgsmålet.
Og det må være at - ja - webservices er klar til stordrift. True - der kan være problemer når man pakker xml'en med en masse binær data som kort eller musik, men ren xml bliver så effektivt pakket ved forsendelse og udbuddet af bandwidth er så stort at der i dag stadig er masser af plads.
Jeg har været ude og besøge lægemiddelstyrelsen som kører noget der hedder "Det Centrale Tilskudsregister" CTR som er indberetning af medicin omkostning således at tilskud kan uddeles som følge heraf. Da systemet blev lavet i starten af 2000 anskaffede man sig ISDN linier ud til hver apotek - det var 64kbit - og i dag bruger man stadig ikke mere end 20% af kapaciteten.
Den 12. september 2003 var i alt 4.114.542 personers køb af tilskudsberettigede lægemidler registreret i CTR.
Der er gennemsnitligt ca. 300.000 transaktioner om dagen, fordelt på godt 3.000 kasseterminaler på de i alt ca. 280 danske apoteker. Systemet skal levere svartider på under 2 sekunder i 95% af tilfældene og i gennemsnit er svartiden under 0,5 sekund. I spidsbelastningssituationer håndteres flere end 70 transaktioner per sekund.
Så jeg er efterhånden blevet overbevist om at kan lade gøre at bruge WS til sine mere krævende applikationer - spørgsmålet kommer dog om man så også kan køre SOA i large scale. Ovenstående eksempel er en god indikator.
Microsoft har virkeligt taget web services til sig i den forestående version af Visual Studio med codename "Indigo".
Indigo er en samling af nye programmerings frameworks som til høj grad understøtter SOA i form af web services. Med vanlig sikkerhed udtalte en microsoft executive at dette kunne blive slutningen på at skrive kode - i stedet vil det bare være et spørgsmål om at sammensætte services.
Indigo sammensætter efter sigende de bedste features fra .NET, ASMX til en ensartet programmerings og administrations-model, men frem for at køre deres eget show er Indigo i højere grad bygget på standarder som HTTP, XML og SOAP (Web services).
Sikkerhedsmodellen for Indigo er opgivet som følgende:
1. beskedudveksling sikres igennem entiteter (fortrolighed)
2. entiteters adgang til ressourcer sikres (autenticitet og adgangskontrol)
3. alle forespørgsler til ressourcer af entiteter registreres (integritet)
Dette lyder jo meget simpelt og mapper sig fint op imod de-fakto CIA-treenigheds sikkerhedsmodellen.
En anden interessant ting er at Indigo bruger "credentials" til at foretage sikkerheden - dette er således et skridt væk fra "token security"
Microsoft ser credentials som
1. Claims (data omkring en entitet)
2. Issuer (kontrollerer og certificerer credentials)
3. Proof of prossession (hvordan en entitet beviser at det er dens claims)
Det lader til at MS Indigo træder et skridt imod en mere standardiseret sikkerhedsmodel (bl.a. imod federated identity) så det bliver spændende at følge udviklingen nærmere når produktet kommer på gaden. Dog var der i præsentationen mange forbehold og det lød til at der stadig var mange løse ender som skulle fixes før produktet var klar.
Indigo er en samling af nye programmerings frameworks som til høj grad understøtter SOA i form af web services. Med vanlig sikkerhed udtalte en microsoft executive at dette kunne blive slutningen på at skrive kode - i stedet vil det bare være et spørgsmål om at sammensætte services.
Indigo sammensætter efter sigende de bedste features fra .NET, ASMX til en ensartet programmerings og administrations-model, men frem for at køre deres eget show er Indigo i højere grad bygget på standarder som HTTP, XML og SOAP (Web services).
Sikkerhedsmodellen for Indigo er opgivet som følgende:
1. beskedudveksling sikres igennem entiteter (fortrolighed)
2. entiteters adgang til ressourcer sikres (autenticitet og adgangskontrol)
3. alle forespørgsler til ressourcer af entiteter registreres (integritet)
Dette lyder jo meget simpelt og mapper sig fint op imod de-fakto CIA-treenigheds sikkerhedsmodellen.
En anden interessant ting er at Indigo bruger "credentials" til at foretage sikkerheden - dette er således et skridt væk fra "token security"
Microsoft ser credentials som
1. Claims (data omkring en entitet)
2. Issuer (kontrollerer og certificerer credentials)
3. Proof of prossession (hvordan en entitet beviser at det er dens claims)
Det lader til at MS Indigo træder et skridt imod en mere standardiseret sikkerhedsmodel (bl.a. imod federated identity) så det bliver spændende at følge udviklingen nærmere når produktet kommer på gaden. Dog var der i præsentationen mange forbehold og det lød til at der stadig var mange løse ender som skulle fixes før produktet var klar.
Bea har netop offentliggjort en undersøgelse bland 1000 "Professionals" i amerikanske virksomheder... (Ud af hvilke 29% kaldte sig selv arkitekt..)
Undersøgelsen viste at SOA var kendt af 44% og det var kun til en grad af 1.76 - hvor eet var "basic understanding" af SOA og fire var en "very advanced" forståelse af SOA.
Læs resumeet her
Undersøgelsen viste at SOA var kendt af 44% og det var kun til en grad af 1.76 - hvor eet var "basic understanding" af SOA og fire var en "very advanced" forståelse af SOA.
Læs resumeet her
På baggrund af den tidligere artikel er jeg begyndt at ræsonnere over hvorvidt web-services er det klare valg i forhold til "availability".
Som det blev forklaret er det et problem hvis systemer går ned "due to heavy load" blot fordi standarden går hen imod at køre web services.
Så jeg ringede til Henrik Hvid som jo har skrevet en bog om SOA og som måske kunne lede mig imod nogle virksomheder som havde erfaringer med SOA uden Web services. Den eneste han kunne komme i tanke om var Danske Bank som har kørt SOA i mange år.
Men har de nu også det? - Vi tog en diskussion om hvorvidt det egneligt var SOA som DanskeBank kører fordi skal man tro side 68 i Henriks bog så skal der åbne standarder til et SOA og det kører Danske Bank ikke.
Man kan sige at Danske Bank tænker SOA men laver komponent baseret udvikling hvilket jeg i øvrigt også har hørt nogen sige før.
Så jeg spurgte om hvorvidt definitionen af SOA så var forkert men det mente han nu ikke og definitionen passer også ok med andre forklaringer på SOA som jeg har læst.
Spørgsmålet er derfor om de som går og siger at man har kørt SOA i rigtig mange år også har ret eller om det reelt bare har været en modul- / komponentbaseret it-arkitektur. Måske skal vi først til at køre rigtigt SOA nu. Det tror jeg er mere rigtigt fordi jeg har endnu ikke mødt nogle eksempler som har kunne sige at deres SOA:
Er Distribueret
Har Løse Koblinger
Er Processorienteret
og
Bygger på Åbne Standarder.
Men det kan jo være at jeg i mine søgning efter case-virksomheder bliver klogere.
For at vende tilbage til forvirringen omkring web services' anvendelighed i high load miljøer gav Henrik mig medhold i det faktum at der kommer successhistorier fra "begge lejre" - både dem som kører web services og så dem som har valgt en leverandørafhængig løsning.
Han forklarede at performance ikke er et stor problem når vi har at gøre med menneskelige interaktioner - om vi venter 1 eller 3 sekunder på at få svar fra en service gør ikke det store - men hvis web services og SOA skal vokse sig stor og stærk så må det være et krav at den også understøtter maskin-processerne.
Måske er vejen frem konverteringen af XML til binær kode. Men det ville være at sluge en stor kamel for XML-grundlaget. Det kan også være at Moore's lov og Bandwidth løser problemet inden det overhovedet når at blive et problem. Lidt mere at kigge på.
Som det blev forklaret er det et problem hvis systemer går ned "due to heavy load" blot fordi standarden går hen imod at køre web services.
Så jeg ringede til Henrik Hvid som jo har skrevet en bog om SOA og som måske kunne lede mig imod nogle virksomheder som havde erfaringer med SOA uden Web services. Den eneste han kunne komme i tanke om var Danske Bank som har kørt SOA i mange år.
Men har de nu også det? - Vi tog en diskussion om hvorvidt det egneligt var SOA som DanskeBank kører fordi skal man tro side 68 i Henriks bog så skal der åbne standarder til et SOA og det kører Danske Bank ikke.
Man kan sige at Danske Bank tænker SOA men laver komponent baseret udvikling hvilket jeg i øvrigt også har hørt nogen sige før.
Så jeg spurgte om hvorvidt definitionen af SOA så var forkert men det mente han nu ikke og definitionen passer også ok med andre forklaringer på SOA som jeg har læst.
Spørgsmålet er derfor om de som går og siger at man har kørt SOA i rigtig mange år også har ret eller om det reelt bare har været en modul- / komponentbaseret it-arkitektur. Måske skal vi først til at køre rigtigt SOA nu. Det tror jeg er mere rigtigt fordi jeg har endnu ikke mødt nogle eksempler som har kunne sige at deres SOA:
Er Distribueret
Har Løse Koblinger
Er Processorienteret
og
Bygger på Åbne Standarder.
Men det kan jo være at jeg i mine søgning efter case-virksomheder bliver klogere.
For at vende tilbage til forvirringen omkring web services' anvendelighed i high load miljøer gav Henrik mig medhold i det faktum at der kommer successhistorier fra "begge lejre" - både dem som kører web services og så dem som har valgt en leverandørafhængig løsning.
Han forklarede at performance ikke er et stor problem når vi har at gøre med menneskelige interaktioner - om vi venter 1 eller 3 sekunder på at få svar fra en service gør ikke det store - men hvis web services og SOA skal vokse sig stor og stærk så må det være et krav at den også understøtter maskin-processerne.
Måske er vejen frem konverteringen af XML til binær kode. Men det ville være at sluge en stor kamel for XML-grundlaget. Det kan også være at Moore's lov og Bandwidth løser problemet inden det overhovedet når at blive et problem. Lidt mere at kigge på.
Det har længe stået klart at SOA ikke er synonym med Web Services. Men fordi web services tilbydes som en åben standard er det naturligt at mene at vi skal gå imod denne implementationsform. Men at web services stadig er langt fra at være den ultimateive SOA-metode beskriver Jared Rodriguez i hans (corporate) blog under artiklen Basics som i hvert fald åbnede mine øjne.
Artiklen giver indsigt i Web services's performance (processering og bandwidth) vanskeligheder i forhold til bl.a. binære løsninger og selvom det langt fra er nogen videnskabelig undersøgelse så giver det stof til tanke om tidsaspektet for web services og er der alternativer - også rent sikkerhedsmæssigt.
Jeg ser et problem i at introducere sikkerhedsperspektivet til udviklere & it-arkitekter som allerede sidder og kæmper med at højne performance for web-service. I sådan et scenario er må sikkerhedsperspektivet tvinges eller sælges bedst muligt således at det ikke bliver udeladt.
Jared er i øvrigt indehaver af Skyway Software som sælger grafiske værktøjer til at bygge SOA samt diverse konsulentydelser dertil - han har netop landet en stor ordre i i fbm. at bygge SOA for British American Tobacco PLC som med tiden vil uskifte dele af deres Oracle, Microsoft og IBM værktøjer med Skyways SOA Builder.
Artiklen giver indsigt i Web services's performance (processering og bandwidth) vanskeligheder i forhold til bl.a. binære løsninger og selvom det langt fra er nogen videnskabelig undersøgelse så giver det stof til tanke om tidsaspektet for web services og er der alternativer - også rent sikkerhedsmæssigt.
Jeg ser et problem i at introducere sikkerhedsperspektivet til udviklere & it-arkitekter som allerede sidder og kæmper med at højne performance for web-service. I sådan et scenario er må sikkerhedsperspektivet tvinges eller sælges bedst muligt således at det ikke bliver udeladt.
Jared er i øvrigt indehaver af Skyway Software som sælger grafiske værktøjer til at bygge SOA samt diverse konsulentydelser dertil - han har netop landet en stor ordre i i fbm. at bygge SOA for British American Tobacco PLC som med tiden vil uskifte dele af deres Oracle, Microsoft og IBM værktøjer med Skyways SOA Builder.
