Websphere i konwersja wysyłanych komunikatów na określony format

0

Cześć,
Słuchajcie, temat dość nie tuzinkowy i zastanawiam się jak go ugryźć. Architektura wygląda tak, mamy sobie aplikację (pudełkowa, nie mamy na nią wpływu i na jej kod źródłowy). Postawiona na IBM-owym Websphere'ze. Aplikacja emituje sobie jakieś eventy. Na tym samym serwerze stoi druga aplikacja (emitter), która przerzuca ta komunikaty na kafkę. Z kafiki są one pobierane przez mikroserwis javowy, rozparsowywane a następnie wyciągane są z tego komunikatu dane. Co tam się z nimi dzieje już nie jest istotne. Wszystko działało super. Komunikaty przychodziły sobie w określonym formacie, emitter je przerzucał, java je czytała. Teraz dostawca tej aplikacji postawionej na WAS-ie, w jej nowej wersji, zmienił całkowicie strukturę komunikatów i mamy kichę bo mikroserwis się wywala. Oczywiście można go przerobić, dostosować do nowej struktury ale to znowu do czasu. Dostawca znowu zmieni format i znowu nam się zacznie wywalać. Oczywiście wpływu na to nie mamy żadnego. Teraz chodzi o to aby móc na takie zmiany szybko reagować. Przeróbka mikroserwisu to nie jest szyba zamia. Ma ktoś jakoś pomysł czego można by użyć aby móc te komunikaty jakoś w locie konwertować na określony format? Załóżmy że dogadujemy sobie jakiś format komunikatu jakiego oczekuje java i to jest świętość. I teraz potrzebujemy czegoś, co przekształci nam te komunikat jaki wysyła aplikacja na komunikat jakiego oczekuje java. Coś w stylu transformaty XSLT. Czy znacie do tego jakieś gotowe rozwiązania? Być może coś takiego istnieje.

0

Obawiam się że generyczne rozwiązanie będzie trudne. Przecież mogą w tej aplikacji w ogóle zmienić granulację komunikatów, albo przestać jakieś emitować. Dużo sensowniej byłoby jednak opierać się o jakieś publiczne i stabilne API.

0

KSQL -> https://docs.ksqldb.io/en/latest/developer-guide/transform-a-stream-with-ksqldb/ chyba rozwiąże problem

0

  1. Nietechniczne -> planować. Dostawca chyba nie wrzuca tego z dnia na dzień, tylko przechodzi to przez solidny proces release managementu (zakładam, że skoro ktoś ma WAS, to i ma odpowiednie ciężkie procesy)? Co jeśli dostawca aplikacji przestanie emitować zdarzania z releasu na release? Co jeśli pojawią się nowe istotne zdarzenia do obsługi?

  2. "Aplikacja emituje sobie jakieś eventy." - co to technicznie znaczy? Gdzie emituje ? W kosmos? Generuje na jakąś kolejkę JMS, czy co? Chodzi o to by zrozumieć, gdzie można się z funkcjonalnością translacji wpiąć i czy ma to sens.

Z tego co rozumiem obecna architektura wygląda tak: WAS->EMITER->KAFKA->Aplikacja

Można zrobić kilka architektur, w których translator jest na WAS albo poza WAS.
TO-BE#1: WAS->EMITER->KAFKA->Translator->KAFKA->Aplikacja
TO-BE#2: WAS->EMITER->TRANSLATOR->KAFKA->Aplikacja
TO-BE#3: WAS->TRANSLATOR->EMITER->KAFKA->Aplikacja

Gdzie zrobić TRANSLATORA? A gdzie masz najszybsze/najmniej problematyczne deploymenty i najmniejszy narzut na testy i development?

1 użytkowników online, w tym zalogowanych: 0, gości: 1