Wspólne cechy

Wiele usług aplikacyjnych ma swoje odpowiedniki zarówno w CORBA, jak i J2EE. Na przykład Java Transaction Service (JTS) to tak naprawdę CORBA Object Transaction Services, mimo że API znacznie się różni. Podobnie jest w przypadku Java Naming and Directory Services - funkcjonalnie odpowiada to CORBA Naming Service. Iona zdecydowała, aby te wspólne elementy obu architektur wyodrębnić w oddzielną warstwę aplikacyjną - ART (Adaptive Runtime Technology).

W uproszczeniu można powiedzieć, że ART realizuje rozproszone transakcje, logowanie operacji i zarządza bezpieczeństwem. Warstwa J2EE czy CORBA jest w pewnym sensie "klientem" ART. Programista może dodać dodatko- wą funkcjonalność, rozszerzając ART - w ten sposób staje się ona dostępna zarówno dla programów wykorzystujących CORBA, jak i tych pisanych w Javie. Dużą zaletą ART jest to, że moduły mogą być dynamicznie dodawane i usuwane. Można wymienić istniejący moduł w trakcie działania całego serwera i aplikacji, która ten moduł wykorzystuje. Co więcej, można przywrócić starsze wersje komponentów itp.

Podstawowym składnikiem ART jest tzw. plug-in - biblioteka, która może być załadowana na serwerze i wykorzystana przez aplikację. Można ją dołączać do programu zarówno statycznie, jak i - co jest częstszym przypadkiem - dynamicznie w czasie działania serwisu. Przykładowo, jako plug-in jest realizowana warstwa współpracy między IIOP (warstwa transportowa CORBA) a J2EE. Równocześnie dzięki architekturze plug-inów można przenieść kontekst między połączeniem do serwera CORBA a połączeniem do J2EE. W połączeniu z rozproszonymi transakcjami XA możliwe jest, by w obrębie jednej transakcji wykonać pewne działanie przy użyciu komponentu EJB działającego na systemie Unix, transakcję na platformie NT, a także kilka operacji na OS/390 - dopiero gdy wszystkie zakończą się sukcesem, monitor transakcji uzna, że cała transakcja została prawidłowo zakończona.

Jednym z najbardziej kosztownych elementów infrastruktury J2EE jest moduł odpowiadający za utrwalenie obiektu (w rzeczywistości nie ma doskonałego rozwiązania, które działa szybko i zapewnia wysoką skalowalność). W Iona za realizację tej funkcjonalności odpowiada jeden z komponentów ART. Serwer zawiera moduł, który wykorzystuje bazę danych. Inny moduł, także dostarczany razem z serwerem, pozwala zapisać element w pliku. Równocześnie programista może otrzymać własny typ modułu.

Bezpieczeństwo w serwerze Iona jest także zapewnione w formie modułów ART. Wspiera on bezpieczną warstwę komunikacji (TLS 1.0/SSL 3.0). Dzięki ART moduły autoryzacyjne są wspólne - bez trudu można dzielić kontekst bezpieczeństwa czy inne informacje potrzebne do identyfikacji klienta. W ten sposób na serwerze Iona jest realizowana idea "pojedynczego punktu logowania".

Dodatkowe moduły tworzące warstwę bezpieczeństwa obsługują niemal każdy standard kodowania/podpisu elektronicznego i autoryzacji. Iona Security Framework obsługuje XML Encrytpion/Signature, SAML, XKMS. Można wykorzystać informacje z katalogu LDAP czy dowolny certyfikat zgodny z X509. Równocześnie dostępny jest specjalny zestaw narzędzi, który pozwala tworzyć własne adaptery odpowiedzialne za bezpieczeństwo.

Integracja

Iona jest obszerną platformą integracyjną. Łączy mainframe, Unixa, Javę, Windows i COM. Dzięki adapterom IMS, CICS czy TFP aplikacje klienckie napisane w C++ czy w Visual Basicu mogą mieć bezpośredni dostęp do systemów pracujących na mainframe. Teoretycznie nawet nie jest potrzebny dostęp do kodu źródłowego na dużych komputerach. Równocześnie, dzięki przenoszeniu informacji o kontekście, systemy mogą korzystać z transakcji bazujących na IIOP (np. systemy w COBOL-u) i udostępniać odpowiednią funkcjonalność jako EJB. Podobne przykłady można mnożyć.

Istnieje możliwość tworzenia rozwiązań, w których komunikacja odbywa się w drugą stronę. Załóżmy, że komponent CORBA chce wykorzystać pewną funkcjonalność EJB - na przykład odpowiedzialną za część operacji związanych z Internetem. W tym momencie pojawia się problem precyzyjnego odwzorowania typów Javy w języku IDL tak, by było to zrozumiałe dla warstwy CORBA. Iona proponuje tutaj dwa typy rozwiązań. Można albo zdefiniować mapowanie Java-to-IDL (co nakłada spore wymagania na różnego typu warstwy ORB), albo stworzyć specjalne komponenty pośrednie, które będą udostępniały IDL (Iona proponuje w tym przypadku dodatkowe moduły generujące odpowiednie wrappery).

Iona oferuje jeszcze jedno rozwiązanie komunikacyjne między platformami CORBA a Java. Jest to produkt o nazwie XMLBus - platforma integracyjna oparta na usługach Web. Zawiera graficzne środowisko do tworzenia i testowania usług. Usługi Web mogą być realizowane przy użyciu dowolnych komponentów CORBA czy EJB. XMLBus to tak naprawdę narzędzie do modelowania przepływów między poszczególnymi składnikami systemu.

Dla programistów

Częścią serwera Orbix E2A jest specjalne narzędzie, które pozwala tworzyć pakiety instalacyjne techniką "przeciągnij i upuść". Dzięki niemu najbardziej żmudna część tworzenia komponentów w Javie jest wykonywana automatycznie. Serwer zawiera specjalne moduły do integracji z narzędziem Sun Forte. Programista może bez opuszczania środowiska Suna testować komponenty uruchamiane na serwerze Iona.

W trochę gorszej sytuacji są programiści piszący według standardu CORBA. Iona Code Generation Toolkit pozwala na podstawie pliku IDL (definiującego interfejs w CORBA) wygenerować odpowiedni szkielet aplikacji klienckiej i serwerowej. Można automatycznie tworzyć moduł testujący serwera lub klienta. Narzędzie wykorzystuje język skryptowy TCL - programista może samodzielnie definiować, w jaki sposób ma być generowany kod. Niestety na tym kończą się ułatwienia.