Java i .Net w drodze do bezpiecznych systemów

Nawet najnowocześniejsze systemy komputerowe muszą w pewien sposób współpracować z istniejącymi już rozwiązaniami. Dotyczy to zwłaszcza komponentów warstwy środkowej, sięgających do danych zgromadzonych w różnych systemach.

Nawet najnowocześniejsze systemy komputerowe muszą w pewien sposób współpracować z istniejącymi już rozwiązaniami. Dotyczy to zwłaszcza komponentów warstwy środkowej, sięgających do danych zgromadzonych w różnych systemach.

Często liczą one kilkadziesiąt lat i zwykle dysponują odmiennymi interfejsami dostępowymi niż te, do których są przyzwyczajeni współcześni programiści.

Sun wraz z J2EE 1.3 opublikował specyfikację JCA - Connector Architecture (JCA). To specyfikacja uniwersalnego , który pozwala na stworzenie interfejsu do każdego systemu, bez względu na to, czy jest to ERP, CRM czy inna aplikacja biznesowa.

Interfejs ma ułatwić udostępnianie usług systemów typu legacy aplikacjom pisanym w Javie. Ze strony programu jest to zbiór komponentów, pełniący podobną rolę jak interfejs JDBC (odpowiadających za dostęp do baz danych). Ma to być jednak interfejs wyższego poziomu, oferujący więcej niż tylko dostęp do surowych informacji zgromadzonych w bazie. Interfejs konektora JCA składa się z dwóch modułów - Common Client Interface, definiującego wspólny interfejs kliencki, a także zbioru usług właściwych dla systemu back-office.

Analizując poszczególne interfejsy CCI, można odnieść wrażenie, że to zmodyfikowana kopia JDBC. Jednak CCI jest przeznaczone do obsługi systemów nierelacyjnych - danych hierachicznych, a nawet takich, w których można tylko określić strukturę dokumentu. Generalnie jest to API niskiego poziomu. Programista powinien "opakować" wywołania CCI i stworzyć warstwę abstrakcji, która ukaże właściwą funkcjonalność systemu back-office. W zasadzie CCI jest interfejsem, który pozwala napisać taką warstwę. Czasami dostawca JCA udostępnia także gotową warstwę abstrakcji. CCI może być wykorzystywane z poziomu aplikacji klienckiej, ale zwykle korzystają z niego komponenty działające na serwerze, które dopiero udostępnią interfejs ostatecznemu klientowi.

Ze strony serwera aplikacyjnego, specyfikacja JCA wymaga istnienia pewnego "zarządcy zasobów", który pozwoli kontrolować komunikację. Dokładny sposób implementacji części serwerowej zależy od producenta serwera, a w dużym stopniu także od docelowego systemu back-office. Generalnie specyfikacja wymaga, by były zaimplementowane mechanizmy obsługi połączeń (zwykle z mechanizmem tworzenia puli używanych połączeń, co zwiększa wydajność), a także moduł obsługujący transakcje i bezpieczeństwo. System z założenia ma obsługiwać transakcje rozproszone (zwykle to taki sam mechanizm co w przypadku kontenera EJB). Jednak twórca konektora może określić, że np. nie obsługuje transakcji bądź obsługuje tylko transakcje lokalne. Mechanizm bezpieczeństwa jest ściśle związany z konkretnym systemem back-office i w zasadzie udostępnia taki sposób autoryzacji i identyfikacji, jaki jest zaimplementowany w tym systemie.

Specyfikację JCA można wykorzystywać nie tylko jako schemat dostępowy do istniejących systemów. Zapewnia ona jednocześnie kolejny mechanizm rozszerzania Javy o niestandardowe interfejsy.

Obecnie JCA jest dostosowana do synchronicznej komunikacji (ewentualnie do modelu żądanie/odpowiedź, ale system nie może zainicjować połączenia zwrotnego do klienta). Specyfikacja CCI dobrze sprawdza się przy obsłudze danych hierachicznych i tabel. Lecz CCI nie obsługuje danych w XML. Kolejny problem dotyczy metadanych. Co prawda CCI zawiera mechanizm dostępu do repozytorium metadanych, jednak nie ma mechanizmu umożliwiającego skorzystanie z tych informacji programiście tworzącemu warstwę abstrakcji.

JCA jest nie tylko specyfikacją. Dla konkretnego systemu należy jeszcze zakupić konkretny konektor JCA. Na razie niewiele jest gotowych konektorów, które w pełni implementują JCA. Na przykład nie można ich stosować przy równoczesnym używaniu asynchronicznych wywołań EJB. Czasami wykorzystanie pełnej funkcjonalności JCA dla pewnych systemów jest trudne bądź nieopłacalne.

Ze strony .Net nie ma standardu porównywalnego z JCA. Zamiast tego platforma może z natury rzeczy wykorzystywać usługi Web (które z założenia mają służyć do komunikacji z dowolnymi systemami) i XML, który jest sposobem przetwarzania danych nierelacyjnych. Jednak, aby stworzyć interfejs do konkretnego systemu, należy wykorzystać serwer BizTalk Server lub inne rozwiązanie zawierające właściwy interfejs dostępu i jest w stanie udostępniać dane w postaci XML.

.Net obsługuje wszelkiego rodzaju metadane, które można zarówno wykorzystywać z poziomu aplikacji, jak i stosować jako narzędzie pomocnicze przy pisaniu kodu. Wprawdzie Microsoft udostępnił pakiet BizTalk Server Toolkit for .Net, ale jest to tylko zestaw interfejsów pośrednich między COM a .Net (wrappery RCW). Pozwala to łatwiej tworzyć komponenty .Net, które są wykorzystywane w różnych elementach BizTalk 2002 - zarówno przy definiowaniu zasad translacji i obiegu dokumentów w BizTalk Orchestration Designer, jak i przy części odpowiedzialnej za komunikację. Do funkcji BizTalk można się odwoływać z poziomu .Net.

Microsoft oferuje także serwer Host Integration, który ma za zadanie zapewnienie warstwy transportowej do starszych systemów i platform sprzętowych. Jednak nie jest dostępny na razie żaden interfejs .Net.

Zwykle ci sami producenci, którzy tworzą konektory JCA, tworzą także interfejsy do BizTalk - oferta jest bardzo zbliżona.


TOP 200