Jakarta Connectors

Jakarta Connector (JCA; dawniej Java EE Connector Architecture) to architektura oprogramowania i Programming Interface (API) dla integracji z heterogenicznych aplikacji w Jakarta-EE platformy. Architektura składa się z dwóch części: interfejsów dostawcy usług (SPI), które dostawca łącznika musi zaimplementować, oraz wspólnego interfejsu klienta (CCI), którego aplikacja używa do interakcji z łącznikiem. JCA zawiera również interfejs API do lokalnego rozgraniczania transakcji .

Standard był nazywany architekturą złącza J2EE. Od wersji 1.6 specyfikacji J2EE przekształciło się w Java EE.

Integracja aplikacji korporacyjnych (EAI)

Enterprise Application Integration (EAI) jest podejście do integracji aplikacji i źródeł danych. Powinno to uprościć wymianę danych i połączenie procesów biznesowych.

Przed tym podejściem często podejmowano próby rozwiązania problemu integracji poprzez wewnętrzne prace rozwojowe i dostosowania.

Jednak aplikacje były często specjalnymi izolowanymi rozwiązaniami na różnych platformach i z różnymi protokołami komunikacyjnymi. Dlatego integracja produktów była możliwa tylko przy dużym wysiłku. EAI definiuje obecnie standard, który umożliwia komunikację między aplikacjami i źródłami danych w jednolity sposób. Ułatwia to wymianę poszczególnych części integracji.

Jednak różnice techniczne między aplikacjami i źródłami danych, które należy wziąć pod uwagę przy integracji, wydają się być problematyczne. W przypadku systemów informatycznych przedsiębiorstwa (EIS) należy wziąć pod uwagę następujące cechy wyróżniające:

Poziom wsparcia technologicznego

Obejmuje możliwość przeprowadzania transakcji lub wspomagania mechanizmów bezpieczeństwa .

Ograniczenia administracyjne i technologiczne

Na przykład EIS może dać użytkownikom różne opcje dostępu.

Możliwość integracji z innymi systemami

Systemy EIS były często dostosowywane do określonych środowisk systemowych, podczas gdy komunikacja z innymi produktami odgrywała jedynie podrzędną rolę.

Szczegóły systemu na niższym poziomie

Interfejsy API klienta w EIS mogą się różnić. Oprócz zastosowania różnych języków programowania ich złożoność może się znacznie różnić.

EAI i platforma Jakarta EE

Ze względu na dużą liczbę różnych systemów EIS rozwiązanie problemu integracji jest bardzo złożone. Aby móc uzyskać dostęp do informacji EIS z aplikacji, wcześniej konieczne było połączenie specyficzne dla aplikacji. Rezultatem był duży wysiłek programistyczny, który wzrastał wraz z liczbą systemów EIS i serwerów aplikacji , ponieważ połączenie z każdym systemem EIS musi być ustanowione dla każdego serwera aplikacji. W przypadku m serwerów aplikacji i n systemów EIS oznacza to wysiłek „m razy n”. (patrz rys. 1)

Architektura łącznika ma na celu zmniejszenie tego wysiłku. Programiści EIS nie muszą dostosowywać swoich systemów do każdego serwera aplikacji. Zamiast tego wystarczy opracować odpowiedni adapter zasobów dla systemu EIS, który można następnie zintegrować z każdym serwerem aplikacji, jeśli obsługuje architekturę konektora.

Aby serwery aplikacji mogły zintegrować adaptery zasobów, ich programiści muszą tylko raz zintegrować architekturę łącznika. Zmniejsza to złożoność problemu integracji do „m + n”. (patrz rys. 2)

architektura

W zarządzanym środowisku , które zostanie wyjaśnione bardziej szczegółowo później, można wyjaśnić najważniejsze komponenty i ich interakcje.

