Blogg
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Måndagen gav intressanta inblickar i Amazons strategier för att nå hög tillgänglighet i sina tjänster. Tjänster blev förresten temat för dagen, vad mig anbelangar. Efter en presentation av server-scriptspråk för enkelt nyttjande av SOA-tjänster, kom dagens höjdpunkt: ett praktikfall på en SOA i megaskala: Danska statens satsning på webservices för ehandel.
Werner Vogels höll en Keynote som blev en blandning mellan Amazon-reklam och en essay över problematik kring skalbarhet. Som grund för sitt anförande om skalbarhet refererades en modell för prioritering mellan tillgänglighet, korrekthet och svarstider. Jag fick associationer till projekt-styrningstriangeln: funktionalitet - kostnad - tid. I båda fallen gäller att två sidor kan låsas, men inte tre. I skalbarhetstriangeln har Amazon valt att alltid låsa svarstidskraven, men att moderera korrekthet och tillgänglighet.
För transaktioner kring betalningar är det förstås mindre förvånande att man inte kompromissar med korrekthet. För övriga funktioner kan asynkron uppdatering gynna skalbarhet. Man upplever att användaren accepterar “ganska aktuell” information (t.ex. lagersaldo), om applikationen ödmjukt ber om ursäkt då det är sannolikt att användaren upplevt en negativ effekt av brister i korrekthet vad gäller information.
Amazon mäter tillgänglighet i termer av användarens upplevelse, snarare än funktionernas absoluta driftsstatus. 15 minuters stop var annan dag är värre en kontinuerliga krascher som var och en ger en fördröjd svarstid på någon sekund. Amazon utgår ifrån att applikationer kommer att krascha, snarare än att investera i att infrastrukturen ska garantera 99.9999% tillgänglighet. Varje applikationsteam har som uppdrag att leverera applikationer som kan överleva en krasch i klustrad miljö. Vidare kräver man av applikationer att kunna partitioneras under drift. Ett exempel skulle kunna vara att flytta kunder för en region från en databas till en annan.
Werner Vogels betonade vikten av att lösa skalbarhetsfrågan utifrån varje enskild applikations förutsättningar. Om man inte tar med applikationers funktionalitet och specifika utmaningar och möjligheter, hamnar man lätt i “upfront design” i termer av dyr och komplex generell skalbarhetsteknologi inom infrastrukturområdet.
Steve Vinosky är chefsarkitekt för IONA. Han inledde med att förklara varför skriptspråk har så dåligt rykte på serversidan: För många arkitekter försöker vara “Enterprisey”.
Från “Signes you are a crappy programmer”
This is serious stuff dammit. “Enterprise” is not just a word, it’s a philosophy, a way of life, a path to enlightenment. Anything that can be written, deployed or upgraded with minimal fuss is dismissed as a toy that won’t “scale” for future needs. Meanwhile most of the real work in your office is getting done by people sending around Excel spreadsheets as they wait for your grand enterprise visions to be built.
Tänkvärt… Nåväl - han visade ett script-språk baserat på Javascript, som utökats med stöd för xml-hantering. Många i publiken, inklusive jag själv, blev nog lite besvikna över att det behövdes ett språk till. Skulle inte Groovy kunna göra nytta som SOA-script-språk? Eller varför inte BPEL-script i form av ett riktigt skripspråk, så att man slipper så väl XML som “doodleware” i form av grafiska editorer?
Danska staten är i full färd med att standardisera en Web-Service-baserad infrastruktur. Infrastrukturen syftar till att effektivisera myndigheternas arbete, genom automatiserade tjänster. Det fanns förstås ett tydligt drivande affärsfall: Man skulle spara ett halvt manår per företag som går över till elektronisk fakturering. Man genomför sedan tidigare elektroniska affärer mellan stat och näringsliv. Användningen av EDIFACT har dock utestängt många små och medelstora företag, p.g.a. pris och komplexitet. Den nya infrastrukturen ska därför fungera över Internet.
Lösningen består av följande delar:
Profilen är baserad på WS-I Basic Profile 1.1. Man har dock varit tvungen att ytterligare styra upp användningen av olika web-service standards. Det beror framför allt på att man tillämpar standarden WS-ReliableMessaging och WS-Addressing, som ännu inte profilerats av WS-I. De ingår dock i WS-I BP 1.2, som planeras vara klar under hösten. Man har utgått från asynkrona flöden för att inte kräva att varje litet företag ska behöva ha en 24/7-infrastruktur. Man stödjer http och SMTP (email) inom ramen för WS-Reliable Messaging. Infrastrukturen i sig (via profilen) standardiserar bara SOAP headern. Standardiseringen av meddelandeformat för olika typer av transaktioner, sker via standardiseringsorgan och är frikopplat från den levererade SOA-infratsrukturen.
För att underlätta för företag att integrera via infrastrukturen, finns en verktygslåda för att skapa service-agenter och implementationsstubbar för Java och Net. Man tillhandahåller också en online-tjänst där man kan få SOAP-meddelanden testade för kompatibilitet.
Danmark har en etablerad infrastruktur för medborgarcertifikat. Varje företag som ska interagera med staten via den nya infrastrukturen, måste ha ett certifikat registrerat i en nationell ldap-databas. på så sätt kan man tillämpa signering och kryptering i enlighet med WS-Security, som stöd för säker Web Service trafik.
Danmark har valt att använda den relativt komplicerade registry standarden UDDI. Man har dock begränsat användningen till ett litet antal attribut för att unikt hitta en partners webservice URL: Tjänst, version, organisationsnummer och version av profilen.
Är Sverige för stort för att lyckas med Danmarks konststycke? Eller är Danskarna helt enkelt smartare? I mitt nuvarande uppdrag inom Västra Götalandsregionen, har jag haft möjlighet att göra ett referensbesök i Danmark. Man har sedan tidigare etablerat en WebService standard man kallar för “Den Gode Web Service”, som drivits av behov av att integrera sjukvården. Den är överlappande med det statlig initiativet - men ändå - Danmark har TVÅ nationella standards - och vi har ingen