Historia Progressa

W niniejszym wpisie chciałbym przedstawić krótką historię Progress Software. Historię której nie powstydziłyby się takie firmy jak Microsoft czy Apple.
Cofniemy się aż do poczatku lat 80-tych, w więc czasów, gdy pracowało się bez Internetu i twardych dysków…

Przyjrzymy się najważniejszym elementom dodawanym i rozwijanym w poszczególnych wersjach aż do dnia dzisiejszego.
Kiedyś, w czasach jeszcze przed pandemią gdy spotkania i szkolenia rzadko były w formie zdalnej byłem dość często pytany o to kiedy pojawił się jakiś element w Progressie; np. od jakiej wersji jest binarny zrzut danych, zniesiony limit rozmiaru plików, kiedy pojawiły się dynamiczne obiekty itp., itd.
Informacje te nie mają znaczenia gdy chcemy pracować na najnowszej technologii. Jednak w tym artykule chodzi o to, że takie informacje są ciekawą historią rozwoju technologii, dlatego cofniemy się w czasie do samego początku Progressa, a więc do pierwszej wersji komercyjnej 2. Okazało się, że zdobycie takich informacji nie jest wcale proste. Dlatego niniejszy tekst nie należy traktować jako kompletne źródło informacji, lecz jako tekst „otwarty” zawierający tyle danych, ile udało się zgromadzić.

Progress Software Corporation powstał w 1981 roku jako Data Language Corporation. Dlatego nazwa DLC obowiązuje do dziś jako domyślny katalog instalacji do wersji 9. Pierwszy zespół składał się z założycieli: Josepha W. Alsopa, Chipa Zieringa i Clyde’a Kessela wraz z pierwszym pracownikiem Mary Szekely. Pierwszy produkt nazywał się „Relational Data Language”, w skrócie RDL, wymawiany „riddle” (w tłum. na polski – zagadka). Biuro mieściło się w Billerica, w stanie Massachusetts, w starym gabinecie dentystycznym. Większość początkowych prac projektowych powstało na stole w jadalni Mary Szekely przy użyciu komputera PC-AT, ze stacją dyskietek i bez twardego dysku.
W 1983 RDL był pokazany na COMDEX (Computer Dealers’ Exhibition w Las Vegas). Nie był to jeszcze produkt komercyjny i zawierał proste narzędzie napisane w języku 4GL, pozwalające na definiowanie tabel, pól i indeksów.

Pierwsza wersja komercyjna produktu pojawiła się w 1984 pod zmienioną nazwą Progress Version 2. Posiadała zaawansowane jak na ówczesne czasy cechy jak obsługę skompilowanych plików .r czy niepełną obsługę konfiguracji klient/serwer. Interfejs użytkownika był wyłącznie znakowy i zawierał kompletne narzędzia napisane w języku 4GL: słownik baz danych (do tworzenia schematu baz) oraz narzędzie do administracji.
Większość podstawowych elementów tej wersji przeszła wiele udoskonaleń i jest obecna w dzisiejszych produktach. Progress w V2 działał na różnych systemach UNIX i DOS.

Progress V3 (1985) – wersja zawierała pierwsze elementy zapowiadające nadejście graficznego interfejsu jak nakładające się ramki, pozwalające wyświetlać różne rodzaje informacji, czy zaznaczanie fragmentów tekstu innym kolorem. Narzędzie do administracji zyskało możliwość zrzutu i ładowania danych do/z innych popularnych wówczas produktów jak dBase czy Excel. Sama firma przeniosła się do „prawdziwego” biura w Billerica.

Progress V4 (1987) – Firma Data Language Corporation przyjęła nazwę swojego produktu, przekształcając się w Progress Software Corporation. W tym samym czasie powstały przedstawicielstwa w Europie. Rozwój aplikacji stał się możliwy na platformach VAX/ VMS, BTOS oraz DOS i UNIX. Data Dictionary wzbogacono o funkcje bezpieczeństwa (security), tak aby deweloperzy mogli zdefiniować uprawnienia do plików bazy.

Progress V5 (1988) – Powstało narzędzie Fast Track, służące do generowania aplikacji. Data Dictionary został poddany gruntownej renowacji. Wszystkie funkcje związane z administrowaniem zostały udoskonalone, włączając obsługę przyrostowego zrzutu i ładowania danych. Wersja zawierała także możliwość jednoczesnego przyłączenia kilku baz oraz pełną obsługę konfiguracji klient-serwer.

Progress V6 (1990) – Pojawił się produkt Data Server (nazwany Gateway) do obsługi innych baz jak Oracle, Sybase czy RMS. Wersja zawierała znakową wersję Results – produktu 4GL do generowania raportów i zapytań.

Progress V6.3 (1991) – W 10. rocznicę powstania, Progress Software Corporation osiągnął znaczącą poprawę wydajności baz danych, wprowadzając procesy asynchroniczne (asynchronous page writers). Firma przeniosła siedzibę do Bedford, w stanie Massachusetts, w której pozostaje do dziś.

Progress V7 (1993) – Deweloperskie środowisko klienckie zostało całkowicie zmodernizowane, w celu przystosowania go do nadchodzących zmian związanych z interfejsem graficznym. Proceduralny model programowania został zmieniony, tak aby mógł obsługiwać model oparty na zdarzeniach. Dodano przy tym wiele konstrukcji językowych do definiowania i obsługi różnych obiektów graficznych budowanego interfejsu w systemie Windows (oraz Motif).
V7 zawierała nowy zestaw narzędzi deweloperskich zwany Application Development Environment (ADE). Wprowadzono tablice tymczasowe i wiele wizualnych elementów, które można było przesuwać i zmieniać ich wymiary. Edytor trygerów był na początku prostym oknem dialogowym, w którym można było napisać kod do obsługi obiektów, a tablica TRG przechowywała ten kod w pamięci.

Graficzne środowisko, a w szczególności główne narzędzie deweloperskie UIB (User Interface Builder) ewoluowało i w swej ostatecznej postaci zawierało Section Editor – edytor do pisania kodu dla wybranej sekcji programu, generowało kod, reprezentujący także wszystkie elementy graficzne wstawione do interfejsu, tworzyło definicje zapytań dla tablic użytych w każdym oknie czy ramce, a także kod do obsługi tych zapytań.

ADE składało się przede wszystkim z narzędzi graficznych: Data Dictionary, Data Administration, UIB i Procedure Editor. Do tego doszedł Results, napisany od nowa dla pracy w trybie graficznym, oraz Report Builder – narzędzie do tworzenia bardziej wymagających raportów. W V7 pojawił się także Translation Manager, do obsługi aplikacji wielojęzykowych.

Progress V7.3 (1995) – Dalszy rozwój graficznego środowiska programistycznego. Wprowadzono zestawy szablonów, definicje pre-procesora, umożliwiające pisania uniwersalnych bloków kodu dla obiektów. Znaczącym elementem jest dodanie do języka 4GL składni pozwalającej na uruchamianie procedur w trybie PERSISTENT, umożliwiający pozostawanie procedury w pamięci do końca sesji (lub ich jawnego usunięcia) i zastosowanie technik quasi-obiektowych (uruchamiania instancji obiektów, wywoływania metod). Środowisko deweloperskie zostało wzbogacone o zestaw prostych narzędzi ProTools. Zestaw ten był systematycznie rozszerzany w kolejnych wersjach Progressa.

Progress V8 (1995) – Idea implementacji technik obiektowych w środowisku deweloperskim została rozwinięta w wersji 8, która zawierała Progress Application Development Model (ADM) i SmartObiekty. Technologia SmartObiektów polegała na tworzeniu interfejsu aplikacji z komponentów (okno, ramka, browser itp.) typu PERSISTENT. W modelu ADM dodano także mechanizm definiowania zdarzeń proceduralnych i zachowania obiektów oraz wprowadzono standaryzację komunikacji między nimi. Pojawił się system do tworzenia i obsługi internetowego interfejsu aplikacji – WebSpeed. Składał się z dwóch głównych produktów: Transaction Servera, odpowiedzialnego za komunikację i działanie aplikacji ,oraz Workshopa – narzędzia deweloperskiego. Późniejsza wersja 8 (1997-od tego roku zacząłem pracę z produktami Progress, którą kontynuuję do dziś :-)) wprowadziła po raz pierwszy serwer aplikacji (AppServer), posiadający tryby pracy: state-aware i state-reset. W 1999 powstało polskie przedstawicielstwo Progress Software w Warszawie na ul. Płowieckiej.

Progress V9 (1998) – Wprowadzono wielki zmiany w stosunku do poprzednich wersji z punku widzenia zarówno tworzenia aplikacji, jak i wydajności baz danych. Zaimplementowano w języku 4GL obsługę przesyłania powiadomień PUBLISH/SUBSCRIBE oraz definiowanie tzw. superprocedur dla wybranych procedur lub sesji. Techniki te rozwinęły obiektowość języka 4GL; wykorzystano je w nowym modelu ADM2. Model ten umożliwia tworzenie aplikacji rozproszonych (z wykorzystaniem AppServera) i odseparowanie warstwy interfejsu od źródła danych. W miejsce narzędzia
UIB powstał bardziej zaawansowany AppBuilder. Z ważniejszych jego funkcji należy wymienić integrację z WebSpeedem i wydajniejsze tworzenie aplikacji internetowych. Edytor zyskał funkcjonalność zaznaczania kolorem pisanej składni. W języku 4GL dodano implementację dynamicznych obiektów, zarówno graficznych (okna, ramki, browsery, przyciski, menu itp.) jak i związanych z przechowywaniem danych (bufory, pola,
tablice tymczasowe, zapytania). Wprowadzono technologię OpenClient i narzędzie ProxyGen (generator proxy) dając możliwość przyłączenia do logiki biznesowej 4GL interfejsu stworzonego w innej technologii (Java, ActiveX). Rozwinięto produkt AppServer, wprowadzając tryb pracy stateless. Zaimplementowano obsługę standardu XML (model DOM).

W późniejszej wersji 9.1D (2002) dodano nowy debugger graficzny oraz wczytywanie danych XML w modelu SAX (SAXReader).

V9 zawierała nową technologię WebClient, która dała możliwość generowania graficznego interfejsu po stronie klienta i łączenia się ze zdalną bazą (za pośrednictwem AppServera) przez Internet (interfejs miał postać aplikacji graficznej 4GL i był darmowy). Na bazie rozszerzonych możliwości języka powstała platforma do tworzenia graficznego interfejsu aplikacji – Dynamics. Interfejs tworzony jest w sposób dynamiczny, przy wykorzystaniu parametrów przechowywanych w specjalnej bazie – tzw. repozytorium (9.1A).
Niezwykle ważną cechą V9 było wprowadzenie nowej struktury baz danych. Wprowadzono tzw. Obszary Przechowywania Danych Typu I, z których każdy można porównać do wcześniejszej bazy wielo-wolumenowej. Każdy taki obszar może zajmować wybrane obiekty bazy i posiadać określone parametry (np. liczbę rekordów w bloku). Nowa architektura przyczyniła się do zwiększenia możliwości projektowanej bazy, lepszego dobrania jej parametrów w stosunku do charakteru danych, praktycznie nieograniczonej ilości przechowywanych informacji oraz lepszej wydajności. Znacznie usprawniono proces odbudowy indeksów oraz dodano obsługę dużych plików (większych od 2GB). Wprowadzono obsługę strony kodowej UTF-8 dla baz oraz klienta wsadowego. Pojawił się silnik SQL92 wbudowany w serwer baz (systematycznie rozwijany w kolejnych wersjach), narzędzie do monitorowania systemów baz danych z konsoli WWW – Fathom Management (znane później jako OpenEdge Management), produkt do replikacji bloków AI z bazy głównej do zapasowej w czasie rzeczywistym – Fathom Replication (później OpenEdge Replication) oraz oprogramowanie wspomagające architekturę klastrową (Failover Clusters).

OpenEdge 10 (2003) – PSC zamiast kolejnej wersji Progress V10, wprowadził produkt OpenEdge (numeracja pozostała bez zmian), który był kontynuacją V9. Celem platformy OpenEdge jest budowanie w łatwy i przejrzysty sposób zaawansowanych aplikacji biznesowych, integracja z nowopowstającymi technologiami oraz wysoka wydajność systemu baz danych. Wprowadzone zostały Obszary Przechowywania Danych Typu II, różniące się od Typu I możliwością zdefiniowania tzw. klastra danych, czyli n sąsiadujących bloków należących do jednego obiektu bazy. Poprawiono wydajność odbudowy indeksów wprowadzając m.in. definiowanie liczby grup sortowania (-SG) oraz buforów (-B). Dodano typy danych: BLOB, CLOB, DateTime, DateTime Timezone. Z punktu widzenia integracji został zaimplementowany OpenEdge adapter dla Sonica ESB oraz technologia wywoływania Web Serwisów z aplikacji OpenEdge a także wystawiania progressowej logiki biznesowej w postaci Web Serwisów. AppServer zyskał kolejny tryb pracy – state-free. W języku 4GL wprowadzono w ProDatSety – obiekty zawierające jedną lub kilka tablic tymczasowych, relacje między nimi i obsługę zdarzeń. Oprócz dodania nowych możliwości do kodowania logiki biznesowej, wspomagają one wymianę informacji przez WebSerwisy i są ważnym elementem architektury OERA. W technologii OpenClient .NET zastąpił ActiveX. Wdrożono obsługę strony kodowej UTF-8 dla klienta graficznego.

OpenEdge 10.0B (2004) – Zwiększono bezpieczeństwo danych na dwóch poziomach. Po pierwsze wprowadzono szyfrowanie transmisji między procesami (klienta, serwera, AppServera itd.), obsługę certyfikatów, zarządzanie kluczami szyfrowania. Po drugie zaimplementowano w język instrukcje pozwalające deweloperowi decydować o wyborze szyfrowanych danych i ich wykorzystaniu.

OpenEdge 10.1A (2005) – Znów pojawiły się duże zmiany. Pierwszą z nich to OpenEdge Architect – nowe zintegrowane środowisko deweloperskie (IDE) do projektowania, testowania i wdrażania aplikacji OpenEdge, oparte na platformie Eclipse. Został zaprojektowany aby poprawić łatwość i wydajność tworzenia nowoczesnych aplikacji biznesowych. Poza AppBuilderem pozostałe narzędzia: edytor, debugger, DB Navigator (zastępujący słownik) zyskały nowy wygląd i funkcjonalność. Zaimplementowane zostały rozszerzenia języka obiektowego. Chodzi tu o „obiektowość” z prawdziwego zdarzenia z enkapsulacją, dziedziczeniem, polimorfizmem. Tak rozszerzony język zyskał nową nazwę: Advanced Business Language (ABL). Trzecią nowością był Auditing – zintegrowany i w pełni konfigurowalny serwis stworzony do kontrolowania zdarzeń w bazach danych OpenEdge, narzędziach bazodanowych oraz aplikacjach ABL i SQL. W technologii XML pojawił się obiekt SAX-Writer. Nowości objęły także administrowanie bazami danych.
Należy wymienić po pierwsze AI Management – usługę związaną z automatycznym zarządzaniem ekstentami after-image. Zastosowano wielowątkowy zrzut danych i odbudowę indeksów, a także możliwość dodawania ekstentów w trybie online.

OpenEdge 10.1B (2007) – Wprowadzono zmiany szczególnie istotne z punktu widzenia architektury baz danych. Dodano nowy 64-bitowy typ danych INT64, co umożliwiło wprowadzenie: obsługi dużych wartości kluczy indeksowych, 64-bitowe klucze adresowania (dla obszaru Typu II), 64-bitowe wartości sekwencji. Podniesiono maksymalny limit obszarów oraz maks. rozmiar pamięci dzielonej. Zrealizowano mechanizm umożliwiający skopiowanie uprawnień użytkowników zdefiniowanych w bazie z fazy kompilacji do runtime’u. Rozszerzono instrukcję wykonania backupu online o opcję włączenia zapisu AI.

OpenEdge 10.1C (2008) – OE 10.1C wprowadził do języka ABL składnię do Structured Error Handling – obsługę błędów charakterystyczną dla obiektowych języków programowania jak Java czy C++. Rozwinięto możliwości komunikacyjne poprzez włączenie protokołu IPv6 (Internet Protocol V6). Od OE 10.1C Administratorzy baz mogą zwiększać wartości następujących parametrów online: -B, -bibufs, aibufs, -L, -Mxs. Dodano nowe elementy do OOP, XMLa, ProDataSetów, OpenEdge Architecta.

OpenEdge 10.2A (2009) – Najważniejszą „rewolucyjną” zmianą była implementacji obiektów .NET z interfejsem języka ABL. Na platformie OpenEdge Architect dodano narzędzia dedykowane do budowy interfejsu aplikacji z wykorzystaniem takich obiektów:
• Visual Designer – edytor WYSIWYG dla tworzenia aplikacji metodą „przeciągnij i upuść”, wspierający obsługę obiektów .NET.
• Class browser, wspierający obsługę klas .NET.
• Wprowadzono rozszerzenia Edytora ABL o nowe cechy UI.

Zastosowano ulepszone metody zapisu/odczytu danych XML do/z ProDataSetów, redukujące rozmiar plików i obciążenie sieci. Wprowadzono OpenEdge Explorer – narzędzie do zarządzania procesami z poziomu przeglądarki internetowej, oparte na interfejsie OpenEdge Management. Ulepszono Data-Server dla Oracle i Microsoft SQL Server. Zmodernizowano Adapter dla SonicMQ.

OpenEdge 10.2B (2010) – W celu umożliwienia budowania bezpieczniejszych aplikacji wprowadzono w OpenEdge Enterprise RDBMS – Transparent Data Encryption (TDE). Zapewnia to szyfrowanie danych, znajdujących się w plikach: baz danych, backupach, plikach zrzutu binarnego. TDE wykorzystuje biblioteki szyfrowania zgodne ze standardami PCI, stosowane przez firmy przetwarzające informacje z kart kredytowych. TDE w minimalnym stopniu wpływa na koszt i czas rozwoju aplikacji. Nie jest wymagana jakakolwiek zmiana samej aplikacji a zarządzanie szyfrowaniem odbywa się niezależnie od kodu ABL. TDE ma minimalny wpływ na wydajność – ok. 5% dla typowych aplikacji OLTP. Deweloperzy mogą teraz przy pomocy składni ABL odczytywać/zapisywać dane ProDataSetów i tablic tymczasowych z/do obiektów JSON. Umożliwia to tworzenie aplikacji typu RIA (Ajax-based Internet Applications), zwiększając ich dostępność poprzez sieć internetową. Zaimplementowano pełne wykorzystanie możliwości .NET z poziomu ABL.

OpenEdge 11 to przede wszystkim nowy serwer aplikacji nazwany najpierw Pacific Application Server, a ostatecznie PASOE (Progress Application Server for OpenEdge). Będzie miał on duży wpływ na migrację aplikacji. W tej wersji oba serwery sa dostępne, ale zapowiedziano, że w następnej wersji nie będzie już klasycznego AppServera. W OE 11 rozwinęły się różne techniki tworzenia aplikacji webowych z wykorzystaniem PASOE i systemy zabezpieczeń bazujące na Spring Security. Powstał produkt OE Authentication Gateway oraz wiele innych udoskonaleń.

W OpenEdge 12 Progress reklamował przede wszystkim nowy serwer baz danych, który obsługuje klientów zdalnych wielowątkowo oraz realizujący złączenia tabel (server-side joins). Udoskonalono mechanizm BHT (Buffer Hash Table), zmniejszając liczbę konfliktów dostępu do pamięci dzielonej. Usprawniono technologię serwera replikacji. Systematycznie dodawane są elementy w programowaniu obiektowym. Stworzono następcę mało wydajnego w rozproszonych systemach OE Management – OpenEdge Command Center (OECC). Progress wspiera integrację z niektórymi wiodącymi technikami, i tak w OECC można wykorzystać Open Telemetry oraz produkty z grupy APM (Application Performance Monitorong). Dalej rozwijany jest PASOE. W bazach danych można przeładować tabelę online lub jej fragment itd.

Nowa wersja OE 13 również zapowiada się ciekawie, o czym będę pisać zapewne na początku przyszłego roku. Jeśli ktoś jest zainteresowany większą ilością szczegółów począwszy od OE 11, to może prześledzić artykuły od 2015 (tak, tak, to już 10 lat!).

Na zakończenie chciałbym serdecznie podziękować Gusowi Björklundowi, Danowi Foremanowi i wszystkim, którzy nadesłali archiwalne zdjęcia.