Перед нами стояла архитектурная задача – разработать ИС для центра дополнительного и безотрывного образования по ИТ ИКИТ. На старте мы выявили несколько проблем:

• бизнес-процессы не до конца поставлены;
• бизнес-процессы будут меняться в ближайшем будущем.

Следовательно, необходимо определиться с архитектурой, которая позволит нам безболезненно внедрять изменения в ИС.

Мы рассмотрели несколько подходов к разработке КИС: традиционный и сервис-ориентированный. Первый подход реализовывается следующими этапами:

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

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

Второй подход подразумевает, что наше приложение будет состоять из набора независимых сервисов [2], каждый из которых реализует отдельную бизнес-функцию, которая является логически обособленной, повторяющейся задачей, являющейся составной частью бизнес-процесса предприятия. Более того, сервисы могут быть реализованы независимо от языков программирования и других технических особенностей реализации, что дает возможность использовать различные технологии и фреймворки. Также сервисы могут быть написаны в независимости от других служб системы, необходимо только знание интерфейса используемых сервисов, то есть службы будут слабосвязанные (loose coupling) [3].

Мы прогнозируем изменения в КИС в ближайшее время. Например, учиться будут не только студенты, но и работники предприятий. В перспективе допустим выход системы как продукта (система для повышения квалификации). Поэтому выбор пал на сервис-ориентированную архитектуру.

Иными словами, мы выделили следующие достоинства данного подхода:

• отсутствие дублирования кода;
• независимость от языка программирования;
• низкая связанность.

В ходе реализации мы столкнулись с технической особенностью ASP.NET MVC, а именно: в данной технологии используются строго типизированные представления. Однако, в большинстве случаев нам необходимы не все поля из источника данных, и необходимы другие, например, вычисляемые. Поэтому возникла необходимость использования собственной клиентской модели. Данные, которые приходят извне, конвертируются посредством сервисов в нашу модель. Это позволяет нам писать логику в контроллерах и верстать представления независимо от того, какие данные мы изначально получаем.

Учитывая все вышеперечисленные особенности, мы решили совместить подход EAI (Enterprise Application Integration) и SOA (Service-Oriented Architecture). Суть подхода EAI Hub/Spoke заключается в использовании централизованного брокера (Hub) и адаптеров (Spoke), которые соединяют приложения с хабом. Spoke присоединяются к приложениям и преобразовывают данные приложения в формат, который понимает хаб и наоборот. Это и позволит решить поставленную задачу.

Рисунок 1.  Архитектура EAI Hub/Spoke.

В результаты комбинации двух подходов EAI и SOA, мы получили следующие преимущества:

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