Что такое OpenEdge Reference Architecture (OERA)?

Из этой статьи вы узнаете о Progress OpenEdge Reference Architecture (OERA) и преимуществах её использования как основы для разработки приложений. Затем разберётесь, как приложение разбивается на слои, и узнаете о назначении каждого слоя в OERA.

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

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

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

Концепция OERA базируется на трёх ключевых принципах проектирования приложений:

Многослойность
Объектно-ориентированность
Сервис-ориентированность

Рассмотрим их.

Многослойное проектирование приложений

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

Некоторые части ABL-кода работают в рамках клиентских, а другие в рамках серверных процессов. На стороне клиента приложение представляет собой пользовательский интерфейс или внешних потребителей сервисов. На стороне сервера приложение предоставляет наборы сервисов для клиентов. Сервисы, предоставляемые клиентам, являются бизнес-логикой приложения вместе с бизнес-данными. Дополнительно могут существовать общие части приложения, которые могут использоваться как клиентскими, так и серверными процессами.

Объектно-ориентированное проектирование

Другой важный принцип, который использует OERA – это объектно-ориентированное проектирование. Стоит отметить, что основанные на OERA приложения можно создавать и без применения объектно-ориентированного программирования, тем не менее, в большинстве случаев объектно-ориентированное проектирование и реализация значительно способствуют повторному использованию кода. Благодаря такому подходу можно легко определить OERA-классы, которые моделируют варианты использования вашего приложения.

Пример. У вас в приложении может быть вариант использования, который выставляет клиенту счет или изменяет контактную информацию по клиенту. Вы определяете клиентский класс для обработки данных покупателя и ассоциированное с этим поведение для представления в пользовательском интерфейсе. Также вы определяете серверный класс, чтобы обработать данные покупателя и ассоциированное поведение, чтобы предоставить информацию о покупателе Клиенту в качестве сервиса и получить эти данные из базы данных. Обе части, и клиентская и серверная, в данном случае могли бы совместно использовать некоторые общие поведения (повторное использование кода), например такие, как проверка параметров безопасности.

Class MyApp.Customer
  Define private variable name as char no-undo.
  Define private variable id as int no-undo.
  Constructor public Customer(params):
    //code for creating object
  End Constructor.
  Method public char getName (id parm):
    //code for returning the name
  End Method.
End Class.

Сервис-ориентированное проектирование

В OERA также важно определить, как Клиенты взаимодействуют с серверными процессами. И лучший способ это реализовать – использовать сервисы. Если Клиенты могут получить доступ к бизнес-логике и бизнес-данным в виде сервисов, то бизнес-компоненты должны быть спроектированы так, чтобы предоставлять эти сервисы для более широкого спектра Клиентов.

Кроме того, поскольку бизнес-логика отделена от Клиентов, вы можете изменять её без оказания влияния на Клиентов, и наоборот, изменять Клиентов без влияния на бизнес-логику.

Слой OERA

Каждый слой приложения, основанного на OERA, играет свою роль, которая определяет его назначение и обеспечивает связь слоя с другими частями приложения. Благодаря взаимосвязям между слоями все части приложения объединяются в единое целое.

В следующей таблице представлены слои и их роли:

Слой	Роль
Business Components (Entity, Task, Workflow, Service Interface)	Реализует бизнес-логику
Data Access	Осуществляет инкапсуляцию бизнес-данных
Data Sources	Реализует доступ к физическим данным
Presentation	Реализует пользовательский интерфейс
Enterprise Services	Реализует внешний доступ к бизнес-компонентам
Common Infrastructure	Реализует код, который может быть использован различными частями приложения

Рассмотрим каждый слой подробнее.

Business Components

Слой Business Components в OERA представляет собой бизнес-логику приложения, который используется для предоставления информации Клиентам (слои Presentation и Enterprise Services). Именно здесь вы определяете, как ваши варианты использования реализуются конкретными функциональными возможностями в приложении.

В слое Business Components используются следующие основные строительные блоки:

Business Entities
Business Tasks
Business Workflows

Существует ещё один элемент – Service Interfaces, который используется для того, чтобы представить каждый из строительных блоков Business Components в качестве сервиса.

У всех элементов слоя Business Components существуют определённые обязанности и взаимосвязи друг с другом.

Business Entity

Прикладной компонент Business Entity (бизнес-сущность) определяет бизнес-логику вокруг наборов данных, представляющих интерес для одного или нескольких вариантов использования приложения. Каждая бизнес-сущность может получать доступ к другим бизнес-сущностям. Кроме того, бизнес-сущность подключается к бизнес-данным с помощью соответствующей части слоя Data Access. Если быть точным, то между бизнес-сущностью и кодом слоя Data Access существует соотношение один к одному (1:1).

Пример. Бизнес-сущность OrderEntity может получить доступ к бизнес-сущности с именем OrderDetailEntity. Бизнес-сущность OrderEntity также имеет доступ к соответствующему Data Access коду – OrderDA.

Бизнес-сущность может иметь разнообразные функциональные возможности, например:

Проверка данных
Управление изменениями в данных
Исполнение бизнес-логики
Поддержка транзакций

Доступ бизнес-сущности может осуществляться из разных слоёв OERA. Бизнес-сущность предоставляет необходимые интерфейсы для доступа к её данным и бизнес-логике. Такой подход более удобен чем, реализовать одно и тоже описание данных и одинаковую бизнес-логику одновременно в разных частях приложения. В итоге, в случае изменения требований к бизнес-приложению, вам достаточно внести соответствующие корректировки только в одном месте.

Business Task

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

Transaction scoping
Координация изменений между различными бизнес-сущностями
Исполнение бизнес-логики
Завершение или отмена задачи

К бизнес-задачам могут иметь доступ компоненты Business Workflow, а также слои Presentation и Enterprise Services. Доступ осуществляется только через компонент Service Interface.

Business Workflow

Компонент Business Workflow (далее, бизнес-процесс) – это часть приложения, которая использует множество бизнес-задач для реализации варианта использования приложения. Обычно работа бизнес-процесса растянута во времени, и включает в себя несколько участников. Участниками бизнес-процесса могут быть конечные пользователи или системы. Бизнес-процесс содержит специальную логику для управления порядком выполнения бизнес-задач и их статусом, например, завершилась ли бизнес-задача успешно или нет. Кроме того, бизнес-процесс может стартовать другие бизнес-процессы.

Доступ к бизнес-процессам может осуществляться из слоев Presentation и Enterprise Services. Любой доступ к бизнес-процессу осуществляется через Service Interface. Также через Service Interface сам бизнес-процесс получает доступ к бизнес-сущностям и бизнес-задачам.

Service Interface

Компонент Service Interface обеспечивает доступ из прочих частей приложения к конкретным бизнес-сущностям, задачам и процессам. При этом некоторые компоненты слоя Business Components могут получать доступ к бизнес-сущностям напрямую без использования Service Interface. Из слоёв Presentation и Enterprise Services доступ к Service Interface осуществляется с помощью сервисных адаптеров (Service Adapter), о которых вы узнаете немного позже.

Фактически, Service Interface определяет, как слои OERA получают доступ к функциональности слоя Business Component через сервисы. Этот компонент определяет имя сервиса и типы параметров необходимых для запроса к сервису. Например, если у вас есть бизнес-сущность с именем CustomerEntity, то у вас может быть определено два компонента Service Interface для получения данных о покупателе, один, который запрашивает в качестве параметра имя покупателя, а другой в качестве параметра запрашивает ID покупателя.

При использовании Service Interface, в случае изменений требований к клиентской части, вам достаточно изменить схему сопоставления данных в интерфейсе сервиса без необходимости изменения бизнес-компонент. Service Interface также предоставляет специальные места для подключения «хуков» к сервисам из общей инфраструктуры (Common Infrastructure) так, чтобы они срабатывали последовательно и, в большинстве случаев, автоматически.

Data Access

Код, реализуемый на уровне слоя Data Access ассоциирован с соответствующей бизнес-сущностью и определяет, как осуществляется доступ к бизнес-данным. Различают несколько типов доступа к данным: для извлечения, для создания и для обновления. При этом, используя слой Data Access, бизнес-сущность может получать доступ к данным из нескольких источников. Например, для реализации слоя DataAccess с именем OrderDA для бизнес-сущности OrderEntity необходимо использовать несколько источников данных (Data Source). В этом случае с помощью ABL DataSets можно объединить данные из множества источников.

Data Sources

Слой Data Source (источники данных) исполняет необходимый код для извлечения, обновления и создания данных из/в физических источников, доступных для ABL-приложения. Такими ресурсами могут быть как непосредственно OpenEdge, так и сторонние базы данных, XML-документы и очереди сообщений (Message Queues). Применение источников данных упрощает получение доступа и обновление физических данных через слой Data Access. С помощью источников данных также можно сопоставлять поля из бизнес-сущностей с полями из исходного физического хранилища данных.

Слои Data Access и Data Source вместе формируют единую точку, в которой описывается соответствие между физическими данными и внутренним логическим форматом. В случае изменения источника данных, только эта часть приложения должна быть изменена.

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

Presentation

Презентационный слой (Presentation layer) представляет собой пользовательский интерфейс для Клиентов OpenEdge в вашем приложении. Этот слой взаимодействует с слоем Business Components для получения и отображения данных конечным пользователям. Презентационный слой, являясь отдельным клиентским процессом, использует общую для многих пользовательских интерфейсов архитектуру MVP (Model-View-Presenter). MVP – это шаблон проектирования пользовательского интерфейса, который был разработан для облегчения автоматического модульного тестирования и улучшения разделения ответственности в презентационной логике (отделения логики от отображения). Шаблон включает в себя следующие компоненты:

Модель (англ. Model) – представляет собой интерфейс, определяющий данные для отображения или участвующие в пользовательском интерфейсе иным образом.
Представление (англ. View) – это интерфейс, который отображает данные (Модель) и маршрутизирует пользовательские команды (или события) Presenter-у, чтобы тот действовал над этими данными.
Presenter действует над Моделью и Представлением. Он извлекает данные из хранилища (Модели) и форматирует их для отображения в Представлении.

Презентационный слой также включает в себя набор компонент сервисного адаптера (Service Adapter), каждый из которых имеет доступ к бизнес-компонентам (Business Components) через сервисные интерфейсы (Service Interface).

Model

Компонент Модель определяет и управляет клиентской версией бизнес-сущности. Для каждой бизнес-сущности к которой получает доступ Клиент, должны существовать соответствующие клиентские бизнес-сущности (Client Business Entity). Иными словами, для работы Клиента каждая клиентская бизнес-сущность должна воспроизводить тот же тип данных, что имеет бизнес-сущность на сервере. Компонент Модель предоставляет данные для Представления (View) и управляет данными для Presenter-а. Модель также получает доступ к бизнес-компонентам через специализированные сервисные адаптеры, которые в свою очередь написаны для вызова определённых сервисных интерфейсов.

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

View

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

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

Presenter

Компонент Presenter координирует данные Модели и события между различными элементами Представления. Этот компонент можно рассматривать как связующее звено между Моделью и Представлением.

Общая логика в Presenter-е (например, какие операции должны быть выполнены в зависимости от типа события) должна быть многократно используемой, чтобы её можно было применить к различным Представлениям.

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

Service Adapter

Компонент сервисный адаптер (Service Adapter) позволяют Клиентам OpenEdge и промышленным сервисам (Enterprise Services) получать доступ к бизнес-компонентам. Каждый сервисный адаптер специфичен для конкретной реализации слоев Presenter и Enterprise Services. Чтобы получить доступ к бизнес-сущности, задаче или рабочему процессу, Клиент OpenEdge должен сделать запрос на обслуживание через сервисный интерфейс. Каждый тип Клиента имеет собственный сервисный адаптер, который соответствует вызываемому сервисному интерфейсу. Сервисный адаптер позволяет изменять вызывающую последовательность или формат данных для запроса без необходимости изменения любого кода за исключением того, что определен в конкретном адаптере. Он также может быть использован для обнаружения сервиса во время выполнения.

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

Enterprise Services

Слой Enterprise Services обеспечивает поддержку внешних OpenEdge Клиентов (не ABL), которые не поддерживают пользовательский интерфейс непосредственно. Поскольку цель приложения, разработанного на основе принципов OERA, состоит в том, чтобы представлять в виде сервисов бизнес-сущности, задачи и рабочие процессы, то вы можете рассматривать внешних OpenEdge Клиентов как процессы, которые запрашивают эти сервисы для получения доступа к бизнес-логике или к бизнес-данным приложения.

Большая часть кода для слоя Enterprise Services написана на языке отличном от ABL. Также как вы пишите сервисные адаптеры для презентационного слоя, вы должны написать отдельный сервисный адаптер для части вашего приложения, которая представляет слой Enterprise Services.

Common Infrastructure

Слой общей инфраструктуры (Common Infrastructure) отвечает за предоставления общей функциональности для других слоёв, которая может быть следующей:

обеспечение безопасности;
поиск ресурсов;
запуск процедуры;
трансформация данных;
предоставление контекстной информации.

Такая функциональность может понадобиться для слоёв Presentation, Enterprise Services и Business Components. В идеале, вы должны разделить приложения на части так, чтобы иметь возможность использовать одну и ту же функциональность в разных слоях. Простой пример некоторых элементов (в данном случае Менеджеров), которые могут быть представлены в вашем слое общей инфраструктуры:

Configuration Manager – может отвечать за данные, которые используются для запуска и управления сервисами, работающими в приложении. Это процесс времени выполнения (runtime), который используется всеми слоями.
Service Manager – отвечает за использование информации, предоставляемой менеджером конфигурации, для исполнения задания по поиску, старту останову и предоставлению доступа к бизнес-компоненту.
Authorization Manager – отвечает за подтверждение наличия доступа к запрашиваемой информации.
Authentication Manager – отвечает за все аспекты проверки идентификационных данных пользователя и предоставление необходимой информации в другие сервисы для подтверждения.
Context Manager – отвечает за отслеживание различных типов контекстной информации, которая необходима приложению.

Применение OERA в проектировании приложений

Как архитектор или разработчик, вам необходимо определить, какие части вашего приложения будут следовать принципам проектирования OERA, которые рекомендует Progress Software. Для начала вам необходимо собрать все требования к приложению. Если у вас уже есть готовые части приложения, то необходимо решить, будете ли вы их модернизировать в соответствии с OERA. Для того, чтобы правильно разделить приложение на бизнес-компоненты, вы должны задокументировать каждый вариант его использования. В идеале, варианты использования должны быть основой для проектирования бизнес-компонент.

Множество Progress-разработчиков используют OERA при проектировании своих приложений. Поэтому на основе их опыта мы рассмотрим разработку приложения в рекомендуемом порядке, о котором и пойдет речь дальше.

Факторы, влияющие на дизайн приложения

Во время проектирования приложения необходимо ответить на следующие вопросы:

На какой платформе будет работать ваше приложение? От этого будет зависеть, как вы будете писать код.
Какая процессорная архитектура будет использована? AppServer-а, WebSpeed Transaction Server-а и Database Server-а будут работать на разных хостах? Если используются сервера приложений, как вы определите, какая часть приложения будет работать на конкретном AppServer-е?
Каковы требования к обеспечению безопасности? Вам необходимо учесть эти требования в приложении.
Есть ли требования для обеспечения multi-tenancy для доступа к данным? Если есть, то необходимо учесть это в программном коде приложения.
Каковы требования к обеспечению доступности приложения? Вы должны гарантировать, что ваше приложение будет доступно для бизнеса. Возможно, вам понадобиться включить в приложение механизмы восстановления после сбоев.
Есть ли какие-либо специальные требования к развертыванию или к настройке, которые должны быть включены в приложение? Будет ли приложение разворачиваться в Облаке?
Как приложение будет обслуживаться? Будет ли возможность обслуживание по частям? От этого может зависеть, как вы структурируете код приложения и упакуете его.

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

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

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

OpenEdge

Что такое OpenEdge Reference Architecture (OERA)?

Многослойное проектирование приложений

Объектно-ориентированное проектирование

Сервис-ориентированное проектирование