JSDO – JavaScript Data Object

Zanim napiszę o tworzeniu serwisów REST, wykorzystaniu danych OpenEdge w produktach Rollbase czy Telerik, trzeba przyswoić sobie pewne nowe pojęcia.
Jednym z nich jest omówiony wcześniej Pacific AppServer. Obecnie zajmiemy się progressowymi obiektami JSDO.
Obiekty te zapewniają wsparcie dla złożonego modelu danych oraz API do manipulowania danymi przy zachowaniu pełnej integralności.

Pierwotnym wykorzystaniem JSDO były aplikacje mobilne jednakże, jak wspomniałem, wykorzystuje się je także w integracji z innymi produktami.

Obiekty po stronie klienta zapewniają dostęp do zasobów wystawionych jako serwis WWW oraz upraszczają mapowanie pomiędzy danymi JSDO i elementami HTML. Zasobami tymi są logika biznesowa ABL oraz dane OpenEdge. Najczęściej wykorzystuje się dane z ProDataSetów, które z kolei mapują dane z baz OpenEdge.

jsdo mapping

JSDO komunikuje się z serwerem aplikacji (OE AppServer, PAS) wysyłając i odbierając dane.
Może wykonywać operacje CRUD (Create, Read, Update, Delete) zdefiniowane w obiektach Business Entity (BE) lub wywoływać metody na AppServerze.

Wszystko to razem, dla kogoś kto zetknął się z nową technologią po raz pierwszy, wydaje się być zbyt skomplikowane. jsdo mapping Niejednokrotnie słyszałem od Was podczas spotkań, że lepiej jest zostać przy znanej technologii, bo tutaj nie za bardzo wiadomo o co chodzi. Jednakże wiele elementów, o których mówię jest zautomatyzowanych. Np. tworząc w OE Developer’s Studio, w danym projekcie nowy obiekt typu Business Entity, mogę wskazać na tablicę z której chcę mapować dane (patrz rysunek). Tworzą się wtedy automatycznie ProDataSet i zasoby REST, a mapowanie PDS JSDO jest automatyczne. Jeśli zachodzi potrzeba mogę edytować metody CRUD dla BE itd. Pokażę wkrótce jak to zrobić.

Katalog JSDO – definiuje logiczny schemat oraz mapowanie do zdalnego źródła danych. Katalog ten zawiera plik JSON (JavaScript Object Notation).
Katalog określa również API do wywoływania zdalnej logiki biznesowej (poza podstawowymi operacjami CRUD).
Katalog ten jest niezbędny jeśli chcemy wykorzystać JSDO jako zewnętrzne źródło danych w innych produktach.

Z danych JSDO można korzystać na różne sposoby. Poniżej przedstawiam przykład przygotowany przez PSC i Telerik. Istnieje zdefiniowany serwis OE, przekazujący dane poprzez JSDO. Mamy podany katalog JSDO z plikiem JSON.

<!DOCTYPE html>
<html>
<head>
<title>Simple JSDO Usage</title>
<script src=”http://oemobiledemo.progress.com/jsdo/progress.jsdo.3.1.js”></script>
</head>
<body><!– results will be written here by JavaScript –><script>
(function () {var serviceURI = “http://oemobiledemo.progress.com/MobilityDemoService”,
catalogURI = serviceURI + “/static/mobile/MobilityDemoService.json”;

// create a new session object
var session = new progress.data.Session();
session.login(serviceURI, “”, “”);
session.addCatalog(catalogURI);

// create a JSDO
var jsdo = new progress.data.JSDO({ name: ‘dsCustomer’ });
jsdo.subscribe(‘AfterFill’, onAfterFillCustomers, this);

// calling fill reads from the remote OE server
jsdo.fill();

// this function is called after data is returned from the server
function onAfterFillCustomers(jsdo, success, request) {
// for each customer record returned
jsdo.eCustomer.foreach(function (customer) {
// write out some of the customer data to the page
document.write(customer.data.CustNum + ‘ ‘ + customer.data.Name + ‘<br>’);
});
}

}());
</script>
</body>
</html>

Obsługa powyższego przykładu jest zrealizowana głównie przy pomocy dwóch obiektów: Session – zarządzanie sesją i autoryzacją oraz JSDO – dostęp do danych OpenEdge poprzez informacje zawarte w katalogu JSDO.

Jak działa ten przykład możecie sprawdzić TUTAJ.

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.