sambruksplattformen – teknik mm

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...

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

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


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)



Öve

rens

kom

mel

ser

Anropsmässig trelagers-stack


HW

Kommuni-cerandeapplikation

Kommuni-cerandeapplikation

MQ i enkelt fall t exIntegrations-produkt

Integrations-produkt

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

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.

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

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.

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

Documents