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.

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. 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. 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. 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. АННОТАЦИЯ
МИКРОСЕРВИСЫ, МИКРОСЕРВИСНАЯ АРХИТЕКТУРА, ВЫВОДЫ,
ФОРМАТЫ ОБМЕНА ДАННЫМИ, JSON, XML, Enduro / X UBF.
Диссертация анализирует и сравнивает форматы обмена микросервисными
данными. Работа содержит исследование того, какие форматы обмена данными
доступны, какие характеристики следует учитывать при выборе этих форматов.
Каждый из выбранных форматов обмена данными реализуется в среде архитектуры
микросервиса, где проводятся измерения производительности конкретного формата
обмена данными путем сериализации данных, десериализации между вызовами
сервисам. Конечные результаты сравниваются и делаются выводы о том, какой из этих
форматов обмена данными лучше, какой из них лучше подходит для конкретных
ситуаций.
В аналитическом разделе диссертации рассматривается формат обмена данными
UBF, который был признан неполным в ходе исследования. На основании этих
недостатков разрабатывается дизайн.
Основная часть диссертации составляет 82 страниц, 41 рисунков, 18 таблиц, 43
названий источников информации и 19 приложений.

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. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
“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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Š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