Обзор OpenEdge-процессов

Архитектура приложения определяет структуру приложения, а также то, как различные части приложения взаимодействуют друг с другом. Необходимо реализовать архитектуру приложения так, чтобы её было легко понять, особенно разработчикам, которые будут развивать и поддерживать проект.

При проектировании приложения лучшим решением будет разделить его на взаимосвязанные части. Как минимум, такими частями могут стать программный код, выполняемый на стороне клиента, а также бизнес-логика и бизнес-данные. Подобное разделение позволит в будущем уменьшить количество программного кода, который будет необходимо изменить и протестировать в случае, если изменятся бизнес-требования. Например, если изменение алгоритма влияет только на то, как исполняется бизнес-логика, то не понадобится изменять код для клиента или для бизнес-данных.

Функциональные компоненты приложения в терминах OpenEdge вместе называются OpenEdge Reference Architecture (OERA), об этом расскажу позже, а сейчас давайте познакомимся с процессорной архитектурой OpenEdge.

Независимо от того, выполняете ли вы тестирование или развёртывание вашего приложения, оно работает в процессной архитектуре OpenEdge, которая содержит один или несколько клиентских процессов и один или несколько серверных процессов. Поэтому важно понимать, что такое OpenEdge-процессы и как написанный вами код их использует.

Как разработчик, вы будите создавать, компилировать и тестировать программный код. При разработке приложения вы должны обеспечить работу определенных OpenEdge- процессов. Например, для тестирования программного кода бизнес-логики должен быть запущен серверный процесс.

Серверные процессы OpenEdge

В среде исполнения OpenEdge может присутствовать несколько серверных процессов. Обычно инсталляция OpenEdge включает в себя ряд компонент, которые представляют собой такие серверные процессы. Вы можете настраивать каждый из процессов и определять способы их старта.

Application Server. Платформа OpenEdge предоставляет два сервера приложения для исполнения бизнес-логики на ABL:

Pacific Application Server (PAS) for OpenEdge – это веб-сервер Apache Tomcat, у которого есть встроенная маршрутизация и функциональность различных адаптеров.
Classic AppServer – требует некоторых дополнительных процессов, включая Name Server для идентификации и регистрации процессов во время выполнения, а также OpenEdge-адаптеры для обработки запросов от не-ABL клиентов.

Progress Software рекомендует использовать PAS for OpenEdge в производственных средах, поскольку он отлично приспособлен для высоких нагрузок, а также прост в развертывании и поддержке.

Database Server – группа процессов, обслуживающих запросы от различных процессов для получения доступа к данным и управления транзакциями в базе данных OpenEdge. Сервер OpenEdge состоит из брокера и одного или нескольких серверов.
Data Server – процесс, который позволяет ABL-клиентам получать доступ к не-OpenEdge базам данных.
Admin Server – процесс, который стартует серверные процессы OpenEdge. Он также необходим для работы OpenEdge Management и OpenEdge Explorer, где используется для обновления конфигурации сервера и файлов свойств.

Типы клиентов OpenEdge

Клиентские процессы OpenEdge взаимодействуют с серверными процессами, которые исполняют бизнес-логику и предоставляют бизнес-данные клиенту. Некоторые типы клиентских процессов работают внутри OpenEdge-приложения, другие используются для поддержки пользовательских интерфейсов, при этом они могут встраиваться друг в друга. В OpenEdge различаются следующие типы клиентских процессов:

ABL client
Open Client
Web services client
Mobile client
WebSpeed client
SQL client

Рассмотрим каждый из них.

ABL client

Клиент ABL работает в рамках процесса, который взаимодействует с серверным процессом OpenEdge. Этот тип клиента запускает процесс ABL- сессии, которая и исполняет ABL-код. Клиент ABL может быть написан для поддержки пользовательского интерфейса, или в качестве процесса, который не имеет пользовательского интерфейса как такового, т.е. для работы в фоновом режиме.

Существует три типа пользовательского интерфейса для ABL-клиентов, каждый из них требует применения собственной модели программирования на ABL:

GUI for .NET – этот тип ABL-клиента представляет собой пользовательский интерфейс, который обеспечивает встроенную поддержку для .NET-форм, элементов управления .NET и основных .Net-классов, которые можно непосредственно просматривать, с которыми можно взаимодействовать и которыми можно управлять посредством событийного или объектно-ориентированного программирования.

GUI for .NET является рекомендуемым пользовательским интерфейсом для ABL-приложений.

GUI – представляет собой пользовательский интерфейс в виде графических виджетов, включая окна, диалоговые окна и графические средства управления, поддерживаемые событийной моделью управления.

Character – представляет собой пользовательский интерфейс, основанный на символьных виджетах для очень упрощенной работы с данными. Такой тип интерфейса может быть полезен для выполнения производственных задач, в которых достаточно простого (текстового) отображения данных и манипулирования информацией.

Open Client

Клиент Open Client работает в рамках процесса, который не является частью ABL-сессии. Такие клиенты могут быть написаны на других языках программирования, таких как C#, VB.NET или Java, и могут предоставлять конечным пользователям множество пользовательских интерфейсов. Они также могут предоставлять функциональность для других приложений, у которых нет пользовательского интерфейса.

