Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Analysis and comparison of microservice data exchange formats on Enduro/X platform

The thesis analyzes and compares the microservice data exchange formats. The work
contains a study of what data exchange formats are available, what characteristics to consider
when choosing these formats. Each of the selected data exchange formats is implemented in a
microservice architecture environment where measurements are made on the performance of a
particular data exchange format by serialization of data, deserialization between service calls.
The end results are compared and conclusions are drawn on which of these data exchange
formats is better, which one would be better suited to specific situations.
The analytical section of the thesis examines the Enduro/X UBF data exchange format, which
was found to be incomplete during the research. Based on these shortcomings, design is being
developed.
The main body of the thesis is 82 pages, 41 pictures, 18 tables, 43 titles of information sources and 19 appendices.

  • Login to see the comments

  • Be the first to like this

Analysis and comparison of microservice data exchange formats on Enduro/X platform

  1. 1. RĪGAS TEHNISKĀ UNIVERSITĀTE Datorzinātnes un informācijas tehnoloģijas fakultāte Lietišķo datorsistēmu institūts Mākslīgā intelekta un sistēmu inženierijas katedra Einārs LECKIS Profesionālā maģistra studiju programmas „Datorsistēmas” students (stud. apl. nr. 151RDC008) MIKROSERVISU DATU APMAIŅAS FORMĀTU ANALĪZE UN SALĪDZINĀJUMS Maģistra darbs zinātniskais vadītājs Dr.sc.ing., prof. J.EIDUKS Rīga 2019
  2. 2. DARBA IZPILDES UN NOVĒRTĒJUMA LAPA Maģistra darbs izstrādāts Mākslīgā intelekta un sistēmu inženierijas katedrā. Ar parakstu apliecinu, ka visi izmantotie materiāli ir norādīti literatūras sarakstā un iesniegtais darbs ir oriģināls. Darba autors: stud. E.Leckis...………………………………....………………………...... (paraksts, datums) Maģistra darbs ieteikts aizstāvēšanai: Zinātniskais vadītājs: Dr.sc.ing.,prof. J.Eiduks…….................…………………………………... (paraksts, datums) Maģistra darbs pielaists aizstāvēšanai: Mākslīgā intelekta un sistēmu inženierijas katedras vadītājs: Dr.habil.sc.ing., prof. J.Grundspeņķis...............……………………………... (paraksts, datums) Maģistra darbs aizstāvēts Mākslīgā intelekta un sistēmu inženierijas katedras Valsts Pārbaudījumu komisijas ….....gada…..….....…sēdē un novērtēts ar atzīmi ( )…..……….. (gads) (datums, mēnesis) Mākslīgā intelekta un sistēmu inženierijas katedras Valsts Pārbaudījumu komisijas sekretāre…….....................……….… (uzvārds, paraksts)
  3. 3. ANOTĀCIJA MIKROSERVISI, MIKROSERVISU ARHITEKTŪRA, SECINĀŠANA, DATU APMAIŅAS FORMĀTI, JSON, XML, Enduro/X UBF. Darbā ir analizēti un salīdzināti mikroservisu datu apmaiņas formāti. Darbs satur pētījumu par to kādi datu apmaiņas formāti ir pieejami, kādas raksturīpašības jāņem vērā izvēloties šos formātus. Katrs no izvēlētajiem datu apmaiņas formātiem tiek ieviests mikroservisu arhitektūras vidē, kur tiek veikti mērījumi uz konkrētā datu apmaiņas formāta veiktspēju veicot datu serializāciju, deserializāciju starp servisu izsaukumiem. Gala rezultāti tiek salīdzināti un veikti secinājumi par to, kurš no šiem datu apmaiņas formātiem ir labāks, kurš no tiem būtu labāk piemērots konkrētās situācijās. Darba analītiskajā nodaļā tiek izpētīts UBF datu apmaiņas formāts, kam izpētes laika tika konstatētas nepilnības. Balstoties uz šīm nepilnībām tiek izstrādāts projektējums. Darba pamattekstā ir 82 lappuses, 41 attēli, 18 tabulas, 43 nosaukumu informācijas avoti un 19 pielikumi.
  4. 4. ABSTRACT MICROSERVICES, MICROSERVICE ARCHITECTURE, CONCLUSIONS, DATA EXCHANGE FORMATS, JSON, XML, Enduro / X UBF. The thesis analyzes and compares the microservice data exchange formats. The work contains a study of what data exchange formats are available, what characteristics to consider when choosing these formats. Each of the selected data exchange formats is implemented in a microservice architecture environment where measurements are made on the performance of a particular data exchange format by serialization of data, deserialization between service calls. The end results are compared and conclusions are drawn on which of these data exchange formats is better, which one would be better suited to specific situations. The analytical section of the thesis examines the UBF data exchange format, which was found to be incomplete during the research. Based on these shortcomings, design is being developed. The main body of the thesis is 82 pages, 41 pictures, 18 tables, 43 titles of information sources and 19 appendices.
  5. 5. АННОТАЦИЯ МИКРОСЕРВИСЫ, МИКРОСЕРВИСНАЯ АРХИТЕКТУРА, ВЫВОДЫ, ФОРМАТЫ ОБМЕНА ДАННЫМИ, JSON, XML, Enduro / X UBF. Диссертация анализирует и сравнивает форматы обмена микросервисными данными. Работа содержит исследование того, какие форматы обмена данными доступны, какие характеристики следует учитывать при выборе этих форматов. Каждый из выбранных форматов обмена данными реализуется в среде архитектуры микросервиса, где проводятся измерения производительности конкретного формата обмена данными путем сериализации данных, десериализации между вызовами сервисам. Конечные результаты сравниваются и делаются выводы о том, какой из этих форматов обмена данными лучше, какой из них лучше подходит для конкретных ситуаций. В аналитическом разделе диссертации рассматривается формат обмена данными UBF, который был признан неполным в ходе исследования. На основании этих недостатков разрабатывается дизайн. Основная часть диссертации составляет 82 страниц, 41 рисунков, 18 таблиц, 43 названий источников информации и 19 приложений.
  6. 6. SATURS IEVADS .....................................................................................................................................8 1. MIKROSERVISI..............................................................................................................10 1.1. Starpprogrammatūras izvēle.....................................................................................15 2. DATU APMAIŅAS FORMĀTI ......................................................................................17 2.1. Datu apmaiņa monolītiskā arhitektūrā......................................................................17 2.2. Datu apmaiņa mikroservisu arhitektūrā....................................................................19 2.3. JavaScript objektu notācija - JSON..........................................................................21 2.3.1. JSON formāta vēsture.......................................................................................22 2.3.2. JSON formāta sintakse .....................................................................................25 2.3.3. JSON formāta datu tipi.....................................................................................26 2.4. Paplašināmā iezīmēšanas valoda - XML..................................................................31 2.4.1. Valodas XML vēsture.......................................................................................32 2.4.2. Valodas XML sintakse .....................................................................................32 2.4.3. Valodas XML datu tipi.....................................................................................35 2.4.4. Valodas XML datu tipu ierobežojumi..............................................................39 2.5. Vienotais bufera formāts ..........................................................................................41 2.5.1. UBF vēsture......................................................................................................43 2.5.2. UBF sintakse ....................................................................................................43 2.5.3. UBF datu tipi ....................................................................................................47 3. JSON, XML UN UBF SALĪDZINĀJUMS......................................................................49 3.1. Izmantotās komponentes ..........................................................................................50 3.2. Testa scenārijs...........................................................................................................52 3.3. Datu formātu veiktspējas rezultāti............................................................................58 3.4. API salīdzinājums.....................................................................................................63 4. ENDURO/X STRUKTURĒTA DATU APMAIŅAS FORMĀTA PROJEKTĒJUMS ..66 4.1. Izmaiņu prasību specificēšana..................................................................................69 4.2. Prasību specifikācijas izstrāde..................................................................................70 4.3. Datu struktūras izmaiņu projektējums......................................................................73 SECINĀJUMI ..........................................................................................................................78 LITERATŪRA.........................................................................................................................80 PIELIKUMI..............................................................................................................................83 1. pielikums. Klienta kopējais makefile
  7. 7. 2. pielikums. Klienta makefile priekš JSON 3. pielikums. Klienta makefile priekš UBF 4. pielikums. Klienta makefile priekš XML 5. pielikums. Klienta pirmkods 6. pielikums. Ziņojuma galvenes fails 7. pielikums. JSON bibliotēkas makefile 8. pielikums. JSON bibliotēkas pirmkods 9. pielikums. Servera kopējais makefile 10. pielikums. Servera makefile priekš JSON 11. pielikums. Servera makefile priekš UBF 12. pielikums. Servera makefile priekš XML 13. pielikums. Servera pirmkods 14. pielikums. UBF bibliotēkas makefile 15. pielikums. UBF bibliotēkas pirmkods 16. pielikums. UBF lauku definīcijas fails 17. pielikums. XML bibliotēkas makefile 18. pielikums. XML bibliotēkas pirmkods 19. pielikums. Kopējā projekta makefile
  8. 8. 8 IEVADS Datorprogrammu un sistēmu saziņa vienmēr ir bijusi aktuāla, it sevišķi laika posmā, kad ir pieejams interneta tīkls, dažādu nozaru kompānijas, dažādas programmas un to specifika, kurām savā starpā jāsadarbojas. Palielinoties internetā pieslēgto iekārtu skaitam (un ne tikai) ir nepieciešamas ātrdarbīgas programmas, ko ne vienmēr var mērogot ar jaudīgām fiziskās iekārtām. Tāda veida programmas ir nepieciešamas reālā laika jomās – visa veida maksājumu veikšana, notikumu uzskaite, produktu pieejamības sarakstu izgūšanai, sūtāmo un saņemto datu validācija u.c. Mūsdienās pasaulē arvien populārāks kļūst lietu internets (angliski Internet of Things, turpmāk tekstā IoT), kas izmanto zemas jaudas datorus, lai veiktu globālus risinājumus. Arī IoT mazajiem sensoru datoriem nepieciešams sazināties savā starpā. Tieši dēļ ierobežotās aparatūras, augsta līmeņa programmēšanas valodas izmantošana šādos risinājumos kļūst neiespējama. Arī mākoņu skaitļošana, servisu orientēta arhitektūra (angliski Service-oriented architecture, turpmāk tekstā SOA) un mikroservisu risinājumi kļūst aizvien populārāki. Izvēloties šādas tehnoloģijas, tas lietojumam dod plašākas iespējas un dažādāku pielietojumu, taču ieviešot jaunas tehnoloģijas rodas jaunas problēmas, nianses kuras konkrētajā tehnoloģijā ir būtiskas. Attīstoties biznesam pieaug prasības, kā rezultātā produktu ir nepieciešams uzlabot, lai tas spētu nodrošināt labāku veiktspēju. Izmantojot tradicionālo monolītisko arhitektūru tas bieži vien sagādā neērtības, jo ne vienmēr šādu lietojumu varēs uzlabot pielabojot tikai kodu. Vienkāršākais un parasti biežāk izmantotais veids kā tiek mērogotas monolītiskas lietojumprogrammas ir to darbināšana vairākās instancēs ko izvieto uz dažādiem fiziskiem resursiem. Šāds risinājums ir nosacīti ierobežots un diezgan dārgs, savukārt mikroservisu arhitektūrā šādu problēmu risināšana notiek daudz racionālāk un lētāk. Mikroservisu arhitektūras dizains nosaka to, ka kopējais lietojums ir sadalīts vairākos brīvi savienotos un neatkarīgos servisos, kas pilda konkrētas biznesa vajadzības (funkcijas). Šāds sadalījumus ļauj mērogot katru no šiem servisiem atbilstoši biznesa vajadzībām. Tāpat tas ļauj katru individuālu servisu dublēt vairākās instancē neskarot pārējos servisus, savukārt monolītiskajā arhitektūrā mērogot kādu no funkcijām parasti ir neiespējams, jo tādā gadījumā ir nepieciešams mērogot visu lietojumu.
  9. 9. 9 Sadalīts lietojums vairākos servisos arī uzlabo lietojuma un koda kvalitāti, jo izstrādātājiem ir vienkāršāk izstrādāt un saprast citu izstrādātos servisus. Gadījumos ja tiek pieļauta kritiska kļūda monolītiskā lietojumā, tad tā pilnībā to paralizēs, bet mikroservisu arhitektūrā tas apstādinās tikai daļu funkcionalitātes un kļūdas novēršanai prasīs daudz mazāk laika, jo atšķirībā no monolītiskās arhitektūras nebūs nepieciešams analizēt visu programmu. Sadalot lietojumu vairākos servisos ir jāparūpējas par to, kā šie servisi spēs savstarpēji komunicēt – apmainīties ar datiem. Šādam nolūkam tiek lietota starpprocesu komunikācija (angliski Inter-process communication, turpmāk tekstā IPC), kas ir mehānisms, lai nodrošinātu komunikāciju un datu apmaiņu starp procesiem. Procesi var komunicēt izmantojot sistēmas koplietojamo atmiņu un izmantojot ziņojumu pārsūtīšanu. Izmantojot šo mehānismu ir nepieciešami arī interfeisi (angliski Application programming interface, turpmāk tekstā API), kas nosaka kā procesi saprot viens otru. Parasti komunikācija starp procesiem notiek izmantojot vienu interfeisu, bet nav izslēgts, ka var tik lietoti dažādi interfeisi. Citus interfeisus lieto ārējiem resursiem, piemēram, no tīmekļa vietnes ienāk HTTP pieprasījums, kur serveris tālākai iekšējai komunikācijai to konvertē uz iekšējo datu apmaiņas formātu un sniedzot atbildi konvertē atpakaļ HTTP formātā. API izvēle procesu komunikācijai ir svarīga, jo datu serializācija un deserializācija maksā laiku. Maģistra darba mērķis ir mikroservisu datu apmaiņas formātu analīze un to salīdzināšana. Lai sasniegtu darba mērķi, tika izvirzīti sekojoši uzdevumi: 1. Mikroservisu datu apmaiņas formātu analīze (JSON, XML, Enduro/X UBF); 2. Mikroservisu datu apmaiņas formātu salīdzinājums (JSON, XML, Enduro/X UBF); 3. Priekšrocību (sarežģītība programmēt augstas veiktspējas C programmēšanas valodas sistēmās, grūtības definēt, ātrdarbības, saderības ar citām sistēmām) analīze un novērtējums; 4. Datu apmaiņas formātu JSON, XML, Enduro/X UBF veiktspējas salīdzinājums mikroservisu arhitektūrā. Tā kā izvēlētā starpprogrammatūra (Enduro/X) ir izstrādāta C programmēšanas valodā (tā arī atbalsta augstāka līmeņa valodas), lai salīdzinātu ātrdarbību vistiešākā mērā un maksimāli tuvu aparatūras līmenim, darbā tiks salīdzināti tieši C programmēšanas valodā izstrādāti mikroservisi, kas datu serializācijai un deserializācijai izmantos JSON, XML, Enduro/X UBF datu apmaiņas formātus.
  10. 10. 10 1. MIKROSERVISI Mikroservisi ir plašs jēdziens, kuram līdz šim nav vienota skaidrojuma. Internetā bieži lietotas mikroservisu definīcijas ir: 1. Mikroservisu arhitektūra ir arhitektūras stils, kurā visa lietojumprogramma ir sadalīta un veidota kā brīvi savienoti, neatkarīgi servisi, kas veidoti atbilstoši uzņēmējdarbībai [1], 2. Mikroservisi ir uz servisiem orientētas arhitektūras stila veids, kurā lietojumprogrammas tiek veidotas kā kolekcija ar dažādiem mazākiem servisiem, nevis kā vesela lietotne [34]. 3. Mikroservisi ir mazas lietojuma komponentes, kas ir neatkarīgi izstrādātas un izvietotas, bet sadarbojas un darbojas, lai veidotu pilnīgu lietojumu [17]. 4. Mikroservisi vai mikroservisu arhitektūra ir lietojumprogrammu izstrādes pieeja, kurā liela lietojumprogramma ir veidota kā moduļu vai servisu komplekts [31]. 5. Mikroservisu arhitektūra sastāv no kolekcijas ar maziem autonomiem servisiem, kur katrs serviss ir pašpietiekams un tam ir jāīsteno viena uzņēmējdarbības funkcija [42]. Tādēļ aplūkojot vairākus skaidrojumus un apvienojot tos ar personīgo darba autora pieredzi, tika izvēlēts šāds skaidrojums - mikroservisi jeb mikroservisu arhitektūra ir arhitektūras stils kas strukturē lietojumu kā servisu kopu. Katrs šāds serviss ir neatkarīgs un tam būtu jāīsteno viena biznesa funkcionalitāte. Tieši šo īpašību ir jāņem vērā, jo mikroservisu būtība slēpjas tajā, ka katrs serviss ir relatīvi mazs.
  11. 11. 11 1.1. att. Tipiska mirkoservisu arhitektūra Attēlā (1.1. att.) ir redzama tipiska mikroservisu arhitektūra kas sastāv no šādām komponentēm: 1. Lietotāja saskarnes; 2. Lietojumprogrammas saskarnes vārtejas (angliski API Gateway); 3. Mikroservisiem; 4. Datubāzes vai vairākām datubāzēm. Izmantojot jebkāda veida tehnoloģiju parasti ir jārēķinās ar to, ka tai ir savas pozitīvās un negatīvās puses, kuras jāņem vērā izvēloties tehnoloģiju savām biznesa vajadzībām. Bieži
  12. 12. 12 vien ignorējot tehnoloģijas stiprās un vājās puses, uzņēmumi nonāk situācijā, kad eksistē problēma, kuras cēlonis ir izvēlētās tehnoloģijas vājā puse un šādos gadījumos nonāk pie secinājuma, ka ir jāmaina izvēlētā tehnoloģija. Mikroservisu arhitektūras būtiskākie ieguvumi: 1. Neatkarīga izvietošana – sniedz iespēju atjaunināt konkrētu servisu bez nepieciešamības izvietot visu lietojumu; 2. Neatkarīga izstrāde – noteikta izstrādes komanda var izstrādāt, pārbaudīt un izvietot servisu; 3. Mazas, orientētas komandas – izstrādes komandas var fokusēties uz vienu servisu. Jo mazāks kods, jo vieglāk to saprast, uzturēt un labot, kā arī jaunpienācējiem ir vieglāk iejusties; 4. Defektu izolācija – ja kāds no servisiem pārtrauc savu darbību, tad tas neietekmē visu lietojumu; 5. Jauktas tehnoloģijas – komandas var izvēlēties labākas tehnoloģijas kas būs piemērotākas servisam; 6. Detalizēta mērogošana – servisi var tikt mērogoti neatkarīgi cits no cita [42]. Atbilstoši avotam (Microservice Architecture, 2018) autors piekrīt minētajiem mikroservisa arhitektūras ieguvumiem. Mūsdienās aizvien vairāk pieaug lietojumu skaits, kas prasa augstu pieejamību. Augstu pieejamību ir grūti nodrošināt izmantojot tradicionālo monolītisko arhitektūru, it īpaši ja iet runa par lietojuma patstāvīgu attīstīšanu. Izmantojot mikroservisu arhitektūru šāda problēma būtiski samazina iespējamo dīkstāvi. Ņemot vērā minēto ieguvumu par to, ka izstrādātāji var darboties produktīvāk atbilstoši avotam (Microservice Architecture, 2018), darba autors tam pilnībā piekrīt pamatojoties uz savas personīgās pieredzes. Izmantojot šādu arhitektūru izstrādātājam ir jāpavada relatīvi mazāks laiks, lai saprastu šī lietojuma daļas loģiku, tādejādi nodrošinot ātrāku izstrādes laiku, kas mērāms izstrādes produktivitātē. Autors secina, ka izmantojot šādu arhitektūru ieguvējs arī ir pasūtītājs, piemēram, ja kodā nejaušības pēc tiek pieļauta kļūda, tad šīs izmaiņas ir vieglāk atgriezt atstājot mazāku iespaidu uz sistēmas kopējo darbību, tāpat arī šīs kļūdas ir iespējams ātrāk pamanīt un izlabot. Mikroservisu arhitektūras būtiskākie trūkumi: 1. Izstrādātājiem jārēķinās ar papildus sarežģītību izstrādājot dalītos lietojumus; 1.1. Integrētās izstrādes rīki (angliski Integrated development environment, turpmāk tekstā IDE) ir orientēti uz monolītisku sistēmu izstrādi un nesniedz tiešu atbalstu dalīto lietojumu izstrādē;
  13. 13. 13 1.2. Izstrādātājiem jārealizē starpprocesu komunikācijas mehānisms (IPC); 1.3. Lietošanas gadījumu īstenošana, kas aptver vairākus servisus, prasa rūpīgu koordināciju starp komandām. 2. Lielāks operatīvās atmiņas patēriņš [30]; 3. Tīkla pārslodze un gaidīšanas laiks – lietojot daudz mazus detalizētus servisus, palielinās starpprocesu komunikācija. Pie nosacījuma, ja saistīto servisu ķēdīte kļūst pārāk gara, tad gaidīšanas laiks var radīt problēmas [42]. Pētot mikroservisu būtiskākos trūkumus atbilstoši avotam (Microservice Architecture, 2018) darba autors daļēji piekrīt avota autora uzskaitītajiem trūkumiem, piemēram, apgalvojums ka IDE ir orientēti uz monolītisko arhitektūru. Pēc autora domām tas ir ļoti atkarīgs no tā kādam nolūkam tiek izmantota izvēlētā IDE un kā tiek organizēts un uzglabāts lietojuma kods. Tā ir laba prakse lietojuma loģiku sadalīt loģiskos moduļos, piemēram, datu importēšanas modulis, kas ir atbildīgs par datu importu no dažādiem datu avotiem (katra importa procedūra var būt neatkarīgs mikroserviss), autorizācijas modulis, kurš ir atbildīgs par lietojuma lietotāju autorizācijas datu validitāti un kontroli (arī šeit procedūras var būt neatkarīgi mikroservisi). Izmantojot šādus loģiskus moduļus lietojuma kods tiek strukturēts vienotā formātā.
  14. 14. 14 1.2. att. Autora veidota lietojuma direktoriju struktūra Attēlā (1.2. att.) autors attēloja lietojuma sadalījumu loģiskos moduļos. Izmantojot šāda veida struktūru lietojuma mikroservisi tiek uzglabāti vienotā zarā, kas IDE rīkam nesagādās grūtības pārvaldīt mikroservisu arhitektūru. Atbilstoši avotam (Microservice Architecture, 2018), kur tā autors min punktu, ka izstrādātājiem jārealizē starpprocesu komunikācijas mehānisms, darba autors tam daļēji piekrīt. Mūsdienās eksistē tik daudz tehnoloģiju kas nodrošina jau gatavu IPC (maksas un bezmaksas). Piemēram, starpprogrammatūra tiek uzskatīta kā IPC mehānisms. Dažas no starpprogrammatūrām: 1. BEA TUXEDO; 2. Narayana; 3. RabbitMQ; 4. OpenTP1;
  15. 15. 15 5. Enduro/X; 6. JBoss Enterprise Application Platform; 7. u.c. Šīs programmatūras jau nodrošina realizētu mehānismu kā notiek komunikācija starp procesiem, pārvalda pašus procesus, nodrošina vienotu konfigurācijas izmantošanu un daudz citu labu iespēju. Lielākā daļa no šāda veida programmatūras piedāvā savu datu apmaiņas formātu datu serializēšanai un deserializācijai, taču neizslēdz iespēju izmantot izstrādātājam vēlamu formātu, kā to rekomendē citi autori – API datu serializācijai rūpīgi jāizvēlas formāts. Apskatot būtiskākos mikroservisu arhitektūras trūkumus autors secina, ka datu apmaiņas formāts šajā arhitektūrā ieņem svarīgu nozīmi, jo mērogojot sistēmu ar mērķi, lai palielinātu apstrādājamos pieprasījumus ir jārēķinās ar to, ka datu serializācija un deserializācija notiks biežāk un ja šajā pieprasījumā notiek vairāku sadarbības servisu izsaukšana, kas veidot ķēdīti, tas var atstāt negatīvu ietekmi, piemēram, kādā no sākotnējiem servisiem vai sistēmas līmenī iestāsies noildze, kā rezultātā pieprasījums netiks apstrādāts. 1.1.Starpprogrammatūras izvēle Attīstoties nozarēm un to tehnoloģijām pieaug programmatūras dažādība. Programmatūras mēdz būt ar dažādām vajadzībām un tās var būt izvietotas dažādās fiziskās iekārtās. Tieši šī iemesla dēļ rodas nepieciešamība sadalīt programmatūru dažādos datoros ko sauc par dalīto programmatūru. Dalītajai programmatūrai ir vajadzīga savstarpēja komunikācija - IPC. Viens no risinājumiem kā nodrošināt šo IPC ir – starpprogrammatūra. Starpprogrammatūra mūsdienās kļūst arvien izplatītāka un tā ieņem svarīgu pozīciju programmatūras izstrādē. Atbilstoši avotam (The Origin (Coining) of the Term "Middleware", 2003) termins starpprogrammatūra radies 1968. gadā NATO konferencē. Tā ieguva savu popularitāti 1980. gados kā risinājums problēmai, kā saistīt jaunākas lietojumprogrammas ar vecākām sistēmām [https://www.feedough.com/what-is-middleware-how-does-it-work/]. Starpprogrammatūra ir datora programmatūra, kas nodrošina servisus operētājsistēmas līmenī priekš dalītiem lietojumiem [18]. Starpprogrammatūra nodrošina starpprocesu komunikāciju - datu pārvaldību, sistēmas atmiņas pārvaldību un citas svarīgas lietas. Šāds risinājums atvieglo darbu izstrādātājiem, jo nav jāuztraucas par to, kā procesi savā starpā varēs komunicēt vienā sistēmā izvietotam lietojumam vai dažādās sistēmās ar dažādu arhitektūru.
  16. 16. 16 Ir pieejams daudz dažādu starpprogrammatūru kas kalpo kā IPC mehānisms. Tās ir pieejamas dažādām programmēšanas valodām – dažas var būt paredzētas Java lietojumiem, citas C/C ++ lietojumiem, citas atbalsta vairākas programmēšanas valodas. Tā kā darba autoram līdzšinējā pieredze programmēšanas valodā lielākoties ir C/C++, tad tas bija kā noteicošais kritērijs pēc kā izvēlēties starpprogrammatūru. Kā papildus kritērijus var minēt darba autora personīgā pieredze un pieejamie starpprogrammatūru salīdzinājumi. Atbilstoši avotam (Enduro/X VS Oracle Tuxedo performance benchmark, 2018) tika veikts salīdzinājums starp Enduro/X un Oracle Tuxedo starpprogrammatūrā, kā rezultātā tika noskaidrots, ka Enduro/X ir, apmēram, par 30% ātrāks starpprocesu ziņojumu sūtīšanā palielinot ziņojuma izmērus. Atbilstoši avotam (Kafka vs RabbitMQ vs Enduro/X vs ActiveMQ on Go – performance benchmark of the year 2018!, 2018), kurā tiek salīdzinātas Apache Kafka, RabbitMQ, Enduro/X un ActiveMQ starpprogrammatūras arī šeit Enduro/X uzrādīja ļoti labus un stabilus rezultātus. Tādēļ mikroservisu arhitektūras realizēšanai autors izvēlējās Enduro/X starpprogrammatūru. Mikroservisu realizēšanai autors ir izvēlējies C programmēšanas valodu, jo tā ir viena no populārākajām programmēšanas valodām atbilstoši avotam (Most Popular and Influential Programming Languages of 2018, 2017). Tā kā veiktspējas testi tiks veikti uz UNIX saimes operētājsistēmas Linux, kuras kodols ir sarakstīts galvenokārt C programmēšana valodā, tad C valodas izvēle ir labs variants mikroservisu rakstīšanai. Tieši šīs izvēles dēļ autors piemeklēja starpprogrammatūru kas nodrošina augstu veiktspēju, kā rezultātā veiktie mērījumi būs precīzāki.
  17. 17. 17 2. DATU APMAIŅAS FORMĀTI Datorprogrammu un sistēmu saziņa vienmēr ir bijusi aktuāla, it sevišķi laika posmā, kad ir pieejams interneta tīkls, dažādas kompānijas, dažādas programmas un to specifika, kurām savā starpā jāsadarbojas. Arī mākoņu skaitļošana, servisu orientēta arhitektūra (angliski Service-oriented architecture, turpmāk tekstā SOA) un mikroservisu risinājumi kļūst aizvien populārāki. Izvēloties šādas tehnoloģijas, tas lietojumam dod plašākas iespējas un dažādāku pielietojumu, taču ieviešot jaunas tehnoloģijas rodas jaunas problēmas, nianses kuras konkrētajā tehnoloģijā ir būtiskas. Palielinoties internetā pieslēgto iekārtu skaitam (un ne tikai) ir nepieciešamas ātrdarbīgas programmas, ko ne vienmēr var mērogot ar fiziskiem dzelžiem. Tāda veida programmas ir nepieciešamas reālā laika jomās – visa veida maksājumu veikšana, notikumu uzskaite, produktu pieejamības sarakstu izgūšanai, sūtāmo un saņemto datu validācija u.c. Mūsdienās pasaulē arvien populārāks kļūst lietu internets (angliski Internet of Things, turpmāk tekstā IoT), kas izmanto zemas jaudas datorus, lai veiktu globālus risinājumus. Arī IoT mazajiem sensoru datoriem nepieciešams sazināties savā starpā. Tieši dēļ ierobežotās aparatūras, augsta līmeņa programmēšanas valodas izmantošana šādos risinājumos kļūst neiespējama. Datu apmaiņas formāts var būtiski ietekmēt lietojuma ātrdarbību. Katrs izvēlētais datu apmaiņas formāts ir unikāls un tam ir sava specifika kā dati tiek sagatavoti transportam. Datu serializācija un deserializācija lielos datu apjomos var aizņemt daudz laika atkarībā no formāta īpašībām. Monolītiskajā arhitektūrā šis aspekts nav tik kritisks, jo lietojums tiek darbināts vienā platformā un vienā izpildāmajā failā. Šim procesam tiek izdalīta procesa atmiņa ar kuru tas strādā. Savukārt mikroservisu arhitektūrā lietojums sastāv no neskaitāmiem mikroservisiem kuriem savā starpā ir jāapmainās ar informāciju. Šim nolūkam tiek lietota IPC un caur to tiek apmainīti dati neskaitāmas reizes. Lai spētu nodrošināt ātrdarbību dalītajos lietojumos viens no svarīgiem izvēlēs posmiem ir datu apmaiņas formāts. 2.1.Datu apmaiņa monolītiskā arhitektūrā Monolītisks lietojums ir tāds lietojums, kur visas tā komponentes atrodas vienuviet – tā ir programma, kas ir pašpietiekama. Šīs programmas daļas ir savstarpēji saistītas un atkarīgas.
  18. 18. 18 Sakarā ar to, ka šādas arhitektūras lietojums darbojas uz vienas platformas un tam ir izdalīts savs atmiņas bloks no kopējās atmiņas, tad visi procesi kas tajā darbojas, datiem var piekļūt uzreiz. 2.1. att. Autora veidots attēls - monolītiskās arhitektūras lietojumprogramma Attēlā (2.1. att.) var redzēt tipisku monolītiskās arhitektūras lietojumu. Šādas arhitektūras lietojums sastāv no: 1. Viena izpildāmā faila (lietojuma); 2. Procesam piešķirtais atmiņas bloks; 3. Trim pavedieniem (var būt arī viens vai vairāki). Attēlā (2.1. att.) ir attēlota situācija, kad pavediens “X” raksta kopējā procesa atmiņas šūnā informāciju (datus), arī pavediens “Y” raksta datus citā atmiņās šūna, kur to pašu šūnu lasa cits pavediens “Z”. Attēlā var labi redzēt, ka šāda arhitektūra ļauj veikt tiešos sistēmas izsaukums darbam ar atmiņu. Šādā risinājumā lietojuma izsaukumiem ir zema cena, jo lietotāja un kodola servisi atrodas vienā atmiņas telpā, kas ļauj veikt ātru atmiņās pārvaldību, failu pārvaldību un citas OS funkcijas izmantojot tiešos sistēmas izsaukumus. Atbilstoši avotam (The Linux Kernel 4.15.0, 2018) autors secina, ka monolītiskajā arhitektūrā datu apmaiņas formāts neieņem tik būtisku lomu kā mikroservisu arhitektūrā, jo nav nepieciešama datu transportēšana izmantojot sistēmas rindas.
  19. 19. 19 2.2. Datu apmaiņa mikroservisu arhitektūrā Dalītais lietojums ir tāds lietojums, kas sastāv no vairākām neatkarīgām daļām. Tas nozīmē, ka jebkurš mikroserviss var tikt pielietots citam lietojumam. Šādu arhitektūru ir vieglāk mērogot, bet datu apmaiņai ir jāizmanto starpprocesu komunikācija. 2.2. att. Autora veidots attēls - dalītais lietojums mikroservisu arhitektūrā Tieši dēļ tā, ka servisu saziņai jāizmanto starpprocesu komunikācija, kur tiek izmantotas sistēmas rindas un arī nepieciešamības gadījumā arī tīkls datu pārraidei uz otru servisu. Attēlā (2.2. att.) ir attēlots dalīts lietojums kas darbojas kā mikroservisu arhitektūra. Šeit serviss “X” sagatavo datus un nosūta tos uz servisu “Y” izmantojot sistēmas IPC. Šis process ir sarežģītāks kā monolītiskajā arhitektūrā, jo kodola servisus nav iespējams izsaukt caur sistēmas tiešajiem izsaukumiem. Kodola servisi un lietotāja servisi šādā arhitektūrā izmanto dažādas adrešu telpas. Dalītajā lietojumā mikroservisu skaits var būt ļoti liels (kas visticamāk tā arī būs) un komunikācija to starpā notiek ļoti bieži, tāpēc loģiski secinot, lai apmainītos ar informāciju starp šiem servisiem būs nepieciešams krietni vairāk iterāciju datu transportēšanā. Dati katrā servisā tiek sagatavoti transportam, lai tos ievietotu sistēmas rindās un caur tām noziņotu otram servisam, ka tam tie dati ir jāpaņem. Otrs serviss šos datus cenšas deserializēt, kas laika izteiksmē arī ir atkarīgs no izvēlētā datu formāta. Kad otrs serviss apstrādā datus, tas var izsaukt citu servisu vai arī atbildēt tam pašam servisam, kur atkal notiek datu serializācijas un deserializācijas darbības. Ņemot vērā problemātisko situāciju ir ļoti svarīgi izvērtēt un izvēlēties pēc iespējas labāku, ātrāku, mazāk resursu izmantojošu datu apmaiņas formātu. Datu apmaiņas formātam ir jābūt pietiekami vienkāršam, lai veiktu manipulācijas ar datiem (rakstīšana, lasīšana, rediģēšana).
  20. 20. 20 Datu formātam noteikti būtu jānodrošina pēc iespējas vienkāršāks API, kas uzlabo koda lasāmību. Jo vienkāršāks API, jo vairāk tas samazina iespēju pieļaut biznesam kritiskas kļūdas, tāpat arī sintaksiskas kļūdas. Datu apmaiņas formāta būtiskākā īpašība ir tā ātrdarbība. Mikroservisu arhitektūrā šī raksturīpašība ir ļoti svarīga un neatņemama sastāvdaļa. Tā kā lietojums sastāv no vairākiem servisiem, tad ir svarīgi, lai datu pārsūtīšana starp servisiem notiek ļoti operatīvi. Datu pārsūtīšanu starp servisiem ietekmē daudzi citi faktori, piemēram, sistēmas noslodze, tīkla noslodze, sistēmas tehniskie parametri u.c. Ar datu pārsūtīšanu šajā kontekstā autors grib pateikt to cik svarīgi ir lai datu formāts spētu ātri serializēt un deserializēt datus, kā arī to cik ātri notiek piekļūšana pie vērtībām izmantojot konkrēto datu apmaiņas formātu. Datu apmaiņas formāta izvēle ir ļoti atbildīgs un sarežģīts posms. Sākotnēji būtu jānoskaidro svarīgi faktori, kas ietekmē datu apmaiņas formāta izvēli. Daži no svarīgākajiem faktoriem datu apmaiņas formāta izvēlē: 1. Kādus datus nepieciešams apstrādāt; 2. Kā datus nepieciešams apstrādāt; 3. Kur un kā datus nepieciešams nogādāt; 4. Cik bieži notiek datu apmaiņa; 5. Par kādu datu apjomu iet runa; 6. Kādi datu tipi tiek izmantoti datos; 7. Vai datu struktūra ir mainīga; 8. u.c. Noteikti vajadzētu ņemt vērā augstāk minētos faktorus un citus faktorus izvēloties datu apmaiņas formātu. Piemēram, ja datu apmaiņa notiek ļoti reti, tad iespējams ka šeit datu apmaiņas ātrums nebūs tik būtisks vai arī, ja datu struktūra ir patstāvīgi mainīga, tad noteikti būtu jāizvēlas tāds datu formāts kuram ir vismazāk atkarību no citām komponentēm. Daži no visbiežāk izmantotajiem datu apmaiņas formātiem zema līmeņa programmēšanas valodās: 1. JavaScript Object Notation – JSON; 2. eXtensible Markup Language – XML; 3. Comma Separated Files – CSV. Izpētot informāciju tīmeklī par piemērotāko datu apmaiņas formātu C programmēšanas valodā, bieži tiek minēti JSON un XML, tādēļ autors izvēlējās šos divus datu apmaiņas formātus izpētīt un salīdzināt.
  21. 21. 21 Tā kā autors salīdzina šos datu formātus izmantojot mikroservisu arhitektūru, kuras realizēšanai izmanto Enduro/X starpprogrammatūru. Enduro/X ir lietojumu serveris un starpprogrammatūra, kas nodrošina iespēju veidot daudzpakāpju mērogojamas lietojumprogrammas (klients/serveris) neviendabīgā (atšķirīgā) izplatītā vidē. Enduro/X programmatūrā IPC komunikācijā izmanto pašu izstrādātu datu apmaiņas formātu, ko sauc par vienoto bufera formātu (angliski Unified Buffer Format, turpmāk tekstā UBF). Tieši šī iemesla dēļ autors izvēlējās šo datu apmaiņas formātu salīdzināt ar iepriekš diviem izvēlētajiem datu apmaiņas formātiem – JSON, XML. 2.3.JavaScript objektu notācija - JSON JavaScript objektu notācija (angliski JavaScript Object Notation, turpmāk tekstā JSON) ir Starptautiskās Standartizācijas Organizācijas (angliski International Organization for Standardization, turpmāk tekstā ISO) apstiprināts datu apmaiņas formāts. Tas ir balstīts uz teksta formātu kas padara to viegli lasāmu. Zemāk attēlā (2.3. att.) ir redzams autora veidots JSON formāta piemērs. 2.3. att. Autora veidots JSON piemērs
  22. 22. 22 Kā redzams attēlā (2.3 .att.) JSON datu apmaiņas formāts ir viegli pierakstāms, tāpat arī lietotājam viegli uztverams un lasāms. Šis formāts ir viegli saprotams un lasāms galvenokārt pateicoties tam, ka tas ir strukturēts. Par strukturētu datu apmaiņas formātu mēdz dēvēt tādu formātu, kas nodrošina datu organizēšanu. Šajā gadījumā adreses dati tiek organizēti (strukturēti) zem vienas atslēgas vērtības, kur tiek aprakstītas adreses detaļas – valsts, pilsēta, iela, māja un mājas numurs. Datu formāts var saturēt vienkāršas datu struktūras kā arī asociatīvus masīvus. Asociatīvs masīvs ir abstrakts datu tips kas sastāv no “atslēga: vērtība” (angliski key:value) pāru kolekcijas ar nosacījumu ka atslēga parādās ne vairāk kā vienu reizi. 2.3.1. JSON formāta vēsture Daglass Krokfords (angliski Douglas Crockford, turpmāk tekstā Daglass) bija pirmais kas specificēja un popularizēja JSON formātu. Šis akronīms radies uzņēmumā “State Software”, kur viens no dibinātājiem bija Daglass. Uzņēmuma līdzdibinātāji piekrita izveidot sistēmu kas izmantoja standarta pārlūkprogrammas iespējas un nodrošināja abstrakcijas slāni globālā tīmekļa (angliski World Wide Web, turpmāk tekstā WEB) izstrādātājiem, lai izveidotu stabilas WEB lietojumprogrammas, kurām bija patstāvīgs abpusējs savienojums ar tīmekļa serveri turot divus Hiperteksta iezīmēšanas valodas (angliski Hypertext Markup Language – HTML, turpmāk tekstā HTML) savienojumus un atbrīvojot tos pirms standarta pārlūkprogrammas pārtraukumiem pie nosacījuma ja netika apmainīti citi dati. Līdzdibinātājiem bija apspriede kurā tie balsoja par to kā nosaukt šo datu formātu – JSML vai JSON, kā arī ar kādu licences tipu to piedāvāt. Tika izvēlēt JSON, jo JSML akronīms jau bija aizņemts JSpeech iezīmēšanas valoda (angliski JSpeech Markup Language) [3]. Sākotnēji JSON bija paredzēts kā JavaScript skriptu valodas apakškopa. JSON tika iegūts no ECMAScript skriptu valodas standarta (ECMA-262 un ISO/IEC 16262) ko pirmreizēji izdeva standartu organizācija “Ecma International” 1997. gada jūnijā. 1999. gada decembrī tika izsludināts trešais ECMA-262 izlaidums un tieši no šī izlaiduma radās JSON. Formāts parasti tiek lietots kopā ar JavaScript, bet tas ir no valodas neatkarīgs datu formāts, tādēļ tas ir pielietojams daudz citās programmēšanas valodās un ne tikai [3]. Oficiālajā JSON tīmekļa vietnē ir izvietotas atsauces uz programmēšanas valodu bibliotēkām kas nodrošina šo datu apmaiņas formātu. Bibliotēkas nodrošina datu formāta ģenerēšanu un parsēšanu.
  23. 23. 23 2.1.tabula. JSON programmēšanas valodu bibliotēkas (modificēts no (Introducing JSON, 2002)) Programmēšanas valoda Bibliotēkas 8th json> ABAP EPO Connector ActionScript ActionScript3 Ada GNATCOLL.JSON AdvPL JSON-ADVPL ASP JSON for ASP, JSON ASP utility class AWK JSON.awk, rhawk Bash Jshon, JSON.sh BlitzMax bmx-rjson C JSON_checker, YAJL, LibU, json-c, json-parser, jsonsl, WJElement, M's JSON parser, Cjson, Jansson, jsmn, parson, ujson4c, nxjson, frozen, microjson, mjson C++ JSONKit, jsonme--, ThorsSerializer, JsonBox, jvar, rapidjson, JSON for Modern C++, ArduinoJson, minijson, jsoncons, QJson, jsoncpp, CAJUN, libjson, nosjob, JSON++, JSON library for IoT, qmjson, JSON Support in Qt, JsonWax for Qt C# fastJSON, JSON_checker, Jayrock, Json, NET - LINQ to JSON, JSON for .NET, JSONSharp, fluent-json, Manatee Json, FastJsonParser, LightJson, liersch,json Ciao Ciao JSON encoder and decoder Clojure data.json Cobol XML Thunder, Redvers COBOL JSON Interface ColdFusion SerializeJSON, toJSON D libdjson Dart json library Delphi Delphi Web Utils, JSON Delphi Library E JSON in TermL Fantom Json FileMaker JSON Fortran json-fortran, YAJL-Fort Go package json Groovy groovy-io Haskell RJson package, json package Java JSON-java, JSONUtil, jsonp, Json-lib, Stringtree, SOJO, json- taglib, Flexjson, JON tools, Argo, jsonij, fastjson, mjson, jjson, json-simple, json-io, JsonMarshaller, google-gson, Json-smart,
  24. 24. 24 Programmēšanas valoda Bibliotēkas FOSS Nova JSON, Corn CONVERTER, Apache johnzon, Genson, JSONUtil, cookjson JavaScript JSON, json2.js, clarinet, Oboe.js LabVIEW flatten Lisp Common Lisp JSON, Emacs Lisp LiveCode mergJSON LotusScript JSON LS Lua JSON Modules M DataBallet Matlab JSONlab, 20565, 23393 Net.Data netdata-json Nim Module json Objective C NSJSONSerialization, Json-framework, JSONKit, Yajl-objc, TouchJSON OCaml jsonm PascalScript JsonParser Perl CPAN Photoshop JSON Photoshop Scripting PHP PHP 5.2 PicoLisp picolisp-json Pike Public.Parser.JSON, Public.Parser.JSON2 PL/SQL pljson PureBasic JSON Puredata PuRestJson Python The Python Standard Library, simplejson, pyson, Yajl-Py, ultrajson, metamagic.json R Rjson, jsonlite Racket json-parsing Rebol json.r RPG JSON Utilities Rust Serde JSON, json-rust Ruby yajl-ruby, json-stream Scheme MZScheme, PLT Scheme Squeak Squeak Symbian s60-json-library Tcl JSON Visual Basic VB-JSON, PW.JSON, .NET-JSON-Transformer
  25. 25. 25 Augstāk tabulā (2.1. tabula) ir uzskaitītas programmēšanas valodas un tām pieejamās oficiāli atzītās bibliotēkas uz doto brīdi. Kā redzams, tad programmēšanas valodās C, C++, C#, Java, Objective C un Python ir salīdzinoši daudz bibliotēku. Arī kopējais programmēšanas valodu skaits ir liels kas liecina par JSON datu formāta pieprasījumu un popularitāti. JSON pirmo reizi tika publicēts oficiālajā tīmekļa vietnē www.json.org 2001. gadā. Piecus gadus vēlāk tika publicēta JSON sintakse kā Interneta inženierijas darba grupas (angliski Internet Engineering Task Force, turpmāk tekstā IETF) RFC 4627 standarts. ECMA- 262 piektais izdevums 2009. gadā ietvēra JSON gramatikas normatīvo specifikāciju [4]. JSON kļuva par ECMA starptautisku standartu 2013. gadā kā ECMA-404 standarts. Tajā pašā gadā RFC 7158 standarts izmantoja ECMA-404 standartu kā atsauci. 2014. gadā RFC 7159 standarts kļuva par galveno atsauci JSON interneta lietošanai (Interneta pasta vairākmērķu paplašinājumi (angliski Multipurpose Internet Mail Extensions - MIME) application / json), līdz ar to RFC 4627 un RFC 7158 standarti kļuva neaktuāli (bet saglabājot ECMA-262 un ECMA-404 standartus kā galvenās atsauces). 2017. gada decembrī RFC 7159 standarts kļuva neaktuāls, jo iznāca jauns RFC 8259 standarts [4]. ECMA-404 standarta otrais (pēdējais) izlaidums, kas izdots 2017. gada decembrī atsaucas uz RFC 8259 standartu, ka JSON sintakse ir identiska. 2.3.2. JSON formāta sintakse JSON sintakse patiešām ir ļoti vienkārša, jo pareizai pierakstei tiek izmantots ļoti maz marķieru (angliski token). Atbilstoši avotam (Introducing JSON, 2002) JSON sastāv no sešiem strukturālajiem marķieriem un trīs literārajiem marķieriem. 2.2.tabula. JSON strukturālie marķieri Vērtība Skaidrojums Unikoda rakstzīme [ Kreisā kvadrātiekava U+005B { Kreisā figūriekava U+007B ] Labā kvadrātiekava U+005D } Labā figūriekava U+007D : Kols U+003A , Komats U+002C
  26. 26. 26 Tabulā (2.2. tabula) ir uzskaitīti strukturālie marķieri kurus lieto JSON pierakstam. Standarti paredz ka starp šiem marķieriem ir atļauts lietot nenozīmīgas atstarpes. Par nenozīmīgu atstarpi tiek uzskatīta viena vai vairākas Unikoda rakstzīmes. Atbilstoši avotam (Standard ECMA-404”, ISO/IEC 21778, 2017) tiek definētas šādas Unikoda rakstzīmes kas raksturo atstarpi: 1. Rakstzīmju tabulācija (U+0009, angliski, character tabulation); 2. Rindiņas pārbīde (U+000A, angliski line feed); 3. Rakstatgrieze (U+000D, angliski carriage return); 4. Atstarpe (U+0020, angliski space). 2.3.tabula. JSON literālie marķieri Vērtība Skaidrojums Unikoda rakstzīme true Patiesa vērtība U+0074 U+0072 U+0075 U+0065 false Nepatiesa vērtība U+0066 U+0061 U+006C U+0073 U+0065 null Nulles vērtība U+006E U+0075 U+006C Tabulā (2.3. tabula) ir uzskaitīti literālie marķieri jeb vērtības kuras lieto JSON pierakstā, lai raksturotu kādas atslēgas vērtību. Kā jau ierasts, industrijā “true” ,“false” un “null” vērtības tiek lietotas visai bieži. 2.3.3. JSON formāta datu tipi Atbilstoši avotam (Standard ECMA-404”, ISO/IEC 21778, 2017) JSON datu formāta ECMA-404 standarts paredz ka katrai atslēgai obligāti ir jābūt definētai vērtībai. Ja vērtība netiek norādīta, tad JSON pieraksts nav pareizs un tiek izvadīta kļūda. Tieši šim nolūkam ir paredzēta literālā vērtība “null”. Atslēgu vērtībām var būt četri datu tipi un trīs literālās vērtības, kuras jau iepriekš tika aprakstītas tabulā (2.3. tabula).
  27. 27. 27 2.4. att. JSON vērtības – datu tipi (aizgūts no (Standard ECMA-404”, ISO/IEC 21778, 2017) Augstāk attēlā (2.4. att.) ir uzskaitītas visas iespējamās JSON vērtības, tās ir: 1. Virkne (angliski string); 2. Skaitlis; 3. Objekts; 4. Masīvs; 5. Patiesa vērtība; 6. Nepatiesa vērtība; 7. Nulles jeb tukša vērtība. Tā kā JSON atbalsta vērtību ar tipu objekts, tas nozīmē ka vērtības var tikt izvērstas. Atbilstoši avotam (Standard ECMA-404”, ISO/IEC 21778, 2017) virkne ir secība ar Unikoda rakstzīmēm šī virkne var būt tukša bez rakstzīmēm, bet tādā gadījumā dubultās pēdiņas tik un tā ir jālieto. Virknes vērtības obligāti ir jāievieto dubultajās pēdiņās, arī ja tas ir tikai viens simbols.
  28. 28. 28 2.5. att. JSON virknes vērtību īpašības (aizgūts no (Standard ECMA-404”, ISO/IEC 21778, 2017) Attēlā (2.5. att.) ir attēlota virknes datu tipa vērtību sintakse. Katra atslēgas virknes vērtība sākas ar dubulto pēdiņu kam seko jebkura Unikoda rakstzīme izņemot dubulto pēdiņu vai vadības simbolu “”. Šis datu formāts ļauj ievietot šīs izņēmumu rakstzīmes īpašā veidā tāpat kā to dara citās programmēšanas valodās. Lai ievietotu šīs īpašās rakstzīmes, kas ir attēlotas attēlā (2.5. att.), pirms rakstzīmēm ir jālieto vadības simbols “”, tas nodrošinās šī simbola izmantošanu virknē. Arī citas papildus rakstzīmes kombinācijā ar vadības simbolu var tikt izmantotas lai formatētu tekstu, piemēram, lietojot vadības simbolu, rakstzīmi “u” un četrus heksadecimālos skaitļus, tas tiks reprezentēts kā unikoda rakstzīme (piemēram, “u005b” tiks aizvietotas ar rakstzīmi “[”). JSON atslēgas vērtības tips skaitlis ir secība ar decimāliem skaitļiem bez liekām nullēm (piemēram, lietojot vērtību 001234 tiks paziņota kļūda par nekorektu vērtību). Gadījumā ja tomēr ir nepieciešams pārsūtīt vērtību ar vairākām nullēm priekšā, tad to ir nepieciešams sūtīt izmantojot virknes datu tipu.
  29. 29. 29 2.6. att. JSON skaitlisko vērtību īpašības (aizgūts no (Standard ECMA-404”, ISO/IEC 21778, 2017) Attēlā (2.6. att.) ir atspoguļota JSON skaitlisko vērtību sintakse. Skaitliskās vērtības var atspoguļot ar pozitīvu zīmi “+”, tāpat arī ar negatīvu zīmi “-”. Tāpat arī tips nodrošina daļskaitļus, kas tiek atdalīti ar punktu. Ja ir nepieciešama eksponenta vērtība, tādā gadījumā jālieto prefikss “e” vai “E” un pēc izvēlēs “+”’vai “-” zīme. JSON datu tips objekts tiek apzīmēts (pierakstīts) kā figūriekavu pāris “{}”. Objekta vērtība var būt tukša vai sastāvēt no viena vai vairākiem “atslēga: vērtība” pāriem. Objekta datu tips nav sakārtots, tas nozīmē ka vērtības tajā tiek uzglabātas tādā secībā kā tās tika pievienotas. 2.7. att. JSON objekta vērtību īpašības (aizgūts no (Standard ECMA-404”, ISO/IEC 21778, 2017) Attēlā (2.7. att.) ir attēlota JSON objekta datu tipa sintakse. Katram objekta elementam ir jābūt atslēgai ar vērtību, kas tiek atdalīti ar kolu. Vairāki pāri ar “atslēga: vērtība” tiek atdalīti ar komatu. Objekts var saturēt citu objektu, kas padara šo datu formātu par strukturētu datu formātu. Tāds datu formāts ir ērts, jo to ir iespējams organizēt pēc lietotāja vajadzībām, kā arī pēc datu īpašībām. Piemēram, ir iespējams aprakstīts cilvēku kā objektu un kādā šī objekta atslēgā aprakstīt tam piederošos automobiļus kā vairākus citus objektus.
  30. 30. 30 2.8. att. Autora veidots attēls - JSON objekts citā objektā Attēlā (2.8. att.) autors ilustrēja augstāk aprakstīto piemēru par personu un tai piederošajām automašīnām. Dotajā JSON piemērā ir attēlots viens kopējs objekts, kas satur masīvu ar personām. Personu masīvā tiek uzglabāti objekti jeb personas. Katra persona satur raksturīpašības – vārdu, uzvārdu un automašīnu masīvu. Automašīnu masīvs uzglabā objektus jeb automašīnas kas raksturo tās. Šādu datu struktūru ir viegli lasīt, jo uzreiz acīm redzami var saskatīt datu piederību konkrētiem objektiem. JSON masīvs ir sakārtots saraksts ar vērtībām. Masīvs sākas ar kreiso kvadrātiekavu un beidzas ar labo kvadrātiekavu. Masīvs var būt tukšs vai ar “atslēga: vērtība” pāriem. 2.9. att. JSON masīva vērtības īpašības (aizgūts no (Standard ECMA-404”, ISO/IEC 21778, 2017) Attēlā (2.9. att.) ir redzama JSON masīva vērtības sintakse. Masīva vērtības tiek atdalītas ar komatu. Šādu datu tipu izmanto tad kad vērtībām ir secīga nozīme. Masīva vērtība var saturēt jebkuru no JSON datu tipiem, kas iepriekš tika uzskaitīti.
  31. 31. 31 2.4.Paplašināmā iezīmēšanas valoda - XML Paplašināmā iezīmēšanas valoda (angliski eXtensible Markup Language, turpmāk tekstā XML) ir iezīmēšanas valoda kas apraksta noteikumu kopumu tādā formātā, kas ir cilvēk lasāms, gan mašīnlasāms. Tas tika iegūts no vecāka standarta formāta, ko sauc par Standarta vispārinātās iezīmēšanas valodu (angliski Standard Generalized Markup Language, turpmāk tekstā SGML), lai būtu piemērotāks tīmekļa lietošanai. SGML ir atzīts ISO standarts - ISO 8879 [5]. XML ir programmatūras un aparatūras neatkarīgs standarts datu glabāšanai un transportēšanai. 2.10. att. Autora veidots XML datu formāta piemērs Kā redzams attēlā (2.10. att.) XML ir strukturēts datu formāts. Katrs XML elements var saturēt vairākus citus elementus, tas piešķir šim datu apmaiņas formātam plašāku pielietojumu. XML cieši sadarbojas ar šādiem standartiem: 1. XML Asynchronous JavaScript And XML( AJAX); 2. XML Document Object Model (DOM); 3. XML Path Language (XPath);
  32. 32. 32 4. XML eXtensible Stylesheet Language Transformations (XSLT); 5. XML Query (XQuery); 6. XML Document Type Definition (DTD); 7. XML Schema Definition (XSD); 8. XML Web Services [25]. 2.4.1. Valodas XML vēsture XML vēsture sākas ar SGML valodas izstrādi 1970 gados. SGML ir iezīmēšanas valoda, kurā apraksta dokumentu marķēšanas valodas. SGML mērķis bija izveidot vārdnīcas kas varētu tikt izmantotas dokumentu iezīmēšanai izmantojot strukturālus tagus [2]. SGML lielākais panākums bija HTML, kas ir SGML lietojumprogramma. HTML nav vienīgais SGML lietojums. HTML neietver visu SGML funkcionalitāti, pat ne tuvu tam. HTML valoda ierobežo izstrādātājus ar noteiktiem tagiem kas paredzēti tīmekļa lapu izstrādei, bet tā tomēr nodrošināja vairāk iespēju nekā tradicionālā tīmekļu lapu iezīmēšanas valoda [21]. HTML nav paredzēts lai apmainītos ar datiem starp nesaderīgām datubāzēm vai, piemēram, sūtīt atjauninātus produkta kataloga datus mazumtirgotāju vietnēm. SGML bija acīmredzama izvēle citām lietojumprogrammām, kas izmantoja internetu, bet nebija vienkāršas tīmekļa lapas, kurās cilvēki varētu lasīt. Galvenā problēma bija tā, ka SGML valoda bija ļoti sarežģīta. Programmas kas tika realizētas vai balstītas uz SGML apakšgrupām, bieži vien nebija saderīgas [21]. 1996. gadā Džonatans (Jon Bosak), Timotejs (Tim Bray), Mihaels (C. M. Sperberg- McQueen), Džeimss (James Clark) un citi speciālisti sāka darbu pie tā saucamās “vieglās” SGML versijas, kas saglabāja lielāko daļu SGML funkcionalitātes, bet tika izņemtas daudzas liekas funkcijas, kas bija jau novecojušas, pārāk sarežģītas un nesaprotamas lietotājiem, kā arī tās funkcijas kas pēdējo 20 gadu laikā nebija noderīgas. 1998 gada februārī tika izlaists šī darba rezultāts – XML 1.0, kas izrādījās tūlītēja veiksme. Daudzi izstrādātāji, kuri zināja, ka viņiem ir vajadzīga strukturāla iezīmēšanas valoda, bet nebija spējuši pieņemt SGML sarežģītību, ar lielāko prieku sāka izmantoja XML [21]. 2.4.2. Valodas XML sintakse XML sintakse nav sarežģīta, taču tā prasa vairāk pieraksta nekā citi datu apmaiņas formāti. Sintakses noteikumi ir diezgan viegli, tāpēc tas nesagādā grūtības tos iemācīties.
  33. 33. 33 2.11. att. XML sintakses noteikumi (aizgūts no (XML Syntax, 2018)) Attēlā (2.11. att.) ir attēloti sintakses noteikumi, lai XML dokumentā rakstītu dažāda veida iezīmēšanu un tekstu. Sintakses noteikumi tiek iedalīti: 1. XML deklarācija jeb prolog; 2. Tagi jeb elementi; 3. Atribūti; 4. Atsauces; 5. Teksts. XML dokumenta deklarācija nav obligāta, bet to parasti lieto lai norādītu XML dokumenta versiju un dokumentā izmantoto kodējumu. 2.12. att. XML deklarācija jeb prolog Attēlā (2.12. att.) ir attēlota XML deklarācijas sintakse. Deklarācija tiek norādīta kvadrātiekavās ar jautājumu zīmēm atverot un aizverot kvadrātiekavu, kā arī tiek norādīta iezīmēšanas valoda – xml (reģistr jūtīgs). Ja tiek lietota deklarācija, tad tā obligāti jānorāda dokumenta sākumā. XML dokuments sastāv no elementiem ko mēdz dēvēt arī par mezgliem vai tagiem. Elements var sastāvēt no: 1. Teksta; 2. Atribūtiem;
  34. 34. 34 3. Citiem elementiem; 4. Vai arī dažādas variācijas no augstāk uzskaitītajiem. 2.13. att. Autora veidots XML piemērs Attēlā (2.13. att.) ir attēlotas divas personas XML pierakstā, kurām ir dažādi tipi – klients un darbinieks. Šajā attēlā elementiem <name>, <surname>, <code>, <birthdate>, <gender> ir teksta saturs. Savukārt <persons> un <customer> ir elementu saturs. Elementam <customer> ir autora definēts atribūts “type”. XML elementi var būt arī tukši bez satura. Tagi kas nesatur tekstu var tikt pierakstīti kā tagi kas paši sevi aizver, piemēram, <gender type=”M”/>. Jāņem vērā ka elementi ir reģistr jūtīgi. XML dokumentā var būt tikai viens saknes elements, citādāk XML struktūra nebūs pareiza. XML atribūts norāda elementam vienu īpašību izmantojot “atslēga= vērtība” pāri. Elementam var būt vairāki atribūti. Atslēgas vērtība vienmēr jāievieto pēdiņās. Atsauces parasti ļauj pievienot papildus tekstu vai atzīmi dokumentā. Šāda veida atsauces vienmēr sākas ar simbolu “&” un beidzas ar semikolu, piemēram, ja ievieto atsauci “&apos;”, tad šis tik aizstāts ar apostrofa zīmi. Elementu un atribūtu nosaukumi ir reģistr jūtīgi, tas nozīmē ka sākuma un beigu elementi jāraksta vienādā reģistrā (piemēram, elements <piemers> nav vienāds ar <Piemers>). Atstarpes starp elementiem un atribūtiem tiek ignorētas, bet jāņem vērā, ka atribūtu un elementu nosaukumi nevar saturēt atstarpes. Tāpat kā citās valodās XML arī
  35. 35. 35 eksistē rezervētās rakstzīmes. Rezervētas rakstzīmes nenozīmē to ka tās nevar izmantot, vienkārši tām ir speciāls pieraksts kā tās drīkst izmantot. 2.4.tabula. XML rezervētās rakstzīmes Rakstzīme Skaidrojums Unikoda rakstzīme < Kreisā stūra iekava U+003C > Labā stūra iekava U+003E & UN zīme U+0026 ' Apostrofs U+0027 “ Dubultā pēdiņa U+0022 Tabulā (2.4. tabula) ir uzskaitītas XML rezervētās rakstzīmes. Lai lietotu šīs rakstzīmes tās jāizvieto ar atsauci uz šo rakstzīmi. 2.4.3.Valodas XML datu tipi XML datu tipi tiek aprakstīti un kontrolēti izmantojot XML shēmu (angliski XML Schema, turpmāk tekstā XSD). Shēma ir dokumenta tipu definīcijas (angliski Document Type Definition, turpmāk tekstā DTD) alternatīva tikai ar plašākām iespējām. DTD definē un apraksta derīgos elementus un atribūtus, savukārt XML shēma apraksta XML dokumenta struktūru: 1. Elementus un to atribūtus kas ir derīgi XML dokumentam; 2. Apakš elementu skaitu un to secību; 3. Elementu un atribūtu tipus; 4. Elementu un atribūtu noklusētās vērtības. Galvenais mērķis kāpēc būtu jālieto šāda shēma ir tas, ka tā kontrolē dokumenta struktūru. Šāda veida shēmas ir lietderīgas, lai sūtītājs un lietotājs varētu zināt kādus datus jāsaņem, tas mazina pieļaujamās kļūdas datu apmaiņā. Virknes datu tips tiek lietots priekš vērtībām kas satur rakstzīmju virknes. Vērtības vietā ir atļauts uzglabāt: 1. Rakstzīmes; 2. Rindiņas pārbīdes; 3. Rakstatgriezes; 4. Atstarpes; 5. Rakstzīmes tabulācijas. No virknes datu tipa izriet vēl daži virknes datu tipi (neskaitot pašu virknes tipu).
  36. 36. 36 2.5.tabula. XML virknes datu tipu paveidi (modificēts no (XSD String, 2018)) Nosaukums Apraksts ENTITIES Elementu saraksts, kas satur datu tipa “ENTITY” vērtības atdalītas ar atstarpi. ENTITY Elements, parasti tiek lietots, tad kad ir nepieciešams iekļaut informāciju, kas nav XML formātā, piemēram, attēls. ID Unikāls identifikators, kura vērtībai jāatbilst “NCName” tipam. IDREF Identifikatora atsauce, izmanto lai atsauktos uz kādu identifikatoru XML dokumentā. IDREFS Identifikatora atsauces, kas atdalītas ar atstarpi. language Norāda to, kādā valodā ir dokuments vai tā daļējs saturs. Name Vārds, kam ir noteikti ierobežojumi – vārdam jāsākas ar burtu, pasvītrojumu vai kolu, kam seko burti, skaitļi, pasvītrojumi, koli, domuzīmes un punkti. NCName Vārds, kam noteikti tādi paši ierobežojumi kā tipam “Name”, bet tas nevar saturēt kolus. NMTOKEN Marķieris, kas var sastāvēt no burtiem, cipariem, punktiem, domuzīmēm, pasvītrojumiem un koliem. Tipam tiek ierobežota atstarpju lietošana. NMTOKENS Tipa “NMTOKEN” saraksts atdalīts ar atstarpēm. normalizedString Virkne, kurā nav rindu pārbīdes, rakstatgriezes vai rakstzīmju tabulācijas. QName Sastāv no prefiksa un vērtības, kas atdalīta ar kolu. Prefiksam un vērtībai jāatbilst tipam “NCName”. token Rakstzīmju virkne, kas satur jebkuru Unikoda rakstzīmi, ko pieļauj XML. Tabulā (2.5. tabula) ir uzskaitīti virknes datu tipa atvasinājumi, kuriem ir savas īpašības. Katrs no tipiem ierobežo tā pielietojumu, taču tas ir domāts tā, lai lietotājam būtu vieglāk kontrolēt datus no jau esošiem datu tipiem. Virknes datu tipiem arī ir iespējams norādīt dažus ierobežojumus. Pieejamie ierobežojumi ir aprakstīti sadaļā 2.2.9. XML datu apmaiņas formāts nodrošina šādus datuma un laika tipus: 1. Datums, XSD shēmā tiek norādīts – xs:element type=”xs:date”, 2. Laiks, XSD shēmā tiek norādīts – xs:element type=”xs:time”, 3. Datums un laiks, XSD shēmā tiek norādīts – xs:element type=”xs:dateTime”. Pēc autora domām šie datu formāti ir parocīgi, jo tas jau nosaka vienotu standartu kā datums un laiks tiek pierakstīts. Šāda veida tipi samazina varbūtību ka XML dokumentu nevarēs apstrādāt kāda cita puse, jo nevarēs paredzēt saņemamo formātu.
  37. 37. 37 Datums tiek pierakstīts šādā formātā – YYYY-MM-DD, kur: 1. YYYY tiek atšifrēt kā gads; 2. MM tiek atšifrēts kā mēnesis (gada mēneša cipars); 3. DD tiek atšifrēts kā diena (konkrētā mēneša diena attiecīgajā gadā). Datuma tipam vērtībā ir iespējams norādīt laika zonu, lai norādītu datumu universālajā koordinātes laikā (angliski Universal Time Coordinated – UTC), vērtības beigās ir jāpievieno lielais burts “Z” vai arī ir iespējams uzstādīt laika nobīdi norādot ar “+” vai “-” laiku formātā “HH:MI”, kur: HH ir stundas un MI ir minūtes. Visi formāta elementi ir obligāti. Laiks tiek pierakstīts šādā formātā – HH:MM:SS, kur: 1. HH tiek atšifrēts kā stundas; 2. MM tiek atšifrēts kā minūtes; 3. SS tiek atšifrēts kā sekundes. Tāpat kā datuma tipam, arī šeit var norādīt laika zonu, laika nobīdi tādā pašā formātā un pierakstā. Visi formāta elementi ir obligāti. Datuma un laika tips tiek pierakstīts šādā formātā – YYYY-MM-DDThh:mm:ss, kur: 1. YYYY tiek atšifrēt kā gads; 2. MM tiek atšifrēts kā mēnesis (gada mēneša cipars); 3. DD tiek atšifrēts kā diena (konkrētā mēneša diena attiecīgajā gadā); 4. T tiek atšifrēts kā pazīme, kas norāda ka sākas laika formāts; 5. HH tiek atšifrēts kā stundas; 6. MM tiek atšifrēts kā minūtes; 7. SS tiek atšifrēts kā sekundes. Arī šim datu formātam ir iespējams norādīt laika zonu un laika nobīdi, kā arī jāņem vērā, ka visi uzskaitītie elementi ir obligāti. Datumam un laikam eksistē vēl dažādi apakš tipi, kurus var izmantot lai kontrolētu datu integritāti. 2.6.tabula. XML datuma un laika paveidi (modificēts no (XSD Date, 2018)) XSD shēmas tipa nosaukums Paskaidrojums duration Apraksta laika intervālu (piemēram, P5D tiek uzskatīts par piecu dienu periodu). gDay Apraksta daļu no datuma– diena (DD)
  38. 38. 38 XSD shēmas tipa nosaukums Paskaidrojums gMonth Apraksta daļu no datuma – mēnesi (MM) gMonthDay Apraksta daļu no datuma – mēnesi un dienu (MM-DD) gYear Apraksta daļu no datuma – gadu (YYYY) gYearMonth Apraksta daļu no datuma – gadu un mēnesi (YYYY-MM) Tabulā (2.6. tabula) ir uzskaitīti visi pārējie XML datuma un laika tipi (izņemot iepriekš aprakstītos – datums, laiks, datums un laiks). Datuma un laika tipiem arī ir pieejami ierobežojumi, kas ir aprakstīti zemāk. Datu formāts ir paredzēts skaitliskām vērtībām. Tāpat kā citiem XML datu tipiem, arī šiem eksistē vairāki tipu iedalījumi šajā kategorijā. 2.7.tabula. XML skaitliskās grupas paveidi (modificēts no (XSD Numeric, 2018)) XSD shēmas tipa nosaukums Paskaidrojums byte Atspoguļo veselu skaitli diapazonā no -128 līdz 127. Papildus var izmantot “+” un “-” prefiksus, kā arī nulles skaitļa priekšā. decimal Atspoguļo skaitliskas vērtības, kas var saturēt decimāldaļu. Lai tos atdalītu, tiek izmantots punkts. int Veselie skaitļi diapazonā no -2147483648 līdz 2147483647. Papildus var izmantot “+” un “-” prefiksus, kā arī nulles skaitļa priekšā. integer Atspoguļo lielus veselos skaitļus, kur decimāldaļa ir aizliegta. No šī tipa izriet 12 apakš tipi. long Atspoguļo vērtības no -9223372036854775808 līdz 9223372036854775807. double dubultas precizitātes peldošā punkta formāts. float Viena precizitātes peldošā punkta formāts. negativeInteger Negatīvs veselskaitlis, kam priekšā tiek lietota “-” zīme. nonNegativeInteger Pozitīvs veselskaitlis, kam priekša var lietot “+” zīmi. nonPositiveInteger Ne pozitīvas vērtības, ieskaitot 0. positiveInteger Pozitīvas vērtības, neieskaitot 0. short Atspoguļo vērtības no -32768 līdz 32767. unsignedLong Atspoguļo veselskaitli ar vērtībām no 0 līdz 18446744073709551615. unsignedInt Atspoguļo veselskaitli ar vērtībām no 0 līdz 4294967295.
  39. 39. 39 XSD shēmas tipa nosaukums Paskaidrojums unsignedShort Atspoguļo veselskaitli ar vērtībām no 0 līdz 65535. unsignedByte Atspoguļo veselskaitli ar vērtībām no 0 līdz 255. Tāpat kā virknes datu tipam, arī skaitliskajam datu tipam eksistē atvasinājumi, kuri spēj uzglabāt datus noteiktā formātā. Arī skaitliskajiem tipiem ir pieejami ierobežojumi, kas ir aprakstīti zemāk. Eksistē divi binārie datu tipi: 1. base64Binary; 2. hexBinary. base64Binary datu formāts tiek lietots lai uzglabātu datus kas tiek šifrēti zem Base64 formāta. Savukārt hexBinary datu tips tiek lietots lai uzglabātu datus, kas tiek šifrēti zem heksadecimālā formāta. Starptautiskais resursa identifikatora (angliski Internationalized Resource Identifier, turpmāk tekstā IRI) datu tips tiek lietots lai uzglabātu IRI. IRI ir interneta protokola standarts kas paplašina vienoto resursu identifikatoru (angliski Uniform Resource Identifier, turpmāk tekstā URI) protokolu. IRI tiek izmantots, lai identificētu resursus. Eksistē divu tipu IRI – absolūtie un relatīvie. Absolūtais URI nodrošina visu resursa kontekstu, kas nozīmē ka tiek reprezentēta pilna adrese, piemēram, “https://www.w3schools.com/xml/schema_dtypes_misc.asp”. Savukārt relatīvie URI tiek norādīti kā atšķirība no esošā URI. 2.4.4.Valodas XML datu tipu ierobežojumi Augstāk aprakstītajiem datu tipiem ir pieejami arī to ierobežojumi. Šie ir XML piedāvātie ierobežojumu atribūti, kuru apraksta XSD shēmā. 2.8.tabula. XML datu tipu ierobežojumi (modificēts no (XSD Misc, 2018)) XSD shēmas tipa nosaukums Paskaidrojums enumeration Sarakts ar pieļaujamajām vērtībām. fractionDigits Norāda maksimālo atļauto decimālzīmju skaitu. Pieļaujamās vērtības ir 0 vai lielāks. length Norāda precīzu atļauto rakstzīmju skaitu vai saraksta vienības. Pieļaujamās vērtības ir 0 vai lielāks.
  40. 40. 40 XSD shēmas tipa nosaukums Paskaidrojums maxExclusive Norāda maksimālo skaitlisko vērtību (vērtībai ir jābūt mazākai par šo noteikto). maxInclusive Norāda maksimālo skaitlisko vērtību (vērtībai ir jābūt mazākai vai vienādai ar šo noteikto). maxLength Norāda maksimālo atļauto rakstzīmju vai sarakstu vienību skaitu. Pieļaujamās vērtības ir 0 vai lielāks. minExclusive Norāda minimālo skaitlisko vērtību (vērtībai ir jābūt lielākai par šo noteikto). minInclusive Norāda minimālo skaitlisko vērtību (vērtībai ir jābūt lielākai vai vienādai ar šo noteikto). minLength Norāda minimālo atļauto rakstzīmju vai sarakstu vienību skaitu. Pieļaujamās vērtības ir 0 vai lielāks. pattern Nosaka precīzu rakstzīmju secību, kas ir pieņemama. totalDigits Norāda precīzu atļauto ciparu skaitu. Jābūt lielākam par nulli. whiteSpace Norāda kā tiek apstrādātas atstarpes. Tabulā (2.8. tabula) ir uzskaitīti visi datu tipu ierobežojumi. Daži no šiem ierobežojumiem nav paredzētu kādam datu tipam, jo tie ir izmantojami citam mērķim, piemēram, atribūts “minExclusive” vai “minInclusive” nevar tik izmantots virknes datu tipam, par cik tas ir paredzēts lai ierobežotu skaitliskās vērtība minimālo (ieskaitot/neieskaitot) vērtību. Lietojot šos ierobežojums XSD shēmas sintakse nedaudz pamainās no iepriekš attēlotajiem piemēriem. 2.14. att. Autora veidots XSD shēmas piemērs ar ierobežojumu Kā redzams attēlā (2.14. att.) tiek izmantots virknes datu tips, bet to vairs nenorāda elementā “element”, bet gan elementa apakš elementā “restriction” atribūtā ar nosaukumu
  41. 41. 41 “base”. Ar šo piemēru tiek panākts, ka vērtības elementā “dzimums” ir iespējamas tikai “virietis” vai “sieviete”. 2.5.Vienotais bufera formāts Enduro/X ir lietojumu serveris un starpprogrammatūra (turpmāk tekstā ATMI), kas nodrošina iespēju veidot daudzpakāpju mērogojamas lietojumprogrammas (klients/serveris) neviendabīgā (atšķirīgā) izplatītā vidē. Enduro/X sistēmas darbības principos ir saskatāmas zināmas līdzības ar Oracle Tuxedo starpprogrammatūru tikai ar savu specifiku [16]. Katrā sistēmā darījumu uzraudzības serviss (angliski Transaction Monitor, turpmāk tekstā TM) darbojas lokāli. Tas kontrolē, tā saucamos, servera procesus, kas ir programmas, kuras ir sākušas savu darbu izmantojot procesu pārvaldnieku (turpmāk tekstā NDRXD). Šīs programmas (serveri) izsludina (paziņo) servisus, kurus var izmantot citas programmas (servisi vai klienti). Enduro/X nodrošina vairāku NDRXD vienlaicīgu darbību tajā pašā sistēma vai vairākās, kas tādā gadījumā veido klasteri. Klastera režīmā servisi tiek koplietoti starp saistītajiem procesu pārvaldniekiem. Ar šādu risinājumu ir iespējams nodrošināt slodzes līdzsvarošanu, lai uzlabotu darba apjoma sadalījumu vairākos skaitļošanas resursos. Slodzes līdzsvarošanas mērķis ir optimizēt resursu izmantošanu, palielināt caurlaidību, samazināt reakcijas laiku un izvairīties no jebkura veida resursa pārslodzes. Enduro/X starpprogrammatūra nodrošina datu apmaiņas formātu “atslēga: vērtība” starp serveriem un klientiem. Šo datu apmaiņas formātu sauc par vienotu bufera formātu (angliski Unified Buffer Format, turpmāk tekstā UBF). UBF datu apmaiņas formāts ir iekšējais datu apmaiņas standarts ko izmanto komunikācijai starp klientiem un serveriem. Šo standartu ir iespējams eksportēt bibliotēkas formātā un izmantot kā programmēšanas valodas datu apmaiņas formātu neizmantojot pašu Enduro/X starpprogrammatūru.
  42. 42. 42 2.15. att. UBF datu formāta sintakse Attēlā (2.15. att.) ir redzams, ka UBF datu formāts nenodrošina strukturētu formātu, kas pēc autora domām ir liels trūkums. UBF datu apmaiņas formāta loģiskā funkcionalitāte ir tāda pati kā lauku manipulācijas valodai (angliski Field Manipulation Language, turpmāk tekstā FML). Enduro/X ir sava FML realizācija, bet tas strādā līdzīgi un API ir vienāds. FML ir C programmēšanas valodas funkciju kopums, kas nodrošina uzglabāšanas struktūru (sauc par lauku buferiem) definēšanu un to manipulāciju. Lauku buferi sastāv no “atslēga: vērtība” pāriem. Buferi nodrošina vienkāršu struktūru, lai apmainītos ar datiem starp citiem saistītiem procesiem. FML nodrošina iespēju piekļūt šiem bufera datiem izmantojot lauku nosaukumus, kas iepriekš tiek definēti.
  43. 43. 43 2.5.1. UBF vēsture UBF datu apmaiņas formāts ir tapis izstrādājot Enduro/X starpprogrammatūru. Programmatūras izstrāde tika uzsākta 2009. gada decembrī. Dibinot uzņēmumu SIA “ATR Baltic” 2011. gada augustā, Enduro/X turpināja attīstīties zem tā kā slēgtā koda projekts. Produkta pirmā versija tika izdota 2012 gada beigās. Pārsvarā to pirmreizēji sāka lietot bankas. Kopš tā brīža oficiāli bija pieejama Enduro/X 1.0 versija [43]. Attīstoties produktam 2015. gadā tika izsludināts, ka Enduro/X ar versiju 2.3.2 ir atvērtā koda programmatūra. Kopš tā brīža turpmākā izstrāde ir publiski pieejama. Līdz versijai 6.0 programmatūra bija pieejama zem GNU GPLv2 licences, savukārt no versijas 6.0 projekts tika pārvietots zem GNU AGPLv3 licences [43]. Attīstoties programmatūrai tika arī attīstīts UBF datu apmaiņas formāts pievienojot jaunu funkcionalitāti. 2.5.2. UBF sintakse Tāpat kā citiem šajā darbā pētāmajiem datu formātiem, arī UBF datu formāts nodrošina vērtību aprakstīšanu faila formātā, šādi faili tiek saglabāti ar paplašinājumu “*.ud”. Šāds faila paplašinājums tiek lietots, jo Enduro/X programmatūra nodrošina utilīt programmu ar nosaukumu “ud” (turpmāk tekstā UD), kas nolasa ievades parametrus no komandrindas, kur tai skaitā tiek norādīta “*.ud” faila atrašanās vieta. Faila sintakse ir ļoti primitīva, bet tā ir ļoti stingri jāievēro, lai apstrādājamais fails tiktu pareizi nolasīts. 2.16. att. Faila struktūras sintakse UD utilīt programmai Attēlā (2.16. att.) ir attēlota faila sintakse, kas sastāv no trīs komponentēm: 1. Atzīme, kas nav obligāta, jo to lieto pie specifiskām darbībām, kas aprakstītas tabulā (2.9. tabula); 2. Lauka nosaukums, obligāts; 3. Lauka vērtība, atkarīga no atzīmes. Lauka nosaukums un vērtība tiek atdalīta ar tabulāciju, citādāk faila formāts nebūs korekts.
  44. 44. 44 2.9. tabula. UD faila pieļaujamās vērtības (modificēts no (Programming a Tuxedo ATMI Application Using FML, 2018)) Apzīmējums Skaidrojums + Ja atzīme tiek norādīta kā šis simbols, tad lauka vērtība ar sastopamības indeksu 0 tiks pamainīta uz norādīto vērtību. - Ja atzīme tiek norādīta kā šis simbols, tad lauka vērtība ar sastopamības indeksu tiks izdzēsta no bufera. Šajā gadījumā vērtība nav jānorāda, bet tabulācija ir jāievieto aiz lauka nosaukuma. = Ja atzīme tiek norādīta kā šis simbols, tad šis lauks, kas norādīts kā lauka nosaukums tiks pamainīts uz to vērtību, kas tiek norādīta kā lauka vērtība. Šeit lauka vērtības vietā tiek norādīts cita lauka nosaukums no kura tiek nolasīta vērtība un piešķirta norādītajam laukam. # Tiek ignorēta un uzskatīta kā komentārs. Ja lauka nosaukuma vietā tiek norādīts vārds “SRVCNM”, tad vērtība tiek uzskatīta par servisa nosaukumu uz kuru tiek nosūtīti šie dati. Ir jāņem vērā ka failam vienmēr ir jābeidzas ar programmēšanas valodā zināmo jaunas rindas simbolu (angliski new line character), tas nozīmē, ka izmantojot teksta redaktoru ir jāpievieno divas tukšās rindas faila beigās. UD programma pēc šī simbola uzskata, ka ievades dati ir beigušies. UD piedāvā arī vairāku servisu izsaukumus dažādos veidos. Piemēram, ja failā tiek norādīti ievades dati kā redzams attēlā (2.17. att.), tad pēc atbildes saņemšanas no servisa X, tas izsauks nākamo servisu X. 2.17. att. UD faila sintakse ar vairāku servisu izsaukumu Attēlā (2.17. att.) ir redzams kā būtu jābūt noformētam failam, kas izsauc trīs servisus. Nolasot šo failu sākotnēji tik izsaukts serviss ar nosaukumu “TESTSV” un padodot tam divus
  45. 45. 45 lauku ar vērtībām. Tad kad serviss “TESTSV” būs izdarījis savu darbu un sniegs atbildi ar apstrādātu buferi, tad tiks izsaukts nākošais serviss ar nosaukumu “TESTSV2”. Buferis tiks atjaunināts pirms otrā servisa izsaukšanas ar tiem laukiem, kuru nosaukumi sakrīt atbildes buferī ar jaunajiem ienākošajiem laukiem. Pieņemsim ka šajā gadījumā atbildes buferis no servisa “TESTSV” paliek nemainīgs ar diviem laukiem “U_NAME” un “U_SURNAME”, kur vērtības ir “Einars” un “Leckis”. Tādā gadījumā pirms otra servisa izsaukšanas tas atjaunos vērtības laukos “U_NAME” un “U_SURNAME” uz “Einars2” un “Leckis2”. To nodrošina līnija ar rakstzīmi “u”, kas ir paredzēta bufera datu atjaunošanai pirms nākošās darbības. Savukārt trešais servisa izsaukums ignorēs otrā servisa atbildes buferi, jo pirms servisa izsaukšanas ir norādīta līnija ar rakstzīmi “n”, kas norāda uz to, ka buferis pirms servisa izsaukšanas ir jāinicializē par jaunu izmantojot norādītās ienākošās vērtības. UD piedāvā arī iespēju apvienot atbildes buferi ar ienākošo buferi, tad pirms servisa izsaukšanas ir jānorāda līnija ar rakstzīmi “j”. Principā atšifrējums šiem burtiem ir ļoti vienkāršs: 1. U – atjaunināt (angliski update); 2. N –jauns (angliski new); 3. J – apvienot (angliski join). UD faila formāts nodrošina arī izmantot rakstzīmes kuras nav iespējams uzrakstīt. Šādam nolūkam tiek lietots vadības simbols “” un heksadecimālās rakstzīmes, piemēram, laukā ar nosaukumu “U_NAME” vērtības vietā varētu rakstīt “45494e415253” un tas servisā tiktu iesūtīts kā “EINARS”. Ļoti svarīga lieta ir lauku definēšana, kam tiek izmantota cita sintakse. Ja lauki nav definēti, tad UD nevarēs apstrādāt ienākošo failu. Lauku definēšanai tiek izmantoti atsevišķi faili, kurus pēc tam ir nepieciešams apstrādāt ar utilīt programmu “mkfldhdr”, kas tiek atšifrēta kā “make field header” jeb latviski tas būtu “izveidot lauku galveni”. Lauku definēšanas fails tiek saukts par lauku tabulu (angliski field table). Izsaucot “mkfldhdr” utilīti un norādot lauku tabulu, tas uzģenerē lauku galvenes failu, kuru jāiekļauj izmantojamajā servisā.
  46. 46. 46 2.18. att. Lauku tabulas faila piemērs Lauku tabulu faili var tikt veidoti ar jebkuru teksta redaktoru. Veidojot šos failus ir jāievēro noteikumi: 1. Tukšas līnijas un līnijas kas sākas ar rakstzīmi “#” tiek ignorētas; 2. Līnijas kas sākas ar dolāra rakstzīmi “$” tiek lietotas galvenes failu veidošanā; 3. Līnijas kas sākas ar tekstu “*base” tiek izmantotas lai lauku numerācija sāktos no šī skaitļa; 4. Pārējām līnijām jāietur šāds formāts – “nosaukums numurs tips atzīme komentārs”. Nosaukums ir paredzēts lauku nosaukumiem. Šim lauka nosaukumam nevajadzētu pārsniegt C priekšapstrādes identifikatora ierobežojumus, kas ir 30 rakstzīmes. Rakstzīmes var saturēt tikai burtus, ciparus un apakš pasvītrojumus. Lauku nosaukumi kuru garums ir lielāks, automātiski tiks saīsināti līdz 30. Lauku nosaukumiem jābūt unikāliem. Lauka numurs tiek lietots tāds kāds tas ir norādīts, ja failā ir definēts “*base”, tad numuram tiek pieskaitīta šī vērtība. Lauku numuri ir tikai cipariskas vērtības un tām ir jābūt unikālām. Enduro/X lieto savu numerāciju, kas ir rezervēta iekšējai lietošanai, tas nozīmē ka lietotājam ir jāizvairās no šo numuru pārklāšanās. 2.10. tabula. Enduro/X identifikatoru tabula (modificēts no (Enduro/X Internal/External Developer Guide, 2018) Intervāls Komentārs 0 Sistēmas rezervētais identifikators ar nosaukumu BADFLDID 1-3999 Iekšējai lietošanai6000-10000 30000001-33554431 4000-5999 Paredzēti lietotāja definētajiem laukiem 10001-30000000
  47. 47. 47 Tabulā (2.10. att.) ir aprakstīti Enduro/X sistēmas rezervētie identifikatoru un lietotājam paredzētie identifikatori. Lietotājam stingri jāņem vērā šie ierobežojumi, jo neievērojot tos sistēma darbosies nestabili un nekorekti. 2.5.3.UBF datu tipi Tā kā UBF ir tipizēts datu apmaiņas formāts, tas nodrošina vairākus datu tipus: 1. SHORT; 2. LONG; 3. CHAR; 4. FLOAT; 5. DOUBLE; 6. STRING; 7. CARRAY. Datu tipi laukiem tiek definēti lauku tabulu failos. Datu tipu kontrole notiek izmantojot šīs tabulu lauku definīcijas. Tabulu lauku definīcijas tiek konvertētas uz C programmēšanas valodas iespēju “typedef”. Tas ir paredzēts lietotāja izdomātu nosaukumu definēšanai ar konkrētu datu tipu. UBF datu formāts nodrošina četrus datu tipus, kas spēj strādāt ar skaitliskām vērtībām. Šie datu tipi atbilst C programmēšanas valodas datu tipiem. Šos datu tipus lietotājs var definēt lauku tabulā, taču ierobežojumi uz tiem šim datu formātam nav pieejami. Ierobežojumus var definēt tikai pašā programmā (klientā vai servisā), kas notiek programmēšanas valodas pierakstā izmantojot striktas pārbaudes. Piemēram, ja ir nepieciešams kontrolēt minimālo un maksimālo vērtību, tad ir jāizmanto atzarojumi (piemēram, if).
  48. 48. 48 2.19. att. Vērtības nolasīšana no UBF un tās validācija Attēlā (2.19. att.) ir attēlots C programmēšanas valodas koda fragments kurā tiek nolasīta lauka “S_REG_STATUSS” vērtība SHORT datu tipā un pēc tam tā tiek pārbaudīta vai iekļaujas lietotāja definētajos ierobežojumos. Tādā pašā veidā tiek nolasītās arī pārējo skaitlisko vērtību datu tipu vērtības. Vērtību pievienošanai un modificēšanai tiek izmantotas citas funkcijas. UBF piedāvā trīs datu tipus kas ietilpst zem virknes kategorijas – CHAR, STRING un CARRAY. Katram no datu tipiem ir savas raksturīpašības. CHAR tips ir paredzēts vērtībām kas satur tika vienu rakstzīmi. STRING un CARRAY ir paredzēts rakstzīmju virknēm, bet starp šiem tipiem ir būtiskas atšķirības: 1. STRING ir rakstzīmju masīvs kas nesatur NULL vērtības; 2. CARRAY ir baitu masīvs, kas var saturēt NULL vērtības.
  49. 49. 49 3. JSON, XML UN UBF SALĪDZINĀJUMS Galvenais maģistra darba mērķis ir izpētīt šos datu apmaiņas formātus un to īpašības, kā arī salīdzināt kurš no šiem datu formātiem nodrošina labākus veiktspējas rezultātus veicot datu serializāciju un deserializāciju starp mikroservisiem. Veiktspējas testos tiek salīdzināti trīs datu formāti – JSON, XML un UBF. Datu formāti JSON un XML tika izvēlēti, jo tie ir visbiežāk industrijā lietotie formāti interfeisos, savukārt UBF tika izvēlēts kā papildus datu apmaiņas formāts, jo to piedāvā Enduro/X, kas tika izvēlēta par pamatu mikroservisu arhitektūras realizēšanai. Divi datu formāti ir uz tekstu bāzēti (JSON un XML) un viens ir binārais formāts (UBF). Tā arī ir būtiskākā atšķirība starp šiem datu formātiem. Autors ar šiem veiktajiem veiktspējas testiem vēlas salīdzināt kurš no visbiežāk izmantotajiem teksta datu apmaiņas formātiem (JSON, XML) ir ātrāks serializējot un deserializējot datus, kā atšķiras veiktspēja binārajam un teksta formātiem. Veiktspējas testu rakstīšanā tiek vērtēts arī programmēšanas ērtums, protams tas vairāk ir autora subjektīvais viedoklis. Lai veiktu veiktspējas salīdzināšanu autors izdomāja scenāriju, kas paredzēts lietotāju reģistrācijai lojalitātes programmā. Tika realizēts tā saucamais klients, kas saņem datu ievadi no lietojuma, kā arī serveris, kas ir paredzēts ievadīto datu sagatavošanai un validācijai. Serverim nolasot datus ir jāpievieno atbildes dati pie nosacījum, ja nerodas kļūda deserializējot datus, kurus pēc atbildes saņemšanas nolasa klients. Šāda veida komunikācija nodrošina datu apmaiņu starp procesiem, kurā ir mērāma datu sagatavošana lietošanai un transportēšanai. Kā jau iepriekš autors minēja, testu piemēru realizēšanai autors izvēlējās C programmēšanas valodu. Tā tika izvēlēta jo tā ir zema līmeņa programmēšanas valoda un to parasti izmanto biznesa vajadzībām, kur datu apstrādes ātrums ir ļoti nozīmīgs. Lai sarakstītu testa scenāriju C valodā, autoram bija jāizvēlas atbilstošas C bibliotēkas JSON un XML formātam. Meklējot tīmeklī kāda XML bibliotēka vislabāk piemērota C valodai, autors nonāca pie secinājuma, ka tā ir “libxml2”, par to liecina atbilstoši avotam (Free C or C++ XML Parser Libraries, 2012), kur ir apkopotas dažas populārākās bibliotēkas ko izmanto C un C++ valodās, “libxml2” atbalstāmo OS saraksts ir krietni lielāks kā citām bibliotēkām. Kā arī ierakstot interneta meklētājprogrammā “Google” sekojošus vārdus “XML parser for C”, tas lielākoties piedāvā “libxml2” bibliotēku.
  50. 50. 50 JSON bibliotēkas izvēlei tika izmantota līdzīga meklēšana. Atbilstoši avotam (Parsing JSON using C, 2015) vairāki lietotāji iesaka izmantot bibliotēku “jansson” pieminot ka tā ir labi dokumentēta, tai nav citu bibliotēku atkarību, nodrošina datu serializāciju, deserializāciju un datu manipulācijas ar vienkāršu API. 3.1. Izmantotās komponentes Lai varētu izpildīt pilnvērtīgus veiktspējas testus tika sagatavots dators ar tīru UNIX saimes OS, lai tā pēc iespējas būtu neatkarīgāka no uzstādītām programmatūrām. Operētājsistēmas uzstādīšana tika veikta uz portatīvā datora – ASUS X540SA-XX018D. Ņemot vērā Enduro/X atbalstāmo OS sarakstu: 1. Linux; 2. FreeBSD; 3. IBM AIX; 4. Oracle Solaris; 5. Cygwin; 6. MacOS. Portatīvajam datoram tika uzstādīta Linux Mint 19 (Linux eleckis-X540SA 4.15.0-43- generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 GNU/Linux) operētājsistēma. 3.1.tabula. Portatīvā datora ASUS X540SA-XX018D galvenie tehniskie parametri Raksturojošais parametrs Vērtība Centrālais procesors (CPU) Intel Pentium N3700. Kodolu skaits: 4 Pavedienu skaits: 4 Takts frekvence: 1.60 GHz Cietais disks (SSD) Samsung 850 Evo (MZ-75E250B/EU). Apjoms: 250 GB Lasīšanas ātrums: 540 MB/s Rakstīšanas ātrums: 520 MB/s Operatīvā atmiņa (RAM) Hynix HMT451S6AFR8A-PB. Apjoms: 4GB Tips: DDR3 Takts frekvence: 1600 MHz
  51. 51. 51 Tabulā (3.1. tabula) ir uzskaitīti galvenie raksturojošie datora parametri. Datora parametri atbilst vidējam mājas datoram. Tā kā veiktspējas testi tiek veikti ar nelielu skaitu mikroservisu un nekādi papildus interfeisi netiek lietoti, tad šie datora parametri pilnībā nodrošina to darbību bez traucējumiem. Tika uzstādītas bibliotēkas “libxml2” un “jansson”. 3.1. att. Komponenšu versijas Attēlā (3.1. att.) ir redzamas bibliotēku versijas un Enduro/X versija. Enduro/X tika uzstādīts atbilstoši avotam (Building Enduro/X On GNU/Linux Platform, 2015), kā arī atbilstoši avotam (Enduro/X Administration Manual, 2018), kurā norādīts kādi sistēmas uzstādījumi ir jāpamaina. Servisu kods tika rakstīts C programmēšanas valodā izmantojot NetBeans 8.0.2 IDE. Kopējā izstrādātā koda struktūra ir: 1. Kopējais makefile pirmkoda kompilēšanai (skatīt 19. pielikumā), 2. Klienta kopējais makefile (skatīt 1. pielikumā), 3. Klienta makefile priekš JSON (skatīt 2. pielikumā), 4. Klienta makefile priekš UBF (skatīt 3. pielikumā), 5. Klienta makefile priekš XML (skatīt 4. pielikumā), 6. Klienta pirmkods (skatīt 5. pielikumā), 7. Servera makefile priekš JSON (skatīt 10. pielikumā), 8. Servera makefile priekš UBF (skatīt 11. pielikumā), 9. Servera makefile priekš XML(skatīt 12. pielikumā), 10. Servera pirmkods (skatīt 13. pielikumā), 11. Ziņojuma galvenes fails (skatīt 6. pielikumā), 12. UBF bibliotēkas makefile (skatīt 14. pielikumā), 13. UBF bibliotēkas pirmkods (skatīt 15. pielikumā), 14. UBF lauku definīcijas fails (skatīt 16. pielikumā), 15. XML bibliotēkas makefile (skatīt 17. pielikumā), 16. XML bibliotēkas pirmkods (skatīt 18. pielikumā),
  52. 52. 52 17. JSON bibliotēkas makefile (skatīt 7. pielikumā), 18. JSON bibliotēkas pirmkods (skatīt 8. pielikumā), 19. Servera kopējais makefile (skatīt 9. pielikumā). Testa rezultāti tiek apkopoti izmantojot Enduro/X hronometru, kas rezultātus raksta teksta failā. Hronometra piefiksētos rezultātus ir iespējams apstrādāt ar Enduro/X izstrādātu skriptu, kas uzzīmē grafikus. 3.2. Testa scenārijs Lai veicamie testi būtu vienādi, autors izveidoja vienu scenāriju, pēc kura tika veidoti mikroservisi izmantojot dažādus datu apmaiņas formātus – JSON, XML, UBF. Scenārija soļi ir: 1. Klients aizpilda ziņojuma struktūru ar datiem; 2. Izsauc funkciju, kas sagatavo (serializē) ziņojumu atbilstoši izvēlētajam datu formātam; 3. Izsauc servera servisu pārsūtot datus; 4. Serveris saņemot datus veic to deserializāciju izmantojot funkciju atbilstoši izvēlētajam datu formātam; 5. Ja netiek konstatētas kļūdas ziņojuma deserializēšanā, tad tas ziņojumam pievieno atbildes informāciju un serializē datus transportam; 6. Serveris atbild klientam pārsūtot datus; 7. Klients saņem informāciju un deserializē; 8. Klients pārbauda atbildes datus. Ziņojums kopā sastāv no trīs datu struktūrām – klients, darbinieks un atbildes dati. Visas datu struktūras tika apvienotas vienā struktūrā, kas raksturo ziņojumu.
  53. 53. 53 3.2. att. Koda fragments - lietotāja datu struktūra Attēlā (3.2. att.) ir attēlota aizpildāmā lietotāja datu struktūra, kas sastāv no tam raksturīgām īpašībām. Papildus šai struktūrai ir tādi lauki kā – pyldnum, pyldnum_items, pyldstr un payldstr_items, kas tiks paskaidroti zemāk. 3.3. att. Koda fragments - pārējās datu struktūras
  54. 54. 54 Attēlā (3.3. att.) ir atspoguļotas pārējās datu struktūras, proti – darbinieks, atbildes struktūra un kopējā ziņojuma struktūra, kas sastāv no augstāk trim minētajām. Šajā piemērā nav izstrādāts gala lietotāja interfeiss, bet dati tiek uzstādīti dinamiski kodā - klienta pusē. 3.4. att. Koda fragments - datu aizpildīšana klienta pusē Attēlā (3.4. att.) ir redzams kā notiek dinamiska datu aizpildīšana klienta pusē. Šajā gadījumā sūtāmie dati vienmēr ir vienādi. Veicot sākotnējos testus ar šādu datu struktūru autors secināja, ka datu serializācija un deserializācija visiem salīdzināmajiem datu formātiem ir ļoti līdzīga ar minimālu laika starpību. Tas ir saistīts ar to, ka dati kurus pārraida vienmēr ir vienādi un to skaits nemainās. Tādēļ autors nolēma pievienot papildus datus, kas tiek pievienoti izejot noteiktu ciklu ar domu, ka tiek palielināta slodze.
  55. 55. 55 3.5. att. Koda fragments - slodzes datu uzstādīšana Attēlā (3.5. att.) ir redzams kā dinamiski tiek uzstādīti iepriekš minētie pyldnum un pyldstr dati. Kopumā iterācija izpildās piecas reizes, kur katrā nākošajā solī tiek pievienoti papildus dati sūtāmajā ziņojumā. Vērtības šajos laukos tiek pievienotas atkarībā no tā, kā tiek startēts klients. Klientu ir iespējams startēt izmantojot komandrindu un norādot argumentu “S” vai “D”. Parametri paredzēti, lai varētu noteikt kādu slodzi pievienot, atbilstoši “S” ir paredzēts virknes datu pievienošanai un “D” skaitlisko vērtību pievienošanai. Atbilstoši tālāk tiek izmantots Enduro/X izstrādāts hronometrs ar kura palīdzību tiek mērīts laiks mīli sekundēs starp klienta un servera komunikāciju, kas iekļauj sekojošus soļus: 1. Datu serializācija; 2. Datu nosūtīšana serverim izmantojot IPC; 3. Datu deserializācija; 4. Atbildes datu ierakstīšana; 5. Datu serializācija; 6. Datu nosūtīšana klientam izmantojot IPC; 7. Datu deserializācija; 8. Atbildes datu pārbaude.
  56. 56. 56 3.6. att. Koda fragments - ziņojuma sagatavošana un nolasīšana klienta pusē Attēlā (3.6. att.) ir pievienots koda fragments kurā var redzēt, kā notiek ziņojuma sagatavošanas funkcijas izsaukums, kurš atbilstoši datu formātam ieraksta informāciju no ziņojuma struktūras datu formātā un sagatavo to transportam. Saņemot sagatavoto ziņojumu, tas tiek nosūtīt izmantojot IPC API funkciju “tpcall”, kurā norāda izsaucamā servisa nosaukumu, ziņojuma buferi, garumu, atbildes buferi, atbildes garumu un karogu, kas parasti raksturo kādu specifisku uzvedību. Pieejamos karogus var aplūkot atbilstoši avotam (TPCALL, 2018), šajā gadījumā funkcijas izsaukums gaidīs atbildi no servera bezgalīgi ilgi. Tad kad serveris būs apstrādājis informāciju (dati tiks veiksmīgi deserializēti), tas pievienos atbildes laukus un serializēs datus transportam. Datus nosūtīs klientam (kā atbildi), lai klients šo ziņojumu saprastu, tam ir nepieciešama deserializācija, kura tiek izsaukta funkcijā “parse_msg”, kas atbilstoši datu formāta nolasa informāciju ziņojuma struktūrā.
  57. 57. 57 3.7. att. Koda fragments - ziņojuma atbildes pārbaude Attēlā (3.7. att.) ir redzams, ka pēc ziņojuma deserializācijas ir iespēja piekļūt datiem un tos var pārbaudīt. Šajā testa scenārijā ir stingri paredzēts, ka serverim ir jāuzstāda šādi atbildes lauki: 1. Rspstatus ar vērtību 100; 2. Rsprspmsg ar vērtību “User successfully registered”. Ja atbildes dati tiek uzstādīti nepareizi vai tie vispār netiek uzstādīti, tad tests nebūs veiksmīgs un tiks pārtraukta turpmākā apstrāde.
  58. 58. 58 3.8. att. Koda fragments - atbildes ziņojuma uzstādīšana servera pusē Attēlā (3.8. att.) ir redzama servera puses daļa, kurā pēc ziņojuma veiksmīgas deserializācijas tiek uzstādīti atbildes dati un tad šie papildinātie dati tiek serializēti, lai tos varētu nodot klientam (izsaucējam) izmantojot IPC API funkciju “tpreturn”. 3.3. Datu formātu veiktspējas rezultāti Kā jau autors iepriekš minēja, sākotnējie testi ar standarta ziņojuma struktūru bija ļoti līdzīgi, jo tā saturs bija nemainīgs, tādēļ tika radīta loģika, kur pēc noteikta iterāciju skaita tiek palielināts ziņojumā pārraidāmie dati.
  59. 59. 59 3.9. att. Veiktspējas salīdzinājums palielinot skaitlisko lauku skaitu Attēlā (3.9. att.) ir attēlots grafiks, kurā ir redzams JSON, XML un UBF datu apmaiņas formātu salīdzinājums, kur katrā iterācijas solī tiek palielināts buferī esošo datu skaits par 100 laukiem. 3.2.tabula. Iterācijas soļi Iterācija Lauku skaits Apstrāžu skaits 1 20 (lietotāja, darbinieka un atbildes lauki) 10000 2 120 (lietotāja ar slodzes datiem, darbinieka un atbildes lauki) 3 220 (lietotāja ar slodzes datiem, darbinieka un atbildes lauki) 4 320 (lietotāja ar slodzes datiem, darbinieka un atbildes lauki) 5 420 (lietotāja ar slodzes datiem, darbinieka un atbildes lauki) Tabulā (3.2. tabula) ir uzskaitīts iterāciju skaits kas tiek veikts ziņojumu nosūtīšanā. Katrā no iterācijas soļiem ir atšķirīgs sūtāmo datu apjoms, piemēram, pirmajā iterācijā tiek sūtīti pamata lauki bez papildus slodzes pievienošanas. Palielinoties iterācijas solim tiek pievienoti papildus 100 lauki, šajā gadījumā skaitliskie lauki, jo klienta serviss tika startēts izmantojot argumentu “D”, kas paredzēts testēšanai pievienojot skaitliskās vērtības buferī. Šo lauku vērtībā tiek ierakstīts skaitlis, kuru aprēķina (iterācijas maksimālais solis – tekošais lauks, 500 – skaitliskais lauks pēc kārtas).
  60. 60. 60 Attēlā (3.9. att.) redzams veiktspējas grafiks, kur tiek mērīts cik mīli sekundes aizņēma sagatavot un apstrādāt datus starp mikroservisiem. Grafika apakšējā skala norāda uz sūtāmo lauku skaitu, kur bāzes lauki nav iekļauti, proti, apakšējai skalai vienmēr jāpieskaita papildus 20 lauki. Katrā iterācijas nākošajā solī tiek palielināts sūtāmo datu skaits, kur šie dati pēcāk tiek (serializēti, deserializēti, papildināti, serializēti, deserializēti) 10000 reizes. Kopā sanāk simulēt 50000 tūkstoš izsaukumus starp servisiem, kur katros 10000 tiek lietots dažāds datu apjoms. Kā redzams (3.9. att.) sākotnēji XML un JSON datu formāti iterācijas punktos 0, 100 un 200 uzrādija visai līdzīgus rezultātus, bet pēcāk XML datu formāts izrādījās ātrāks. Kā redzams UBF formāts darbojas vis ātrāk, kam teorētiski tā arī bija jābūt, jo tas ir binārais datu formāts, kur datu serializācija un deserializācija aizņemt mazāk laika, jo tiek lietoti datu tipi. 3.3. tabula. Pirmo mērījumu rezultāti iterāciju sadalījumā palielinot skaitliskās vērtības Datu formāts iterācija Patērētais laiks sekundēs katrā iterācijas punktā 1 2 3 4 5 JSON 3.37 14.37 23.28 30.86 38.29 XML 3.73 14.30 20.55 27.78 30.67 UBF 1.10 2.27 3.90 11.20 13.61 Apskatot rezultātus tabulā (3.3. tabula) var novērot, ka JSON apstrādes laiks sākot no otrās iterācijas vidēji starp nākošajām iterācijām pieaug vidēji par 8.73 sekundēm. XML salīdzinājumā ar JSON vidēji pieaug par 6.74 sekundēm, kas ir par 2 sekundēm mazāk. Taču novērojot grafiku jāņem vērā, ka XML formātam ir tendence kristies, atšķirībā no JSON, kas diezgan strauji aug. Ja salīdzina UBF ar pārējiem datu formātiem, tad šeit ir novērojami krietni augstāka veiktspēja. UBF apstrādes laiks vidēji starp iterācijām ir 3.13 sekundes, ir aptuveni divas līdz trīs reizes mazāks kā XML un JSON. Vadoties pēc grafika un rezultātiem var novērot, ka UBF apstrādes laiks pieaug daudz vienmērīgāk nekā pārējos formātos. Lai mērījumu rezultāti būtu precīzāki autors atkārtoja testa scenāriju piecas reizes, kā rezultātā apkopoja vidējos apstrādes laikus. 3.4.tabula. Apkopoti datu apmaiņas formātu mērījumi iterāciju sadalījumā palielinot skaitliskās vērtības Datu formāts iterācija Patērētais laiks sekundēs katrā iterācijas punktā 1 2 3 4 5 JSON 3.33 14.15 23.22 31.23 38.63 XML 3.66 13.95 20.41 26.21 31.61
  61. 61. 61 Datu formāts iterācija Patērētais laiks sekundēs katrā iterācijas punktā 1 2 3 4 5 UBF 1.10 2.45 4.62 9.12 13.55 Rezultāti ir ļoti līdzīgi pirmreizējiem testiem, kas nozīmē, ka atkārtotie testi darbojās ļoti līdzīgi ar nelielām svārstībām, kas varētu būt radušās sistēmas darbības laikā paralēlo procesu ietekmē. Piemēram, ja apskatam rezultātus trešajā iterācija, kur 10000 reižu apstrādājot datus JSON tas aizņēma vidēji 23.22 sekunde un XML 20.41 sekundes, tad var izrēķināt, ka XML pie šādiem pašiem nosacījumiem spētu apstrādāt, apmēram, par 1377 ierakstiem vairāk (2.81 sekunžu laikā), kas ir aptuveni par 13.77% vairāk. Savukārt, ja tādā pašā veidā salīdzina, piemēram, XML un UBF, tad starpība ir krietni lielāka, jo UBF tajā pašā iterācijā spēj apstrādāt par 15.79 sekundēm ātrāk, kas piemērojams 34177 apstrādes reizēm un ir aptuveni par 341.77 % vairāk. Tātad izejot no pieejamajiem rezultātiem, var secināt ka apstrādājot datus palielinot apjomu - pievienojot skaitliskās vērtības buferī, vis labāk to spēj apstrādāt binārais datu formāts – UBF, otru vietu ieņem XML, kam seko JSON. Nākošais veiktspējas tests bija gandrīz tāds pats kā ar skaitlisko vērtību palielināšanu, tikai šeit tiek pievienotas teksta virknes. Klients tika startēts ar argumentu “S”, kā jau iepriekš tika noskaidrots ar domu, ka tas apzīmēs, ka slodze jāliek uz virknes datiem. 3.10. att. Veiktspējas salīdzinājums palielinot virknes lauku skaitu
  62. 62. 62 Šajā testa gadījumā ar katru iterāciju tiek palielināts virknes lauku skaits, kur katrā jaunpievienotajā lauka vērtībā tiek ierakstīts vērtībā “String with number %d. This is test”. Šajā virknē “%d” apzīmē to, ka tā vietā tiks ievietota skaitliska vērtība, kura tiek ņemta no tekošā lauka skaita kurš tiek pievienots. Kā redzams (3.10. att.) arī šeit sākotnēji XML un JSON datu formāti iterācijas punktos 1, 2 uzrādija visai līdzīgus rezultātus, bet pēcāk XML datu formāts izrādījās ātrāks. Kā redzams UBF formāts darbojas vis ātrāk, kam teorētiski nevajadzētu tik krasi atšķirties, jo apstrādājot datus binārajā formātā, virknes dati aizņem arī lielu apjomu. Bet šādiem nolūkiem parasti datos tiek uzstādīti indeksi, iespējams tieši šī iemesla dēļ UBF parādīja labu veiktspēju. Attēlā var redzē, ka šajā testa scenārijā visi datu formāti beigās ietur aptuveni vienādu starpību viens starp otru. Jāpiebilst, ka XML un UBF turpina augt, bet JSON apstrādes laiks jau nedaudz beigās samazinājās. Pilnīgi iespējams palielinot apjomu un darbojoties ilgāk grafiks varētu izskatīties pilnīgi citādi. 3.5. tabula. Pirmo mērījumu rezultāti iterāciju sadalījumā palielinot virknes vērtības Datu formāts iterācija Patērētais laiks sekundēs katrā iterācijas punktā 1 2 3 4 5 JSON 3.41 18.06 30.93 43.48 53.43 XML 3.75 15.28 20.84 27.66 35.91 UBF 1.11 2.51 4.66 8.04 11.75 Apskatot rezultātus tabulā (3.5. tabula) var novērot, visiem datu apmaiņas formātiem apstrādes laiks ir lielāks nekā apstrādājot skaitliskas vērtības, tas ir skaidrojams ar to, ka šajā scenārijā datu apjoms ir krietni lielāks. Ja skaitliskā vērtība sastāv no 3 baitiem, tad tekstuālā no 34 līdz 37. Salīdzinot JSON un XML datu apmaiņas formātus, tad arī šajā gadījumā var secināt ka XML izrādās ātrāks, bet XML formātam vadoties pēc grafika ir tieksme augt, savukārt JSON šajā gadījumā pamazām sāka kristies. Vidējais pieauguma solis starp iterācijām JSON formātam ir 12.51 sekundes, kur XML ir par 4.47 sekundēm mazāks. Šie rezultāti liecina, ka JSON izmantojamās bibliotēkas algoritmi strādā lēnāk kā XML. JSON un UBF salīdzinājumā, JSON ir krietni lēnāks. Piemēram, aplūkojot pēdējo iterāciju, kur apstrādājamo datu skaits ir vis lielākais, JSON tas aizņēma 53.43 sekundes, kas ir nepilna minūte, bet UBF tas aizņēma tikai 11.75 sekundes, kas ir gandrīz 5 reizes mazāk. JSON pie šādu datu apjoma sekundē viduvēji apstrādā 187 pieprasījumus serializējot, desereializējot datus ieskaitot transportu un paralēlo procesu darbību. Skatoties uz skaitli 187

×