Środowisko zarządzane definiuje środowisko dla opartej na Java EE, wielowarstwowej aplikacji z obsługą sieci WWW, która uzyskuje dostęp do systemu EIS. Aplikacja składa się z co najmniej jednego komponentu aplikacji, takiego jak Enterprise JavaBeans (EJB) lub JavaServer Pages (JSP), które działają w kontenerze . Możliwe są następujące pojemniki :

• Kontener WWW dla stron JSP, serwletów i statycznych stron HTML
• Pojemnik EJB na komponenty EJB
• Kontener klienta aplikacji dla niezależnych klientów aplikacji

Komunikacja komponentów aplikacji Java EE odbywa się za pośrednictwem kontraktu komponentu kontenera, który reprezentuje łącze między kontenerem a serwerem aplikacji. Jest to zdefiniowane w specyfikacji Java EE.

Aby mieć dostęp do funkcji systemu EIS, komponenty aplikacji używają adaptera zasobów. Dostęp do tego uzyskuje się za pośrednictwem interfejsu API klienta.

System kurczy się

Integracja adaptera zasobów z serwerem aplikacji odbywa się poprzez tzw. Kontrakty systemowe. Regulują interakcję między adapterem zasobów a serwerem aplikacji. Ich implementacja jest wymagana przez specyfikację złącza.

Serwer aplikacji i adapter zasobów współpracują ze sobą, aby wszystkie mechanizmy związane z systemem były przezroczyste dla komponentów aplikacji. W związku z tym wymagane są trzy ważne umowy systemowe:

Umowa na zarządzanie połączeniami

Umożliwia to serwerowi aplikacji zarządzanie pulami połączeń do bazowego systemu EIS, co prowadzi do lepszego wykorzystania połączeń.

Umowa o zarządzanie transakcjami

Ta umowa umożliwia serwerowi aplikacji używanie menedżera transakcji do zarządzania transakcjami między wieloma menedżerami zasobów.

Kontrakt na zarządzanie bezpieczeństwem

Umowa o zarządzanie bezpieczeństwem ma na celu zapewnienie bezpiecznego dostępu do EIS. Zapewnia obsługę bezpiecznego środowiska aplikacji, które pomaga zminimalizować problemy z bezpieczeństwem i chroni informacje zarządzane przez system EIS.

Dla realizacji 3 kontraktów systemowych specyfikacja konektora definiuje interfejsy, które w dużej mierze muszą być implementowane przez adapter zasobów.

Niezarządzane środowisko

Oprócz opisanego w skrócie powyżej środowiska zarządzanego, specyfikacja konektora opisuje również środowisko niezarządzane . To definiuje aplikację dwuwarstwową. Klient aplikacji korzysta bezpośrednio z adaptera zasobów w celu uzyskania dostępu do systemu EIS. Nie jest do tego wymagany serwer aplikacji.

Ponieważ do tego typu integracji zwykle używany jest prosty standardowy menedżer połączeń używanego adaptera zasobów, funkcje takie jak użycie pul połączeń zwykle nie są obsługiwane.

Rysunek 4 przedstawia, w jaki sposób klient aplikacji może uzyskać dostęp do systemu EIS za pośrednictwem adaptera zasobów. Interfejs skierowana jest gdy wymagana jest nowa gra. To żądanie połączenia jest przekazywane do interfejsu, którego implementacja przejmuje zarządzanie połączeniem. Utworzenie fizycznego połączenia jest następnie realizowane przez interfejs. Fizyczne połączenie z systemem EIS jest reprezentowane przez interfejs. ConnectionFactoryConnectionManagerManagedConnectionFactoryManagedConnection

W celu aplikacja klienta do umożliwienia funkcji dostępu EIS, otrzymuje się uchwyt na Connectionprzykład, że był ConnectionFactorygenerowany przez wspomniany interfejs, za pomocą którego może on dostęp EIS.

Zarządzane środowisko

