Środowisko wykonawcze

Po sprawdzeniu projektu i zbudowaniu artefaktów zadania muszą zostać uruchomione w konkretnym środowisku. Warstwa wykonawcza odpowiada za to, jak działają zadania, jak przekazują dane i jak reagują na zakończenie pracy lub błąd. Junexis rozwija biblioteki wykonawcze oraz kontrakty tych zachowań.

Wspólne znaczenie, różne implementacje

Nie ma dziś jednej, w pełni ujednoliconej implementacji obsługującej wszystkie środowiska Junexis. Biblioteki .NET, implementacje dla urządzeń w C i Rust oraz kod pomocniczy generowany dla Go, TypeScript i C++ mają różny zakres. Obecność funkcji w jednej implementacji nie oznacza jej dostępności we wszystkich pozostałych.

Od plików do działającego systemu

Etap	Za co odpowiada
Kompilator Junexis	sprawdza opis i generuje kod oraz manifesty dla obsługiwanych środowisk
Narzędzia środowiska docelowego	budują i przygotowują wygenerowany kod do wykonania
Warstwa wykonawcza	realizuje obsługiwane zachowania zadań i komunikacji podczas pracy
Uruchomienie i wdrożenie	ustalają, gdzie i z jaką konfiguracją działają procesy lub urządzenia
Obserwacja	dostarcza sygnały pozwalające sprawdzić stan i przebieg wykonania

Zainstalowanie .NET na serwerze nie uruchamia automatycznie każdego projektu Junexis. Potrzebne zależności wynikają z wybranej ścieżki i przygotowanej paczki. Przykładowo wygenerowany serwer Go korzysta z właściwego mu kodu wykonawczego; nie należy utożsamiać go z biblioteką zadań .NET.

Przykład: pomiary temperatury

Podczas działania systemu źródło dostarcza pomiary, odbiorca je przetwarza, a interfejs pokazuje wynik. Trzeba ustalić również, co dzieje się, gdy:

źródło produkuje dane szybciej, niż odbiorca je przetwarza,
pomiar nie nadchodzi w oczekiwanym czasie,
jedno z zadań kończy się błędem,
połączenie zostaje przerwane albo system jest zatrzymywany.

To pytania o zachowanie działającego systemu. Odpowiedzi zależą od użytych prymitywów, konfiguracji oraz implementacji wybranego środowiska. Sam poprawny diagram połączeń nie potwierdza odporności na te sytuacje.

Rola w platformie

flowchart LR
    MODEL["Semantyka programu"] --> DOTNET["Wykonanie .NET"]
    MODEL --> C["Wykonanie embedded C"]
    MODEL --> RUST["Wykonanie embedded Rust"]
    DOTNET --> SIGNALS["Logi, stan gotowości i zdarzenia"]
    C --> SIGNALS
    RUST --> SIGNALS
    SIGNALS --> OBS["Observability i Narrative"]

Zakres rozwijanych implementacji

środowisko wykonawcze .NET dla zadań i podstawowych prymitywów komunikacyjnych,
kanały, kolejki i strumienie o odrębnej semantyce,
mechanizmy timeout, retry, circuit breaker i supervision,
telemetria, metryki oraz integracja z warstwą obserwacji,
testy współbieżności, benchmarki i profilowanie,
aktywne implementacje dla urządzeń wbudowanych w C i Rust,
testy zgodności zachowania z wygenerowanym kodem.

Powyższa lista opisuje różne części komponentu, a nie wspólny zestaw gwarancji każdego środowiska. Test biblioteki, budowanie wygenerowanego kodu i próba na rzeczywistym urządzeniu są osobnymi dowodami. Samo istnienie implementacji nie potwierdza gotowości produkcyjnej całego systemu.

Szybkie sprawdzenie

junexis runtime primitives --json

Polecenie pokazuje informacje udostępniane przez zainstalowane CLI o prymitywach wykonania. Nie uruchamia całej aplikacji i nie sprawdza automatycznie jej sieci, urządzeń ani kompletności wdrożenia.

Testy projektu środowiska wykonawczego należą do dokumentacji deweloperskiej; użytkownik sprawdza kontrakt przez publiczne CLI.

Kontrakty komunikacji

chan<T>, queue<T> i stream<T> określają różne sposoby przekazywania typowanych danych. Nie należy traktować ich jako zamiennych nazw tego samego połączenia. Szczegóły buforowania, odbioru, potwierdzeń i utraty danych trzeba sprawdzić dla konkretnej implementacji oraz konfiguracji.

flowchart TB
    TASK["Zadanie"] --> CHAN["chan&lt;T&gt;<br/>kontrolowany przepływ"]
    TASK --> QUEUE["queue&lt;T&gt;<br/>obsługa wiadomości"]
    TASK --> STREAM["stream&lt;T&gt;<br/>najnowsza obserwacja"]
    CHAN --> NEXT["Kolejne zadanie"]
    QUEUE --> WORKERS["Konsumenci"]
    STREAM --> WATCHERS["Obserwatorzy"]

Granice

Zakres prymitywów różni się pomiędzy środowiskiem .NET, wygenerowanym Go, TypeScript i implementacjami dla urządzeń wbudowanych. Osobna, uniwersalna warstwa transportów zdalnych nie jest jeszcze gotowym produktem.

Ponowienie operacji nie gwarantuje, że jej skutek wystąpi tylko raz. Zatrzymanie zadania nie oznacza automatycznie zachowania jego stanu po restarcie. Trwałość, dopuszczalne straty danych i sposób odzyskiwania trzeba określić oraz sprawdzić w konkretnym systemie.

Zobacz jak działa Junexis, stan platformy oraz macierz języka i wykonania.