Serwisy REST – porównanie różnych typów

W kilku wcześniejszych artykułach opisałem, krok po kroku, tworzenie serwisu typu REST, wykorzystującego obiekty JSDO.

Wiem od niektórych z Was, że z tymi serwisami wiążą się pewne niejasności. Nic w tym dziwnego, to nie są progressowe technologie i wiążą się o stworzone niedawno standardy.

Kilka osób pytało mnie np. o różnice między tworzeniem serwisu REST na bazie projektów: Data Object, ABL Web App czy REST (rysunek poniżej).

Pierwsze dwa typy projektów służą do tworzenia serwisów Data Object. W Progress Developer Studio for EpenEdge zaimplementowano dwa typy projektów ze względu na dwa rodzaje AppServerów, z którymi współpracują.
Projekt Data Object jest wykorzystywany do tworzenia serwisów przy użyciu klasycznego AppServera, a ABL Web App z Pacific AppServer. Do wersji OpenEdge 11.5 włącznie zamiast tych dwóch projektów był dostępny tylko projekt Mobile.

W obu projektach (Data Object, ABL Web App) można utworzyć Business Entity – obiekt danych np. Customer czy Order, z którym tworzona jest klasa obiektu oraz obiekty JSDO. Klasa zawiera gotowe metody realizujące różne funkcje na danych (Create, Read, Update, Delete). Tworzony jest także plik . json, który można użyć definiując obiekty w środowisku Rollbase czy Telerik. Jest to prosta, szybka metoda, nie wymagająca szczegółowej wiedzy dewelopera nt serwisów REST.

Inne podejście jest reprezentowane w projekcie typu REST. Projekt ten wybierają deweloperzy  gdy aplikacja wymaga bezpośredniego dostępu do kontekstu HTTP (request/response), nagłówka, cookies itp. Daje to dodatkowe możliwości ale wymaga o wiele więcej pracy. Trzeba samemu “zamapować” każdą procedurę, klasę i parametr; dodać notacje itd.

Np. dodać nowe zasoby, parametry oraz przypisać im określone czasowniki (verb) możemy w narzędziu REST Resource URI Editor.

Serwis OpenEdge – Telerik Kendo UI

W niniejszym “odcinku” pokażę jak wykorzystać utworzony wcześniej serwis REST OpenEdge jako źródło danych w produkcie Telerik Kendo UI.

Mamy więc gotowy serwis i działający serwer aplikacji PAS.

Kendo UI, to zestaw bibliotek tworzących interfejs webowy oparty na HTML5 i JavaScript.

Należy pobrać plik ZIP i rozpakować w lokalnym katalogu.
Zawiera on bibliotekę funkcji JavaScript dla obiektów JSDO oraz przykładowe pliki HTML. Każdy z takich plików zawiera linki do dalszych bibliotek na stronach Progressa i Telerika.
Pliki te wygodnie jest otwierać w Notepad++.

Otwórzmy w Notepad++ plik Our_Sample.html. W sekcje HEAD znajdują się odnośniki do zewnętrznych bibliotek.

Nas bardziej interesuje sekcja SCRIPT, a dokładniej parametry serviceURI, catalogURI oraz resourceName, które powinny mieć wartości zgodne z utworzonym serwisem.

Po edycji tych parametrów plik HTML wygląda następująco:

Klikając na nagłówek kolumny dane są sortowane wg jej wartości. Można przeciągnąć nagłówek kolumny do górnej strefy i wtedy dane będa pogrupowane. Można także edytować, kasować i tworzyć nowe rekordy.

Pozostałe pliki html prezentują dane z serwisów zewnętrznych. Np. Other_KendoUIPieChart.html

Co teraz? Chciałbym pokazać jak wykorzystać dane z naszego serwisu w Telerik Platform for OpenEdge, ale przedtem trzeba wziąć na warsztat system Rollbase. Do Telerika jednak niedługo wrócimy.

Tworzenie serwisów OpenEdge cz. II

W poprzedniej części pokazałem jak stworzyć projekt oraz serwis OpenEdge. Teraz zajmiemy się utworzeniem logiki biznesowej aby wystawić przez ten serwis dane z bazy Progress.

W widoku Project Explorer klikamy prawym klawiszem myszy na podkatalog AppServer i wybieramy New -> Business Entity.

Tworzymy nową klasę obiektu biznesowego np. Customer. Pamiętajmy, że w nazwie rozróżnia się wielkość liter. Można opcjonalnie wypełnić pola Description i Purpose. Klikamy Next.

Ekran Select a schema file. Wybieramy aktywne połączenie z bazą danych oraz tabelę Customer. (W tym miejscu możemy zamiast połączenia z bazą wskazać przygotowany wcześniej plik schematu, w którym będzie zdefiniowany ProDataSet z kilkoma tabelami). Zauważmy listę operacji, jakie zostaną zdefiniowane w klasie. Domyślnie są to CRUD czyli: Create, Read, Update, Delete i takie zostawiamy.

Klikamy Finish.

Można zauważyć, że w projekcie pojawiły się nowe zasoby (podkatalog AppServer): plik klasy Customer.cls, plik customer.i z definicjami ProDataSeta dsCustomer oraz tablicy tymczasowej ttCustomer.

Plik Customer.cls zawiera gotowe metody dla operacji CRUD. Dane będą przekazywane między bazą OpenEdge a ProDataSetem. Możemy modyfikować te metody dla naszych potrzeb. Teraz jednak zostawiamy je w stanie domyślnym.

Teraz nowy obiekt biznesowy trzeba dodać do serwisu. Rozwijamy Defined Services i prawym klawiszem klikamy na Edit.

Ekran Edit an ABL Service. Nic tu nie zmieniamy. Next.

Ekran Create a Data Object service. Zaznaczamy zdefiniowane wcześniej zasoby, czyli klasę Customer. Zanotujmy składnię URI, przez którą będzie dostęp do naszych zasobów OpenEdge w serwisie REST. Finish.

W podkatalogu static został wygenerowany plik mobile6.json zawierający opis serwisu. Zajrzymy do niego za chwilę.

Otwieramy widok Servers i uruchamiamy naszą instancję appservera oepas1 . Może to potrwać kilka minut.

Po uruchomieniu appservera PAS wpisujemy w przeglądarce www link:

http://localhost:8810/mobile6/rest/mobile6Service/Customer

Widać, że udostępniliśmy tabelę Customer poprzez serwis REST.

Jeśli chcemy podejrzeć plik json, możemy go odszukać i otworzyć na dysku lub wpisać poniższy link:

http://localhost:8810/mobile6/static/mobile6Service.json

Następnym razem pokażę prosty przykład jak wykorzystać gotowy serwis z technologią Telerik.

Tworzenie serwisów OpenEdge cz. I

Chcę teraz napisać o tworzeniu serwisów typu REST, które są bardzo przydatne w integracji danych pochodzących z baz OE z nowym front-endem np. Rollbase, Telerik Kendo UI czy z urządzeniami mobilnymi.

Wspomniałem o tym w zeszłym miesiącu w artykule o JSDO.

Serwisy tworzymy w Progress Developer Studio for OpenEdge. Zakładam, że mamy skonfigurowane środowisko: w zakładce Servers widzimy : Pacific AppServer (domyślna nazwa oepas1)

oraz w Preferencjach mamy zdefiniowane połączenie z bazą danych sports (kopia bazy sports2000).

Gdyby były problemy z dojściem do tego miejsca, to bardzo proszę o wiadomość. Opis jest tutaj.

Proces tworzenia nieznacznie różni się od tego miejsca w OE 11.5 od OE 11.6. Najpierw zajmiemy się wersją OE 11.5.


Tworzymy nowy projekt OpenEdge (nazwa np. mobile5), wybieramy typ Mobile. Klikamy Next.

Pojawia się ekran Select AVM and Layout Options. Nic tu nie zmieniamy, klikamy Next.

Następny ekran: Define AppServer content module. Zaznaczamy, który serwer aplikacji będzie obsługiwał nasz serwis. Tutaj wybieramy PAS, czyli oepas1. (Gdybyśmy chcieli użyć tradycyjnego OE AppServera, to moglibyśmy wybrać restbroker1).

Zaznaczamy Publish changes immediately i Next.

Ekran Create a Mobile service. Upewniamy się, że zaznaczona jest opcja Create a Mobile service oraz jako Supported servers wybrany oepas1. Klikamy Next.

Ekran Create a Mobile App. Ponieważ nie budujemy aplikacji mobilnej, a jedynie serwis, odznaczamy tę opcję. Next.

Ekran Define PROPATH. Nic nie zmieniamy. Next.

Ekran Select database connections. Dodajemy do projektu istniejące połączenie z bazą danych (zdefiniowane wcześniej). Klikamy Next.

Ostatni ekran: Static Web Pages, zawiarający konfigurację folderów serwisu. Nic tu nie zmieniamy. Klikamy Finish. Tworzony jest nowy projekt.

Po utworzeniu powinniśmy zobaczyć zasoby projektu jak poniżej.


Teraz zrobimy to samo dla OE 11.6.

Tworzymy nowy projekt OpenEdge (nazwa np. mobile6), wybieramy typ ABL Web App (dla klasycznego AppServera wybieramy typ Data Object). Klikamy Next.

Ekran Provide ABL Web App deploy details.

Zaznaczamy Web Application: Deploy as WebApp, Sopported servers: oepas1 oraz Publish changes immediately. Klikamy Next.

Na ekranie Ceate an ABL Service zaznaczamy typ serwisu: Data Object (Annotated RPC) i klikamy Next.

Ekran Select AVM and Layout Options. Nic tu nie zmieniamy, klikamy Next.

Kolejny ekran Define PROPATH. Nic nie zmieniamy. Next.

Ekran Select database connections. Dodajemy do projektu istniejące połączenie z bazą danych. Klikamy Finish i czekamy aż serwis zostanie utworzony.

W drugiej części zajmiemy się wystawianiem danych z bazy OpenEdge poprzez utworzony serwis.

 

Pacific AppServer (PAS)

Pacific AppServer (PAS) to nowy serwer aplikacji oparty na technologii Tomcat. Dlaczego Progress Software stworzył ten produkt? Przecież od wielu lat istnieje OpenEdge AppServer? Czy między obu produktami istnieją istotne różnice?

PAS to AppServer nowej generacji stworzony do obsługi wszelkich aplikacji progressowych w tym Rollbase, Corticon, OpenEdge, Telerik. Występuje wyłącznie w wersji 64-bitowej.
Nie należy go traktować jako produkt zastępujący tradycyjny OpenEdge AppServer ale jako produkt dodatkowy. Został zaprojektowany dla wydajnej i bezpiecznej pracy w chmurze.

Istotna różnica między obydwoma produktami jest widoczna w wyborze modelu sesji. Używając klasycznego OE AppServera, klient łączy się z AS pracującym z już określonym modelem sesji (managed: state-aware, state-reset, stateless lub unmanaged: state-free).

W przypadku PAS, model sesji jest kontrolowany przez proces klienta: CONNECT -sessionModel Session-Managed|Session-Free.

Ponadto, agent PAS jest wielo-sesyjny. Agent OE AppServera obsługuje tylko jedną sesję.

speed

PAS oprócz Web Servera ma wbudowaną obsługę dla wywołań AIA, REST, SOAP. Dla OE AppServer potrzebne są do tego dodatkowe adaptery.

Z punktu widzenia wydajności przewaga PAS jest ogromna. Wczesne testy (2014) wykazały:
– 493% wzrost jednoczesnych połączeń procesów klientów
– 48% spadek użycia CPU
– 96% spadek użycia pamięci
– 736% wzrost transakcji na sekundę (wykorzystano znany wielu użytkownikom program ATM).

Właściwości obu serwerów aplikacji można podsumować w poniższej tabeli.

OpenEdge AppServer Pacific AppServer for OpenEdge
Dla każdego modelu sesji (state-aware, state-reset, stateless, state-free) musi być uruchomiony osobny broker. PAS nie ma modelu sesji. Klient decyduje który model będzie używany (session-Managed, session-Free).
Do obsługi połączeń http i komunikacji SOAP, REST konieczna jest instalacja dodatkowych adapterów. Pełna obsługa komunikacji jest już wbudowana w PAS
Każdy agent AppServera może obsługiwac jedną sesję ABL. Nowy agent potrafi obsłużyć kilkaset sesji ABL.
Brak Web Servera Wbudowany Web Server

Zastanówmy się kiedy używać każdego z opisanych serwerów aplikacji. Przewaga PASa może wskazywać, że jego wybór będzie lepszy w każdej sytuacji. Pamiętajmy jednak, że z tą zmianą wiąże się także konieczność posiadania odpowiedniej wiedzy jak administrować nowym serwerem, jak się z nim komunikować itd. Tradycyjny AppServer posiada tryby pracy, które choć niewydajne (szczególnie state-aware, state-reset), upraszczają komunikację aplikacja-serwer oraz zarządzanie kontekstem. Warto jednak podnieść swoją wiedzę i rozważyć migrację aplikacji szczególnie gdy zależy nam na wzroście wydajności, która stoi zdecydowanie po stronie serwera PAS.