Dette indlæg er alene udtryk for skribentens egen holdning.

Profilen for de overvægtige web services: XLWS

2 kommentarer.  Hop til debatten
Blogindlæg7. februar 2008 kl. 00:01
errorÆldre end 30 dage

En af mine kolleger sendte forleden en intern email rundt med et link til en lang række facts om Service Orienteret Arkitektur (SOA). Jeg skal advare om at det er stærke sager i kaliberen:

SOA is being used in the developing world to solve hunger. Entire populations will be fed on future business value.

SOA og i særdeleshed den variant der bygges op omkring web services med XML er for længst blevet god tone på CIO kontoret. Men hvor SOA begrebet med sin lidt uldne overflade og whiteboardvenlige kulør er så overskueligt i 50.000 fods højde, forholder det sig helt anderledes når det skal realiseres med web services i jordhøjde. Her har ivrige teknikere nemlig i årevis flittigt beriget verden med den ene WS-specifikation efter den anden, der overlapper, konkurrerer og alle gør krav på titlen "standard".

Måden at håndtere denne underskov af specifikationer på er at sortere i dem og profilere dem der overlever. En profil skærer gennem mylderet for specifikke brugsscenarier og skræller alt det fedt fra, der ikke er relevant i den konkrete sammenhæng.

Artiklen fortsætter efter annoncen

Imidlertid er der trods den flittige skare af teknikeres anstrengelser endnu områder der ikke er dækket og derfor heller ikke profileret. Et af disse drejer sig om udveksling af meget store dokumenter.

Overvægtige data

Med store datamængder bliver skalerbarhed, konfidentialitet, integritet, performance, pålidelighed og andre nonfunktionelle egenskaber krydret med ekstra kompleksitet. Når man har brug for at sende virkeligt store mængder data er det f.eks. pludselig ikke spor morsomt at forbindelsen ryger efter at 99% af de 200MB er overført på 20 minutter uden at det i øvrigt er muligt at gøre andet end at starte helt forfra.

Det er heller ikke bare lige sådan at foretage digital signering med en enveloped XML Signature fordi specifikationen ikke (altid) egner sig til streaming. Signaturen kan nemlig være indlejret i de data der signeres, hvilket øjeblikkelig nødvendiggør en two-pass algoritme.

Der overføres selvfølgelig store filer mellem forskellige organisationer i dag, klassifikationer, fakturaer, kataloger, etc. Mange sætter en FTP server op og opfinder en katalog- og navngivningsstruktur der gør det muligt at adskille data fra forskellige klienter, andre anvender SCP eller måske endda HTTP.

Det gør de bla. fordi der altså ikke er en profil der bare lige passer ind i en web service verden og stablen af dybe tallerkener i forskellige farver og former indenfor området er således faretruende høj.

Denne mangel har IT- og Telestyrelsen tænkt sig at gøre noget ved og inviterer derfor til en workshop, hvis formål er at definere forretningskrav og en teknisk løsning på de overvægtige web services. Resultatet skulle gerne blive en profil der én gang for alle hamrer en pæl ned i problemstillingen, XLWS.

Der er gratis adgang til arrangementet, så hvis du har stødt på problemet og måske endda har en holdning til en god løsning håber jeg vi ses den 12/3! For hvem ved: Måske er dette den afgørende brik i at løse hungersnødsproblemerne i denne verden én gang for alle ...

2 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
2
17. februar 2008 kl. 13:12

Hej Peter,

Beklager den sene respons: Der kom lige en skiferie i vejen.

Nu er vi stadig på tegnebrættet og har ikke klart defineret scopet af opgaven så med det forbehold: En af de datatyper jeg selv har i tankerne er klassifikationer f.eks. varekataloger, organisationstræer o.lign. som mange systemer indenfor samme domæne vil have behov for at dele.

I nogle scenarier vil det være fint nok blot at kunne lave et online opslag mod en klassifikation, men i andre duer det ikke af performancehensyn (ved lookupfelter i opslag på datasæt) eller af robusthedshensyn (dette system SKAL være online uanset om forbindelsen til den ydre verden er nede f.eks. fordi det anvendes til medicinsk behandling). Der har man brug for en lokal (read-only) kopi.

Du har utvivlsomt ret i at mange batch-scenarier vil kunne håndteres med andre midler herunder mange parallelle kald, men jeg føler mig nu stadig overbevist om at problemstillingen er der.

Jeg regner med at vi ses den 12/3. Så kan vi jo sammen prøve om vi kan skyde de forretningsscenarier der bliver stillet op i sænk - eller designe en profil der kan håndtere dem :-)

/Kåre

1
10. februar 2008 kl. 00:45

"Mange bække små giver en stor å" – det gamle mundheld hylder sparsommelighed på bekostning af en mere flamboyant (og egentlig ganske tiltalende) livsstil. Men at samle bække (forretningsobjekter) sammen til åer (batches af forretningsobjekter) er ikke så fikst i en SOA-sammenhæng.

Mange store, overvægtige webservices er komponeret af små bække. For der findes egentlig ikke så mange store (>1 MB i XML-format)forretningsobjekter, vel? Er problemet ikke oftere at XML webservices (og en SOA) misbruges til at håndtere filoverførsel i forbindelse med batch-afvikling?

Kåre, du nævner overførsel af fakturerer som noget der giver 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 forretningsprocsser igennem med et kritisk blik: Din 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 flyder gennem forretningsprocesser i et proces-rammeværk – og er ikke velegnet til batch-overførelser fra fortiden. Så når vi SOA-enabler en gammel batch-silo, så skal det gøres med omtanke.

Og så fandt jeg mit yndlingscitat fra sitet du nævner: ”Peace is not merely the absence of violence, but also the presence of SOA.”