Существует две модели для разработки Open Client :

С использованием прокси
С использованием OpenAPI

Когда Open Client разрабатывается с использованием прокси, то файлы классов (Java) или .NET сборки (assembly) создаются с помощью OpenEdge-инструментов. Здесь прокси используются для обеспечения взаимодействия между сервером приложений и клиентом. Прокси помогают разработчикам быстро писать код для доступа к серверу приложений, так как все детали реализованы в прокси.

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

Web services client

Клиенты, написанные на множестве различных языках программирования (ABL, Java, C#, VB.NET, HTML), могут получить доступ к ABL-приложению через веб-сервисы, если это приложение было создано с возможностью предоставления веб-сервисов. Веб-сервис клиенты ABL работают в своей собственной ABL-сессии. Прочие же веб-сервис клиенты работают в клиентских процессах, реализованных на основе DLL или JVM.

На стороне сервера разработчик приложения должен создать (с помощью инструментов OpenEdge) некоторые артефакты, необходимые серверу приложений для предоставления сервисов с использованием протоколов SOAP или REST.

Когда вы используете PAS for OpenEdge, веб-сервис клиенты могут получать прямой доступ к серверу приложений через протокол HTTP/S. Сервер приложений PAS for OpenEdge также поддерживает доступ посредствам SOAP и REST.

Различают два типа веб-сервисов:

REST Web services. REST (Representational State Transfer) использует URI (Uniform Resource Identifier) для идентификации ресурсов и использования HTTP методов (GET, PUT, POST и DELETE) для работы с ресурсами. В качестве формата для обмена данными OpenEdge использует JSON (JavaScript Object Notation). REST Web сервисы в OpenEdge разворачиваются в REST Management Agent, который работает в экземпляре PAS for OpenEdge.
SOAP-based Web services. SOAP (Simple Object Access Protocol) использует XML-сообщения для обмена информацией между клиентским приложением и веб-сервисами. Вы должны использовать схему XML, рекомендуемую консорциумом World Wide Web (W3C) для описания простых и сложных типов данных в файлах WSDL (Web Services Description Language). Файлы WSDL публикуются и содержат описание публичного клиентского интерфейса к веб-сервисам, основанным на SOAP. В качестве транспорта для SOAP-сервисов используется HTTP. В OpenEdge такие сервисы развёртываются в адаптере WSA (Web Services Adapter), который работает в экземпляре PAS for OpenEdge.

Mobile client

Приложения OpenEdge Mobile состоят из мобильного приложения (Mobile App), мобильных сервисов и соответствующей бизнес-логики. Такие приложения имеют два архитектурных компонента:

Пользовательский интерфейс: в виде «родных» мобильных приложений (Mobile Native App), которые инсталлируются на мобильное устройство, и в виде мобильных веб-приложений, которые запускаются в веб браузере.
PAS for OpenEdge: размещение мобильных сервисов в качестве веб-приложения, к которым получает доступ мобильное приложение. Дополнительно здесь реализуется интерфейс мобильных сервисов и исполняется бизнес-логика. Интерфейс мобильного сервиса – это один или несколько ABL-ресурсов доступных через мобильные сервисы.

Для разработки мобильных приложений используется Progress Developer Studio for OpenEdge и Mobile App Builder. В Developer Studio создаются ABL-ресурсы, которые упаковываются в мобильные сервисы и публикуются на сервере приложений. В Mobile App Builder создаётся пользовательский интерфейс мобильного клиента и реализуется его связь с сервисами OpenEdge Mobile. Инструментарий Mobile App Builder также предназначен для упаковки мобильного приложения для соответствующих мобильных платформ, таких как iOS и Android, или в качестве веб-приложение для работы в браузере.

WebSpeed client

Клиент WebSpeed запускается в веб-браузере, он написан с использованием HTML и/или JavaScript. Этот клиент получает доступ к сервисам, размещенным на веб-сервере, используя HTTP или HTTPS. На стороне веб-сервера работают программа CGI (Common Gateway Interface) и WebSpeed Messenger. Роль WebSpeed Messenger заключается в получение запросов от клиентов WebSpeed и последующее перенаправление этих запросов к специальному типу сервера приложений, который называется WebSpeed Transaction Server, который и исполняет вариацию языка ABL, называемую SpeedScript.

В свою очередь, SpeedScript используется для предоставления сервисов клиентам и формирования HTML-страниц на веб-сервере для показа клиентам. Дополнительно WebSpeed Messenger может быть использован в качестве одиночного агента для получения запросов и показа статических HTML-страниц через веб-сервер.

SQL client

Клиент SQL – это процесс, который может исполняться SQL-механизмом для интерпретации SQL-операторов и использования их для получения доступа к серверу базы данных. Клиент SQL может работать в рамках различных типов процессов, таких как AVM, DLL и JVM. Такие клиенты получают доступ к серверу базы данных напрямую без применения серверов приложений. Обычно SQL-клиенты используются для управления базой данных и формирования отчетов для администраторов и некоторых бизнес-пользователей.

SQL-клиенты не используются для реализации какой-либо бизнес-логики приложения.

На этом у меня всё. В следующей статье вы познакомитесь с OpenEdge Reference Architecture.

Статья подготовлена по материалам Progress Education Community

Обучение