Sambruksplattformen – teknik mm

Sambruksplattformen – teknik mm Workshop5-6maj_tekn.ppt

Agenda • Bakgrund • Vad är det för områden som behövs? • Några begrepps-stackar • Topologier • Temporal kvalitet - aktualitetskrav • ACID, långa transaktioner • Web Services • Avrundning • Ställ gärna frågor under tiden!

Visionen 1 Fråga: Ska de övre rektanglarnakunna VARA verksamhetssystem...?

Visionen 2 Mycket av fokus kommer att vara klassisk system-integration (och modern för dendelen) !

Egentligen ett vitt begrepp Två eller flera applikationer behöver kommunicera Fokuserar här på kommunikation över nätverk mellan system/applikationer (Många av aspekterna kan gälla även för kommunikation utan nätverk, liksom för client/server-kommunikation) Vad som här menas med systemintegration Appl 1 Appl 2

”100% Buzz Word Compatible” • EAI (Enterprise Application Integration) • Integration Broker • B2B, A2A (Business to business, application to application) • EDIFACT (FN. Trög start men ökar fortfarande!) • DACOM (Inget är nytt under solen; Datemas 70-talssystem) • XML och XSL (är bara en komponent) • Web Services (är bara en komponent) • SHS (Myndigheternas Spridnings- och HämtningsSystem) • Data Warehouse (Kan vara fel att använda för operativ integration) • MOM, Message Broker (Message Oriented Middleware, modeord ca 1995) • mm mm...

Delarna 1 • ”Middleware” för systemintegration i sig • Den tekniska "rörläggningen" som kan förmedla meddelandeneller anrop (API:er) mellan applikationer. Utförs med enkla Web Services.

Delarna 2 • Teknik-meddelanden • Diverse "kring-saker" som behövs för att en applikation ska fungera, t ex användar-hantering, roll-hantering,aktivitetsloggning, felhantering mm.

Delarna 3 • Funktions- meddelanden • Själva nytto-meddelandena som tänks mellan en e-tjänstswebbapplikation och bakomliggande verksamhetssystem (eller evsidoliggande e-tjänster)mot andra myndigheter mm. • Principer förHUR dessa API:er ska specificeras (syntax, semantik, sekvens, kontext, kommunikationsprofil etc) ingår i teknikdelen, inte VILKA API:erna är och vad de innehåller, det ingår i info-modelleringsjobbet! Stort!

Delarna 4 • Regler och konventioner • Hur ska anrop ske • Vilka saker måste vara givna • Ett antal givna kommunikationsprofiler där någon/några normalt SKA användas (t ex vad gäller transaktioner, aktualitetskrav, asynk/synk, leveransskydd eller ej mm) • Rutiner för hur undantag från föregående går till • Kokbok

Process-definition Process-definition Visio-fil ellerBPML etc Svårast Semantik-definition Semantik-definition Word-dokument ellerRDF-schema etc Svårt Syntax-definition Syntax-definition Överenskommelser XML-schema t ex Välj integrations-produkt Väljintegrations-produkt I vårt fall Web Services(ofta annars MQ eller förr Corba etc) Jämför med den ”mera nertill detaljerade” sjulagers OSI-stacken Definitioner i femlagers-stack ”Ren datakom” ”Ren datakom” TCP/IP dominant idag HW

Process-definition Process-definition Visio-fil ellerBPML etc Svårast Semantik-definition Semantik-definition Word-dokument ellerRDF-schema etc Svårt Syntax-definition Syntax-definition Överenskommelser XML-schema t ex Väljintegrations-produkt Väljintegrations-produkt I vårt fall Web Services(ofta annars MQ eller förr Corba etc) Jämför med den ”mera nertill detaljerade” sjulagers OSI-stacken Definitioner i femlagers-stack Tips: överteoretisera inte! ”Ren datakom” ”Ren datakom” TCP/IP dominant idag HW

Kommuni-cerandeapplikation Kommuni-cerandeapplikation Integrations-produkt Integrations-produkt MQ i enkelt fall t ex Anropsmässig trelagers-stack ”Ren datakom” ”Ren datakom” TCP/IP dominant idag HW

