wtorek, sierpnia 23, 2011

Inteligentna warstwa transportowa



Message Context przy używaniu JMS-a nie trzeba wkładać do XML-a jako elementu opakowującego oryginalny komunikat, nagłówki JMS z powodzeniem wystarczą, zwłaszcza że można je wykorzystać do routingu. Nagłówki JMS można transformować do nagłówków SOAP i HTTP.

OriginalOrigin(1) - system będący pierwotnym źródłem komunikatu, nazwa kodowa
OriginalTarget(1) - system będący pierwotnym celem komunikatu, nazwa kodowa
BusinessFlowNames^ - nazwy biznesowych przepływów obsługiwanych przez przepływ techniczny; po starych logach i bieżących z awarii można szybko ustalić dotknięte funkcjonalności i dostosować reakcję do ważności przepływów biznesowych; komunikaty w ramach reużywalnych usług można dla ważnych procesów przekazywać do dedykowanych komponentów; pole wyliczane jako zbiór
srcComponent^ - komponent aktualnie wysyłający komunikat: adapter, broker, proxy/router; nazwa kodowa jako przedrostek zawiera nazwę środowiska: prod, preprod, test, dev
dstComponent* - komponent, który ma odebrać wysyłany komunikat - jeśli jest on znany;  nazwa kodowa jako przedrostek zawiera nazwę środowiska: prod, preprod, test, dev
dstOperation - nazwa operacji, która ma obsłużyć komunikat
dstOperationVer^ - wersja usługi (operacji); można szybko ustalić podczas awarii, że wysyłane są komunikaty starego typu do nowo wdrożonego komponentu lub nowe komunikaty do starego komponentu; można wersjonować usługi i zapewnić równoległe działanie za pomocą routingu.
dstCommType^ - rodzaj komunikacji: request-response synchronicznie, asynchronicznie, one-way, event, ping itp.; pole zawiera zbiór
dstTimeLeft^- pozostały czas na przetworzenie komunikatu, służy do ustawiania timeout-ów JDBC, JMS, HTTP itp., uaktualniany na każdym hopie; uwzględniane w obsłudze pól JMSTimestamp i JMSExpiration.
addWaitTime^ - dodatkowy czas czekania na odpowiedź przez nadawcę komunikatu, jeśli wykonawca operacji przekroczył dstTimeLeft, ale mieści się w dstTimeLeft+addWaitTime to odsyła odpowiedź, w przeciwnym przypadku wycofuje lub potwierdza operacje zgodnie z oczekiwanym zachowaniem transakcyjnym i nic nie odsyła; wynikowy timeout nadawcy to dstTimeLeft+addWaitTime
replyTo* -adres JMS lub WS, na który trzeba dostarczyć odpowiedź
priority - priorytet komunikatu
flowPath^ - pełna ścieżka, przez które hosty, komponenty, operacje, identyfikatory zadań/procesów/wątków komunikat przeszedł
retryNumber^ - ilość prób przetworzenia komunikatu, jeśli na początku się nie udało; musi być brana pod uwagę razem z dstTimeLeft
txHandling^ - obsługa transakcji: none, XA, best effort, compensate, detect duplicates; jeśli komponent dostaje komunikat z nieprawidłowym/nieobsługiwanym założeniem, co do transakcyjności, powinien go odrzucić i odesłać błąd; pole powinno być zapisywane w metryczce procesu/usługi w katalogu usług tak, żeby deweloperzy korzystający z usługi wiedzieli jak działa
idLevelN* - identyfikator do korelacji, wiele poziomów, aktualnie wypełniany jest pierwszy wolny
corrLevelN* - identyfikator do korelacji, wiele poziomów, aktualnie wypełniany jest pierwszy wolny
kvPairs* - dodatkowe parametry w postaci klucz1=wartość1|klucz2=wartość2
errorArea* - obszar błędu, wartość słownikowa, wykonawca komunikatu nie musi odesłać dokładnego dziedzinowego komunikatu o błędzie w JMS Body, może zalogować u siebie konkretny błąd/wyjątek i odesłać komunikat z wypełnionymi errorArea+errorCode
errorAreaName* - nazwa systemu, który wygenerował błąd
errorCanRepeat* - czy po otrzymaniu błędu można ponowić wywołanie i jest szansa, że się powiedzie: yes, no, maybe, duplicate danger
errorCode* - konkretny kod błędu
warnings* - ostrzeżenia, wartość słownikowa; przykładowo: SLA na granicy przekroczenia, komponent będzie niedługo w stanie obsługi w oknie serwisowym, komponent jest w starej wersji i jest przeznaczony do wyłączenia
meta* - pole do różnych brzydkich rzeczy (np. przechowywania oryginalnego requestu w celu porównania, czy broker dobrze zrobił mapowanie), którego używanie powinno być zabronione

(1) - wypełnia tylko adapter/channel
*- opcjonalne
^ - pola mogą być wypełniane automatycznie lub wartościami domyślnymi
pola error i warnings używane są tylko w odpowiedziach

Dzięki odseparowaniu nagłówków od JMS Body minimalizujemy narzut na przepakowywanie komunikatów, w JMS Body może być dowolny tekst, format, w tym XML.

OriginalOrigin, OriginalTarget, BusinessFlowNames i flowPath są bardzo ważne dla skutecznego działania IT Operations.

Heurystyka PERSISTENT/NOT_PERSISTENT: timeLeft > 3 minut lub dstCommType = (one-way, event) wymusza tryb dostarczania komunikatu z zapisem na dysk, w innych przypadkach stosowany ulotny tryb przechowywania. Wybór trybu przez dewelopera może być błędny, a późniejsze konsekwencje spore, dlatego ustawianie trybu powinno być wbudowane i automatyczne.

Do tworzenia nagłówków JMS można wykorzystać dwa procesy: prosty makeTransportProperties (ustawianie wszystkich rzeczy automatycznie) i zaawansowany makeTransportPropertiesEx. Wyjście z procesów zasila wejście aktywności wysyłającej, która nie jest ukrywana przed deweloperem. Może oczywiście istnieć wysokopoziomowy proces do wysyłania i odbierania np. transparentnie powtarzający komunikaty w ramach timeLeft i retryNumber.

0 komentarze: