XML, webservices og store mængder data

I dag har IT- og Telestyrelsen tænkt sig at gøre noget problemerne ved at sende store datamængder gennem webservices. De har inviteret til en workshop - i indkaldelsen står der noget om, at relevansen af ønsket om at sende store datamængder ikke er blandt de emner, der vil blive diskuteret. Men jeg har nu tænkt mig at forsøge alligevel når jeg dukker op.

For selv om der er scenarier, hvor en service kræver store datamængder, så ser jeg ofte situationer hvor konceptet 'service' misforstås og misbruges til at sende batch-agtige klumper af transaktioner at sted. Den tilgang til service-orientering skal hurtigt muligt aflives.

Et almindeligt eksempel på denne misforståelse og misbrug er overførsel af en batch af fakturerer, hvilket kan give ret store dokumenter. Men én faktura fylder nu ikke meget ? først når du sætter 10.000 af dem sammen i ét service-kald giver det problemer.

Så den bedste løsning er i stedet at se sine forretningsprocesser igennem med et kritisk blik: En fil med 10.000 fakturerer er egentlig 10.000 forretningstransaktioner som kan afvikles gennem 10.000 asynkrone service-kald i parallel. Jep, der er overhead på hver transaktion, men hardwaren skalerer jo fint og båndbredde falder i pris måned for måned.

SOA er bedst til håndtering af forretningsobjekter der hver for sig flyder gennem forretningsprocesser i et proces-rammeværk ? og er ikke velegnet til batch-overførelser fra fortiden. Så når vi SOA-enabler de gamle batch-siloer skal det gøres med omtanke.
Jeg er spændt på om der virkelig er så meget behov for de store datamængder (som der kan være til varekataloger og den slags) ? eller om de store datamængder oftere er et falskt problem.

Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lars Hansen

Jeg ved fra tidligere erfaringer at netop sådan noget som varekataloger kan være en udfordring. XML er netop velegnet her, fordi der kan være forskellige typer af attributter afhængig af varetypen. Samtidig kan det også være sådan at HELE kataloget skal godkendes eller afvises (sådan er forretningsprocessen altså). Der er så bare det problem at nogle virksomheder har 10 varer i sit sortiment mens andre har 5000+.

Men jeg går trods alt ud fra at det er et ret begrænset antal tilfælde hvori den slags problemstillinger indgår. Men jeg håber da at du vil fortælle os hvad IT- og Telestyrelsen har af forklaring på relevansen.

  • 0
  • 0
#2 Mikkel Meyer Andersen

Interessant emne! Jeg har netop for nylig haft behov for at eksekvere en webservice med >5000 objekter. Hvert objekt kun kunne sendes afsted separat, hvilket resulterer i mange transaktioner. Ved tests tog det ca. 10 sek. pr. objekteksekvering. Det er noget af en behandlingstid! Men hurra for multithreading: ved at sætte 15 tråde til at køre parallelt gav det næsten 1/15 behandlingstid (da alle objekterne blev indsamlet i starten af kørslen, var det lige til at dele disse ud til de respektive tråde). Og så tager jeg hatten af for C#/.NET - det er nemt at blande webservices, multithreading osv. for derved at opnå effektive programmer (at man så skal sno sig for at få C# til at behandle ImsExceptions er en anden sag).

  • 0
  • 0
#3 Anders Østergaard Jensen

Jeg kan sagtens nikke genkendende til din problemstilling, og det vel -- med enhver protokol, der genererer et overførselsmæssigt overhead -- uafgængigt af servicelaget (om der står SOA foran eller ej). Men det er svært at afhjælpe problemet, hvis der er et overordnet behov for transaktionsstyring (og det er vel derfor, man afvikler en stak objekter i én kørsel).

Så snart man skriver sine objekter ned i en database med et krav om rollback, hvis noget fejler, er det ikke særlig hensigtsmæssigt at køre alt i asynkrone SOAP-kald. Så jeg vil på det kraftigste overveje at holde web service-diskussionen uden for et "klassisk" arkitekturproblem, der vel ret beset bør afkobles helt fra al SOA-snakken.

  • 0
  • 0
Log ind eller Opret konto for at kommentere