Общие сведения

	Департамент информационных технологий города Москвы
Требования к типовой архитектуре приложения Листов Версия 1.2
Москва, 2013

Общие сведения

1. Цель документа

2. Назначение документа

3. Область применения

4. Ограничения и допущения

1. Связанные документы

1. 
   Основные архитектурные принципы, М. 2013
   

2. Термины, определения и аббревиатуры

3. Требования к структуре приложения

   1. Типовая структура приложения

1. 
   Презентационный слой
   
2. 
   Слой бизнес-логики
   
3. 
   Слой хранения данных
   

2. Назначение слоев

   1. Презентационный слой

• 
  реализует интерфейс, позволяющий клиенту взаимодействовать с приложением
  
• 
  взаимодействует со слоем бизнес логики, где собственно и сосредоточена основная логика приложения
  

• 
  “тонкий” клиент – программное обеспечение, функционирующее в среде интернет browser’а и отрисовывающее свой интерфейс средствами HTML, JavaScript и CSS;
  
• 
  “толстый” клиент – программное обеспечение, функционирование которого обеспечивается непосредственно операционной системой (без промежуточного ПО) и для отрисовки интерфейса такого обеспечения используются средства ОС
  

2. Слой бизнес-логики

3. Слой хранения данных

4. Общие требования к проектированию приложения

• 
  Логическая независимость. Слои должны быть слабо связаны (взаимодействовать друг с другом на уровне интерфейсов) и обеспечивать возможность модификации какого-либо слоя без внесения изменения в другие слои.
  
• 
  Физическая независимость: Физическая независимость должна обеспечить возможность независимого развертывания программного обеспечения разных слоев на различном оборудовании.
  

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

5. Требования к компонентам слоев приложения

   1. Требования к компонентам презентационного слоя

1. 
   Компоненты презентационного слоя должны отображать представление пользовательского интерфейса, сформированное либо непосредственно на клиентском слое (Desktop, мобильное приложение), либо полученное со слоя презентационной логики (WEB приложение, работающее через Internet browser)
   
2. 
   Компоненты презентационного слоя для WEB приложений не должны быть ориентированы на конкретный Internent browser и должены быть совместим с большинством широко используемых browser’ов последних версий - IE, Chrome, Firefox, Safari.
   
3. 
   В состав презентационного слоя для WEB приложений не должны входить компоненты, специфичные для конкретной операционной системы (например, ActiveX компоненты)
   
4. 
   Компоненты презентационного слоя, реализованные в виде “толстого” клиента должны иметь встроенные возможности по автоматическому обновлению версий. Возможно использование внешних, по отношению к компонентам клиентского слоя, решений, реализующих функционал автоматического обновления версий (решений, аналогичных Web Start).
   
5. 
   Компоненты презентационного уровня должны представлять собой исключительно слой визуализации и не содержать бизнес – логики.
   
6. 
   Компоненты презентационного слоя могут непосредственно взаимодействовать только с компонентами слоя бизнес – логики
   
7. 
   Компоненты презентационного слоя для WEB приложений, размещенные на серверной стороне приложения должны быть развернуты внутри контейнера, который обеспечивает сервисы, связанные с масштабированием, сетевым взаимодействием, информационной безопасностью и пр.
   
8. 
   При создании компонент презентационного слоя необходимо использовать программные стандартные технологии презентационного уровня
   
9. 
   При обслуживании клиентов не следует допускать неконтролируемого роста числа потоков операционной системы, запускаемых для обработки клиентских вызовов. Должна быть возможность ограничения числа одновременно запущенных потоков путем настроек и переиспользования уже существующих потоков (пул потоков)
   
10. 
    Операции, требующие длительного времени на обработку, должны выполняться асинхронно. Задача передается на уровень бизнес – логики, а клиент уведомляется о том, что его запрос принят в обработку. По завершению выполнения задачи клиент тем или иным образом уведомляется об этом. Таким образом, ресурсы, используемые для обслуживания данного запроса, могут быть освобождены и переиспользованы для обслуживания других запросов.
    
11. 
    При взаимодействии клиентского устройства с серверной частью приложения должна решаться задача минимизации сетевого трафика. Снижение объема сетевого трафика должно осуществляться как за счет минимизации собственно объем передаваемой информации (например, за счет кэширования информации на устройстве клиента), так и за счет выбора соответствующего протокола обмена информацией между клиентским устройством и серверной составляющей решения (например, использовать JSON, а не XML).
    

1. Требования к компонентам слоя бизнес-логики

1. 
   Компоненты слоя бизнес-логики взаимодействуют с компонентам презентационного слоя и слоя данных
   
