Stary, dobry znajomy: Oracle Forms

Michał Kuratczyk, principal solution architect, Oracle Polska

Historia narzędzi Oracle Forms sięga późnych lat 80. i choć ich popularność wyraźnie spadła wraz z rozpowszechnieniem się Internetu, wciąż wiele aplikacji bazuje na tym rozwiązaniu.

Pod wieloma względami dostępna obecnie wersja 11g niewiele przypomina te sprzed 20 lat, z drugiej jednak strony, mimo wielu dużych zmian, wciąż pełni tę samą funkcję: pozwala szybko tworzyć aplikacje bazodanowe. W tym artykule przyjrzymy się przyszłości samej technologii oraz zastanowimy się, kiedy warto się z nią rozstać i jak to zrobić.

Przyszłość technologii Forms

Na początek sprawa najważniejsza: Forms jest na rynku od 20 lat i prędko nie zniknie. Na rynku można usłyszeć wiele opinii i plotek na temat końca Formsów, ale oficjalny dokument mówi jasno (cytuję w oryginale, dla podkreślenia autentyczności):
Oracle has no plan to desupport these products. Furthermore, new version of Oracle Forms, Oracle Reports will continue to be released as part of Oracle Fusion Middleware and Oracle Forms 11g and Oracle Reports 11g are components of Oracle Fusion Middleware 11g.
Zadowoleni użytkownicy Formsów nie mają zatem powodów do obaw – mogą dalej korzystać z tej technologii i rozwijać swoje aplikacje korzystając z nowych funkcjonalności. Dla pozostałych, w drugiej części artykułu omówimy możliwe sposoby migracji z Forms do innych rozwiązań.

Nowości w Forms 11g

Na pierwszy rzut oka największą zmianą w Forms 11g jest zmiana używanego serwera aplikacji Java z OC4J na WebLogic. Wpływ tej zmiany na tworzenie i działanie aplikacji Formsowych jest jednak minimalny, ponieważ główny komponent uruchomieniowy, Forms Server, jest napisany w C/C++, a zatem w ogóle nie jest uruchamiany w kontenerze Java. Zmigrowane zostały jedynie procesy Forms Listener Servlet i Forms Servlet, które są niewielkimi komponentami napisanymi w Javie. Zmiany odczują zatem głównie administratorzy, którzy będą musieli nauczyć się zarządzania serwerem WebLogic.
Znacznie ciekawsze, choć nie tak widoczne, są dwie nowe funkcjonalności: wsparcie dla bazodanowych kolejek AQ (Advanced Queuing) oraz wsparcie dwukierunkowej komunikacji z JavaScriptem znajdującym się na stronie z formatką. Wsparcie dla AQ umożliwia wywoływanie kodu Forms z zewnątrz – np. z procesu BPEL. Po odczytaniu komunikatu z kolejki, serwer Forms wywołuje nowy trigger WHEN-EVENT-RAISED, który obsługuje zdarzenie. Ponieważ Formsy działają w trybie żądanie-odpowiedź, pojawił się także nowy parametr MAX_EVENT_WAIT, który określa maksymalny czas od pojawienia się zdarzenia w kolejce, do jego obsłużenia. Komunikacja między formatką a JavaScriptem pozwala z kolei na wywoływanie zdarzeń z zewnątrz, ale na poziomie interfejsu użytkownika. Możemy zatem przygotować stronę, na której osadzona będzie formatka oraz dowolny inny kod HTML, który będzie wywoływał zdarzenia w formatce i na przykład przekazywał do formatki wartości pól, które użytkownik wypełnił poza formatką. Możliwa jest także komunikacja w drugą stronę – formatka (lub Forms trigger) może wywołać dowolny kod JavaScript, na przykład odświeżenie fragmentów strony znajdujących się obok formatki. Korzystając z tej możliwości można teoretycznie całkowicie ukryć przed użytkownikiem aplet Forms, przygotowując nowy interfejs użytkownika, który jednak wszystkie operacje będzie przekazywał do apletu w celu obsłużenia logiki biznesowej.
Opisane powyżej nowe funkcje ułatwiają integrowanie aplikacji Forms z bardziej nowoczesnymi technologiami oraz z narzędziami SOA – takimi, jak szyny usług i silniki procesów biznesowych. Choć od dawna możliwe jest wywoływanie kodu Java z poziomu Forms (poprzez Forms Java Importer), to nowe możliwości powodują, że rzadziej będzie to konieczne. Z drugiej strony 11g upraszcza tworzenie zaawansowanych rozszerzeń w Javie, gdy faktycznie są one potrzebne. Inne zmiany wprowadzone w Forms 11g, to przede wszystkim ulepszone mechanizmy diagnostyczne i narzędzia administracyjne.

Migrować, czy nie migrować

Istnieje przynajmniej kilka dobrych powodów, które mogą nas skłonić do odejścia od Formsów (większość z nich dotyczy także innych technologii poprzedniej generacji). Przede wszystkim na rynku jest coraz mniej osób programujących w Forms. Nie ma raczej co liczyć na absolwentów, czy samouków, a rywalizacja o doświadczonych programistów będzie się zaostrzać - tak, jak niegdyś o osoby znające COBOLa. Po drugie, choć Formsy przez lata ewoluowały wraz z całym światem IT, to jednak nie wpisują się idealnie we współczesne trendy komponentowych aplikacji webowych, czy architektury SOA (choć wersja 11g jest krokiem naprzód w tym zakresie). I chociaż bez problemu możemy z Forms wywoływać web services, a także udostępniać logikę biznesową aplikacji Forms jako usługę, to jednak Formsy od początku były tworzone jako narzędzie dla aplikacji bazodanowych. Jeśli zatem nasza aplikacja ma korzystać z różnych źródeł danych, komunikować się z wieloma innymi aplikacjami i integrować na poziomie interfejsu użytkownika, to prawdopodobnie Forms nie jest najlepszym wyborem.

Sposób migracji

Istnieją dwie zasadnicze ścieżki migracji: ewolucyjna i rewolucyjna. Pierwsza polega na integrowaniu Formsów z modułami napisanymi w innych technologiach i stopniowym przepisywaniu poszczególnych formatek. Druga, to całkowite odejście od Forms w jednym kroku. Ścieżka ewolucyjna pozwala oswoić się z nowym środowiskiem i przećwiczyć proces migracji na mniej krytycznych modułach aplikacji, zanim zabierzemy się za przepisywanie tych najważniejszych. Podejście rewolucyjne wymaga dobrej znajomości docelowego stosu technologicznego, oswojenia użytkowników z nowym środowiskiem oraz odpowiedniego podejścia do osób, które dotychczas rozwijały aplikację (przeszkolenie ich w zakresie nowych narzędzi lub znalezienie dla nich nowych zajęć, by nie stracić wiedzy zdobytej przez nich przez lata rozwoju i eksploatacji systemu). Jeśli nadal używamy Formsów w wersji klient-serwer, a chcemy przejść do środowiska webowego, to prawdopodobnie nie obejdzie się jednak bez rewolucji.
Kiedy nakreślimy już proces migracji, pozostaje pytanie: w jaki sposób przenosić poszczególne komponenty do nowego środowiska? Do wyboru mamy oczywiście migrację manualną, która jest niczym innym, jak napisaniem aplikacji od nowa. Podczas przepisywania możemy nie tylko zmienić technologię, ale również przemyśleć na nowo interfejs użytkownika i oczyścić aplikację z elementów, które nawarstwiły się przez lata i niepotrzebnie komplikowały implementację. Z drugiej strony trzeba się liczyć z tym, że pisząc wiele rzeczy od nowa, popełnimy nowe błędy, a prawdopodobnie także powielimy stare, które były już kiedyś rozwiązane.
Z pomocą przychodzą narzędzia automatyzujące migrację. Osoby liczące na całkowicie automatyczne przeniesienie aplikacji Forms, na przykład do Java EE, będą jednak rozczarowane. Żadne dostępne na rynku narzędzie nie podejmie za nas decyzji, czy określona funkcjonalność powinna być zaimplementowana jak dotychczas w PL/SQL, czy przeniesiona do warstwy aplikacji. Tym bardziej żadne narzędzie nie przepisze kodu PL/SQL do Javy. Narzędzia pomogą nam jednak stworzyć funkcjonalny prototyp nowej aplikacji, mogą z dużą dokładnością stworzyć nowy interfejs użytkownika zbliżony do poprzedniego, jak również wskażą miejsca, które wymagają ręcznej pracy.

Narzędzia wspierające

Na rynku dostępnych jest przynajmniej kilka narzędzi wspierających migrację z Forms do innych technologii. Tutaj chciałbym się skupić na dwóch, które dostarczane są przez Oracle. Po pierwsze, do dyspozycji mamy rozszerzenie środowiska JDeveloper o nazwie JHeadstart. JHeadstart potrafi na podstawie formatek stworzyć działającą aplikację Java EE wykorzystującą framework ADF, posiadającą interfejs użytkownika zaimplementowany w JSF (ADF Faces), ale zbliżony do oryginalnej aplikacji w zakresie rozłożenia elementów na stronie i nawigacji. Aplikacja taka ma także dostęp do bazy danych – podstawowe operacje odczytu, zapisu czy wyszukiwania danych powinny działać automatycznie, podobnie jak listy wartości i inne typowe elementy formatek. Logika biznesowa pozostaje jako kod PL/SQL, więc należy albo ręcznie przepisać ją do Javy (lub innego języka), albo wywoływać w niezmienionej postaci (potencjalnie wystawiając ją jako web service). Dalszy rozwój aplikacji może odbywać się w oparciu o dowolne narzędzia środowiska Java EE, choć w zakresie IDE zalecany jest JDeveloper (jako jedyny posiada specjalne wsparcie dla frameworku ADF). Nie przeszkadza to jednak używać także innych środowisk i frameworków. Co ważne, JHeadstart nie generuje żadnego kodu Java, a jedynie pliki XML, dzięki czemu nie trzeba utrzymywać generowanego automatycznie kodu (co zwykle jest dość trudne). JHeadstart jest także, a nawet przede wszystkim, narzędziem do wysokopoziomowego tworzenia aplikacji w oparciu o ADF. Koncepcyjnie można go porównać do narzędzia Designer ze świata Formsów, który również pozwala na podstawie schematu bazy danych, wysokopoziomowej definicji funkcjonalności oraz szablonów (stron, formularzy, zakładek, przycisków, etc.), wygenerować działającą aplikację. Możemy ją następnie dowolnie modyfikować w JDeveloperze, a nasze poprawki przenieść do szablonów JHeadstarta, by zostały uwzględnione przy następnej generacji. Oczywiście możemy także po wstępnej migracji JHeadstartem zrezygnować całkowicie z tego narzędzia i dalej rozwijać aplikację typowymi narzędziami ze świata Java EE.
JHeadstart może ułatwić migrację do całkowicie nowego świata – technologii Java EE. Jeśli jednak chcemy pożegnać się z Formsami, ale pozostać w świecie baz danych i języka PL/SQL, to możemy skorzystać z narzędzia Application Express (APEX) – darmowego dodatku do bazy danych Oracle. APEX pozwala tworzyć aplikacje WWW bezpośrednio w bazie danych (nie wymaga serwera aplikacji, a jedynie serwera HTTP, który jest dołączony do bazy danych). APEX potrafi migrować aplikacje Forms (jak również MS Access i Excel) do bazy danych Oracle i udostępniać je przez WWW. Podobnie jak w przypadku JHeadstarta, migracja skomplikowanych formatek będzie wymagała ręcznej pracy, ale dzięki częściowej automatyzacji możemy wyraźnie skrócić czas migracji. Dalszy rozwój aplikacji odbywa się w tym przypadku poprzez edycję kodu PL/SQL z logiką biznesową oraz wykorzystanie narzędzia APEX w zakresie interfejsu użytkownika (generowany jest kod PL/SQL, który z kolei w czasie działania generuje HTML).

Podsumowanie

Oracle Forms zdobyły sobie przez lata wielu zagorzałych zwolenników. Z drugiej strony dynamiczny rozwój rynku i technologii internetowych powoduje, że nieliczne firmy decydują się na rozwijanie nowych aplikacji w tej technologii. Znacznie częściej słyszymy pytania o to, kiedy i w jaki sposób należałoby zrezygnować z Formsów w istniejących aplikacjach. Najkrótsza odpowiedź: pośpiechu nie ma, ale warto zastanowić się co zyskujemy, a co tracimy wybierając Formsy. Jak wiadomo, kiedy mamy tylko młotek, wszystko wygląda jak gwóźdź. Innymi słowy, im więcej narzędzi znamy, tym lepiej potrafimy rozwiązywać rozmaite problemy, które przed nami stoją.

Więcej informacji

Oracle Forms Statement of Direction
http://www.oracle.com/technology/products/forms/pdf/10g/ToolsSOD.pdf

J2EE Application Development for Forms and Designer Developers
http://www.oracle.com/technology/products/jdev/collateral/4gl/formsdesignerj2ee.html

ADF learning center
http://www.oracle.com/technology/products/adf/learnadf.html


Napisz do autora:
Michal.Kuratczyk@oracle.com