2010.06_Stary, dobry znajomy Oracle Forms_[Aplikacje Biznesowe].pdf

APLIKACJE BIZNESOWE

Stary, dobry znajomy:

Oracle Forms

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.

Dowiesz się:

• O przyszłości Oracle Forms;

• O nowościach w Forms 11g;

• O migracji z Forms do innych technologii.

Powinieneś wiedzieć:

• Co to jest Oracle Forms

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ć.

cji 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 konte-

nerze Java. Zmigrowane zostały jedynie procesy Forms

Listener Servlet i Forms Servlet, które są niewielkimi kom-

ponentami 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 no-

we 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 ko-

du 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. Po-

nieważ Formsy działają w trybie żądanie-odpowiedź, po-

jawił 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że-

my zatem przygotować stronę, na której osadzona będzie

formatka oraz dowolny inny kod HTML, który będzie wy-

woł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

Przyszłość technologii Forms

Na początek sprawa najważniejsza: Forms jest na ryn-

ku od 20 lat i prędko nie zniknie. Na rynku można usły-

szeć wiele opinii i plotek na temat końca Formsów, ale ofi-

cjalny dokument mówi jasno (cytuję w oryginale, dla pod-

kreślenia autentyczności): Oracle has no plan to desup-

port these products. Furthermore, new version of Orac-

le 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 po-

wodów do obaw – mogą dalej korzystać z tej technologii

i rozwijać swoje aplikacje, korzystając z nowych funkcjonal-

noś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 We-

bLogic. Wpływ tej zmiany na tworzenie i działanie aplika-

6/2010

P od wieloma względami dostępna obecnie wersja

Stary, dobry znajomy: Oracle Forms

znajdujących się obok formatki. Korzystając z tej możliwo-

ści, można teoretycznie całkowicie ukryć przed użytkowni-

kiem aplet Forms, przygotowując nowy interfejs użytkow-

nika, który jednak wszystkie operacje będzie przekazywał

do apletu w celu obsłużenia logiki biznesowej.

Opisane powyżej nowe funkcje ułatwiają integrowa-

nie aplikacji Forms z bardziej nowoczesnymi technolo-

giami 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 uprasz-

cza tworzenie zaawansowanych rozszerzeń w Javie, gdy

faktycznie są one potrzebne. Inne zmiany wprowadzone

w Forms 11g to przede wszystkim ulepszone mechani-

zmy diagnostyczne i narzędzia administracyjne.

wego 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ży-

wamy Formsów w wersji klient-serwer, a chcemy przejść

do środowiska webowego, to prawdopodobnie nie obej-

dzie się jednak bez rewolucji.

Kiedy nakreślimy już proces migracji, pozostaje pytanie:

w jaki sposób przenosić poszczególne komponenty do no-

wego środowiska? Do wyboru mamy oczywiście migrację

manualną, która jest niczym innym, jak napisaniem apli-

kacji od nowa. Podczas przepisywania możemy nie tylko

zmienić technologię, ale również przemyśleć na nowo in-

terfejs 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 mi-

grację. Osoby liczące na całkowicie automatyczne prze-

niesienie aplikacji Forms, na przykład do Java EE, bę-

dą jednak rozczarowane. Żadne dostępne na rynku na-

rzędzie nie podejmie za nas decyzji, czy określona funk-

cjonalność powinna być zaimplementowana jak dotych-

czas 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ć funk-

cjonalny prototyp nowej aplikacji, mogą z dużą dokładno-

ścią stworzyć nowy interfejs użytkownika zbliżony do po-

przedniego, jak również wskażą miejsca, które wymaga-

ją ręcznej pracy.

Migrować, czy nie migrować

Istnieje przynajmniej kilka dobrych powodów, które mo-

gą 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 progra-

mujących w Forms. Nie ma raczej co liczyć na absolwen-

tów czy samouków, a rywalizacja o doświadczonych pro-

gramistów będzie się zaostrzać - tak, jak niegdyś o osoby