2. 
   Компоненты слоя бизнес – логики должны размещаться внутри контейнера, который обеспечивает сервисы, связанные с масштабированием, сетевым взаимодействием, информационной безопасностью и пр.
   
3. 
   Компоненты слоя бизнес – логики строятся с учетом их переиспользования. Одни и те же компоненты слоя бизнес – логики могут взаимодействовать как с различным компонентами презентационного слоя, так и быть преиспользованы различными приложениями (посредством интеграционных решений)
   
4. 
   Для обеспечения логической независимости (см. п. “Общие требования” данного документа), реализация взаимодействия со слоем хранения должна быть выделены в отдельные компоненты, которые и будут подлежать переработке в случае изменения слоя данных (другие компоненты слоя бизнес – логики при этом останются без изменений)
   
5. 
   Взаимодействие слоя бизнес – логики, со слоем данных должно быть ориентировано на оптимизацию процесса взаимодействия с точки зрения производительности. Следует организовывать кэширование информации и оптимизировать процессы взаимодействия со слоем данных путем недопущения неконтролируемого роста количества соединений между слоем бизнес логики и слоем хранения и переиспользования (в случае возможности) уже открытых соединений (пулы соединений).
   

1. Требования к компонентам слоя хранения

1. 
   Компоненты слоя данных взаимодействуют с компонентами слоя бизнес - логики
   
2. 
   Для доступа к данным следует использовать стандартные протоколы доступа (например: SQL для реляционных баз данных, CMIS для систем управления контентом (ECM)). Должно быть минимизировано использование расширений к стандартам на доступ к информации, предлагаемых вендорами, ровно, как и проприетарных протоколов и языков для работы с данными, присущих конкретным продуктам конкретного вендора.
   
3. 
   Структура данных операционных приложений должна быть оптимизирована под задачи бизнес-процессов, поддерживаемых приложением и проектироваться исходя из типовых запросов, специфичных для конкретной системы
   
4. 
   Для реляционных баз данных должна использоваться высокая степень нормализации: 3-я нормальная форма и выше
   
5. 
   Организация данных должна быть ориентирована на поддержку выполнения большого количества транзакций в единицу времени. Система хранения должна быть оптимизирована для обработки в ходе транзакций небольших объемов информации за минимальное время
   
6. 
   Историчность данных допустима только на такую глубину, которая требуется для поддержки операционного процесса.
   

6. Типовая модель приложения

1. 
   Функции приложения должны быть сгруппированы в функциональные компоненты приложения, каждый из которых должен работать независимо от других функциональных компонентов приложения
   
2. 
   Общие функции должны быть сосредоточены в выделенных общих инфраструктурных компонентах приложения (компоненты ядра, компоненты доступа к базе данных и т.д).
   
3. 
   Выделяются типовые не функциональные компоненты приложения, реализующие следующие функции:
   

• 
  Обеспечение безопасности приложения
  
• 
  Осуществление мониторинга и логирования
  
• 
  Администрирование
  
• 
  Интеграции с внешними системами (АПИ)
  

1.1.функциональные компоненты.

1.2.Типовые не функциональные компоненты.

1. Безопасность

2. Мониторинг и логирование

3. Администрирование

4. Интеграция с внешними системами

1. 
   Посредством реализации компонентов прикладного программного интерфейса (Application Program Interface - API) Компоненты API должны реализовать интерфейс доступа к функциям приложения для внешних систем и обеспечить интеграцию в ИТ ландшафт Москвы без переделки остальных компонентов приложения. Компоненты API должны поддерживать такие протоколы взаимодействия, как SOAP/HTTP, JMS и другие. другими приложениями
   
2. 
   Посредством реализации специальных интерфейсных компонентов на уровне слоя хранения. Данные компоненты предназначены для поддержки ETL процессов при интеграции приложений с централизованными репозиториями данных. Интерфейсные компоненты слоя данных должны быть стабильны по своей структуре для обеспечения независимости ETL процессов от изменений в структурах данных слоя хранения приложения.
   

1.3.Требования к Типовым не функциональным компонентам.

1. Требования к компонентам безопасности

1. 
   Компоненты слоя безопасности должны реализовывать функции управления доступом пользователей к приложению, а также функции идентификации, аутентификации авторизации и защиты обрабатываемых данных.
   
2. 
   Компоненты слоя безопасности должны обеспечивать аудит действий пользователя
   
3. 
   Специфика взаимодействия приложения с используемой платформой LDAP должна быть инкапсулирована посредством компонент слоя безопасности
   
4. 
   Посредством компонент слоя безопасности приложение должно быть интегрировано с общегородской системой СУДИР
   

6. Требования к компонентам мониторинга и логирования