+7 (495) 956-79-28
Демо-версия клиента под BlackBerry
Версия для печати
Главная / Пресс-центр / Статьи и интервью / Архитектура CompanyMedia: все как в вебе
Статьи и интервью

Архитектура CompanyMedia: все как в вебе

30.03.2012

Автор: Станислав Макаров
Источник: информационный портал "CNews"
Дата публикации: 15.03.2012

Архитектура определяет все будущие возможности системы: насколько она будет масштабируемой, производительной, гибкой, и в итоге — насколько успешной на рынке. Поэтому архитекторы просто обязаны заложить все ее будущие возможности еще на "нулевом" цикле разработки. Как же это было сделано в новой CompanyMedia?

Архитектура CompanyMedia: все как в вебе

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

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

Противоречия — двигатель творческого процесса

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

Многоуровневая архитектура CompanyMedia

Если обратиться конкретно к CompanyMedia, то ее успех на рынке был тесно связан с довольно широким распространением платформы Lotus Notes, которая на момент своего появления была действительно революционной. При этом нельзя сказать, что CompanyMedia есть всего лишь какая-то программа на Lotus Notes. За более чем 15 лет ее развития разработчики "Интертраст" накопили обширную экспертизу в предметной области, которая объединяет в себе традиционный российский подход к управлению документами и поручениями и дух коллективной работы Lotus Notes, не связанной бюрократическими условностями.

Вследствие этого CompanyMedia обладает несколькими качествами, которые отличают ее от других СЭД. Во-первых, изначально базовым объектом в системе является документ, а не запись в базе данных. Затем, представления (View) реализованы на уровне платформы. Это дает очень гибкие возможности навигации и просмотра документов. Кроме того, функции управления оргструктурой и пользователями реализованы в CompanyMedia наиболее полно по сравнению с другими СЭД.

К сожалению, при всех своих архитектурных преимуществах, платформа Lotus Notes не смогла стать стандартом де-факто. Анализ причин, по которым это произошло, не входит в нашу задачу.

Два ответа на банальный вопрос

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

Можно выбрать и другой путь: сделать ставку на нового лидера рынка, мобилизовать все ресурсы и выполнить миграцию своей системы на новую платформу, попытавшись при этом сохранить старых клиентов и завоевать новых.

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

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

Кроме того, далеко не все старые клиенты выскажут готовность перейти на новую платформу, какая бы она ни была. Следовательно, придется поддерживать оба решения, а это еще более усугубит финансовую ситуацию.

Затем, не стоит забывать о конкуренции. На новом рынке придется заново завоевывать себе репутацию и нарабатывать клиентскую базу. Старые заслуги обычно в зачет не идут.

И, наконец, новая платформа может тоже утратить лидерство и история вновь повторится. В сверх-динамичном мире ИТ это вполне возможно.

В общем, сформировался клубок неразрешимых, казалось бы, противоречий. В "Интертраст" хорошо понимали недостатки обоих вариантов и продолжали искать решение, которое позволило бы выйти из этой ситуации. И однажды такая идея появилась.

Знания в предметной области не зависят от ECM-платформы

Итак, опыт в документообороте у "Интертраст" был накоплен солидный, но идти по пути создания линейки приложений под разные платформы, как поступили некоторые конкуренты, компании не хотелось. Компания пыталась найти архитектурное решение, которое позволило бы максимально использовать наработанную экспертизу и при этом избежать зависимости от платформы.

Вспоминает Владимир Панов, главный архитектор "Интертраст": "Это было лето 2010 года. Мы сидели в беседке возле офиса и обсуждали архитектуру будущей CompanyMedia. Все уже понимали, что дальнейшая ориентация исключительно на Lotus Domino заведет нас в тупик. Тогда как раз вышел стандарт CMIS, который показался нам очень интересным. Как пришла эта идея – сделать СЭД независимой от хранилища и работать с любыми ECM-платформами – уже сложно сказать, но она всем понравилась.

Конечно, это другие риски и другой объем работы, никто так не делает, ни одной системы в подобной архитектуре лично мне неизвестно. Иногда бывают интеграторские проекты с использованием CMIS, но не промышленные системы".

Сам стандарт CMIS тогда был еще недостаточно проработан, отсутствовала практика проектов, поэтому взять его за основу архитектуры системы было рискованно.

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

Если для собора 100 лет на строительство - это нормально, ведь любой приличный храм должен строиться лет двести-триста, то для информационных систем такой подход не годится

Если для собора 100 лет на строительство - это нормально, ведь любой приличный храм должен строиться лет двести-триста, то для информационных систем такой подход не годится

Подробнее: http://opendev.cnews.ru/reviews/index.shtml?2012/03/30/483799_2

Если для собора 100 лет на строительство - это нормально, ведь любой приличный храм должен строиться лет двести-триста, то для информационных систем такой подход не годится

Сейчас разработка новой CompanyMedia идет полным ходом, приоритетность включения ECM-платформ в число поддерживаемых определяется, в первую очередь, пожеланиями крупных заказчиков, которые по разным обстоятельствам собираются мигрировать с Lotus Domino кто на IBM FileNet, кто на OpenText. Технически нет видимых препятствий обеспечить поддержку Documentum, Alfresco или Oraсle.

Бизнес-процессы определяют работу СЭД

Ядро системы – это ее бизнес-логика, от реализации которой зависит функциональность и производительность системы. CMIS не был единственным стандартом, который повлиял на развитие архитектуры CompanyMedia, в части описания бизнес-процессов разработчики "Интертраст" решили следовать стандарту BPMN.

По словам Владимира Панова, за счет выноса бизнес-логики в отдельный модуль ее стало возможным реализовать более универсально, расширяемо и так далее. В это время как раз стал популярным BPMN (версия 1.2 вышла в январе 2009). И уже в мире в целом накопилась некоторая экспертиза – еще не в России, а за рубежом.

"BPMN 2.0 собственно впервые решил проблему исполняемых процессов, формализуемых в такой нотации. (Разработка версии 2.0 шла давно, вышла в январе 2011 г.) Она оказалась достаточно развитой, но не настолько сложной, чтобы ей не мог никто пользоваться, и в то же время достаточно выразительной, чтобы определять исполняемые процессы. А у нас уже был опыт с предыдущей версией. И тут появилась почти уверенность, что на этой основе мы сможем реализовывать свою бизнес-логику, сделать ее более универсальной и расширяемой", - рассказывает эксперт.

После внимательного изучения рынка движок бизнес-процессов было решено оставить собственный. Ведь этот компонент фактически и содержит в себе всю экспертизу, все знания в предметной области, которые позволили"Интертраст" создать образ профессиональной и ответственной команды. Разработчики посчитали, что переписывать все наработки на каком-то внешнем средстве класса BPM было бы нерационально.

Людей встречают по одежке, а системы — по пользовательскому интерфейсу

Заказчики в один голос требовали веб-интерфейс. И при этом они хотели, чтоб этот интерфейс был бы настолько же быстрым и функциональным, как привычный декстоп Windows. Конечно, это не вопрос дизайна, это вопрос архитектуры. Конечно, у CompanyMedia уже был веб-интерфейс, но пользователей он не удовлетворял. И это не была вина разработчиков, веб-решения первой волны все были несколько неуклюжими вследствие неразвитости стандартов и технологий.

Как рассказывает Владимир Панов, сначала разработчики обратили внимание на HTML5, еще один стандарт, набирающий популярность. У Adobe Flex в процессе дотошных исследований были найдены определенные проблемы, не фатальные, но неприятные. С другой стороны, HTML5 быстро развивался, стала возможной разработка Rich Internet Application, RIA.

Было понятно, что клиент должен быть интерактивным, это требование остается. Но его реализация стала возможна чисто браузерными средствами, без технологий типа Flash или Flex. И дальше осталось выбрать платформу для разработки. В итоге остановились на Google Web Toolkit, GWT, но не сразу.

Функциональный дизайн системы и внешний вид "Интертраст" разрабатывал в сотрудничестве со "Студией Артемия Лебедева". Такой выбор партнера объясняется отнюдь не желанием поразить своих заказчиков или пустить им пыль в глаза. От дизайнеров ждали не просто красивые картинки, а систему, которой людям удобно будет пользоваться. Кстати, вот как выглядит кликабельный макет будущей CompanyMedia.

Интероперабельность нужна обязательно

Сейчас "Интертраст" активно развивает веб- и мобильный клиенты. Но их спектр может и расширяться. Архитектура сервера должна строиться так, чтобы при появлении нового клиента не возрастали нагрузки на сервер. Новые версии СЭД CompanyMedia будут строиться по принципу сервисно-ориентированной архитектуры, СОА с использованием концепции Representational State Transfer, REST, это стиль архитектуры программного обеспечения для распределенных гипермедиасистем, подобных Всемирной паутине.

Как прокомментировал Владимир Панов, гипертексты и гипермедиа изначально организованы по принципам REST. Информационная система в этом случает строится по-другому, она состоит из клиентов и серверов (не в аппаратном, а чисто в логическом смысле). Клиенты инициируют запросы к серверам; серверы обрабатывают запросы и возвращают подходящие ответы. Запросы и ответы создаются на базе передачи представлений ресурсов. Он может являться практически любым понятным и значимым адресуемым объектом. Представление ресурса — это обычно документ, отражающий текущее или требуемое состояние ресурса. Весь этот механизм реализуется в протоколе HTTP.

И получалось, что много лет, с начала 2000-х интернет в значительной степени использовали неправильно, нарушая постоянно, сплошь и рядом, изначальный архитектурный подход REST.

В системе CompanyMedia больше ресурсов, чем где бы то ни было (в том смысле, как подразумевает REST). Эксперт уверен, что на принципах REST компании удастся построить более открытую клиент-серверную архитектуру. Спецификация REST API для CompanyMedia 4/5 будет опубликована по адресу: https://sup.inttrust.ru:8446/prjdocs/cmj/specs/internal/rest.html.

 
Подписка на новости
Ваш E-mail
вернуться наверх