Recently in SOA reflektioner Category
Et meget godt billede af de udfordringer man står overfor i ToldSkat:
/D101%2F04F1.gif)
Figuren viser, at de 71 systemer på listen (den inderste cirkel) er knyttet sammen indbyrdes ved 453 forbindelser. Figuren viser endvidere, at der eksisterer 312 forbindelser mellem ToldSkats systemer og et eller flere systemer hos 97 eksterne interessenter (den yderste cirkel). (Det bemærkes, at én linje i figuren i nogle tilfælde dækker flere forbindelser).
Billedet og tekst er fra rigsrevisionens udvidet notat til statsrevisorerne om ToldSkats IT-systemer den 8. juni 2004
Figuren viser, at de 71 systemer på listen (den inderste cirkel) er knyttet sammen indbyrdes ved 453 forbindelser. Figuren viser endvidere, at der eksisterer 312 forbindelser mellem ToldSkats systemer og et eller flere systemer hos 97 eksterne interessenter (den yderste cirkel). (Det bemærkes, at én linje i figuren i nogle tilfælde dækker flere forbindelser).
Billedet og tekst er fra rigsrevisionens udvidet notat til statsrevisorerne om ToldSkats IT-systemer den 8. juni 2004
Da åbne standarder er et emne jeg behandler i forhold til sikkerhedsproblematikken, har jeg skrevet et lille kapitel omkring åbne standarder som jeg gerne vil dele. Kommentarer modtages gerne.
Åbne standarder
Jensens (2004) principper for SOA, stemmer meget godt overens med Rosen & Lublinsky (2005), men som en interessant distinktion trækker Jensen åbne standarder (open-standards) frem som en af de mest fundamentale drivkræfter for SOA.
I denne gennemgang vil åbne standarder kort blive beskrevet hvorefter deres anvendelighed i forhold til SOA og sikkerhed diskuteres.
Standard definition
En teknisk standard kan betegnes som en kodifikation beskrivende en implementation eller procedure som anvendes med øje for sammenligning. (Krechmer, 2002)
_QUOTEC
Åbne standarder
Jensens (2004) principper for SOA, stemmer meget godt overens med Rosen & Lublinsky (2005), men som en interessant distinktion trækker Jensen åbne standarder (open-standards) frem som en af de mest fundamentale drivkræfter for SOA.
I denne gennemgang vil åbne standarder kort blive beskrevet hvorefter deres anvendelighed i forhold til SOA og sikkerhed diskuteres.
Standard definition
En teknisk standard kan betegnes som en kodifikation beskrivende en implementation eller procedure som anvendes med øje for sammenligning. (Krechmer, 2002)
_QUOTEC
En nærmere bestemmelse af standarder bygger dog på en opdeling som anvist i figur 5.
Vertikalt kan standarder plottes afhængig af standardens kodifikation som anfører i hvor høj grad den pågældende standard er udarbejdet igennem en standardiseringsorganisation (SDO ) som tilfældet er for de-jure standarder, eller gradvist er blevet en standard igennem brug, uden decideret indblanding fra en standardiseringsorganisation, som tilfældet er for de-facto standarder.
For både de-facto og de-jure standarder gælder det at de starter ud som specifikation, men i kraft af bred anvendelse bliver specifikationen til en standard.
På den horisontale akse er distinktionsparameteren tilgængelighed, og der skelnes imellem åbne og patenterede standarder. Modellens værdi som en grafisk repræsentation for standarders status vil blive diskuteret senere.
Patenterede standarder er i sig selv en antitese (Krechmer, 2005). Et patent er en metode til at værdisætte det unikke, men standarder er det tekniske samfunds middel til at definere det ensartede. Således er der en basal modsætning imellem det ensartede og det unikke, hvilket skaber grundlag for et politisk spørgsmål om hvorledes der prioriteres imellem de ene af de to.
Åbne standarder er sværere at definere. Perens' (2005) seks principper for åbne standarder er nok de mest anvendte: Availability, Maximize End-User Choice, No Royalty, No Discrimination, Extension or Subset, Predatory Practices. Disse principper udgør et godt fundament for at fastlægge åbne standarder, men de håndterer ikke distinktionen imellem forskellige grader af åbenhed.
Åben definition
Den generelle konsensus er, at "åben" skal ses som offentligt tilgængelige specifikationer, der kan adopteres uden restriktioner. ITST (2004) fortolker "åben" til at standarden skal være, og forblive, gratis og tilgængelig i sin helhed således, at andre kan anvende den samme standard for deres egne produkter.
Derved skelner ITST ikke imellem standarder, som er frembragt på baggrund af en offentlig proces og de som er fremkommet fra en lukket proces og derefter frigivet.
_QUOTEC
Grundlæggende kan man argumentere at åben er en tilstand - enten er noget åben eller lukket. Men denne opstilling vil være for rigid og kan hindre standarders udvikling i sidste ende. Er Microsofts nye "Åben Format" (Open Format) f.eks. lige så åbent som Oasis' Open Document?
Begge filformater er i dag gratis og tilgængelige, men de er ikke begge opstået på baggrund af en offentlig proces. Dette betyder bl.a., at specifikationerne ikke har været bearbejdet således, at en bred konsensus er opnået på tværs af standardens interessenter.
Ifølge et interview med IBM (IBM, 2005, 0:33:00) er åbne standarder et salgsargument i kraft af den handlingskraft det giver kunden overfor leverandørerne. Derfor kan det forventes, at flere organisationer forsøger at deklarere deres formater som åbne standarder, på trods af forskellige specifikationstilgange. I takt med at åbne standarder bliver et mere betydningsfuldt salgsargument, er der også risiko for at der sker en udvanding af begrebet.
_QUOTEC
Der findes dog måder at måle openhed på. Krechmer (2005b) har opstillet ten rights that enables open standards, som opstillet i tabel 1. Disse er rettigheder der spænder fra delagtigørelse i specifikationsfasen til løbende support af standardens anvendelse. Opsætningen af principper giver mulighed for at rangdele eller klassificere standarder i forhold til deres åbenhed, ved at vægte hvert princip med en faktor kan der opstilles en resultattabel som gør det muligt at benchmarke standarder.
Igennem en overordnet certificerings-instans, vil resultatet kunne danne grundlag for, at en bedømmelse af standarders åbenheden. Samtidig vil standarderne kunne mappes ind i modellen (figur 6) for at give et grafisk overblik.
En relateret metode til evaluering af standarder er, at adoptere licens-strukturen for open-source. Open-source har også været nødt til at gradbøje begrebet "åben", men gør det igennem forskellige typer licenser. For hver licens eksisterer der forskellige former for kontrol og frihed og således kan ophaver af en open-source applikation, selv bestemme i hvor høj grad, hun ønsker at give applikationen fri. For standarder vil en lign. model f.eks. indikere hvor åben specifikationsfasen for standarden har været og i hvor høj grad standarden kan anvendes som model for andre standarder.
Åbne fordele
Åbne standarder besidder en række fordele i forhold til proprietære standarder. Mest oplagt, er åbne standarder en katalysator for interoperabilitet. Dette sker i kraft af offentlige tilgængelige specifikationer, som giver alle systemleverandører mulighed for at basere deres produkter på disse tilgængelige specifikationer.
Værdien af interoperabilitet ligger i den netværkseffekt, som der dannes i kraft af at flere anvender en standard. På kort sigt er der dog ikke noget krav om åbne standarder for at opnå interoperabilitet (hvilket mange af Microsofts produkter er eksempler på), men på længere sigt kan en standards åbenhed have stor betydning for dens udbredelse og accept.
Interoperabilitet opnås igennem en række forskellige måder: Igennem lovmæssig tvang kan der skabes interoperabilitet, hvilket dog derved sætter markedskræfterne ud af spil og den valgte løsning er måske ikke den mest ideelle. Monopol kan fordre interoperabilitet.
Monopoler og lovmæssig tvang er meget lig hinanden, men har dog den væsentlige forskel, at love formodes fremsat for at fordre samfundets bedste tarv hvorimod monopoler mest gavner organisationen der besidder monopolet. Patenter anses i denne forstand som et forsøg på at monopolisere den teknik man besidder.
Åbne standarder kan være med til at fjerne det lock-in som leverandører har haft i kraft af deres proprietære protokoller. Den medfølgende leverandøruafhængighed påvirker fleksibiliteten af systemet, idet der nu vil være større valgfrihed til at vælge netop den leverandør der kan levere det produkt som bedst passer til organisations krav.
Åbne standarder medfører også en række sikkerhedsmæssige fordele som opstår i kraft af at sprede risikoen for at en leverandør går konkurs imellem flere leverandører. Dog er der ikke noget som tyder på at forskellige systemer er mere sikre overfor angreb. Tværtimod vil flere systemer kræve en større serviceindsats at holde opdateret.
Efterhånden som jeg får gravet mig dybere ned i SOA finder jeg flere og flere eksempler på at SOAs principper er mere nuanceret end som sådan og nødvendigvis må fortolkes for også at give mening.
Hvis man tager fat i Henrik Hvid Jensens fire principper for serviceorienteret arkitektur består arkitekturen af følgende principper: distribueret; baseret på åbne standarder; procesorienteret og løst koblet (man kan diskutere om disse er tilstrækkelige - Lublinsky har også business driven og stateless invocation som to principper).
Ubetinget af 4 eller 6 principper så er den grundlæggende ide stadig understøtningen af interoperable arkitekturer på tværs af organisationer - her er man nødt til at overholde de standarder og principper igennem noget der ligner en fælles referencemodel.
Men det bliver mere og mere tydeligt at principperne må være op til fortolkning i SOA indenfor organisationers fire mure.
I et interview med Kåre Kjelstrøm fra Silver Bullet redegjorde han for hans tanker omkring "intern" og "ekstern" SOA - hvor den eksterne SOA følger principperne meget rigid er der "room for more slack". I den interne SOA hvor man af performance hensyn kan vælge at sige - "vi kører .NET eller J2EE som vores standard platform".
Microsofts nye Indigo udviklingsplatform kommer til at understøtte noget lignende - i systemkald imellem systemer vil den etablere det mest gunstige kommunikationsform - hvis det andet system også er Microsoft anvendes deres proprietære standard ellers anvendes webservices.
En sådan pragmatisk holdning er nødvendig for at komme i gang med "the learning experience of SOA". Små skridt af gangen. I en survey af webservices.org snakker man på samme måde om Webservices version 1 og version 2 - I version 1 anvendte 35% af adspurgte firmaer webservices til at skabe en standardiseret kommunikationsform imellem heterogene systemer. I version 2 vil fokus være ekstern for organisation og måske også over imod anvendelsen af service repository selvom jeg dog tror at det vil vare lidt endnu (især for private virksomheder).
Til at understøtte hele SOA arkitekturprocessen har Oasis-Open arbejdet på en SOA Reference Model som nu er i working draft. Modellen er udsprunget fra erkendelsen at SOA er anvendt i så mange forskellige kontekster at der er behov for at rydde op og klart definere arkitekturmodellen for SOA. I OASIS' SOA-RM har en SOA flere komponenter som alle er rettet imod arkitekturens centrale element - "services".
Services nedbrydes i fire afgrænsede aspekter nærmere betegnet:
⢠Descriptor
⢠Policy
⢠Contract
⢠Data Model
Derudover er der nogle tværgående anliggender:
⢠Semantics
⢠Discovery, Presence and Availability
SOA-RM udgør et abstrakt rammeværk til at forstå betydningsfulde entiteter og deres indbyrdes relationer i en serviceorienteret miljø og modellen understøtter udviklingen af konforme standarder og specifikationer som understøtter miljøet.
Jeg hilser denne udvikling meget velkommen da det vil kunne hjælpe med at få spredt SOA ud til ikke kun at være defineret af konsulenternes markedsføringsafdelinger men også akademisk anvendeligt med udgangspunkt i forskningsarbejde.
Samtidig vil en uniform model gøre det nemmere for virksomheder i at kortlægge deres roadmap for hvordan de vil tilbyde ekstern eller version 2 SOA.
SOA-RM eller ej så tror jeg at Ronald Schmelzer, senior analytiker ved ZapThink har ret i hans postulat i et Infoworld interview "Architecture is very difficult -- in fact, architecture is mostly a challenge for people, rather than technology [...] So, the SOA Reference Model will go a long way to helping people deal with the human aspects of making architecture work, but it will be up to companies to adopt and implement the reference model in ways that directly impact their businesses."
Hvis man tager fat i Henrik Hvid Jensens fire principper for serviceorienteret arkitektur består arkitekturen af følgende principper: distribueret; baseret på åbne standarder; procesorienteret og løst koblet (man kan diskutere om disse er tilstrækkelige - Lublinsky har også business driven og stateless invocation som to principper).
Ubetinget af 4 eller 6 principper så er den grundlæggende ide stadig understøtningen af interoperable arkitekturer på tværs af organisationer - her er man nødt til at overholde de standarder og principper igennem noget der ligner en fælles referencemodel.
Men det bliver mere og mere tydeligt at principperne må være op til fortolkning i SOA indenfor organisationers fire mure.
I et interview med Kåre Kjelstrøm fra Silver Bullet redegjorde han for hans tanker omkring "intern" og "ekstern" SOA - hvor den eksterne SOA følger principperne meget rigid er der "room for more slack". I den interne SOA hvor man af performance hensyn kan vælge at sige - "vi kører .NET eller J2EE som vores standard platform".
Microsofts nye Indigo udviklingsplatform kommer til at understøtte noget lignende - i systemkald imellem systemer vil den etablere det mest gunstige kommunikationsform - hvis det andet system også er Microsoft anvendes deres proprietære standard ellers anvendes webservices.
En sådan pragmatisk holdning er nødvendig for at komme i gang med "the learning experience of SOA". Små skridt af gangen. I en survey af webservices.org snakker man på samme måde om Webservices version 1 og version 2 - I version 1 anvendte 35% af adspurgte firmaer webservices til at skabe en standardiseret kommunikationsform imellem heterogene systemer. I version 2 vil fokus være ekstern for organisation og måske også over imod anvendelsen af service repository selvom jeg dog tror at det vil vare lidt endnu (især for private virksomheder).
Til at understøtte hele SOA arkitekturprocessen har Oasis-Open arbejdet på en SOA Reference Model som nu er i working draft. Modellen er udsprunget fra erkendelsen at SOA er anvendt i så mange forskellige kontekster at der er behov for at rydde op og klart definere arkitekturmodellen for SOA. I OASIS' SOA-RM har en SOA flere komponenter som alle er rettet imod arkitekturens centrale element - "services".
Services nedbrydes i fire afgrænsede aspekter nærmere betegnet:
⢠Descriptor
⢠Policy
⢠Contract
⢠Data Model
Derudover er der nogle tværgående anliggender:
⢠Semantics
⢠Discovery, Presence and Availability
SOA-RM udgør et abstrakt rammeværk til at forstå betydningsfulde entiteter og deres indbyrdes relationer i en serviceorienteret miljø og modellen understøtter udviklingen af konforme standarder og specifikationer som understøtter miljøet.
Jeg hilser denne udvikling meget velkommen da det vil kunne hjælpe med at få spredt SOA ud til ikke kun at være defineret af konsulenternes markedsføringsafdelinger men også akademisk anvendeligt med udgangspunkt i forskningsarbejde.
Samtidig vil en uniform model gøre det nemmere for virksomheder i at kortlægge deres roadmap for hvordan de vil tilbyde ekstern eller version 2 SOA.
SOA-RM eller ej så tror jeg at Ronald Schmelzer, senior analytiker ved ZapThink har ret i hans postulat i et Infoworld interview "Architecture is very difficult -- in fact, architecture is mostly a challenge for people, rather than technology [...] So, the SOA Reference Model will go a long way to helping people deal with the human aspects of making architecture work, but it will be up to companies to adopt and implement the reference model in ways that directly impact their businesses."
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.
