8000 DHX protokolli ja AS4 protokolli võrdlus? · Issue #49 · e-gov/DHX · GitHub
[go: up one dir, main page]
Skip to content

DHX protokolli ja AS4 protokolli võrdlus? #49

New issue
New issue
Open
Open
DHX protokolli ja AS4 protokolli võrdlus?#49

Description

@ingmarp
ingmarp
opened on Feb 20, 2017

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:

  • standardiseeritud OASISe poolt ja avatud standard
  • võimaldab nii push kui ka pull mudelit
  • kõrgetasemeline turvalisus ka X-tee kasutamise vajaduseta, samas võimalik kasutada ka üle X-tee
    • vajaks tegelikult testimist, kas ikka saab kasutada üle X-tee
  • sõnumi kohalejõudmise teavitus nii sünkroonne kui ka asünkroonne
  • AS4 tugi on realiseeritud väga paljudes tarkvarades, samuti on mitmeid avatud lähtekoodi ja litsensiga AS4 sõnumikäsitlejaid (message handler)

AS4 puudused:

  • ei ole Eestis leiutatud?

DHX eelised:

  • X-tee kasutamine tagab turvalisuse
  • ???

DHX puudused

  • ei võimalda push mudelit
  • ei võimalda kasutamist väljaspool X-teed
    • puudub signeerimise/krüpteerimise võimalus
  • puudub asünkroonne teavitus sõnumi kohalejõudmise kohta
  • ???

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/

