Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

22.02.2019

Новости:


Все новости

Интеграционные платформы, Точка зрения

Интеграция приложений такая, как она есть

Необходимые пояснения

Не с большой охотой взялся автор за написание этой статьи — уж больно избитой кажется тема; по поводу интеграции не рассуждает сейчас разве что ленивый. Здесь во всей красе провоцируется мифотворчество, процветает необоснованный оптимизм, вызывающий напрасные надежды, пропагандируется легковесный подход к исключительно сложным технологическим проблемам. Количество «белого шума» на тему интеграции достигло таких размеров, что никак не может оставить здравомыслящего специалиста в стороне. Свой удручающий вклад вносят производители интегрирующего программного обеспечения, зачастую рекламирующие свои «уникальные» программы интеграции примерно так же, как рекламируются зубная паста и фруктовые соки. Если сбросить с этой темы вполне объяснимый маркетинговый флер, то картина складывается примерно следующая.

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

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

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

Им это было не нужно. Они решали частную функциональную задачу, и постарались решить ее лучше, чем конкуренты, за что им честь и хвала. Более того, часто делалось так, чтобы интеграция разработанного приложения с внешним миром была как можно больше усложнена, а если и разрешалась, то только за счет опять же частных средств, придуманных компанией-разработчиком, в ущерб открытым стандартам интеграции. Разработчики приложений специально делали свои приложения такими, чтобы, если кто-то и захотел интегрировать их с другими, то обязательно снова обратился бы к разработчику. Никто и не думал при разработке приложения, что оно станет частью какого-то большого процесса! Скажите, ломал ли автор популярной финансовой программы голову, чтобы сделать так, чтобы программа эта максимально просто интегрировалась бы в другие большие системы? Уверен, что нет: это противоречит интересам бизнеса, в интересах разработчика распространять свой продукт, а не потворствовать распространению чужого. Интересы бизнеса были и всегда останутся выше любых технологических соображений.

Но если уж разработчики большинства существующих ныне приложений сознательно (разумеется, не афишируя этого) шли не на открытие, а на обособление своих систем и заранее позаботились о том, чтобы сделать такую интеграцию максимально сложной — о какой интеграции мы говорим, когда сам интегрируемый объект сделан так, чтобы не быть интегрируемым?

Дело в «больном», а не в «лекарстве». Для объяснения причин сложности интеграции приложений воспользуемся метафорой, уподобив приложения, подлежащие интеграции, больному, которого нужно «поставить в строй», а интегрирующее программное обеспечение — лекарству, которое это призвано сделать. В ком (или в чем) здесь дело? Некоторые считают, что универсальное лекарство существует, его нужно только найти — и случится чудо, больной станет здоровым и начнет общаться с другими людьми. Мы же, руководствуясь традиционным консерватизмом и здравым смыслом, считаем, что нужно не изобретать универсальные лекарства, а сосредоточиться на больном и понять, что не дает ему возможность принимать участие в полноценном диалоге с другими людьми. Чтобы решить эту задачу, нужно проанализировать анатомию типового приложения и понять, что же в этой анатомии нехорошо? Но для анализа необходим критерий интегрируемости приложений.

Критерий интегрируемости приложений

Представим, что вдруг кто-то, в какие-то времена (не обязательно сейчас, это могло быть и несколько лет назад) вдруг решил бы разработать свое собственное приложение таким образом, чтобы оно было максимально интегрируемым в некие глобальные приложения, на тот момент неизвестные и неопределенные. Что можно было бы посоветовать такому разработчику?

В первую очередь, вне зависимости от внутренней архитектуры приложения, этот человек должен был бы позаботиться о том, чтобы весь значимый прикладной функционал был доступен программно. На практике это означало бы, что для выполнения любой значимой внешне доступной прикладной операции можно было бы написать на любом (максимум) или на одном (минимум) языке программирования программу. Однако для этого данное приложение должно быть оснащено интерфейсом прикладного программирования (Application Programming Interface, API); будем для краткости называть его в рамках этой статьи программным интерфейсом. Таким образом, мы приходим к понятию индекса качества программного интерфейса. Его можно измерять в диапазоне от нуля до единицы, от полного отсутствия какого бы то ни было программного интерфейса до наличия исчерпывающе полного (в смысле доступности прикладной функциональности) программного интерфейса.

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

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

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