Wspomniane już środowisko zarządzane należy teraz zbadać bardziej szczegółowo, ponieważ stanowi ono główny element architektury łącznika. W przeciwieństwie do środowiska niezarządzanego, komponenty aplikacji i adapter zasobów są połączone z serwerem aplikacji za pośrednictwem kontraktów, które interweniują w szczególności w zarządzaniu połączeniami, transakcjami i bezpieczeństwem. W przeciwieństwie do środowiska niezarządzanego widać, że implementacja ConnectionManagerinterfejsu odbywa się w obrębie serwera aplikacji. Dostęp do adaptera zasobów z serwera aplikacji jest również regulowany przez umowy systemowe.

Konfiguracja adaptera zasobów

Informacje konfiguracyjne adaptera zasobów, takie jak nazwa serwera lub numer portu, można ustawić za pomocą tak zwanego narzędzia do wdrażania . Skonfigurowany w ten sposób adapter zasobów jest używany przez serwer aplikacji do ustanawiania połączeń fizycznych z bazowym systemem EIS.

Ustanowienie i bezpieczeństwo połączenia

W celu uzyskania połączenia getConnectionmetoda jest wywoływana ConnectionFactoryprzez komponent aplikacji. Ta prośba zostanie ConnectionManagerprzekazana do. Menedżer połączeń na serwerze aplikacji przetwarza żądanie i szuka odpowiedniego połączenia. Jeśli nie ma odpowiedniego połączenia, tworzone jest nowe. Mechanizmy bezpieczeństwa (login, hasło) zarządzane przez menedżera bezpieczeństwa muszą być zgodne, aby móc korzystać z istniejącego połączenia.

Pula połączeń jest zarządzana przez serwer aplikacji i nie jest określana przez specyfikację konektora.

Serwer aplikacji używa ManagedConnectionFactoryinterfejsu do tworzenia połączeń fizycznych, które są ManagedConnectioninstancjami.

Podobnie jak w środowisku niezarządzanym, komponent aplikacji otrzymuje uchwyt do tego fizycznego połączenia. Korzystając ze wspólnego interfejsu klienta (CCI), jest to ponownie Connectioninstancja, za pośrednictwem której można uzyskać dostęp do EIS.

Transakcje

Serwer aplikacji używa LocalTransactioninterfejsu adaptera zasobów do sterowania lokalnego (w systemie EIS) . Transakcje rozproszone są regulowane przez menedżera transakcji, który XARessourcekorzysta z interfejsu adaptera zasobów.

Menedżer transakcji zarządza transakcjami przy użyciu własnych mechanizmów wewnętrznych, które nie są określone w specyfikacji JCA.

Na rysunku 6 klient wywołuje komponent EJB X, który uzyskuje dostęp do systemu TP i wywołuje EJB Y. To z kolei dotyczy systemu ERP. Serwer aplikacji korzysta z menedżera transakcji w celu uzyskania dostępu transakcyjnego za pośrednictwem kilku menedżerów zasobów EIS.

Wydarzenia

ConnectionEventListenerInterfejs informuje serwer aplikacji o różnych wydarzeniach z fizycznego połączenia ManagedConnection. Zdarzeniami mogą być na przykład zamknięcie połączenia, wystąpienie błędów lub status transakcji.

adnotacja

W poprzedniej wersji przedstawiono podstawowe relacje między interfejsami w architekturze łącznika. Aby móc zaimplementować te interfejsy, potrzebne są oczywiście bardziej szczegółowe informacje. Szczegółowe informacje na temat interfejsów można znaleźć w specyfikacji konektora lub w dokumentacji Java zestawu Java EE SDK.

linki internetowe

• Architektura złącza JEE w języku Java EE 7 Samouczek Oracle (w języku angielskim)
• JSR 322: Java EE Connector Architecture 1.6 (angielski)
• JSR 112: J2EE Connector Architecture 1.5 (angielski)
• JSR 16: Architektura złącza J2EE (angielski)

Indywidualne dowody

1. ↑ JSR 322: Java EE Connector Architecture 1.6 (angielski)