State / wykonanie i komunikacja
State jest opcjonalny
Nie każdy system Junexis potrzebuje State. Wybierasz go tam, gdzie dalsza praca wymaga zachowania i uzgodnienia stanu istotnego dla poprawności kontynuowania pracy.
Kiedy może być potrzebny?
- Po ponownym uruchomieniu trzeba wiedzieć, które zadanie już zakończono.
- Utracono odpowiedź i trzeba ustalić wynik wcześniejszej operacji.
- Potwierdzenie dotyczy konkretnego przydziału pracy i nie może zmienić nowszej próby.
- Powracający komponent musi uzupełnić wiedzę przed wznowieniem zależnych działań.
Kiedy zacząć bez niego?
Prosty przepływ bieżących danych może nie wymagać takiej pamięci. Jeżeli wymagania spełnia wybrany Runtime i jego dostawcy, State nie musi być częścią rozwiązania.
Brak State nie oznacza braku jakiejkolwiek trwałości. Na przykład baza aplikacji może zachowywać własne dane niezależnie od niego.
Podział z Runtime
| Runtime | State |
|---|---|
| Uruchamia i wykonuje zadania. | Zachowuje i uzgadnia stan wymagany do ich kontynuowania. |
| Obsługuje wybrany sposób komunikacji. | Pomaga rozliczyć dostarczenia i wyniki w wybranym scenariuszu. |
| Podejmuje dalszą pracę zgodnie z kontraktem wykonania. | Dostarcza fakty potrzebne do ustalenia, czy zależna praca może być kontynuowana. |
Integracja musi wskazywać, kto jest właścicielem konkretnego faktu. W repozytorium istnieje lokalny scenariusz współpracy z rzeczywistym Runtime. Nie oznacza to automatycznego podłączenia State do każdej aplikacji.
Opcjonalny nie znaczy pomijalny podczas awarii
Jeżeli rozwiązanie wybrało State jako wymagane źródło faktów, jego niedostępność nie zmienia tego rozwiązania w wariant bez State. Zależna praca powinna poczekać na wymagane ustalenia zamiast zgadywać wynik lub osłabiać przyjęte zasady.
State a dane aplikacji
Rekord pomiaru, klienta czy zamówienia należy do obszaru Storage. State ma zachowywać i uzgadniać stan potrzebny do rozstrzygnięcia, czy aplikacja może kontynuować pracę. Nie zastępuje bazy biznesowej ani brokera wiadomości.