[Bitrepository-devel] Protokol-præciseringer

Kåre Fiedler Christiansen kfc at statsbiblioteket.dk
Tue Jul 12 19:54:08 CEST 2011


Hej alle,

Her kommer min opfølgning på mailen omkring protokol-ting.
Generelt tror jeg ikke vi har afklaret så meget om denne mail.

On Fri, 2011-06-24 at 13:22 +0200, Kåre Fiedler Christiansen wrote:
> Hej,
> 
> Ved implementationen af Get har vi identificeret følgende ting som vi
> ikke synes er helt klare når vi skal implementere.
> Nogle af dem er fordi den del af protokollen ikke er helt færdig, andre
> mangler vi måske blot at tage stilling, eller skrive en stilling vi
> allerede har taget ned.
> 
> Emnerne kommer i fire klumper.
> 
> === Behandling af beskeder ved modtagelse ===
> 
> Når vi modtager en besked, er der nogle måder vi skal opføre os på, som
> for nogle vist er aftalt, men jeg ikke er sikker på hvor er skrevet ned;
> og hvor andre er noget hvor vi blot skal have taget stilling.
> 
> 1. Modtagelse af beskeder hvor pillar IDs ikke svarer til os
> 
> Jeg tror det er vores aftale at de blot skal ignoreres, men er det
> skrevet ned noget sted?

Jeg har stadig ikke fundet et sted hvor vi har skrevet de helt basale
regler for hvordan man behandler beskedflowet ned. Jeg tror det skal stå
et sted her:
https://sbforge.org/display/BITMAG/Message+exchange+protocol

> 2.  Skal man sanityChecke de elementer der både findes i JMS headers og
> beskeden. Hvad skal man gøre hvis de er forskellige? (CorrelationID,
> BitRepositoryCollectionID, ReplyTo, To (kan sammenlignes med
> destinations man lytter på), type)
> 
> Jeg synes det vil være en god idé at sanitychecke - men jeg er ikke
> sikker på hvordan det skal håndteres.
> Hvad vi skal gøre hvis checket fejler? Jeg foreslår vi blot logger en
> fejl lokalt og fortsætter. Jeg foreslår at det blot er en anbefaling til
> pillar, og ikke et krav.
> Hvem "vinder" hvis headeren er uenig med beskeden? Jeg foreslår beskeden
> altid vinder (dog ikke med "To" - den er jo allerede modtaget). Det
> synes jeg vi skal gøre til et krav.

Med Jun's input tror jeg at det mest meningsgivende måske er at sige at
det er op til aftageren af en besked at vælge hvilken værdi man bruger:
Den fra headeren eller den fra XML'en - og sige at hvis de er
forskellige er opførslen udefineret. Det er rigtigt at ellers kunne vi
lige så godt lade være med at duplikere beskederne.

Det bør dog beskrives her:
https://sbforge.org/display/BITMAG/Division+of+message+content+between
+xml+and+message+headers

Og der bør udvides med at det er et krav at duplikere data i headers -
ellers kan vi ikke bruge det.

Dog bliver vi nødt til at bruge ReplyTo fra headers, da temporære
destinationer ikke kan reproduceres fra informationer i XML'en efter
hvad jeg kan se.

> 3. Hvad skal man gøre hvis der ikke er et correlationID i beskeden?
> 
> Ignorer? Generer et correlationID? Benyt JMS message ID? Jeg foreslår vi
> anbefaler at man benytter JMS message ID men ikke gør det til et krav.

Jeg er slet ikke sikker på hvor brug af correlation ID er beskrevet. Det
skal beskrives helt firkantet, og jeg synes det skal beskrives i pinlige
detaljer hvem der har ansvar for at generere det hvornår, med klare
krav. Det bør stå et sted der er henvist til herfra:

https://sbforge.org/display/BITMAG/Message+exchange+protocol

> === Svar med "fejlkoder" og alarmer ===

For hele denne sektion tror jeg vi burde have to sektioner på wiki'en:
På en underside til
https://sbforge.org/display/BITMAG/Message+exchange+protocol
skal vi beskrive konceptet omkring alarmer og fejlkoder; og derudover
skal der for hver underside af
https://sbforge.org/display/BITMAG/Functionality
beskrives konkrete alarmer og fejlkoder.

> Her er vi vist ikke helt klar med specifikationen - men kan vi tage
> nogle første her-og-nu valg?
> 
> 1. Der er et fundamentalt problem lige nu, med at
> IdentifyPillarsForGetFile ikke kan sende fejlkoder med i svaret. Det er
> vist i modstrid med hvad vi har aftalt, da vi ønsker at pillars kan
> svare selvom de ikke har filen, så klienter ikke skal vente på et
> timeout.
> 
> 2. Lige nu tror jeg det eneste sted der er en specifikation af mulige
> fejl-koder er i Eld's proof-of-concept-fejlkoder i XSD'erne. Det ville
> være godt at få et sted at vedligeholde en liste af hvad der er og
> hvornår det skal bruges.
> Tilsvarende med hvilke alarmer der skal sendes hvornår.
> 
>  * Her er en liste af potentielle "Negative svar" og alarmer vi har
> identificeret
>    * Potentielle negative svar på enhver besked
>       * Ukendt BitRepositoryCollection
>       * Uunderstøttede versioner (også alarm?)
>       * Ugyldig XML (også alarm?)
>       * Fejl i sanitycheck - se ovenfor (også alarm?)
>       * Intet correlation ID - se ovenfor (også alarm?)
>       * Intern pillar-fejl forhindrer behandling (også alarm?)
>    * Potentielle negative svar ved IdentifyPillarsForGetFile
>       * File not found
>    * Potentielle negative svar ved GetFile
>       * File not found
>       * Del af fil requested men ikke understøttet
>       * Ingen/ugyldig URL angivet til at levere fil på
>       * Problemer med at uploade filen til den givne URL (også alarm?)
> 
> 3. I hvilke beskeder skal man sende fejlkoder? Jeg forventer at en
> fejlkode betyder at konversationen er afsluttet for den pillars
> vedkommende, og de derfor ikke skal sendes i
> "ProgressResponse"-beskederne, som indikerer status undervejs, men
> derimod i "FinalResponse"-beskederne.
> 
> === TimeToDeliver ===
> Jeg tror vi har aftalt at time-to-deliver er optional, men hvis den angives er det den forventede tid før man kan begynde at levere - men er det skrevet ned nogen steder?
> 
> Vi har også snakket om at man kan give opdaterede estimater i ProgressResponse-beskeder. Men det kan på nuværende tidspunkt ikke sættes i beskeden.

Stadig udestående.

> === Request af flere filer i én GetFile-besked ===
> 
> Det er noget vi har snakket om nogen gange, men jeg ved ikke rigtig hvor
> vi står. 
> 
> Er der et use case for det? Eller skal vi blot droppe understøttelsen
> helt. Jeg tror det er mig selv der har foreslået det for at kunne
> gruppere requests til at brunge offline-medier online, men det kan i
> virkeligheden klares lokalt på en pillar - på SB tape pillar'en husker
> vi filer der er requested, men genererer kun et job til at bringe dem
> online med passende mellemrum. Det giver samme effekt.
> 
> Hvis vi skal understøtte det mener vi der er et problem i at der er kun
> én URL i beskederne, så vi ved ikke hvordan man skal levere flere filer.

Jeg synes stadig vi blot skal droppe muligheden for at requeste flere
filer i en besked.

Hilsen
  Kåre



More information about the Bitrepository-devel mailing list