Необходимые пояснения
Не с большой охотой взялся автор за написание этой статьи — уж больно избитой кажется тема; по поводу интеграции не рассуждает сейчас разве что ленивый. Здесь во всей красе провоцируется мифотворчество, процветает необоснованный оптимизм, вызывающий напрасные надежды, пропагандируется легковесный подход к исключительно сложным технологическим проблемам. Количество «белого шума» на тему интеграции достигло таких размеров, что никак не может оставить здравомыслящего специалиста в стороне. Свой удручающий вклад вносят производители интегрирующего программного обеспечения, зачастую рекламирующие свои «уникальные» программы интеграции примерно так же, как рекламируются зубная паста и фруктовые соки. Если сбросить с этой темы вполне объяснимый маркетинговый флер, то картина складывается примерно следующая.
Интеграция — мера вынужденная. Интеграция — вовсе не благо, это то, на что идут вовсе не от хорошей жизни. Перефразируя известное высказывание, можно сказать, что «лучшее интеграционное решение- это полное отсутствие какой бы то ни было интеграции». Но, к сожалению, в практике информационных технологий это- недостижимый идеал (хотя попытки следования этому идеалу были, и мы о них расскажем). Поэтому все рассуждения об «эффективной» интеграции не имеют под собой никакой почвы, ибо организация идет на интеграцию вынужденно, она могла и должна была бы потратить выделяемые на интеграцию ресурсы с большей пользой, например, на внедрение полезных для основного бизнеса приложений.
Разработчики приложений не хотели интеграции. Интеграция приложений представляет собой задачу высшей категории сложности. Почему? Ответ очевиден: сложность порождена тем, что изначально приложения задумывались и создавались как совершенно автономные системы, не призванные быть частью каких-то глобальных бизнес-процессов.
Никто из создателей таких приложений не побеспокоился, чтобы снабдить свою систему хорошими интерфейсами, пригодными для интеграции. Никто из создателей таких приложений не стал придумывать такие «хитрые» механизмы реализации бизнес-процессов внутри приложений- так, чтобы они органически стали частью глобальных процессов связывания.
Им это было не нужно. Они решали частную функциональную задачу, и постарались решить ее лучше, чем конкуренты, за что им честь и хвала. Более того, часто делалось так, чтобы интеграция разработанного приложения с внешним миром была как можно больше усложнена, а если и разрешалась, то только за счет опять же частных средств, придуманных компанией-разработчиком, в ущерб открытым стандартам интеграции. Разработчики приложений специально делали свои приложения такими, чтобы, если кто-то и захотел интегрировать их с другими, то обязательно снова обратился бы к разработчику. Никто и не думал при разработке приложения, что оно станет частью какого-то большого процесса! Скажите, ломал ли автор популярной финансовой программы голову, чтобы сделать так, чтобы программа эта максимально просто интегрировалась бы в другие большие системы? Уверен, что нет: это противоречит интересам бизнеса, в интересах разработчика распространять свой продукт, а не потворствовать распространению чужого. Интересы бизнеса были и всегда останутся выше любых технологических соображений.
Но если уж разработчики большинства существующих ныне приложений сознательно (разумеется, не афишируя этого) шли не на открытие, а на обособление своих систем и заранее позаботились о том, чтобы сделать такую интеграцию максимально сложной- о какой интеграции мы говорим, когда сам интегрируемый объект сделан так, чтобы не быть интегрируемым?
Дело в «больном», а не в «лекарстве». Для объяснения причин сложности интеграции приложений воспользуемся метафорой, уподобив приложения, подлежащие интеграции, больному, которого нужно «поставить в строй», а интегрирующее программное обеспечение- лекарству, которое это призвано сделать. В ком (или в чем) здесь дело? Некоторые считают, что универсальное лекарство существует, его нужно только найти- и случится чудо, больной станет здоровым и начнет общаться с другими людьми. Мы же, руководствуясь традиционным консерватизмом и здравым смыслом, считаем, что нужно не изобретать универсальные лекарства, а сосредоточиться на больном и понять, что не дает ему возможность принимать участие в полноценном диалоге с другими людьми. Чтобы решить эту задачу, нужно проанализировать анатомию типового приложения и понять, что же в этой анатомии нехорошо? Но для анализа необходим критерий интегрируемости приложений.
Критерий интегрируемости приложений
Представим, что вдруг кто-то, в какие-то времена (не обязательно сейчас, это могло быть и несколько лет назад) вдруг решил бы разработать свое собственное приложение таким образом, чтобы оно было максимально интегрируемым в некие глобальные приложения, на тот момент неизвестные и неопределенные. Что можно было бы посоветовать такому разработчику?
В первую очередь, вне зависимости от внутренней архитектуры приложения, этот человек должен был бы позаботиться о том, чтобы весь значимый прикладной функционал был доступен программно. На практике это означало бы, что для выполнения любой значимой внешне доступной прикладной операции можно было бы написать на любом (максимум) или на одном (минимум) языке программирования программу. Однако для этого данное приложение должно быть оснащено интерфейсом прикладного программирования (Application Programming Interface, API); будем для краткости называть его в рамках этой статьи программным интерфейсом. Таким образом, мы приходим к понятию индекса качества программного интерфейса. Его можно измерять в диапазоне от нуля до единицы, от полного отсутствия какого бы то ни было программного интерфейса до наличия исчерпывающе полного (в смысле доступности прикладной функциональности) программного интерфейса.
Однако этого недостаточно. Если программный интерфейс существует, но не является открыто публикуемым, то его ценность невелика, ведь им нельзя воспользоваться легально. Поэтому можно дополнительно ввести индекс открытости программного интерфейса, также измеряемого от нуля до единицы, от полностью закрытого (ничего не опубликовано), до полностью открытого интерфейса (опубликован интерфейс ко всем прикладным функциям приложения; здесь мы оставляем за скобками детальность публикации, поскольку измерить ее трудно).
Индекс интегрируемости приложения можно определить как индекс качества программного интерфейса, помноженный на индекс открытости программного интерфейса. В результате мы получим числовой показатель, который (в известной степени) характеризует способность приложения быть частью какого-то другого, глобального приложения (сейчас популярен термин композитное приложение). Об этих вещах мало кто задумывается сейчас, однако это ведь не новость: десятилетия назад разработчики пакетов прикладных программ в обязательном порядке следили за тем, чтобы у пакета прикладных программ был доступный и хорошо документированный интерфейс.
Однако вернемся к критерию интегрируемости приложений. Предложенного индекса недостаточно, ведь приложения изменяются, модифицируются, перерабатываются, появляются их новые версии, поэтому должен меняться и программный интерфейс, а все изменения должны находить отражение в публикации по интерфейсу. Поэтому целесообразно ввести еще индекс актуальности программного интерфейса, принимающий два значения- единица (программный интерфейс полностью соответствует текущей версии приложения) и ноль (не соответствует). Тогда индекс интегрируемости приложений можно измерять, перемножая все три введенных нами индекса. Тогда критерий интегрируемости можно сформулировать так: идеально интегрируемое приложение имеет индекс интегрируемости, равной единице. Автор рекомендует читателям оценить приложения, с которыми они работают (и которые, возможно, планируют связывать), исходя из критерия интегрируемости; это упражнение поможет по-иному взглянуть на проблему интеграции.
Анатомия приложений
Анализ внутренней конструкции приложений- обязательный этап в оценке степени интегрируемости тех приложений, которые предполагается связывать в рамках того или иного проекта. Этот анализ усложняется тем, что обычно разработчики приложений стараются скрыть детали внутренней конструкции приложений от интегратора (строго говоря, они и не обязаны ничего предоставлять интегратору), так как обладают авторским правом на разработанный ими программный продукт и от них никто и ничто (кроме советских ГОСТов) не требует предоставлять даже программный интерфейс, не говоря уже об анатомии приложения. Тем не менее, определенные заключения по анатомии приложения сделать все-таки можно и нужно.
История болезни
Большая часть приложений, разработанных самостоятельно для применения внутри организации или для ограниченного тиражирования, была создана в эпоху, когда необходимо было быстро сделать программный продукт, удовлетворяющий прикладным, функциональным, чисто потребительским требованиям. О наличии программного интерфейса или о каких-либо архитектурных требованиях мало кто задумывался; разработка велась на доступных подручных программных средствах, которые как раз и предопределяли архитектуру будущего приложения.
Сценарий был таким. Архитектура «клиент-сервер», какая-то СУБД, какое-то средство быстрой разработки приложений, быстро спроектировали базу данных, разработали экранные формы с помощью соответствующего дизайнера, а затем сгенерировали коды для обработки данных на основе связывания элементов интерфейса представления (полей экранных форм) с объектами базы данных. Здесь и нашли свою погибель программные интерфейсы. По-хорошему, нужно было бы отделить (изолировать) слой обработки данных и реализовать прикладную логику на одном из языков третьего поколения (3GL), оформив программный доступ к прикладным функциям в виде хорошо документированного программного интерфейса.
Причина заболевания
Однако развитие пошло по другому пути. Разработчикам нужно было быстрее сдавать приложения заказчику, и не было времени на программирование «вручную». Кроме того, их интересовал не программный интерфейс (к нему надо было бы еще добавлять экранные формы), а интерактивное взаимодействие человека с СУБД, экранные формы, и возможность из них оперировать с базой данных. Поэтому и возникли языки (и соответствующие среды) четвертого поколения (4GL); они сыграли, на взгляд автора, не очень положительную роль, поскольку базировались, в общем-то, на неверном принципе связывания элементов интерфейса представления с объектами баз данных и генерации на этой основе SQL-запросов к базам данных.
Однако у них было очень важное преимущество: они позволяли разрабатывать приложения быстро (отсюда термин Rapid Application Development, RAD) и без больших затрат на тщательное программирование «вручную». Вскоре все эти инструментарии благополучно канули в лету- во многом из-за развития Web-технологий. Многие ли сегодня вспомнят продукты класса Informix-4GL, NewEra, Forte и Ingres OpenRoad? Но приложений на их основе было разработано много, они остались нам в наследство в качестве объекта для интеграции.
Но как их интегрировать, если там не к чему подключиться программно- нет интерфейса прикладного программирования? Вся специфика анатомии таких приложений состоит в том, что в них в программном коде клиента (так как они все исполнены в архитектуре «клиент-сервер») смешаны функционал интерфейса представления (работа с экранными формами) и прикладной функционал, и отделить один от другого простым путем невозможно (необходима переработка всего приложения).
Диагностика
В этом разделе мы подвергли анализу типовую внутреннюю конструкцию стандартного приложения, разработанного в архитектуре «клиент-сервер», и убедились, что весьма часты случаи, когда анатомия такого приложения полностью исключала даже возможность создания программного интерфейса. И это ведь только одна типовая анатомия, а сколько их еще было!*
Даже те, кто постарался разработать свое приложение в классической трехзвенной модели «внешнее представление- прикладная логика- обработка данных», не всегда смогли выдержать соответствие критерию интегрируемости приложений. Архитектура на основе Web здесь ничего не изменила; разработчики приложений по-прежнему игнорировали критерий интегрируемости, так как это требовало весьма и весьма тяжелой работы по написанию и поддержанию в актуальном состоянии внешнего программного интерфейса. Разработчиков вполне можно было понять: заказчик от них этого не требовал, ему нужно было решить функциональную прикладную задачу. И уж никак заказчик не задумывался о том, что в перспективе это приложение понадобится как-то встраивать в архитектуру информационной системы.
Продолжим рассуждение в терминах метафоры лекарства и больного. Всестороннее обследование больных покажет, что очень многие из них находятся в крайне запущенном состоянии, и никакое лекарство не способно их из этого состояния вывести. Необходим систематический комплекс лечебных мероприятий, рассчитанный на перестройку всего организма больного. Дело не в лекарстве, а в лечении! Что это должно быть за лечение, поговорим в заключительных разделах статьи.
Сейчас уже вряд ли что-то можно исправить в конструкциях унаследованных приложений, и, если их не планируется заменить чем-то другим, надо интегрировать то, что есть. Но как же можно «подключиться» программным способом к такому приложению, «недружественному» с точки зрения критерия интегрируемости? Остается один путь- использовать все возможные открытые программные интерфейсы к внутренним программным компонентам приложения, и первейший кандидат здесь- система управления базами данных.
Большинство СУБД обладает открытым программным интерфейсом. Поэтому можно попробовать работать с СУБД- отслеживать значимые события в базе данных через механизм триггеров, перехватывать их, извлекать данные, ассоциированные с этими событиями, упаковывать их в стандартный формат (разумеется, описание дает XML) и передавать в транспортную среду предприятия (ее можно построить, например, на основе IBM MQSeries или Oracle Advanced Queuing). Такой функциональностью обладает технологический адаптер к базе данных, основное средство подключения «закрытых» приложений в интеграционных средах. Но адаптер- это суррогат программного доступа к приложению, и на этой основе можно создавать системы, перебрасывающие блоки данных из базы данных одного приложения в базу данных другого (80% всех интеграционных проектов только это и реализует), но не полноценные композиционные приложения.
Промышленные приложения
Ситуация с промышленными приложениями несколько иная. Их разработчики постарались снабдить свои продукты адекватными программными интерфейсами, однако опять же, некоторые из них постарались максимально усложнить пользование этими интерфейсами. К примеру, в одной из реализаций для программного доступа нужно было обязательно использовать частный язык программирования, поддерживаемой только этим производителем программного обеспечения и никем иным. Вообще, разработчики промышленных приложений заняли в отношении программного доступа к своим системам оппортунистическую позицию, впрочем, вполне объяснимую. Когда заказчики начали всерьез работать над интеграционными проектами, и стало ясно, что жизненно необходим хоть какой-то программный доступ к приложениям, созданием адаптеров к промышленным приложениям занялись не их (приложений) разработчики, а независимые фирмы, не располагающие детальной информацией о программных интерфейсах к приложениям.
Хотя, если рассуждать логически, все должно было бы быть устроено как раз наоборот. Допустим, компания разработала новое бизнес-приложение и выходит с ним на рынок. Помимо великолепных функциональных характеристик (они в первую очередь и интересуют потенциальных заказчиков), компания рекламирует и полнофункциональный и отлично документированный интерфейс прикладного программирования, представляющий для потенциальных заказчиков ценность с точки зрения интегрируемости нового приложения в их информационные системы. Однако в жизни происходит не так. Повсеместно рекламируется прикладной функционал, ведь целевая аудитория маркетинговой кампании- это управленцы, финансисты, производственники, специалисты по логистике и т.д. В тендерах на приобретение промышленных приложений конкурс проводится с безусловной ориентацией на прикладной функционал, технические требования обычно формальны и сводятся к поддержке общеупотребительных стандартов коммуникаций прикладного уровня. И ни слова о наличии хорошо документированного программного интерфейса! Нет такого требования в тендерах! А раз нет, то и нечего требовать от разработчиков прикладного программного обеспечения соответствия критерию интегрируемости, ведь заказчику-то это и не нужно (было бы нужно, то он уж обязательно бы позаботился об этом требовании, вписал бы его огромными буквами в запрос для предложения). Почему так происходит- тема следующего раздела.
Функциональный подход мешает интеграции
Функциональный подход мешает интеграции- такой тезис был выдвинут Валерием Артемьевым на круглом столе по проблемам интеграции приложений (см. «Открытые системы», № 9, 2006). Действительно, решение функциональных (а следовательно, специализированных) задач влечет за собой жесткую ориентацию исполнителей на максимально полное соответствие возможностей конкретного программного продукта выработанным заранее критериям прикладной функциональности. Клиенты выбирают прикладной функционал, точно соответствующий специфике задачи или, если критерии недостаточно определены, выбирают лучший в своем классе продукт. Удовлетворение критерию интегрируемости не является требованием конкурса, так как не имеет к прикладному функционалу никакого отношения. Будет выбранное приложение легко интегрируемым- отлично, не будет- это не проблемы прикладников, интеграцией-то они не занимаются, это дело ИТ-дирекции, дело системных архитекторов и технологов.
Так почему их позиция не учитывается? Приходится с сожалением признать, что в этом отношении вес позиции прикладника существенно больше веса позиции системщика. Но даже если позиция системщика является весомой, он не будет анализировать анатомию приложения, так как в большинстве случаев системщик уповает на волшебные возможности интеграционного решения, придерживаясь позиции «все дело в лекарстве, а не в больном». Этим и объясняется поразительный факт- в тендерах на приобретение программной платформы для интеграции приложений часто вообще не приводят никаких сведений об интегрируемых приложениях. Творцы таких тендеров всерьез считают, что хорошая интегрирующая платформа должна безусловно обладать качеством универсальности в отношении любого приложения.
Интеграция на этапе разработки
Мы уже говорили, что лучшее решение задачи интеграции- это отсутствие какой бы то ни было интеграции. Звучит парадоксально, но, тем не менее, подход вполне реализуем, если считать, что интеграция осуществляется заранее, на этапе разработки полнофункционального комплекса бизнес-приложений. В свое время в Oracle, вдохновленные этой идей, разработали интегрированный набор приложений, который и сейчас сохранил свое название- Oracle E-Business Suite. Смена парадигмы была отражена даже в названии- от множества приложений (Oracle Applications) перешли тогда к единому набору Oracle E-Business Suite. Основная идея состояла в том, чтобы вообще отказаться от интеграции силами заказчика, переложить всю заботу об интеграции с плеч заказчика на плечи разработчика бизнес-приложений*.
Технологически задача интеграции решалась за счет использования единой централизованной базы данных (и соответственно, модели данных), а также единого технологического стека (СУБД- 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 СНГ.
* Современный мир приложений напоминает животный мир, а задача классификации приложений с точки зрения их «анатомии» достойна ума нового Карла Линнея; по крайней мере, без такой классификации нам будет трудно понимать, с чем мы имеем дело.— Прим. автора.
* Сейчас, после приобретения PeopleSoft, J.D. Edwards, Siebel и других компаний, в Oracle вновь вернулись к термину Oracle Applications, так как теперь в ее арсенале несколько бизнес-приложений.— Прим. автора.
