e-gov / dhx Goto Github PK
View Code? Open in Web Editor NEWDokumendivahetusprotokoll DHX | Document exchange protocol using X-Road
Home Page: https://www.ria.ee/dhx
License: MIT License
Dokumendivahetusprotokoll DHX | Document exchange protocol using X-Road
Home Page: https://www.ria.ee/dhx
License: MIT License
Protokoll ei keela seda. Küll aga tekib küsimus, mis oleks mitme vahendaja mõte? DHX ei paku saatjale teavet, millega too saaks otsustada, kummale dokument saata. Üheaegselt mitme vahendaja olemasolu võib viidata sellele, et vahendaja vahetamisega on midagi sassi läinud - asutus on lisatud uue vahendaja vahendusnimekirja, vana ei ole aga asutust eemaldanud. Siiski ei saa seda alati käsitada veaolukorrana.
X-tee nimeruumi predefined osa – ka kuskil X-tee dokumentatsioonis peaks olema tulevikus kirjas, et DHS/vms-nimelise infosüsteemi puhul kehtib X-tee EE/GOV nimeruumis eraldi reeglid (vt ülal). Et selle abil saaks siis hiljem automaatselt DHX protokolli kasutajaid leida. Paralleelselt/alternatiivselt tuleks kirjeldada ka, et sendDocuments pole EE/GOV osas vabas kasutuses.
........
Mõistlik oleks hoida DHX X-tee protokollist lahus – selles mõttes, et DHX kasutab X-tee protokollistikku (transpordikihina, e-identimise ja adresseerimise süsteemina), kuid ei ole X-tee protokolli osa ning X-tee protokoll üldse ei nimeta DHX-i. Aga kas see on võimalik?
Praktiliseks, aga ka juriidiliseks küsimuseks võib kerkida, kas X-tee liige, leides teise liikme teenuse sendDocument – või eeldades sellises teenuse olemasolu võimalust - võib eeldada, et tegu on DHXi teenusega? Kui X-tee kasutajate ja DHX-i kasutajate hulgad ei lange kokku, siis ta ei saa seda eeldada.
Liige A tahab saata liikmele B dokumenti, kasutades DHXi. Praeguse protokollikavandi kohaselt liige A paneb dokumendi „pimesi“ teele - katsetab, kas liikme B teenus sendDocument võtab dokumendi vastu.
Ei ole välistatud, et liikmel B on sama nimega, kuid erineva semantikaga, mitte-DHX teenus.
Kuna DHX ei ole X-tee protokolli osa, siis ei saa X-tee kasutamisest iseenesest tekkida X-tee liikmele kohustusi DHX-i suhtes midagi teha või arvestada. DHX-st ei saa tekkida X-tee liikmele kohustusi muul viisil, kui: 1) liige ise otsustab DHX-i kasutada; 2) DHX-i kasutamise kohustus pannakse mingile X-tee liikmete rühmale.
Seega X-tee liige B (kes ei ole DHXi kasutaja) võib teha teenuse sendDocument, mille sisu erineb DHXi sendDocument teenusest. X-tee reeglid ei keela tal seda tegemast.
Tekib semantiline konflikt – mitte-DHX teenus võib saadetist valesti tõlgendada. Ei ole välistatud isegi rasked tagajärjed.
Kas liige A võib DHX dokumendi „pimesi“ teele panna (praegune protokolli kavand) või ta peaks enne kindlaks tegema (kuidas?), et adressaadi sendDocument teenus on ikka DHXi teenus? Või peaks saatmine olema kaheringiline: esimesel pöördumisel kinnitab adressaat, et tegu on DHXi teenusega; dokument saadetakse alles pärast kinnitust?
Üks lahendus oleks DHX-is kasutada spetsiifilisemat nime, nt sendDHX vms.
Teine lahendus oleks võtta kasutusele „DHX-i kasutajate“ grupp (tehniliselt X-tee liikmegrupp). Sätestada protokollis, et DHX teenus avatakse ainult „DHX-i kasutajate grupile“. Gruppi võiks hallata pädev riigiasutus või isegi DHX-i kasutajate kogukond ise.
Või siis siduda DHX (ja teised sarnased süsteemid) otseselt X-tee protokolliga - kasutades IANA eritähendusega nimedega ja numbritega sarnast mehhanismi (https://tools.ietf.org/html/rfc6335).
Väljatöötamisel on X-tee monitooringulahendus. Statistikat hakatakse tootma ja tarbima selle kaudu.
X-tee arendaja tõi välja, et objectType
atribuut on X-tee v6 headerites kohustuslik (Viide: http://x-road.eu/docs/x-road_message_protocol_v4.0.pdf, lk 7. Väljavõte: <xs:attribute ref="objectType" use="required"/>). Meie turvaserver kontrollib x-tee v6-te ja seetõttu ei lähe puuduliku headeriga sõnum läbi.
Teie spekis on samamoodi vastav atribuut client headeri puhul puudu: https://www.ria.ee/dhx/sendDocument
Sama probleem on ka https://www.ria.ee/dhx/representationList näites.
Rakendamise motivaatorid (deployment incentives) ja demotivaatorid (disincentives) on üldjoontes selged, kuid vajavad veel täiendat analüüsimist.
Kirjandus: Thaler D (2016). Out With the Old and In With the New: Planning for Protocol Transitions.
DVK korral võis Kapsel sisaldada mitu adressaati. Iga adressaat käis DVK-st eraldi receiveDocuments teenusega küsimas.
DHX korral kaob keskne postkast. Seega peab muutuma ka mitmele adresaadile saatmise loogika.
Ilmselt saatja peab ise sama Kapsli igale adressaadile eraldi saatma. Saatja peab arvestama et mõni adressaat võib tagastada vea. Seega saatja (kasutajaliidese) realisatsioon võiks olla selline et saadetud dokumendi iga adressaadi korral oleks näha kas dokument võeti vastu või tagastati viga.
Uus UK võiks mitmele adresaadile saatmist lihtsustada, niimoodi et võtab DHS-ilt vastu kapsli üks kord ja teostab ise edasi saatmised mitmele adressaadile.
Käesolev issue on mõeldud e-arvetega seonduva arutamiseks. Hoiame arutelu siin, siis jääb jälg kõigile huvilistele nähtavaks! RIA poolt oleme koostanud juhendi E-arved DVK-s üleminekuperioodil. Juhend on praegu veel kavandi seisuses, kuid valmides peaks andma ammendavad vastused kõigile osapooltele, kelle e-arvemajandust DHX-ile üleminek ja DVK sulgemine puudutab. Palume arutelus osalejatel sellega tutvuda. Kõik küsimused, arvamused ja ettepanekud on teretulnud. Aitäh!
Seda näitab protokolli täiendav analüüs ja verifitseerimine. Kavandatud funktsionaalsus katab dokumendivahetuse põhivajaduse. Täiendavate omaduste lisamisel peab vaatama, millisesse kihti omadus läheb.
X-tee mõttes on piisavaks ja pidavaks kinnituseks dokumendi kättesaamise kohta X-tee päringu vastus (Response message). Kui soovitakse "kõrgema taseme" s.t äritaseme kinnitust, siis see saab tulla ainult DHS-st. Äritaseme kinnituse võib teostada DHX dokumendina. Sellise käitumismustri võib vormistada eraldi kihina; ei pea tingimata olema DHX-i osa.
(küsitud kohtumisel arendajatega 17.03.2016)
Asutus saab DVK-s kirjeldama oma ametikohti. Saatjad kasutavad seda teavet.
Algallik-andmekoguks ametikohtade osas on Riigi personali- ja palgaarvestuse andmekogu (SAP). Loogiline - ja AvTS nõudele vastav - oleks võtta need andmed sealt.
(küsitud kohtumisel arendajatega 17.03.2016)
Jah, DVK pakub asutustele võimalust publitseerida oma allasutuste nimekiri. Allasutuste nimekirju saab DVK-st X-tee teenuse abil pärida. DHS-ides kasutatakse seda dokumentide adresseerimisel.
DHX-i puhul tuleks sama teave võtta RKOARR-st. RKOARR-is on allasutuste andmed kõige autentsemal kujul. RKOARR viiakse üle Äriregistri juurde ning täiendatakse RKOARRi X-tee teenuseid. Selline andmekasutus vastaks riigi IT koosvõime ja AvTS nõudele.
Miinuseks on see, et DHS-is tuleks mõned asjad ümber teha. See on üks asi, mida võiks lahendada kavandatav Universaalne tarkvarakomponent?
Tere
Mul on mõned küsimused viimase sendDocument speki[1] kohta.
faultcode
, faultstring
. äriloogilise vea näites on faultCode
, faultString
. vist peaks mõlemas suur täht olema?Lisaks üldise DHX speki[2] otsevõimekuse osa on ebaselge. See ei paista eriti alamsüsteemide olemasolu arvestavat.
[1] https://github.com/e-gov/DHX/blob/646aa1d7ca0f2ddc1e9ed60308f494cdff5c745c/docs/sendDocument.md
[2] https://github.com/e-gov/DHX/blob/616c62147f20d3d63619e31ff9471508cf759cef/docs/index.html
AK:
Tere. Veel üks asi. Hakkasin nüüd mõtlema et milleks on protokollis kirjas et PEAB mõne aja pärast saatmist uuesti üritama. Mulle tundub et seda kas on vaja uuesti saatma või mitte võiks igaüks ise otsustama. Meil on sünkroonne suhtlus DHS-de vahel, aga kui teeme korduvsaatmist siis see ei ole lõpuks kasutaja jaoks sünkroonne, sest kasutajale ei saa kohe öelda kas saatmine ebaõnnestus. Kui keegi teab et ta saadab ainult väiksed dokumendid ja tahab kohe teada kas dokument jõudis kohale, siis miks mitte anda sellist võimalust?
TP:
Minu arvates võiks seal olla VÕIB proovida uuesti saatmist (ja se on ka mõtekas ainult teatud tüüpi tehniliste vigade korral vist)
Lisaks tundub et DHS süsteemid realiseerivad siiski enda sisemiselt saatmise asünkroonselt paljud. Nagu koosolekutest selgus
St et kasutajale ütlevad saatmisel "Läks teele" aga saadavad asünkroonselt ja on eraldi vaade kus on näga dokumentide saatmise staatused
Vrdl CSS 3, HTML 5 jt.
Ei ole, aga see peab tekkima.
Kirjandus: RFC 6709 Design Considerations for Protocol Extensions (2012), jaotis 4.1 Version Numbers.
(küsitud kohtumisel arendajatega 17.03.2016)
See on huvitav mõte, mis vajab kaalumist.
Kesksüsteemi, millega liituda või liidestuda, DHXis ei ole.
Ärilises plaanis:
DHX-ile ülemineku hõlbustamiseks võib siiski mõelda administratiivseid protseduure, DHXi rakendajate nimekirja pidamist ja infovahetust.
Tehnilises plaanis:
DHX saatmiseks pole vaja DHXiga liituda – ehk selleks et saata ühele DHX protokolli osapoolele dokumenti, pole vaja realiseerida endal vastuvõtmise päringut.
DHX vastuvõtmiseks tuleb välja arendada vastuvõttev teenus.
Ükshaaval kasutajate lisamine pole ilmselt mõistlik.
Kaaluda võib X-tee kasutajate grupi "DHX-i kasutajad" loomist. DHXi teenuseomanik avaks teenuse grupile. Gruppi peab keegi haldama - sinna liikmeid lisama. Võib-olla võiks seda teha RIA. Millised võiksid olla grupi haldamise reeglid?
Peaks hindama, kui suur on väärkasutamise oht.
Vajab mõtlemist, kas testimisteenus võiks olla X-tee arendus- või testkeskkonnas (ja kes seda teenust osutaks)?
Vrdl vastavustestimine EL dokumendivahetuslahenduses e-Delivery: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+Conformance+testing.
Laiendatavus on oluline. Vrdl ühe protokolli kriitika:
"a protocol design that sets the clock back at least 20 years, while the rest of the distributed systems community has made extensibility and Postel's robustness principle driving considerations for practically all modern protocol designs.
"Custom message metadata extensibility".
Sõnumivorming ei tohiks olla "non-extensible locked box".
Võib olla oleks mõistlik lisada representationList teenuse vastusesse ka kehtivusajad(ehk millal vahendamine algab ja lõpeb). Mõtlen et see võiks olla abiks et vigu vältida tulevikus. Ka teenustepakkujatele on see vist lihtsam - pärast lepingu sõlmimist võib vahendatava kohe lisada representationListi ja unustada, kuna lepingu alguskuupäeval vahendamine automaatselt algab ja lepingu lõppkuupäeval automaatselt lõpeb.
Kas puhverdamine võiks toimuda TS tasemel? Algselt oli X-teel nii kavandatud („asünkroonne X-tee“) – teave Ahti Kelderilt.
i don't know
How user client is connected to the security server?
give me a example please!!!!!
thanks for you!!!!
EK:
Kui nüüd saatmine muutub hajusaks ja keegi tahab saata 500 le adressaadile 50 megast dokki, see tähendab siis ju 500 x-tee päringut järjest.
Aeglaseks ei jää ?
Voi kas sealt ei teki mingit riskikohta ?
Lahenduseks võib olla Universaalsesse tarkvarakomponenti sõnumijärje funktsionaalsuse lisamine.
Eesmärk on "kapslit" võimalikult vähe muuta.
Lahendamist vajavad küsimused:
Vt ka https://github.com/e-gov/DHX/blob/master/files/Mis%20mille%20sees%20k%C3%A4ib.md
Üleminek on planeeritud sujuvana.
Üleläinud asutus peab saatmisel välja selgitama, kas adressaadil on juba DHX-i võimekus (s.t kas adressaat on ka juba üle läinud). [Kuidas väljaselgitamine toimub on tehniline aspekt ja on kirjeldatud protokollis] Kui adressaadil on DHX-i võimekus, siis saadab DHX-iga. Vastasel korral saadab DVK-sse. Üle minemata adressaat saab dokumendi DVK-st kätte.
Kui üle minemata asutus soovib dokumenti saata, siis ta saadav tavalisel viisil DVK-sse. DVK-sse loome võimekuse, millega DVK vaatab, kas adressaat on juba DHX-le üle läinud ja kui on, siis edastab dokumendi adressaadile DHX protokolli kaudu.
Seega üleminekuperioodil toimib DVK vahendajana vana ja uue protokolli vahel. Süsteemid ise ei pea paralleelset DHX-i ja DVK võimekust endale looma.
(See korraldus rakendub ka e-arvete edastamisele. Ei ole vahet, millises järjekorras operaatorid ja nende DVK-d kasutavad kliendid üle lähevad.)
Vt https://github.com/e-gov/DHX/blob/master/Protokoll.md#9-%C3%9Cleminek
Luua tööriist, mille abil hajusale dokumendihaldusele ülemineku erinevad osapooled saavad ülevaate kes on juba DHX-i võimekuse loonud.
VAJADUS
Avaliku sektori üleminek detsentraliseeritud dokumendivahetusele algab plaanide kohaselt 2017. a. Erinevad sihtrühmad (asutused, arendajad, teenusepakkujad, ITAO) hakkavad meie poole pöörduma küsimustega:
Vajame jooksvat ülevaadet ülemineku seisust.
Vajalik teave sisaldub mitmes allikas: X-tee globaalses konfiguratsioonis, DHX-i vahendajate poolt X-teel publitseeritavates vahendusnimekirjades ja osalt ka RIHAst. Puudub lihtne viis selle teave kiireks kokkusaamiseks ja inimesele esitamiseks.
ETTEPANEK
Luua lihtne tööriist, mis pöörduks X-tee globaalse konfiguratsiooni ja X-teel publitseeritavate DHX-i vahendusnimekirjade poole, koguks sealt teabe ülalnimetatud kolmele küsimusele vastamiseks ning esitaks veebiliidese kaudu inimkasutajale. Tööriista põhikasutajaks oleksid RIA teenusehaldurid ja ülemineku koordinaator, kes kasutavad teavet erinevate sihtrühmade nõustamiseks, probleemide lahendamiseks, üleminekuprotsessi seireks ja statistika andmiseks dokumendihaldust koordineerivale üksusele ITAO-le. Tööriist peaks olema konfigureeritav nii, et teenuse saaks avalikult avada. (X-tee globaalne konfiguratsioon on tehniliselt avalik, DHX-i vahendusnimekirjade avalikkuse kohta tuleb seisukoht kujundada.)
Terminoloogia: Tööriista abil esitatav nimistu on sisuliselt DHX-i „aadressiraamat“.
EI OLE SKOOBIS
DHX-i „aadressiraamatut“ ei pakuta masinloetavalt. DHX-i rakendav infosüsteem peab, DHX protokolli kohaselt, dokumendiedastuseks vajaliku aadressiotsingu teostama lokaalselt (https://e-gov.github.io/DHX/#74-lokaalne-aadressiraamat).
Tööriist pakuks ainult hetkeseisu teavet. Ajalugu võib olla vajalik, eelkõige DHX-i vahendajatega seotud probleemide ja järelevalve teostamiseks. Seda oleks siiski tunduvalt raskem teostada, vajadusel saab pöörduda X-tee logide poole.
TEOSTUS
Teenus on suunatud inimkasutajale (DHX-i planeerijale, arendajale, haldajale, dokumendihalduse koordinaatorile). Käideldavusnõue on madal.
Tööriista programmeerimiseks vajalikud tarkvarakomponendid on DHX etalonteostuse käigus juba loodud. Kokkupanemise maht on väike.
Tööriistaga ei looda uusi andmeid, andmebaasi ei vaja.
Analüüsi vajab küsimus, kas DHX-i aadressiraamat peaks tervikuna või osaliselt olema avalik. Kui mitte, siis on vaja autentimist ja pääsuhaldust.
Protokoll ei võta seisukohta selles küsimuses.
Kuidas ministeerium saaks saata kirja kõigile valitsemisala asutustele?
Praegune vaade on, et see oluline vajadus peaks jääma DHS-de endi kanda. Leviedastus eeldab kataloogiteenuse (directory service) olemaolu. Teiste sõnadega, peab olema võimalus adressaatide rühmi moodustada ja hallata. Tõenäoliselt on mõned laiemat huvi pakkuvad rühmad. Nende haldamiseks võiks koht olla. Kui, siis aga pigem RKOARRi (Riigi ja kohaliku omavalitsuse asutuste riikliku registri) juures. Kindlasti on asutusespetsiifilisi rühmi. Nende haldamine peaks jääma asutuse DHS-i pädevusse.
MÄRKUS. Praegune DVK pakub "adressaatide DVK serveris automaatse lisamise" teenust [DVK spetsifikatsioon 1.6.0-1, lk 56]:
DVK serverit on võimalik seadistada nii, et kui saadetav dokumendikonteiner vastab etteantud tingimustele, siis lisatakse dokumendi adressaatide hulka üks või mitu täiendavat adressaati. Nimetatud lahendus on vajalik näiteks selleks, et garanteerida mingi projektiga seotud dokumentide jõudmine kõigile asjassepuutuvatele osapooltele.
Automaatse adressaatide lisamise korral muudab DVK server saadetava dokumendikonteineri XML andmeid, s.t. lisatud adressaadid on nähtavad ka kõigile teistele adressaatidele ja dokumendi esialgsele saatjale.
Analüüsimist vajab olukord, kus DHS teenindab hulka asutusi, nendele asutustele saadetakse regulaarselt group mail-i ja kirjad on suured. Sellistel juhtudel oleks hea vältida sama kirja mitu korda samasse DHS-i (kuigi erinevatele adressaatidele) saatmist.
TP:
Intervjuudes on selgunud, et mitmes asutuses on 2 või enam infosüsteemi mis kasutavad DVK-d eraldi kausta alusel. Registirkood on neil üks, aga kaust on erinev. Ja preagu nii saatmine (sendDocuments) kui ka vastuvõtmine (receiveDocuments) käib vist registrikood+kaust alusel.
Kuidas me DHX korral selle ära lahendame?
Vahendamine siin ka ei aita, kui vahendamist teeme registrikoodi alusel (esialgse plaani järgi).
Kas peaks juurde tooma mingi uue mõõtme "kaust" vms ka DHX korral?
[9:04:41] Tõnu Põld: Tene variant on ka et ühel asutusel on mitu DHX alamsüsteemi:
EE/GOV/12345/DHX1/sendDocuments
EE/GOV/12345/DHX2/sendDocuments
Aga see ajab ka asja segaseks vist
DHX töötoas arendajatega 9.02.2017
Tõnu: "Testitud ja töötab 200 Mb faili saatmine DHX-ga."
Arendaja: "See on suur samm edasi. Varem tekkisid probleemid 30-40 Mb failidega. Vaja oleks 600 Mb."
Priit: DHX on algselt mõeldud dokumentide edastamiseks. "Dokumendi tekst peab olema [..] võimalikult lühike." Asjaajamiskorra ühtsed alused § 10, lg 2.
Suurte failide saatmine on kahtlemata vajadus, aga kas see on DHX-i eesmärk? Võib-olla vajame vooedastus- (ingl Streaming) protokolli? Fragmentedastus oli DHX-i puhul kaalumisel, kuid sellest loobusime.
Nõue on et dokument edastatakse "kapslis" (jaotis "Sõnumivorming", p 1). Kas vastuvõttev süsteem peaks seda kontrollima?
Jah, protokoll on suunatud Eesti avaliku sektori dokumendivahetusele, kus kapsel on nõutud. Protokolli tuleks täiendada nõudega, et vastuvõttev süsteem kontrollib kapsli olemasolu. Vigase kapsliga või kapslita saadetise kohta antakse veakood.
[10.11.2016 12:43:30] Aleksei: "1.5 Dokumenti saatev süsteem PEAB määratlema kasutatava DXH protokolli versiooni." - kas seda etalonteostuses dokumendi vastuvõtmisel kontrollitakse?hetkel ei kontrollita. ma ei leidnud protkolli tekstis et on vaja kontrollida ja mis see kontroll peab siis olema, kas tuleb kontrollida et major version on sama?
[10.11.2016 12:54:50] Eneli Järve: Protokoll ütleb nii: Dokumenti saatev süsteem PEAB määratlema kasutatava DXH protokolli versiooni.
[10.11.2016 12:55:36] Eneli Järve: kas määratlema=kontrollima
[10.11.2016 12:56:02] Eneli Järve: see nagu ütleks, et kuskil peab olema versioon määratud
[10.11.2016 12:57:31 | Muudetud - 12:57:47] Tõnu Põld: Ma ütleks et kontrollimine on Vastuvõtva süsteemi ülesanne. Kui vastuvõttev süsteem ei toeta seda versiooni siis ta peaks andma vea
[10.11.2016 12:58:26] Eneli Järve: jah, see siis tähendab, et määrab ära, kas versioon on õige. Aga kas see on DHS-is vaja kuidagi rakendada ning kas peaks protokolli panema ka sellekohase kirjelduse?
[10.11.2016 12:59:20] Eneli Järve: Sest me oleme pannud küll, et peab versiooni defineerima - aga mis ta edasi teeb?
[10.11.2016 12:59:22 | Muudetud - 13:01:23] Tõnu Põld: Küsimus on kas kasutame selle vea jaoks koodi "DHX.Validation" või lisame uue vea "DHX.UnsupportedVersion"
[10.11.2016 12:59:39] Eneli Järve: Priit teab :)
[10.11.2016 13:04:00] Eneli Järve: Kui mina protokolli loen, siis ma ei loe välja seda, et ta peab andma vea...ma arvaks, et kuskil peab olema tuvastatav, et mis versioon on :D Noh nagu meil täna kapsliga on - saab saata nii 1.0 kui 2.1..ja see on eristatav, et millist versiooni siis keegi kasutab
[10.11.2016 13:04:20] Eneli Järve: aga võib-olla tehniline inimene saab aru paremini.
[10.11.2016 13:04:38] Tõnu Põld: Ei peagi viga andma, kuid ilus oleks
[10.11.2016 13:05:06 | Muudetud - 13:06:05] Tõnu Põld: Sest siis on meil püstitatud äri nõuete täitmine parem
[10.11.2016 13:05:23] Tõnu Põld: Sest viga andes saatja teab et vastuvõtja ei saanud dokumenti kätte
[10.11.2016 13:05:34] Tõnu Põld: muidu saadab saatja dokumente musta auku
[10.11.2016 13:05:35] Aleksei: teenuse spekkis öeldud et ikkkagi PEAKS vea andma, aga protokollis endas mitte:
[10.11.2016 13:05:36] Aleksei: Päringu saatja annab teada, millise DHX protokolli versiooni kohaselt päring on moodustatud. Vastuvõttev süsteem PEAB kontrollima parameetri DHXVersion olemasolu. Vastuvõttev süsteem PEAKS versiooninumbri alusel otsustama, kas suudab päringsõnumit töödelda ja suutlikkuse puudumisel päringu tagasi lükkama.
[10.11.2016 13:05:43 | Muudetud - 13:07:35] Tõnu Põld: ja äri-nõuded ei ole täidetud
[10.11.2016 13:05:59] Eneli Järve: mhm, see on sama teema
[10.11.2016 13:06:05] Eneli Järve: mida rääkisime
[10.11.2016 13:06:15] Eneli Järve: et kas me peame keelam,a kõike
[10.11.2016 13:06:37 | Muudetud - 13:06:51] Tõnu Põld: PEAKS tähendab et erijuhl ei pea, st see pole nii range kui PEAB
[10.11.2016 13:07:15] Eneli Järve: Priit ütles, et vaba maa - liberalism jne :)
[10.11.2016 13:07:37] Eneli Järve: igaühe otsustada, kas ta tahab kontrollida ja keelata
[10.11.2016 13:07:53 | Muudetud - 13:08:03] Eneli Järve: või võtab vastu ka teisi versioone
[10.11.2016 13:08:04] Tõnu Põld: PEAKS tähendab et üldjuhul PEAB andma vea
[10.11.2016 13:08:56] Tõnu Põld: tehnilised küsimused on:
Versiooni numbri kontroll vähemalt soovitusena võiks siiski jääda, kui kunagi tuleb uus versioon siis on elu tükk maad lihtsam.
Veakoodina eelistaks eraldi koodi DHX.UnsupportedVersion, sest see võimaldab DHX rakendajal peale ehitada automaatika - näiteks kui 2.0 versiooni korral saab ta vea DHX.UnsupportedVersion, siis proovib vanemat versiooni 1.0
Vea koodide vabaks laskmist ei poolda, sest vea koodide kasutamine võimaldab vajadusel teostada automaatset (masin) töötlust. Näiteks programmiliselt eristada kas dokumendi saatmist on mõtekas uuesti üritada jms.
Kui vea koodid vabaks lasta, siis pole neil üldse mõtet, siis jätame lihtsalt "vea tekst" välja, mis on siis mõeldud inimesele (mitte masinale)
Saadetavad versioonid numbrid võiksid olla sellised, mis ei sisalda patchi numbrit, st saata ainult major versioon 1 (mitte 1.0.10) või 2.
Kuigi see vajab pisut mõtlemist veel, äkki me soovime siiski et süsteemid käituksid erinevalt ka alamversioonide (1.3.2) korral? Kuigi see soov teeb asja kaunis keerukaks DHX rakendaja poolel ja võib muuta DHXi tegelikult soovitud nõuetele mitte-vastasavaks (kättetoimetatavus jt nõuded ei ole enam täidetud).
Segaduse tekkimise võimalus on pigem teoreetiline. Siiski peaks tagama, et segadust ei saaks tekkida. Pigem organisatsiooniliste kui tehniliste meetmetega, sest X-teel ei ole "kindla tähendusega nimede" (assigned names) mehhanismi. X-tee liikme alamsüsteemi DHX registreerimisel RIA-s tuleks kontrollida, et X-tee liige peab silmas DHX-i, mitte midagi muud.
Kirjandus: RFC 6943 Issues in Identifier Comparison for Security Purposes.
Nõuete vormistus tuleb viia vastavusse standardiga RFC 2119.
Vt "Protokollide spetsifitseerimise parim praktika", p 6 "Nõuete tugevus".
Hõlmamine? - mis praegu tuleb vastuseks kui kiri kohale tuleb? Kuidas täna on? Liivi otseselt hõlmamise vajadust ei näinud, kuid kättesaamise kohta peaks küll teate saama. Kas see kättesaamise teavitus on DHS-is kuidagi lahendatud? Kas siis peame eraldi teenuse selleks DHX-i raames tegema?
Kättesaamise kinnitus edastatakse X-tee vastussõnumis.
7.6 Dokumendi lugemine edastatuks
Saatev süsteem PEAB lugema dokumendi edastatuks, kui on saanud sendDocument teenuselt positiivse vastuskoodiga vastussõnumi.
Kinnitus dokumendi kättesaamise kohta saadetakse X-tee päring-vastus (request-response) sõnumipaari vastussõnumis. Kui osapooled vajavad kõrgema äriloogika kihi taseme kinnitusi, siis neid võib realiseerida DHX protokolli väliselt või DHX protokolli pealiskihina.
https://github.com/e-gov/DHX/blob/master/files/Protokoll.md#76-dokumendi-lugemine-edastatuks
Arvestatud on sellega, et kättesaamise kinnituse koostab ja saadab teele vastuvõttev süsteem ilma inimese sekkumiseta. Turvaserverid on tavaliselt seadistatud nii, et vastussõnumit (response) oodatakse 5 minutit. Kui selle aja jooksul vastussõnumit ei tule, siis loeb saatja süsteem, et dokument ei jõudnud kohale.
Kui soovime, et kättesaamise kinnituse koostamine vajab inimese sekkumist, siis tuleb see teostada eraldi teenusega (inimene ei mahu turvaserveri timeout-i sisse). Praegu sellist teenust protokolli võetud ei ole, kuna vajadus ei ole selge.
Oht on ka teha üldine teenus, mille semantika ei ole osapooltele selge. Kättesaamise semantika on ju laiem küsimus, kus võib olla konkreetsete dokumendiliikidest või kontekstist sõltuvaid nüansse.
„Sain kirja kätte“
„Sain raha kätte“
„Sain arve kätte“
„Sain kohtukutse kätte“
jne
Vrdl RFC 6819 OAuth 2.0 Threat Model and Security Considerations.
Jah, turvakäsitlust (ingl Security Considerations, kui järgida IETF stiili, on vaja).
Nt Tallinna linnal.
Hinnata protokolli RFC 5218 What Makes for a Successful Protocol? kriteeriumite lõikes. Vt ka Rogersi five generic characteristics of innovation that impact on the adoption decision: relative advantage, compatibility, complexity, trialability and observability.
Mis moodi DHX puhul käib selle teenuse avamine asutusel asutustele? Kas iga asutus peab seda ise iga kontakti puhul eraldi tegema? Nö. andma loa oma teenusele?
X-teel on võimalus avada teenus kõigile. Praegu on nii mõeldud.
AGA - vt issue #16
Vaikimisi kõigile avamine eeldab, et X-tee liikmeid saab üldjuhul usaldada.
Võimalik on teha ka "ukse" ja doorkeeper-iga lahendus. Tehniliselt X-tee nn grupi - DHX kasutajate gruppi - loomise kaudu. Menetlus oleks:
Sellisel juhul peame ette kirjutama, et teenus avatakse ainult grupile "DHX kasutajad".
Tunnistagem, et sellises korras on oma administratiivne võlu: DHX-i rakendamise protsess oleks jälgitav ja administratiivselt kontrollitav.
Võib küll öelda, et asjatu bürokraatia, kuid kui inimestele liiga vähe struktuuri ette anda, siis nad kaotavad orientatsiooni?
"Laoteenuse" osutamine oli aktuaalne kümme aastat tagasi.
Tänapäeval oleks ehk õigem, kui asutuse dokumente hoitaks asutuse DHS-is.
Jah, DHX-i arendamisel üritatakse järgida avastandardite (ingl open standards) põhimõtteid.
Interneti standardimise organisatsioon IETF ([RFC 6852]) seab avastandardi kriteeriumiteks:
Euroopa Liidu infopoliitikas on avastandardeid tähtsaks peetud. EL koosvõime raamistiku esimeses versioonis (v1.0, 2004) sõnastati avastandardi kriteeriumid:
Hiljem on avastandardi mõiste poliitiliste võitluste mõjul hägustunud. Ülevaate käesoleva hetke seisust annavad Euroopa Komisjoni teatis [COM(2016)] ja [Moody].
Täpsem ülevaade avastandardi mõistest ja selle erinevatest käsitlustest on Vikipeedia artiklis Open standard.
[RFC 6852] RFC 6852 Affirmation of the Modern Paradigm for Standards, 2013.
[COM(2016)] COM(2016) ICT Standardisation Priorities for the Digital Single Market.
Moody G (2016) FRAND is no friend: How to make EU tech standards compatible with open source, Ars Technica.
DVK pakub võimalust edastada dokumente fragmentidena. (DVK spetsifikatsioon, jaotis "Dokumentide edastamine fragmentidena"). Kas DHX peaks nõudma sama?
Kõigepealt tuleb välja selgitada, kas selle järele on reaalset vajadust. Asjaajamise kord nõuab, et "Dokumendi tekst peab olema [..] võimalikult lühike." Dokument võib sisaldada rasterjooniseid, samuti võib dokumenti edastada pildistusena. Need suurendavad faili. Kuid dokumentivahetuse skoobis ei tohiks olla gigabaidiste kettatõmmiste jms väga suurte failide edastamine.
Fragmentedastuste standardimisel - kui selleks on ärivajadus - võib aluseks võtta senise DVK lahenduse, kus sendDocument
päringus edastatakse:
fragmente_kokku
- edastatavate fragmentide hulk (s.t. mitmeks tükiks dokument on jagatud)fragment_nr
- edastatava fragmendi järjekorranumber alates 0-st (s.t. 0, 1, 2, jne.)edastus_id
- edastussessiooni ID. Saatja poolt vabalt valitav võimalikult unikaalne string, mis on ühiseks nimetajaks kõigile edastatavatele tükkidele.Edastatav dokument peab olema esmalt GZIP-ga kokku pakitud.
Fragmentedastuse toe nõuet on võimalik püstitada, kuid ilmaasjata seda teha ei tuleks.
Teen ettepaneku, et enne üleriigilist üleminekut DHX protokollile teha analüüs AS4 protokolli sobivuse kohta, tuues välja DHX protokolli eelised ja puudused võrreldes laialdaselt kasutatava ning OASISe poolt standardiseeritud AS4 protokolliga.
AS4 peaks olema ka võimalik kasutada üle X-tee, siis saaks kasutada signeerimata/krüpteerimata sõnumeid. Vahetades sõnumeid X-tee väliselt, saaks kasutada sertide vahetamist ja signeerimist/krüpteerimist.
AS4 eelised:
AS4 puudused:
DHX eelised:
DHX puudused
Viited:
https://www.drummondgroup.com/index.php/component/content/article/127-b2b/b2b-products/b2b-faqs/243-as4-faq
https://www.oasis-open.org/news/pr/as4-profile-of-ebms-3-0-becomes-oasis-standard
https://www.codit.eu/blog/2016/02/01/as4-for-dummies-part-i-introduction/
http://holodeck-b2b.org/
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.