Něco málo z pravěku, zajímavý byl Symbian OS, to je ten systém co se používal na prvních Nokia smartphonech. Symbian vychází ze systému EPOC. Systém se používal na organizérech firmy Psion někdy od roku 1991. V té době nabízel preemptivní multitasking, grafické rozhraní, aplikace (database, word processor, spreadsheet) na CPU 4.7 Mhz a 256 KB RAM. Architektura EPOCu byla inspirována systémem VAX/VMS, 70 léta.
Jádrém návrhu bylo asychronní nátura aplikace. Taková typická mobilní aplikace většinu času čeká na událost (stisk klávesy, příchozí SMS, příchozí mail). Používál se Active Object návrhový vzor. Vzor zahrnuje Active Scheduler a Active Object. Scheduler je smyčka která čeka na signál nebo spravuje active objecty. Active Object zapouzdřuje volání asynchronní metody a zpracování výsledku. Asynchronní metoda je operace nad resourcem, např žádost o notifikaci na příchozí SMS, resourcem je příchozí SMS. Resource spravuje systémovy server (Windows server, Telephony server, Network server.). Jakmile server zpracuje požadavek, server vyšle signal clientovi, active scheduler se probudí, najde správny active object a zpracuje výsledek. Asynchronní metoda je tedy client-server request, podobně jako REST. I samotné UI eventy jsou implementovaný jako active object, který donekonečna žádá o uživatelský vstup. Aplikační framework poskytoval plnou podporu pro asynchronní volání a řesil tyto problemy:
- organizaci asynchronních volání
- zrušení (cancel) asynchronního volání, které stále běží
- pád clienta (applikace)
- pád servera v systému
Operace nad resourcem byly serializované, tzn např aplikace mohla vyvolat pouze jednu žádost o stisk klávesy v čase, až se zpracoval výsledek, aplikace mohla žádat znovu. Měli to tehdy pěkně vyřešené, od začátku navrhli pěkný design, takže orientovat se v ruzných části systému bylo jednoduché. Ve výsledku Active Object vzor je kooperativní multitasking v aplikaci (lehké vlákna).
Mrkni na dnešní Event Sourcing, CQRS, Eventual consistency. Problémy jsou stále stejné. Např vytvoření objednávky v systému, vytvoří se událost, událost se vloží do fronty, z fronty událost vybere nějaky microservice, a vytvoří objednávku ve své databázi. Client pošle dotaz na vytvořenou objednávku, ale objednávka není ještě uložena. Client pošle dotaz znovu, objednávka stále není vytvořena a řekněmě, že už postráda smysl. Co teď? Je operace idempotentní? Zrušit? Jak? Kompenzační událost, která zruší předchozí událost? Jak? Událost je pravděbodobně stále ve frontě a čeká na zpracování. Takže objednávka muže existovat než příjde kompenzační událost na řadu?
108 Odpovědí
46465 Zhlédnutí