Activity

  1. PriitParmakson commented on Feb 20, 2017

    @PriitParmakson
    PriitParmakson
    on Feb 20, 2017
    Contributor

    Aitäh, Ingmar!
    Mõnede väidetega ei saa nõus olla.

    • Ei saa nõus olla väitega, et DHX ei paku signeerimist ja krüpteerimist. DHX tugineb X-tee protokollistikule. X-tee pakub nii signeerimist kui ka krüpteerimist. Ei ole mõtet kahes kihis (X-teel ja DHX-is) teostada samu funktsionaalsusi.
    • Ei võimalda push mudelit? Interaktsiooni algatab dokumendi saatja. Selles mõttes on täiesti push mudel.
    • See, et DHX-i (praegusel kujul) ei saa kasutada väljaspool X-teed, ei ole puudus, vaid kaalutletud disaini otsust. 8)
    • Teoreetiliselt võib küll mõelda DHX-i edasiarendamist nii, et aluseks on X-tee asemel mõni muu protokollistik. See võimalus on aga pelgalt teoreetiline. Eelkõige sellepärast, et aluskiht peab pakkuma universaalset adresseeritavust, kindlat identiteeti, signeerimist-krüpteerimist jms. Raske on leida protokollipinu, mis seda kõike võimaldaks ja oleks ka väikeste kuludega kasutusele võetav.
    • X-tee tugi on samuti realiseeritud paljudes tarkvarades. Erinevalt AS4-st on need meie infosüsteemides juba kasutatavad tarkvarad.
    • AS4 on kasutusel Euroopa Liidu piiriüleses andmevahetuslahenduses eDelivery. Oleme RIAs teostanud X-tee ja AS4 vahelise lüüsi (ühest protokollist teise tõlkija).
    • Asünkroonse kättesaamise kinnituse järele me ei leidnud olulist ärivajadust seda standardida. Kui selline vajadus aga peaks ilmnema, siis on võimalik protokolli laiendada.
    • DHX on täpselt samamoodi avatud standard nagu AS4. Boonusena on meil Eestis DHX-i suhtes aga sõnaõigus protokolli edasiarendamise üle.

    See ei tähenda, et võrrelda ei võiks. Võiksime võtta RIA tööplaani.

  2. ingmarp commented on Feb 20, 2017

    @ingmarp
    ingmarp
    on Feb 20, 2017
    Author

    Vabandust, mul jäi viga sisse - DHX ei toeta pull mudelit. Samas DHX siiski ei toeta signeerimist / krüpteerimist väljaspool X-tee kasutamist. AS4 puhul saaks kasutada signeerimist/krüpteerimist väljaspool X-teed või siis signeerimata/krüpteerimata versiooni X-tee põhises suhtluses. Ehk oleks võimalik ka lahendus, kus üks pool on X-tee taga ja teine mitte.
    X-tee v6 riistvaralise turvaseadme (ja tegelikult ka turvaserveri olemasolu) nõue välistab DHX protokolli laialdase kasutamise erasektoris. Paraku avalik sektor ei eksisteeri ilma erasektorita (nagu raha tegelikult ei kasva riigieelarves iseenesest) ning seetõttu tasuks seekord vältida lühinägeliku otsust, võttes kasutusele protokolli, mida saavad kasutada ainult suure eelarvega avaliku sektori asutused. Turvaserveri nõude tõttu ebaõnnestus RIA üleriigiline projekt e-arvetele üleminekuks aastal 2011-2012 - kõikidesse EDHS-idesse arendati e-arve tugi, kuid ERPidele turvaservereid külge pookida ei õnnestunud.
    X-tee tugi on küll olemas mõnedes tarkvarades, kuid DHX tuge pole hetkel veel arendatud. Võimalus oleks jätta DHX arendamata ja selle asemel AS4 arendada. Või siis mõlemad ühe projekti raames realiseerida, tagades ühilduvuse ülejäänud maailmaga.
    Adresseerimise ja teenuste publitseerimise kohta on ka standardid olemas ja need küsimused on lahendatud nii OpenPEPPOLi kui ka eSens eDelivery raames.

  3. hanneskiivet commented on Feb 28, 2017

    @hanneskiivet
    hanneskiivet
    on Feb 28, 2017
    1. Esiteks, on RIA-le antud selge ülesanne korraldada avaliku sektori dokumendivahetust. Selleks töötasime välja DHX protokolli konkreetse eesmärgiga (vt protokolli ptk 1.1). Laiemat kasutust RIA ei piira, küll aga ei vii me läbi selleteemalisi analüüse.
    2. RIA poolt on DHXi ärinõudena sõnastatud, et see toetaks X-tee v6 (vt protokolli ptk 1.4). Seda seetõttu, et mitte lahendada (ratta leiutamisega) osapoole identifitseerimise/usalduse, digiallkirjastamise, krüpteerimise, ruutimise jne osa protokollis, vaid toetuda juba loodule. RIA pole nõus seda ärinõuet muutma, kuna vastasel korral ei tagaks me enam DHSides lihtsalt teostatavuse nõuet. Arvamusel, et AS4 (sh kogu OpenPEPPOLi ja eSENS eDelivery ökosüsteemi) paralleelne (!) kasutuselevõtt on riigile kuluefektiivsem kui DVK suhtluse DHXile viimine, pole sisulist põhjendust. RIA e-arve projekti laialdane juurutamine ei õnnestunud konkureeriva teenuse loomise tõttu, mitte turvaserveri nõude tõttu. HSMi soetamist toetatakse riigi/EL poolt ning meie hinnangul on see riigiüleselt kuluefektiivsem kui mitmetasemelist (turvalist) andmevahetuskihti ülalhoida.
    3. DHX protokoll on kujundatud avastandardina ja aluskihina laiendatavana (vt protokolli ptk 1.4). Seetõttu saab huvipool:
      3.1. võtta aluseks DHX protokolli ning luua selle alusel täiesti uue protokolli, millel on teine eesmärk ja teised ärinõuded.
      3.2. teha konkreetseid motiveeritud muudatusettepanekuid. Samas tulenedes punktist 2 ei toeta RIA X-tee v6 nõude kaotamist. Küll aga võib huvipool teha iseseisvat analüüsi AS4 (rist)kasutuselevõtu osas ning oleme valmis seda arutama.

  4. ingmarp commented on Feb 28, 2017

    @ingmarp
    ingmarp
    on Feb 28, 2017
    Author

    Tänan vastuse eest, argumendid on Eesti avaliku sektori vaatenurgast arusaadavad.
    Loodan ka, et riigi/EL poolt toetatud HSMid kõikide osapoolteni peatselt jõuavad ning teenusepakkujaid pole järjekordselt ära unustatud.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions
      0