java-ee
Architektura konektorów Java (JCA)
Szukaj…
Uwagi
Najpierw wyjaśnijmy kilka terminologii:
- Wiadomości wychodzące to miejsce, w którym wiadomość zaczyna się od serwera (a dokładniej, jest inicjowana z aplikacji zainstalowanej na serwerze, w tym przypadku
WebSphere Liberty) i kończy się w EIS. - Wiadomości przychodzące to miejsce, w którym wiadomość zaczyna się od EIS i kończy na serwerze.
- Wiadomość Punkt końcowy ogólnie miejsce, w którym wiadomość kończy się w pozycji siedzącej / odbieranej na określonym etapie jej cyklu życia.
Dlatego w przypadku połączeń wychodzących mamy na myśli sytuację, w której aplikacja uzyskuje połączenie z zewnętrznym systemem EIS i odczytuje lub zapisuje w nim dane. W przypadku połączeń przychodzących mamy na myśli sytuację, w której adapter zasobów (RA) nasłuchuje zdarzeń z zewnętrznego systemu EIS i wywołuje połączenia z aplikacją, gdy takie zdarzenie nastąpi.
Ilustracja Outbound RA
Ilustracja przychodzącego RA
Co oznacza MessageEndPoint w JCA?
Serwer aplikacji (np. WebSphere Liberty ) zapewnia komponenty MBean punktu końcowego wiadomości, które pomagają w zarządzaniu dostarczaniem wiadomości do komponentów bean sterowanych komunikatami, które działają jako detektory w określonych punktach końcowych, które są miejscami docelowymi, oraz w zarządzaniu zasobami EIS, które są wykorzystywane przez te komponenty sterowane komunikatami. Komponenty sterowane komunikatami, które są wdrażane jako punkty końcowe komunikatów, nie są takie same, jak komponenty bean sterowane komunikatami, które są skonfigurowane dla portu nasłuchiwania. Komponenty bean sterowane komunikatami, które są używane jako punkty końcowe komunikatów, muszą zostać wdrożone przy użyciu ra.xml ActivationSpecification zdefiniowanej w konfiguracji RA dla JCA (znalezione w pliku ra.xml ).
Co to znaczy aktywować MessageEndPoint?
Za pomocą MBeans punktu końcowego wiadomości możesz aktywować i dezaktywować określone punkty końcowe w swoich aplikacjach, aby mieć pewność, że wiadomości są dostarczane tylko do nasłuchiwanych elementów sterujących, które wchodzą w interakcję ze zdrowymi zasobami EIS. Ta funkcja umożliwia optymalizację wydajności aplikacji JMS w sytuacjach, w których zasób EIS nie działa zgodnie z oczekiwaniami. Dostarczenie wiadomości do punktu końcowego zwykle kończy się niepowodzeniem, gdy komponent bean sterowany komunikatem, który nasłuchuje, wywołuje operację względem zasobu, który nie jest zdrowy. Na przykład dostawca przesyłania komunikatów, który jest adapterem zasobów przychodzących, który jest zgodny z JCA, może nie dostarczyć wiadomości do punktu końcowego, gdy jego komponent bean sterowany komunikatami próbuje zatwierdzić transakcje na serwerze bazy danych, który nie odpowiada.
Czy MessageEndPoint musi być fasolą?
Powinno. W przeciwnym razie skończysz w wielkim bałaganie, tworząc własny niekonwencjonalny sposób robienia rzeczy, które w pierwszym rzędzie przekraczają cel podążania za specyfikacją Java EE. Zaprojektuj komponenty bean sterowane komunikatami, aby przekazywać przetwarzanie biznesowe innym komponentom bean korporacyjnym. Nie uzyskuj dostępu do zasobów EIS bezpośrednio w komponencie bean sterowanym komunikatami, ale pośrednio za pośrednictwem komponentu bean delegowanego.
Czy możesz pokazać prosty przykład dotyczący pracy / wdrażania MessageEndPoint?
Pomocny przykład znajdziesz w drugim zasobie, o którym mówię poniżej.
Przydatne zasoby edukacyjne:
Przykład adaptera zasobów
class MyResourceAdapter
implements javax.resource.spi.ResourceAdapter {
public void start(BootstrapContext ctx){..}
public void stop(){..}
public void endpointActivation (MessageEndpoingFactory mf, ActivationSpec a){..}
public void endpointDeactivation (MessageEndpoingFactory mf, ActivationSpec a){..}
public void getXAResources(ActivationSpec[] activationSpecs){..}
}