Spørgsmål til mine leverandør-kolleger. I forhold til NgDP.
Kig i Next Generation Digital Post - Technical Integration v1.0.pdf .
Afsnit 4.8.4 Receiving Memo.
Der er to måder et modtagersystem kan modtage Meddelelser på, når Modtagersystemet ønsker at bruge REST som transport-protokol.Det er:
Jeg læser det sådan, at uanset hvilken af de to modeller man ønsker at anvende, så skal Modtagersystemet udstille en REST snitflade som NgDP-platformen kan ramme.
Hvis Modtagersystemet benytter one MeMo over REST push så vil Modtagersystemet modtage den fulde MeMO i ét servicekald.Hvis Modtagersystemet benytter one MeMo over REST PULL publish subscribe så vil Modtagersystemet modtage en henvisning til en Meddelelse. Modtagersystemet skal herefter selv hente Meddelelsen.
Jeg vil gerne vide der gør at one MeMo over REST PULL publish subscribe er interessant at implementere. Er der leverandører der kan se en fordel her?
Baggrund:Jeg har selv været fortaler for at NgDP-platformen skulle have en pull-baseret model. Men sådan som den hér er implementeret giver den ikke de fordele som jeg gerne ville have: At Modtagersystemet ikke skal udstille en en REST snitflade som er tilgængelig på Internettet. Det er et ønske vi kender fra kunder der i dag har DP1/DP2-afhentningssystemer.Den form for pull-model jeg har haft i hovedet, når jeg har talt for en pull-baseret model, er den som vi kender fra DP1/DP2. I den model skal Afhentningssystemet kalde en service på DP1/DP2-platformen for at få udleveret IDer på Meddelelser der skal hentes, hvorefter Afhentningssystemet henter disse og kvitterer for modtagelsen.
Er der nogen use cases som vi som leverandører kan se, der gør at det er interessant/bedre at implementere one MeMo over REST PULL publish subscribe end one MeMo over REST PULL publish subscribe?
Hej Jens.
Som jeg husker det, skal modtagersystemet håndtere meddelelser op til 99MB.
Hvis jeg tager programmørbrillerne på, så tror jeg det er lettere at håndtere "download"/PULL af 99MB end at dit endpoint skal kunne modtage 99MB. Afhængig af implementering skal du have op til 99MB i memory pr. besked mens ngDP uploader til dig, da det hele givet sendes som form-data fra ngDP.
Jeg tænker også at ngDP i teorien kunne finde på at sende dig 50 PUSH uploads samtidig, der er ingen der siger at de sender en, venter til du er færdig og så sender en ny.
Hvis du kun modtager referencer, så kan du gemme dem i en databasen, og selv lave PULL en af gangen i det tempo du nu har lyst til, uden at risikere CPU/Memory problemer. Tænker du endda kan skrive løbende i en fil på disken og spare yderligere memory undervejs.
Hvis der er en hardcore programmør der kan korrigere så skyd :-)
Mvh Bent Cazper Kjeldsen
Hej
De møder vi har været til har alle givet os det indtryk at løsningen indeholder en PULL løsning.
Det som er beskrevet i 4.8.4.2 er IKKE en PULL løsning det forudsætter at der findes en PUSH løsning.
Man kunne så som Bent skriver betragte det som et gode vi selv kan hente nå vi vil MEN det ændre jo ikke ved at det bliver en mere komplicerede drift løsning.
Vi har rigtig mange decentrale løsninger kørende hvor hele løsningen er baseret på PULL derved er løsningen nem at håndtere pga. start til mål er en hele lige som Jens skriver. Det giver alle vores kunder en nem måde at vide om det virker/ ikke virker = billig/overskuelig/fjern overvågning osv…..
Hvis vi kigger på 0.9 er PULL ikke rigtig beskrevet så det er jo først nu vi kan gennemskue løsningen så har da en forventning at det bliver lavet om. Har også svært ved at forstå hvorfor PULL er lavet sådan det giver ingen mening.
DET ER EN OMMER…