Ramy aplikacji (framework) to próba rozwiązania wielu problemów małych i średnich przedsiębiorstw oraz uczynienia pracy programisty lżejszą i wydajniejszą.

Ramy aplikacji są definiowane w różny sposób, na ogół powiązany z możliwościami narzędzia do tworzenia aplikacji. Dość powszechnie akceptowana definicja, nie związana bezpośrednio z żadnym narzędziem brzmi: "Ramy aplikacji to uogólniony, obiektowy podsystem do budowy aplikacji. Składa się z abstrakcyjnych klas obiektów, metod ich współpracy oraz z rzeczywistych klas".

Inna definicja mówi, że ramy aplikacji to "architektura częściowo wykończonych podsystemów, których instancji można używać wielokrotnie; ramy zawierają także podstawowe elementy architektury do tworzenia aplikacji".

Programowanie obiektowe promuje wielokrotne używanie obiektów, natomiast ramy aplikacji - wielokrotne używanie projektu aplikacji. Oznacza to w szczególności, że ramy aplikacji niekoniecznie muszą składać się z typowych obiektów w rozumieniu klasycznej teorii programowania obiektowego (która zakłada m.in. że obiekty muszą mieć możliwość dziedziczenia oraz powinny być trwałe - persistent).

W prostszej definicji, wygodnej w codziennej praktyce programistycznej, zakłada się, że ramy aplikacji to dokładnie przetestowany zestaw modułów programowych, które można używać i rozszerzać dla utworzenia aplikacji. Odłączenie modułów od programowania obiektowego ma na celu objęcie terminem także tych ram aplikacji, które są oparte na zupełnie innych zasadach ich tworzenia, np. z proceduralnych modułów kodu, lub zostały opracowane do innych celów, np. świadczenia usług (usługi sieciowe, bezpieczeństwa, dostępu do baz danych).

Zalety i wady

Najważniejszą zaletą ram aplikacji jest możliwość wielokrotnego wykorzystania raz napisanego kodu. Ponieważ zaś dobre ramy aplikacji zawierają już wiele gotowych obiektów, nie trzeba ich opracowywać samemu. Ponadto ich użycie skraca czas potrzebny do konserwacji gotowego systemu. Ramy ukrywają przed programistą szczegóły nieistotne dla jego projektu, a jednocześnie pozwalają na wykorzystanie bezpośrednio obiektów lub ich zmodyfikowanie przez dziedziczenie, napisanie własnych obiektów albo skorzystanie z obiektów handlowych.

Wadą ram aplikacji jest konieczność starannego przemyślenia projektu aplikacji w celu wpasowania go do gotowego rozwiązania architektonicznego ramy. Nie da się już posadzić programisty z narzędziem do szybkiego tworzenia aplikacji (typu RAD) i kazać mu opracować program "byle jak, pod warunkiem że szybko".

Następną wadą ram aplikacyjnych jest ich ścisłe powiązanie z językiem programowania. Na ogół obiekty opracowane za pomocą PowerBuildera lub Delphi nie kwalifikują się do używania w środowisku programowania C++ lub Java (i odwrotnie).

Solidnie opracowane ramy to ogromny nakład pracy i duże koszty. Dlatego szansę mają jedynie te ramy, które są opracowywane przez duże konsorcja firm, powiązanych wspólnymi celami. Na przykład ramy projektu San Francisco opracowuje ponad 200 firm z całego świata, we współpracy z jego inicjatorem - IBM.

Typy ram

Funkcjonalne właściwości ram aplikacji można wykorzystać tylko wtedy, gdy w aplikacji użyje się wzorca projektu, gotowych podsystemów oraz modułów kodu opracowanych specjalnie dla potrzeb aplikacji. Ponieważ jej kształt jest w znacznej części zdeterminowany przez architekturę ram aplikacji, projektanci aplikacji i programiści powinni używać tylko takich ram, które są elastyczne - dają się łatwo przystosować - oraz takich, które można łatwo rozszerzać.

Ramy obiektowe. Są to stosunkowo popularne ramy aplikacji. Zawierają zwykle abstrakcyjne i konkretne klasy obiektów. Zapewniają usługi dla aplikacji przez mechanizmy enkapsulacji, dziedziczenia, polimorfizmu, abstrakcję i in., dostępne we współczesnych językach programowania obiektowego. Ramy obiektowe są ściśle powiązane z językiem programowania. Większość narzędzi do opracowania aplikacji zawiera na ogół ramy do tworzenia interfejsu użytkowego aplikacji lub dostępu do baz danych. Niektórzy producenci narzędzi do opracowania aplikacji (np. Borland) dostarczają wiele gotowych komponentów obiektowych, łącznie kodem źródłowym, co zdecydowanie ułatwia ich używanie oraz przyspiesza proces tworzenia nowych komponentów.

Ramy usługowe. W przeciwieństwie do ram obiektowych, nie pozwalają na dziedziczenie właściwości. Dostarczają różnego rodzaju usług. Ramy obiektów rozproszonych to najlepszy przykład usług dostępnych w sieciach komputerowych.

O prymat konkurują ze sobą dwie kompletne architektury obiektów rozproszonych - Microsoft DCOM i OMG CORBA. Distributed Component Object Model stanowi część składową środowiska Windows NT, zaś jego ograniczona wersja COM - podstawę obiektową w innych wersjach Windows. DCOM w zasadzie jest ograniczony do środowiska Windows, mimo że obecnie Microsoft we współpracy z niemiecką firmą Software AG przenosi go do środowisk unixowych, ale z ograniczoną funkcjonalnością.

Architektura brokerów obiektowych, oparta na specyfikacji Common Object Request Broker Architecture (CORBA), opracowanej przez konsorcjum producentów Object Management Group, zawiera obszerny zestaw usług, dostępnych z praktycznie dowolnej platformy systemowej, w tym także z Windows za pomocą bramy (gateway) DCOM-CORBA. CORBA definiuje usługi katalogowe, bezpieczeństwa, dostępu do baz danych, komunikacyjne i in. Realizacje brokerów CORBA, umożliwiających dostęp do tych usług, są dostępne u takich producentów, jak: IONA Technologies z Irlandii, IBM i Visigenic (USA).

Mimo ogromnej przewagi liczby instalacji Windows, technika komunikacji obiektowej w środowisku rozproszonym Windows nie miała zbyt wielu zwolenników z powodu braku gotowych ram obiektowych do budowy kompletnych aplikacji. W ramach architektury CORBA natomiast są dostępne interesujące rozwiązania ram obiektowych. Ostatnia specyfikacja CORBA 3.0 pozwala na korzystanie z usług środowiska za pomocą aplikacji napisanych w języku Java; pojawiło się więc wiele inicjatyw opracowania ram aplikacyjnych. Najbardziej zaawansowany jest projekt San Francisco. Firmy współpracujące z IBM dostarczyły już pierwsze komponenty i kompletne ramy.

Ramy proceduralne. Są to zwykle gotowe biblioteki funkcji do używania w aplikacji. Elementy ram proceduralnych na ogół nie pozwalają na modyfikowanie lub rozszerzanie dostępnych usług. Jeżeli jakaś cecha funkcjonalna nie jest dostępna w ramie, trzeba ją zakodować samemu. Możliwości ram proceduralnych do tworzenia rozproszonych aplikacji w biznesie można wykorzystać dzięki zastosowaniu monitorów transakcji, takich jak: IBM-owski CICS, Microsoft Transaction Server, Tuxedo (BEA), TopEnd (NCR) lub Encina (Transarc).

Monitory transakcji zapewniają także usługi dostępu do baz danych, umożliwiając realizację aplikacji trójwarstwowych, ze specjalizowanym serwerem aplikacji. Nowa tendencja to łączenie się architektury obiektów rozproszonych z monitorami transakcji. Obecnie w architekturze DCOM dostępny jest Microsoft Transaction Monitor, zaś w ramach architektury CORBA wbudowuje się usługi transakcyjne, oparte na rozwiązaniach firmy Transarc.

Ramy komponentowe. To najszybciej rozwijająca się dziedzina zastosowań ram aplikacji. Motorem ich rozwoju stało się rozpowszechnienie Internetu oraz pojawienie się i powszechne stosowanie komponentów JavaBeans i ActiveX. Programista używa komponentów przez włączanie ich do aplikacji przy zastosowaniu typowych narzędzi programistycznych i interfejsu komponentów, stanowiącego najczęściej ustalony interfejs przemysłowy lub firmowy (de facto). Programista może zmieniać ich wygląd i zachowanie przez zadawanie wartości pewnych parametrów komponentów.

Programista ma jednak ograniczone możliwości wpływu na kształt i właściwości funkcjonalne komponentów, gdyż najczęściej nie ma on dostępu do ich kodu źródłowego. Na ogół komponenty zajmują się elementami interfejsu użytkowego na stacji klienta, a ramy usługowe lub proceduralne zapewniają dostęp do usług serwera (bazy danych, aplikacji, komunikacyjnego i in.). Obecnie dostępne komponenty działają na poziomie najniższym obiektów interfejsu, nie ma zaś wielu dostępnych na rynku komponentów wyższego poziomu, realizujących większe uniwersalne funkcje biznesowe (takie jak: księga główna, moduł zamówień).

Możliwość łączenia komponentów różnych dostawców oznacza, że programista może zakupić wiedzę, której nie posiada, albo która jest mu potrzebna tylko sporadycznie. W sprzedaży dostępne są specjalizowane komponenty do określonych typów zastosowań (pionowa orientacja biznesowa) - finanse, sprzedaż, obsługa hurtowni.

Firmowe ramy aplikacji

W większości przypadków zarys ramy aplikacji jest tworzony przez jedną firmę, zaś jej elementy to wynik grupowej pracy licznego konsorcjum firm i organizacji. Często mechanizmy leżące u podłoża ram są standaryzowane przez instytucje międzynarodowe, ale na ogół nie ma to większego wpływu na powodzenie lub porażkę ram aplikacji. O sukcesie decyduje raczej dostępność obszernego zestawu elementów.

Istnieją solidne ramy aplikacji, często podbudowane metodyką tworzenia aplikacji, powiązane z największymi i najpotężniejszymi narzędziami programistycznymi i firmami konsultingowymi. Najczęściej jednak nie są one udostępniane publicznie, lecz wymagają zakontraktowania usług tych firm konsultingowych.

Ramy aplikacji i Java

Pojawienie się języka Java, promowanego przez twórców jako uniwersalna platforma do pisania i uruchamiania aplikacji, spowodowało ogromne zainteresowanie programistów dostępem do ram aplikacyjnych i usługowych Java. W wyniku prac, głównie firmy Javasoft, pojawiły się ramy stosunkowo niskiego poziomu, np. Java DataBase Connectivity (JDBC), ramy do zdalnego wywołania metod (Remote Method Invocation - RMI) oraz sporo modułów usługowych związanych z bezpieczeństwem sieci, usługami katalogowymi i in. Natomiast największe ramy aplikacyjne w Javie to ww. projekt San Francisco.

Dla kogo ramy aplikacji?

Ramy aplikacji to wyższy poziom wielokrotnego używania kodu i projektu niż zapewniają go czyste języki programowania obiektowego lub typowe narzędzia do tworzenia aplikacji. Jednakże zastosowanie ram aplikacji nie zapewnia sukcesu projektu. Użycie ram aplikacji wymaga znacznego wysiłku przy ich planowaniu w celu dostosowania go do specyfiki ramy. Również proces szkolenia programistów dotyczący ich użycia wymaga wiele wysiłku. Ponadto, aby dobrze skorzystać wielokrotnie z części kodu i elementów ram, konieczna jest dyscyplina programistyczna, niedopuszczenie do poprawiania kodu zgodnie z potrzebami chwili, ale niezgodnie z metodyką nieodłącznie związaną z ramami aplikacji.

Użycie ram aplikacji to proces długofalowy, dający szansę na duże oszczędności przy tworzeniu wielu podobnych aplikacji. Stosowanie się do standardów obiektowych i komponentowych daje szansę wykorzystania gotowych elementów, dostępnych po znacznie niższej cenie niż wyniesie koszt ich opracowania na miejscu. W Internecie łatwo znaleźć informacje na temat dostępnych elementów i zasad ich używania.