znające COBOLa. Po drugie, choć Formsy przez lata ewo-

luowały wraz z całym światem IT, to jednak nie wpisują się

idealnie we współczesne trendy komponentowych aplika-

cji 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 udo-

stę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 apli-

kacjami i integrować na poziomie inter-

fejsu użytkownika, to prawdopodobnie

Forms nie jest najlepszym wyborem.

Sposób migracji

Istnieją dwie zasadnicze ścieżki migra-

cji: ewolucyjna i rewolucyjna. Pierwsza

polega na integrowaniu Formsów z mo-

dułami napisanymi w innych technolo-

giach i stopniowym przepisywaniu po-

szczególnych formatek. Druga, to cał-

kowite odejście od Forms w jednym kro-

ku. Ścieżka ewolucyjna pozwala oswo-

ić się z nowym środowiskiem i przećwi-

czyć proces migracji na mniej krytycz-

nych modułach aplikacji, zanim zabie-

rzemy się za przepisywanie tych naj-

ważniejszych. Podejście rewolucyj-

ne wymaga dobrej znajomości docelo- Rysunek 1. Przykładowy efekt działania JHeadstart – formatka Forms

www.sdjournal.org

APLIKACJE BIZNESOWE

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ę sku-

pić na dwóch, które dostarczane są przez

Oracle. Po pierwsze, do dyspozycji mamy

rozszerzenie środowiska JDeveloper o na-

zwie JHeadstart. JHeadstart potrafi na pod-

stawie formatek stworzyć działającą aplika-

cję Java EE wykorzystującą framework ADF,

posiadającą interfejs użytkownika zaimple-

mentowany w JSF (ADF Faces), ale zbliżo-

ny do oryginalnej aplikacji w zakresie rozło-

żenia elementów na stronie i nawigacji. Apli-

kacja taka ma także dostęp do bazy danych

– podstawowe operacje odczytu, zapisu czy

wyszukiwania danych powinny działać auto-

matycznie, 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 niezmienio-

nej postaci (potencjalnie wystawiając ją jako web service).

Dalszy rozwój aplikacji może odbywać się w oparciu o do-

wolne narzędzia środowiska Java EE, choć w zakresie

IDE zalecany jest JDeveloper (jako jedyny posiada spe-

cjalne 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ż po-

zwala na podstawie schematu bazy danych, wysokopo-

ziomowej definicji funkcjonalności oraz szablonów (stron,

formularzy, zakładek, przycisków etc.) wygenerować dzia-

łającą aplikację. Możemy ją następnie dowolnie modyfi-

kować w JDeveloperze, a nasze poprawki przenieść do

szablonów JHeadstarta, by zostały uwzględnione przy na-

stępnej generacji. Oczywiście możemy także po wstępnej

migracji JHeadstartem zrezygnować całkowicie z tego na-

Rysunek 2. Aplikacja webowa po migracji

rzę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że-

gnać się z Formsami, ale pozostać w świecie baz danych

i języka PL/SQL, to możemy skorzystać z narzędzia Appli-

cation Express (APEX) – darmowego dodatku do bazy da-

nych Oracle. APEX pozwala tworzyć aplikacje WWW bez-

pośrednio w bazie danych (nie wymaga serwera aplikacji,

a jedynie serwera HTTP, który jest dołączony do bazy da-

nych). 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, mi-

gracja skomplikowanych formatek będzie wymagała ręcz-

nej pracy, ale dzięki częściowej automatyzacji możemy wy-

raź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 techno-

logii. Znacznie częściej słyszymy pytania o to, kiedy i w ja-

ki sposób należałoby zrezygnować z Formsów w istnie-

ją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ło-

tek, wszystko wygląda jak gwóźdź. Innymi słowy, im wię-

cej narzędzi znamy, tym lepiej potrafimy rozwiązywać roz-

maite 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/

earnadf.html.

MICHAŁ KURATCZYK

Principal solution architect, Oracle Polska

6/2010

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: