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

23.05.2017

Новости:


Все новости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диагностика

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

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

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

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

Большинство СУБД обладает открытым программным интерфейсом. Поэтому можно попробовать работать с СУБД — отслеживать значимые события в базе данных через механизм триггеров, перехватывать их, извлекать данные, ассоциированные с этими событиями, упаковывать их в стандартный формат (разумеется, описание дает XML) и передавать в транспортную среду предприятия (ее можно построить, например, на основе IBM MQSeries или Oracle Advanced Queuing). Такой функциональностью обладает технологический адаптер к базе данных, основное средство подключения «закрытых» приложений в интеграционных средах. Но адаптер — это суррогат программного доступа к приложению, и на этой основе можно создавать системы, перебрасывающие блоки данных из базы данных одного приложения в базу данных другого (80% всех интеграционных проектов только это и реализует), но не полноценные композиционные приложения.

Промышленные приложения

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

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

Функциональный подход мешает интеграции

Функциональный подход мешает интеграции — такой тезис был выдвинут Валерием Артемьевым на круглом столе по проблемам интеграции приложений (см. «Открытые системы», № 9, 2006). Действительно, решение функциональных (а следовательно, специализированных) задач влечет за собой жесткую ориентацию исполнителей на максимально полное соответствие возможностей конкретного программного продукта выработанным заранее критериям прикладной функциональности. Клиенты выбирают прикладной функционал, точно соответствующий специфике задачи или, если критерии недостаточно определены, выбирают лучший в своем классе продукт. Удовлетворение критерию интегрируемости не является требованием конкурса, так как не имеет к прикладному функционалу никакого отношения. Будет выбранное приложение легко интегрируемым — отлично, не будет — это не проблемы прикладников, интеграцией-то они не занимаются, это дело ИТ-дирекции, дело системных архитекторов и технологов.

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

Интеграция на этапе разработки

Мы уже говорили, что лучшее решение задачи интеграции — это отсутствие какой бы то ни было интеграции. Звучит парадоксально, но, тем не менее, подход вполне реализуем, если считать, что интеграция осуществляется заранее, на этапе разработки полнофункционального комплекса бизнес-приложений. В свое время в Oracle, вдохновленные этой идей, разработали интегрированный набор приложений, который и сейчас сохранил свое название — Oracle E-Business Suite. Смена парадигмы была отражена даже в названии — от множества приложений (Oracle Applications) перешли тогда к единому набору Oracle E-Business Suite. Основная идея состояла в том, чтобы вообще отказаться от интеграции силами заказчика, переложить всю заботу об интеграции с плеч заказчика на плечи разработчика бизнес-приложений2.

Технологически задача интеграции решалась за счет использования единой централизованной базы данных (и соответственно, модели данных), а также единого технологического стека (СУБД — Oracle Database, сервер приложений — Oracle Application Server) и единой модели управления потоками работ.


Рис. 1. Гелиоцентрическая модель

С точки зрения прикладной функциональности, ключевая идея состояла в универсальном характере программного комплекса бизнес-приложений. То есть он реализует прикладной функционал столь широкого спектра (ERP, CRM, SCM, HRM и т.д.), что в потенциале способен обеспечить все потребности современного предприятия. Отсюда следовала и методология внедрения программного комплекса бизнес-приложений на предприятии. Внедренный сначала в виде нескольких решавших наиболее актуальные задачи модули, Oracle E-Business Suite расширялся, слой за слоем поглощая «старые» бизнес-приложения, отрабатывавшие частные задачи, и в перспективе заменял все эксплуатируемые унаследованные приложения. Процесс в динамике проиллюстрирован на рис. 1; модель такого процесса может быть характеризована как «гелиоцентрическая».

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

Ситуация изменилась, когда корпорация Oracle стала владельцем множества бизнес-приложений. Так или иначе, но у заказчика могло эксплуатироваться несколько приложений из этого множества, причем все они были «равновесными», «равноудаленными от центра», каждое решало функционально полно собственную задачу. Новая конфигурация в пространстве бизнес-приложений (см. рис. 2А) заставила нас несколько изменить отношение к интеграционным средствам. Они уже приобретали самостоятельную роль и значение. Здесь как раз и кроется причина появления целого спектра новшеств в семействе продуктов Oracle, таких как Oracle Enterprise Service Bus (общая шина сервисов предприятия; см. рис. 2Б), Oracle Data Hub (интеграция посредством консолидации; рис. 2В), Business Process Management (проектирование и реализация бизнес-процессов предприятия; рис. 2Г) и др. Заказчик может выбрать одну из моделей интеграции, и построить интеграционную платформу предприятия на соответствующей этой модели линейке программных продуктов Oracle. Особый интерес для российского рынка представляет концепция общей шины сервисов предприятия (Enterprise Service Bus, ESB).


Рис. 2. Другие модели интеграции

ESB расширяет исключительно плодотворную идею интеграционной шины предприятия за счет использования сервисов. Во многом — и концептуально, и технологически — ESB опирается на продукты класса Message Oriented Middleware (MOM), добавляя к традиционной транспортной среде, которая обеспечивалась продуктами наподобие IBM MQSeries или Oracle Advanced Queuing, применение сервисов со стандартизованными интерфейсами как универсальной среды интеграции. В этом смысле направление ESB весьма интересно и перспективно. Для российского рынка интеграционных решений, где превалируют задачи передачи данных от одного приложения другому, этот подход станет в течение 2007 года исключительно популярным.

Однако программные продукты категории ESB не решают и не могут решить вопрос ограниченности архитектуры унаследованных приложений и сложности их встраивания в системы с сервис-ориентированной архитектурой (Service-Oriented Architecture, SOA) с целью сделать их элементом композиционных приложений — для этого унаследованные приложения надо переписывать!

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

Что нового в интеграционных решениях

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

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

Ключевые различия приложений определяются тремя их архитектурными компонентами — моделью данных, которая лежит в их основе, технологическим стеком, на котором реализовано приложение (базовое программное обеспечение — среда времени исполнения, то есть СУБД, сервер приложений и т.д.), а также моделью бизнес-процессов. Различие в моделях бизнес-процессов (равно как и в механизмах их реализации) является главным препятствием для того, чтобы приложения стали частью глобального бизнес-процесса.

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

Вот что говорит о Oracle Fusion Applications глава корпорации Oracle Ларри Эллисон (см. Ларри Эллисон: Middleware и БД для Oracle Fusion Applications у нас уже есть. Cnews, 20.09.2006): «Здесь важно понимать, что Fusion Applications — это совершенно новый продукт, написанный заново».

В этом контексте становится ясной и цель цепочки приобретений компаний — разработчиков бизнес-приложений. Вот что замечает по этому поводу Эллисон: «Отдельно подчеркну, что Fusion — это не объединение людей, работавших на разных проектах, это абсолютно новая система… Например, какая польза от приобретения Siebel? Выгода в том, что разработчики Siebel — специалисты № 1 по CRM в мире. Поэтому они пишут для Fusion Applications соответствующий блок. А разработчики PeopleSoft — признанные гуру в создании HR-систем, и они программируют соответствующий модуль для Fusion. Мы купили не компании, не их продукты, а команды профессионалов».

Заключение

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

Глеб Ладыженский — директор по технологиям Oracle СНГ. Изложенная в статье точка зрения может не всегда однозначно совпадать с позицией корпорации.


1 Современный мир приложений напоминает животный мир, а задача классификации приложений с точки зрения их «анатомии» достойна ума нового Карла Линнея; по крайней мере, без такой классификации нам будет трудно понимать, с чем мы имеем дело.— Прим. автора.


2 Сейчас, после приобретения PeopleSoft, J.D. Edwards, Siebel и других компаний, в Oracle вновь вернулись к термину Oracle Applications, так как теперь в ее арсенале несколько бизнес-приложений.— Прим. автора.



Открытые системы #09/2006

Комментарии

Страницы комментариев: 1 :: 2 :: следующая

verlena, Wed Dec 19 17:07:46 2007:
Спасибо автору. Интересно и не банально. Подталкивает к размышлениям... Действительно - "доктор сказал - в морг, значит - в морг". Т.е. об интегрируемости (как впрочем и о других нефункциональных требованиях - производительность, масштабируемость и пр.) след задумываться на стадии проектирования, а потом уже действительно - в морг... Да и само по себе определение программной архитектуры предполагает выделение компонентов и определение их взаимодействия (множество определений можно найти здесь - http://www.sei.cmu.edu/architecture/published_definitions.html) Иными словами, получается, что грамотно спроектированное приложение по умолчанию предполагает хорошую интегрируемость... А SOA действительно, не является панацеей - как не стала панацеей ООП от бардака в программном коде...
Т.е. в целом я согласна с автором :)
Но... Помимо интеграции на уровне приложений существует понятие интеграции на уровне данных... И Oracle, надо сказать, какое-то время назад активно поддерживал именно данный уровень (в отличие от например того же купленного ныне PeopleSoft). Что предполагает существование (и поддержку) некой концептуальной модели данных, а так же поддержку интерфейсов взаимодействия посредством неких структур хранения. В этом смысле создание хранилищ данных можно считать интеграционными проектами. А подход интеграции уровня данных - вполне жизнеспособным. И "БД в центре" может оказаться хорошим вариантом. Как Вы считаете?
verlena, Wed Dec 19 14:46:55 2007:
Спасибо автору. Интересно и не банально. Подталкивает к размышлениям... Действительно - "доктор сказал - в морг, значит - в морг". Т.е. об интегрируемости (как впрочем и о других нефункциональных требованиях - производительность, масштабируемость и пр.) след задумываться на стадии проектирования, а потом уже действительно - в морг... Да и само по себе определение программной архитектуры предполагает выделение компонентов и определение их взаимодействия (множество определений можно найти здесь - http://www.sei.cmu.edu/architecture/published_definitions.html) Иными словами, получается, что грамотно спроектированное приложение по умолчанию предполагает хорошую интегрируемость... А SOA действительно, не является панацеей - как не стала панацеей ООП от бардака в программном коде...
Т.е. в целом я согласна с автором :)
Но... Помимо интеграции на уровне приложений существует понятие интеграции на уровне данных... И Oracle, надо сказать, какое-то время назад активно поддерживал именно данный уровень (в отличие от например того же купленного ныне PeopleSoft). Что предполагает существование (и поддержку) некой концептуальной модели данных, а так же поддержку интерфейсов взаимодействия посредством неких структур хранения. В этом смысле создание хранилищ данных можно считать интеграционными проектами. А подход интеграции уровня данных - вполне жизнеспособным. И "БД в центре" может оказаться хорошим вариантом. Как Вы считаете?
verlena, Wed Dec 19 12:12:52 2007:
Спасибо автору. Интересно и не банально. Подталкивает к размышлениям... Действительно - "доктор сказал - в морг, значит - в морг". Т.е. об интегрируемости (как впрочем и о других нефункциональных требованиях - производительность, масштабируемость и пр.) след задумываться на стадии проектирования, а потом уже действительно - в морг... Да и само по себе определение программной архитектуры предполагает выделение компонентов и определение их взаимодействия (множество определений можно найти здесь - http://www.sei.cmu.edu/architecture/published_definitions.html) Иными словами, получается, что грамотно спроектированное приложение по умолчанию предполагает хорошую интегрируемость... А SOA действительно, не является панацеей - как не стала панацеей ООП от бардака в программном коде...
Т.е. в целом я согласна с автором :)
Но... Помимо интеграции на уровне приложений существует понятие интеграции на уровне данных... И Oracle, надо сказать, какое-то время назад активно поддерживал именно данный уровень (в отличие от например того же купленного ныне PeopleSoft). Что предполагает существование (и поддержку) некой концептуальной модели данных, а так же поддержку интерфейсов взаимодействия посредством неких структур хранения. В этом смысле создание хранилищ данных можно считать интеграционными проектами. А подход интеграции уровня данных - вполне жизнеспособным. И "БД в центре" может оказаться хорошим вариантом. Как Вы считаете?
Кирилл, Wed Dec 19 10:35:23 2007:
verlena, вы в корне не правы. ООП как раз создаёт базу, на основе которой уже можно создавать методики управления сложностью (тот же патерновый подход, Унифицированный рациональный процесс и прочие), сама по себе ООП-парадигма конечно же не является панацеей. А употребляя SOA и ООП в едином контексте, вы вообще мягкое с зелёным пытаетесь сопоставить.
verlena, Wed Dec 19 09:36:50 2007:
Спасибо автору. Интересно и не банально. Подталкивает к размышлениям... Действительно - "доктор сказал - в морг, значит - в морг". Т.е. об интегрируемости (как впрочем и о других нефункциональных требованиях - производительность, масштабируемость и пр.) след задумываться на стадии проектирования, а потом уже действительно - в морг... Да и само по себе определение программной архитектуры предполагает выделение компонентов и определение их взаимодействия (множество определений можно найти здесь - http://www.sei.cmu.edu/architecture/published_definitions.html) Иными словами, получается, что грамотно спроектированное приложение по умолчанию предполагает хорошую интегрируемость... А SOA действительно, не является панацеей - как не стала панацеей ООП от бардака в программном коде...
Т.е. в целом я согласна с автором :)
Но... Помимо интеграции на уровне приложений существует понятие интеграции на уровне данных... И Oracle, надо сказать, какое-то время назад активно поддерживал именно данный уровень (в отличие от например того же купленного ныне PeopleSoft). Что предполагает существование (и поддержку) некой концептуальной модели данных, а так же поддержку интерфейсов взаимодействия посредством неких структур хранения. В этом смысле создание хранилищ данных можно считать интеграционными проектами. А подход интеграции уровня данных - вполне жизнеспособным. И "БД в центре" может оказаться хорошим вариантом. Как Вы считаете?
Глеб Ладыженский, Sat Oct 13 18:55:53 2007:
Уважаемые авторы комментариев к мой статье,

Огромное спасибо, что Вы прочли мой текст. Все комментарии интересны по существу, точны и корректны, точнее и не скажешь.

С уважением,
Глеб Ладыженский
Кирилл, Wed Oct 10 09:45:31 2007:
Да, Red, вы правы. К плохой БД уже ничего не приделаешь. Особенно в Раше повсеместно распространена практика не принимать в расчёт особенности СУБД и вообще никак не проектировать модель хранения данных, пологаясь на различные промежуточные решения в вида дата-брокеров и прочей мишуры. В результате последующая работа с данным вне разработанного приложения становится практически невозможной, а сами данные теряют свою полезность.
Rad, Tue Oct 9 15:29:43 2007:
SOA - не есть выдумка Oracle, так же как и ESB. Автор дает один из возможных путей интеграции приложений. Хотя и этот подход не без изъянов, т.к. далеко не ко всякой БД можно приделать сервисы. По аналогии с больным и лекарством - не вскую простуду можно вылечить аспирином. Поэтому, даже зная несколько "типовых рецептов" интеграция приложений остается сложной и, как правило, уникальной для каждой реализации задачей. Не будет и панацеей разработка приложений с учетом программных интерфейсов, просто потому, что сами программные интерфейсы со временем потребуют модификации. Такова сущность эволюции.
Кирилл, Tue Aug 28 09:58:58 2007:
boom, понимаете, аналогия с АСУТП немного не корректна, в том смысле, что в промышленности вряд ли кому-то в голову прийдёт мысль покупать устройство, которое не работает в принципе по заданному функционалу, а в ИТ-сфере такое происходит сплошь и рядом. Поэтому купить "конструктор от Оракл" не такое уж плохое решение.
boom, Sun Aug 26 14:08:57 2007:
Наконец на этом сайте появились люди со здравым смыслом. Автор понятное дело все свел к тезису "зачем интегрировать, лучше купить универсальный конструктор от оракла и переписать все заново" Это конечно не менее тупиковый путь. Оракл хоть и скупает все на корню, однако "всех партизан не перевешает". Все одно, найдется не одна тысяча компаний которые сделают лучший по функциональности продукт. Да и зачем отапливать помещение лишним сервером ради перспективной интеграции? И БД "в центре" через которую можно обмениваться данными - тоже не всегда хороший вариант. Глобально, проблема интеграции решится тогда, когда разработчик будет _вынужден_ следовать определенной интеграционной парадигме при разработке конкретного функционала. Если воспользоваться аналогией автора больной-лекарство, эта интеграционная парадигма может выглядеть как "беременность".
Вот хочешь - не хочешь - а 9 месяцев соблюдай правила. Или не будет человека, который в перспективе может стать больным.
Например, большенство компаний выпускающих промышленные контроллеры для создания АСУТП, вынуждены создавать OPC сервер для своих изделий. Ибо рыночная ценность таких изделий намного выше, чем у собратьев у которых OPC отсутствует. Хороший пример рыночной необходимости создания заведомо интегрируемых изделий.

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru