Введение в OpenEdge Mobile: RUN-TIME АРХИТЕКТУРА

Клиентский доступ к AppServer с использованием мобильных сервисов

Рисунок 2 показывает, как OpenEdge JSDO осуществляет доступ к мобильному ресурсу, который работает одинаково для заданного JSDO независимо от типа приложения.

Каждый JSDO, созданный для мобильного приложения, может получить доступ к одному мобильному ресурсу из состава мобильных ресурсов, предоставляемых соответствующим мобильным сервисом мобильного веб-приложения. Одно мобильное веб-приложение может поддерживать один или несколько мобильных сервисов, а веб-сервер Apache Tomcat может разместить несколько мобильных веб-приложений.

На рисунке 2, мобильное веб-приложение содержит два мобильных сервиса, Inventory и OrderIntry. Сервис OrderEntry содержит два мобильных ресурса, Orders и Customers, которые реализованы в виде ABL-классов Orders.cls и Customers.cls, и к которым, соответственно, на стороне клиента обеспечивают доступ Orders JSDO и Customers JSDO.

Примечание. Разделение ресурсов в рамках сервиса OrderEntry приведено только для иллюстрации, чтобы показать, как два ресурса работают с одной временной таблицей каждый, один с записями таблицы Order, а второй с записями таблицы Customer. На практике, эти временные таблицы могут быть объединены с использованием ProDataSet, который предоставит доступ одного JSDO к одному мобильному ресурсу.

Обратите внимание, веб-приложение OpenEdge Mobile инсталлируется и запускается в контейнер Apache Tomcat Java подобно веб-приложению OpenEdge REST, и им можно управлять теми же инструментами OpenEdge. Аналогично, сервис OpenEdge Mobile очень похож на веб-сервис OpenEdge REST. Различия между ними заключаются в том, как мобильный сервис предоставляет ресурсы мобильному приложению.

Веб-сервис OpenEdge REST идентифицирует каждый ресурс по уникальному URI, к которому REST-клиент отправляет явный HTTP-запрос, в результате чего вызывается соответствующая процедура на сервере приложений. Веб-сервис REST затем возвращает результаты работы AppServer-процедуры REST-клиенту в виде HTTP-ответа, который клиент должен интерпретировать согласно требованиям соответствующего веб-сервиса REST.

Сервис OpenEdge Mobile, в отличие от OpenEdge REST веб-сервиса, представляет указанные данные и программы singleton-класса сервера приложений или процедурные объекты как данные и операции единственного мобильного ресурса и мапирует операции для этого ресурса непосредственно к соответствующим JavaScript-методам одного JSDO. Мобильный сервис выполняет маппинг с помощью файла каталога JSDO, который генерируется для сервиса в момент его создания. Такой JSDO-каталог представляет собой JSON-файл, содержащий информацию о схеме данных и операциях, которые поддерживает каждый мобильный ресурс в сервисе. Следовательно, мобильное приложение должно загрузить этот JSDO-каталог для мобильного сервиса прежде, чем будет создан JSDO для доступа к любому мобильному ресурсу предоставляемому сервисом.

Таким образом, мобильное приложение вместо того, чтобы идентифицировать URI, отправлять HTTP-запросы и интерпретировать HTTP-ответы по правилам соответствующего REST-ресурса (вызов AppServer-процедур), должно лишь вызвать соответствующий метод или методы из JSDO для выполнения связанных ABL-процедур из класса или процедурного объекта на сервере приложений. Всеми входными и выходными параметрами и прочими результатами работы ABL-процедуры обмениваются с JSDO и его JavaScript-методами в виде соответствующих свойств JavaScript-объектов, которые мобильное приложение передает и возвращает из JDSO и его методов.