Topologier: Punkt-till-punkt Appl 1 Appl 2 = integr-logik • Såsom visat i ”stackarna” på tidigare bilder • Vanligaste varianten • Låg komplexitet • Ex: MQ Series, MSMQ, JMS, batchfiler, datareplikering, DCOM, EJB/RMI, Unix-RPC, enkla Web Services...

Topologier: ”Inter-application spaghetti” Appl 1 Appl 4 Appl 3 = integr-logik Appl 2 • Problem-scenario om man använt punkt-till-punkt mellan för många applikationer • Svårt överblicka konsekvenser vid förändringar • Dyrt ifall en applikation ska bytas ut

Topologier: Nav (hub) Appl 1 Appl 4 Appl 3 Appl 2 = integr-logik • Topologin för många avancerade integrationsprodukter • Minskar risken för ”inter-application spaghetti” • Potential för kontrollerad alla-till-alla-kommunikation • Risk för duplicerad affärslogik i ”routing-logiken” • Viktigt att info-modellera ”objekt-modell” • Erbjuder vanligen info-formatkonvertering • Ex: BizTalk, Mercator, AMTrix, SHS (i viss mån)

Topologier: Buss Appl 1 Appl 4 Appl 3 = integr-logik Appl 2 • Topologin för vissa avancerade integrationsprodukter • Minskar risken för ”inter-application spaghetti” • Potential för kontrollerad alla-till-alla-kommunikation • Viktigt att info-modellera ”subjekt-modell” • Anpassningslogiken hamnar nära respektive applikation • Ex: TIBCO

1 4 3 2 Topologier: Sambruksplattformen • Vi måste vi nog nöja oss med en ”kontrollerad kompromiss” • En övervikt kan man dock förvänta av meddelanden från en e-tjänst och inåt mot verksamhetssystem eller andra myndigheter • De avancerade integrationsprodukterna (EAI) vore alldeles för dyra och komplicerade

En prisfråga mot en leverantör Frågan körs mot en lokal (replikerad) kopia av prisregistret Några verksamhets-scenarios • En lagersaldofråga mot en leverantör • Frågan körs online mot leverantören • En faktura går till en kund • Fakturan överförs via en kö på någon kvart till kunden Behoven ska styra ”aktualitetskrav”

Mikrosekund-färskt data överallt är väl trevligt som idé... Men riskerar ge sämre stabilitet, längre svarstider, sämre skalbarhet, högre kostnader Särskilt via ett medium som Internet eller ett stort WAN ...och ofta behöver inte allt vara så extremt färskt, 1-10 min fördröjning eller mer kan vara helt OK beroende på verksamhetskraven Asynkron kommunikation, det är väl sämre än online?

Sannolikhet för stabilitet • En utmaning att få hög ”uptime” för ett sammansatt system med hårda beroenden • Obeveklig sannolikhet: Multiplicera sannolikheterna; 0,95*0,95*0,95 = 0,85 t ex • Asynkron grundkaraktär kan möjliggöra att presentation görs allteftersom, jmfr Web • Befordrar även upplevd prestanda, anrop kan ofta ske parallellt i tiden

Asynkront med/utan leveransskydd? • Enkel meddelandeförmedling utan leveransskyddande kö kan vara rätt då meddelanden kan få komma bort och prestanda är viktigast, t ex börskursinfo mm • Eller i client/server – att ett asynkront svarsmeddelande har kommit kan vara ”självmarkerande” • Asynkront med leveransskydd passar extra bra bör ”backoffice”-flöden, aviseringar till andra system, transar till ekonomisystem mm mm.

Asynkront med Web Services • Tyvärr kan man inte säga att beprövade Web Services (såsom vi vågar använda dem) i sig stödjer asynk. Ännu mindre med leveransskydd. • Sambruksplattformen måste istället definiera kommunikationsprofiler med vissa regler för hur anslutna applikationer utförs, t ex med databasköer.

ACID • Atomicity, Consistency, Independency, Durability • Kallas även atomära transaktioner eller allt-eller-ingen-uppdatering (ofta two-phase-commit - 2PC) • Uppdateringar garanteras att inte kunna bli ”halva” • Självklart för relationsdatabasuppdateringar men inte idag för systemintegration • Utan ACID risk att t ex en försäljning registreras i handelssystemet men tappas bort i ekonomisystemet • Egentligen borde man alltid sträva mot ACID...

Inkompatibla teknikmiljöer (trots XA-initiativet t ex) En del system-integrationsprodukter stöder inte alls ACID Ger hårda beroenden (versionsbyten, leverantörsinlåsning etc) Risk får dålig ”uptime” Kan bli riktigt långsamt (faktor 10 kan vara realistiskt) Dålig skalbarhet pga långa databasinterna lås vilket ger deadlock-timeout Även om standarden WS-Transactions för Web Services numera finns så är den inte alls beprövad ...men ACID kan ge problem

Lösning 1: Avstämningar! • Välfungerande 60-talslösning • Skapa buntsummor, dagssummor e dyl i bägge ändar, skicka dessa en annan kommunikationsväg • Manuell koll eller automatiskt larm • Korrigera manuellt eller automatiskt • Manuell korrigering kan mycket väl vara optimalt!

Klar trend nu att koppla lösare vid system-integration (delvis pga Web Services-trenden) Måste därvid tänka att en ”transaktion” kan pågå i timmar, dagar eller veckor innan den är definitiv Behövs ”compensation schemes”, dvs backnings-funktioner insystemerade i applikationerna! Dessa initieras manuellt eller automatiskt Lösning 2: Långa transaktioner!

Misslyckad uppdatering --> larm • Undantaget kan vara logiskt. T ex: • Inga pengar på kontot • Slut på varan i lagret • Undantaget kan vara tekniskt. T ex: • Ena databasservern har hög last och ger timeout • En uppdaterande Web Service över Internet ger timeout medan lokal uppdatering gått vägen • Löser ut olika logik beroende på behov, t ex compensation-verb

Web Services för integration • Stora förhoppningar knyts till Web Services för integration • Både inom en verksamhet och emellan verksamheter (A2A och B2B) • Den allra största fördelen är interoperabilitet mellan helt olika teknikplattformar • Den andra fördelen är enkelhet (än så länge i alla fall)

Web Services Web Services är definitivt ingetentydigt begrepp! Vad är Web Services?

Man brukar mena åtminstone tre olika saker med Web Services • Enkla fjärranrop(~RPC)Praktiskt beprövat. Ger mindre plattformsberoende.Anropsparterna ”känner” varandra. Protokollet SOAP över http(s).Stort stöd hos IBM, Microsoft och BEA. Hög aktivitet. • Hitta och använda tjänsterpå InternetEj så beprövat. Visionen om on-line-leverantörsval, B2B (business-to-business) etc.UDDI-katalog för att hitta tjänst. SOAP för att använda tjänst. • Business processing-visionenEj beprövat. ebXML etc. Ambitiöst teoribygge, risk ta lång tid. Delresultat kan dock influera WS-världen praktiskt.Jämför med EAI-produkter (Enterprise Application Integration).

Web Services och integration • Observera att enkla Web Services (SOAP/http) såsom det är rimligt realiserbart idag/snart inte alls har samma kompletta scope som t ex EAI-produkter eller SHS har, t ex vad gäller: • Asynkront med leveransskydd (säker kö) • På gränsen att asynkront överhuvudtaget ska anses finnas med SOAP/http • Routing • Konvertering • En-till-många • ACID (finns dock ny, ej beprövad standard) • mm

Web Services i Sambruksplattformen • Vi måste fokusera på det som är rimligt enkelt och beprövat och ger bra interoperabilitet • Därmed endast enkla fjärranrop via Web Services över SOAP/http(s) • Sambruksplattformen måste över tiden få nya utgåvor, kanske kan man i framtiden inkludera delar av ebXML e dyl.

Avrundning • Den stora utmaningen blir att skapa funktions-meddelanden dvs den verksamhetsmässigt användbara semantiken och syntaxen • Det gäller att hålla igen så inte tekniken i Sambruksplattformen blir för komplex – då bleve det lika dyrt som en stor EAI-produkt;”Det bästa är det godas fiende” • Kokbok, råd och utbildning blir synnerligen viktiga komponenter för framgång! • Plattformen måste förvaltas, få ”fixar” och framtida versioner

Sambruksplattformen – teknik mm