Temat: Ciekawy problem

Mam do przemyślenia pewien problem. Wymyśliłem juz rozwiazanie ale moze ktoś z was wpadnie na lepszy pomysł.
Mam aplikacje X od zewnetrznego dostawcy (napisana c++).Przyjmuje ona na wejsciu tekstowe parametry, a zwraca obiekty binarne. Musze sie do tych obiektów dobrać z poziomu Stateful Session beana. Oto jakie rozwiazania przychodzą mi do glowy:
1) umieścić aplikacje X na tym samym komputerze co konter aplikacji z EJB kami. Z Session Beana wywoływać metode na klasie, ktora posreniczy miedzy EJB a zewnetrzna applikacja. Klasa ta kontaktowała by sie z aplikacja przy pomocy JNA.
2) Przeniesc tą aplikacje na zewnetrzny serwer. na tym serwerze postwic tomcata, a na tomcacie servis ktory z jednej strony udostepnia webservisy, a z drugiej łączy sie z zewnętrzna aplikacja X. Wtedy nasz session bean wywoływałby webserivice na drugim serverze a on uruchamiałby nasza apliacje X i zwracał plik binarny (tez przez webservice). Zastanawiam sie tylko jak by wygladała obsługa tranzakcji. Co sie stanie jeśli nasza zewnetrzna aplikacja nie zdąży na czas.
3) tak jak w rozwiazaniu numer 2) tylko ze zamiast EJB użyć JMS. Jedyny problem jaki widze w tym rozwiazaniu to taki ze nie wiem jak zaimplementować oczekiwanie na odpowiedz. Wiadomo ze można użyć message driven beana, ale jak w takim razie sprawić zeby ta odpowiedz z powrotem trafila do metody z session beana ktory wysłał JMS? Z tego co mi wiadomo, do session beana nie mozna wrzucić metody odbierajacej komunikacy JMS.
Jak narazie, ze wzglendu na wydajniosc ( aplikacja X jest bardzo zasobożerna), wybralem rozwiązanie numer dwa, ale zastanawiam sie jeszcze nad JCA. Ma ktos doswiadczenie z conectorami?

Temat: Ciekawy problem

Co to znaczy przyjmuje na wejsciu parametry? :)

Wystawia jakis interfejs ? (CORBA / Database / ... )
Przetwarza requesty rownolegle / musza byc przetwarzane kolejno / wspiera transakcyjnosc ?

I pewnie pare innych pytan by sie znalazlo :)

1. JNA - Planowales umiescic w kontenerze EJB czy poza nim?

Jesli poza, to nie widze korzysci i tak musisz wystawic cos co bedzie opakowywalo aplikacje X i wystawialo interfejs dla EJB.
Szedlbym raczej w kierunku opakowania czyms innym niz JNA, tak by inne aplikacje (zdeployowane na zdalnym serwerze) mogly to
rozwiazanie potencjalnie wykorzystac w przyszlosci, czyli np. Web Servis, ktory rozwazasz w pkt. 2.

Jesli w konenerze, to co na to specyfikacja EJB ? JNI z tego co pamietam bylo co najmniej nie zalecane do wykorzystania w kontenerach EJB.
Nie wiem jak JNA dziala od srodka, ale wydaje mi sie, ze ma gleboko ukryte podobne mechanizmy i z tego wzgledu podbnie moze nie byc
zalecane ;-) Zdaje sie, ze wirutalna maszyna nie pozwalala na ladowanie tej samej biblioteki przez mechanizmy JNI w roznych class loaderach.
Nie wiem czy to sie przeklada na JNA.

2. Mozesz ustawic EJB session w vendor specific descriptors i/lub timeout na wywolanie web servisu. Wtedy dostaniesz powiadomienie
(zapewne w postaci wyjatku) i kontener sam z siebie wycofa transakcje (w przypadku beanow CMT).

Co wiecej, jesli bedziesz mial jakis load-balancing / fail-over, to zapewne aplikacja z SSB bedzie zdeployowana na kilku serwerach. Tym samym konieczne byloby powielenie aplikacji X na tych kilku serwerach.

3. Z tego co piszesz, to JMS nie ma sensu w tym przypadku. Mam na mysli "oczekiwania na odpowiedz", ktore to kojarzy mi sie z blokowaniem przetwarzania, a w JMS nie o to chodzi. Na upartego mozna pomyslec o zmianie designu aplikacji i korzystac z JMS, ale pytanie podstawowe to, czy odpowiedz z X jest wymagana do przetwarzania i blokuje to przetwarzanie, czy moze wymagana jako jedna ze skladowych odpowiedzi?

4.Z JCA nie mam zbyt dużego doświadczenia, ale sprowadza się to do zarządzania pulą zasobów (połączeń do systemu X) i transakcaji w ustandaryzowany sposób. Czyli, oprócz tego, że zaimplementujesz
"jakoś" połączenie do systemu X, to musisz zaimplementować kilka dodatkowych interfejsów JCA, dorobić deskryptory RA i jeszcze to "zdeployować", a później jeszcze niech się trafi migracja na inny serwer aplikacyjny :) W tym przypadku korzyść wydaje mi się niewielka.

pozdrawiam,
PK

Temat: Ciekawy problem

Ad.3.

Jest sposób obsługi JMS w sposób synchronicznie-asynchroniczny, czy jak by tego nie określić. Pattern request-reply, z którego miałem okazje korzystać i okazuje sie to całkiem przyjemne rozwiązanie.

Więcej szczegółów:
http://www.eaipatterns.com/RequestReplyJmsExample.html

Edit: Można ustawić sobie timeout w ms, podawany jako parametr w metodzie receive.Grzegorz Ligas edytował(a) ten post dnia 22.09.09 o godzinie 17:08