Анатомия приложений

Анализ внутренней конструкции приложений — обязательный этап в оценке степени интегрируемости тех приложений, которые предполагается связывать в рамках того или иного проекта. Этот анализ усложняется тем, что обычно разработчики приложений стараются скрыть детали внутренней конструкции приложений от интегратора (строго говоря, они и не обязаны ничего предоставлять интегратору), так как обладают авторским правом на разработанный ими программный продукт и от них никто и ничто (кроме советских ГОСТов) не требует предоставлять даже программный интерфейс, не говоря уже об анатомии приложения. Тем не менее, определенные заключения по анатомии приложения сделать все-таки можно и нужно.

История болезни

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

Сценарий был таким. Архитектура «клиент-сервер», какая-то СУБД, какое-то средство быстрой разработки приложений, быстро спроектировали базу данных, разработали экранные формы с помощью соответствующего дизайнера, а затем сгенерировали коды для обработки данных на основе связывания элементов интерфейса представления (полей экранных форм) с объектами базы данных. Здесь и нашли свою погибель программные интерфейсы. По-хорошему, нужно было бы отделить (изолировать) слой обработки данных и реализовать прикладную логику на одном из языков третьего поколения (3GL), оформив программный доступ к прикладным функциям в виде хорошо документированного программного интерфейса.

Причина заболевания

Однако развитие пошло по другому пути. Разработчикам нужно было быстрее сдавать приложения заказчику, и не было времени на программирование «вручную». Кроме того, их интересовал не программный интерфейс (к нему надо было бы еще добавлять экранные формы), а интерактивное взаимодействие человека с СУБД, экранные формы, и возможность из них оперировать с базой данных. Поэтому и возникли языки (и соответствующие среды) четвертого поколения (4GL); они сыграли, на взгляд автора, не очень положительную роль, поскольку базировались, в общем-то, на неверном принципе связывания элементов интерфейса представления с объектами баз данных и генерации на этой основе SQL-запросов к базам данных.

Однако у них было очень важное преимущество: они позволяли разрабатывать приложения быстро (отсюда термин Rapid Application Development, RAD) и без больших затрат на тщательное программирование «вручную». Вскоре все эти инструментарии благополучно канули в лету — во многом из-за развития Web-технологий. Многие ли сегодня вспомнят продукты класса Informix-4GL, NewEra, Forte и Ingres OpenRoad? Но приложений на их основе было разработано много, они остались нам в наследство в качестве объекта для интеграции.

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

Диагностика

В этом разделе мы подвергли анализу типовую внутреннюю конструкцию стандартного приложения, разработанного в архитектуре «клиент-сервер», и убедились, что весьма часты случаи, когда анатомия такого приложения полностью исключала даже возможность создания программного интерфейса. И это ведь только одна типовая анатомия, а сколько их еще было!1

Даже те, кто постарался разработать свое приложение в классической трехзвенной модели «внешнее представление — прикладная логика — обработка данных», не всегда смогли выдержать соответствие критерию интегрируемости приложений. Архитектура на основе Web здесь ничего не изменила; разработчики приложений по-прежнему игнорировали критерий интегрируемости, так как это требовало весьма и весьма тяжелой работы по написанию и поддержанию в актуальном состоянии внешнего программного интерфейса. Разработчиков вполне можно было понять: заказчик от них этого не требовал, ему нужно было решить функциональную прикладную задачу. И уж никак заказчик не задумывался о том, что в перспективе это приложение понадобится как-то встраивать в архитектуру информационной системы.

Продолжим рассуждение в терминах метафоры лекарства и больного. Всестороннее обследование больных покажет, что очень многие из них находятся в крайне запущенном состоянии, и никакое лекарство не способно их из этого состояния вывести. Необходим систематический комплекс лечебных мероприятий, рассчитанный на перестройку всего организма больного. Дело не в лекарстве, а в лечении! Что это должно быть за лечение, поговорим в заклю