Upload
azizi
View
83
Download
0
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
Sambruksplattformen – teknik mm
Wor
ksho
p5-6
maj
_tek
n.pp
t
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) !
Vad som här menas med systemintegration
• 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)
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...
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!
Delarna 1
• ”Middleware” för systemintegration i sig – Den tekniska "rörläggningen" som kan
förmedla meddelanden eller 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änsts webbapplikation och bakomliggande verksamhetssystem (eller ev sidoliggande e-tjänster) mot andra myndigheter mm.
– Principer för HUR 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
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!
Definitioner i femlagers-stack
”Ren datakom” TCP/IP dominant idag”Ren datakom”
HW
XML-schema t exSyntax-definition
Syntax-definition
Semantik-definition Word-dokument eller
RDF-schema etc
Semantik-definition
Svårt
Process-definition Visio-fil eller
BPML etc
Process-definition
Svårast
Jämför med den ”mera nertill detaljerade” sjulagers OSI-stacken
I vårt fall Web Services(ofta annars MQ eller förr Corba etc)
Välj integrations-produkt
Väljintegrations-produkt
Öve
rens
kom
mel
ser
Definitioner i femlagers-stack
”Ren datakom” TCP/IP dominant idag”Ren datakom”
HW
XML-schema t exSyntax-definition
Syntax-definition
Semantik-definition Word-dokument eller
RDF-schema etc
Semantik-definition
Svårt
Process-definition Visio-fil eller
BPML etc
Process-definition
Svårast
Jämför med den ”mera nertill detaljerade” sjulagers OSI-stacken
I vårt fall Web Services(ofta annars MQ eller förr Corba etc)
Väljintegrations-produkt
Väljintegrations-produkt
Öve
rens
kom
mel
ser
Anropsmässig trelagers-stack
”Ren datakom” TCP/IP dominant idag”Ren datakom”
HW
Kommuni-cerandeapplikation
Kommuni-cerandeapplikation
MQ i enkelt fall t exIntegrations-produkt
Integrations-produkt
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!
Topologier: Punkt-till-punkt
Appl 1 Appl 2
• 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...
= integr-logik
Topologier: ”Inter-application spaghetti”
Appl 1 Appl 4
• 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
Appl 2Appl 3
= integr-logik
Topologier: Nav (hub)
Appl 1
• 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)
Appl 2
Appl 4
Appl 3
= integr-logik
Topologier: Buss
Appl 1
• 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
Appl 2
Appl 4
Appl 3= integr-logik
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
1 4
2 3
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!
Några verksamhets-scenarios
• En prisfråga mot en leverantör– Frågan körs mot en lokal (replikerad) kopia av prisregistret
• 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”
Asynkron kommunikation, det är väl sämre än online?
• 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
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.
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!
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...
...men ACID kan ge problem
• 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
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!
Lösning 2: Långa transaktioner!
• 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
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
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!
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)
Vad är Web Services?
Web Services
Web Services är definitivt ingetentydigt begrepp!
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änster på 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.
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!
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