Модульные системысменят «динозавров»

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

Ведущие поставщики систем ERP это уже чувствуют и готовят свои системы к переходу на новые архитектуры.

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

Но так ли уж нужны компонентные системы? Марина Аншина, руководитель сектора разработок и системной поддержки отдела корпоративных информационных систем компании TopS, и Сергей Орлик, менеджер по продуктам представительства компании Inprise в России, странах СНГ и Прибалтики, в один голос утверждают: да, такие системы нужны. Мир вокруг нас меняется все быстрее и быстрее. Чтобы удержаться на плаву, предприятиям-заказчикам надо иметь возможность быстро адаптироваться к частым переменам и оперативно вносить изменения в свой бизнес. Следовательно, гибким должен быть не только сам бизнес, но и информационные системы, которые позволяют предприятию вести дела. Едва ли может считаться гибкой прикладная система (например, ПО управления предприятием), на перенастройку и переналадку которой уйдет слишком много времени. Ведь в данном случае велика вероятность, что за этот срок на рынке, где работает заказчик, произойдут изменения, которые сведут на нет усилия по перенастройке системы. Предприятие, обладающее негибкой прикладной системой, грозит оказаться в роли Ахилла, который, согласно логике древних философов, так никогда и не сможет обогнать черепаху. Но современный рынок — вовсе не такая уж медлительная черепаха, как кажется иным руководителям.

Компании Inprise и TopS предложили заказчикам внимательнее присмотреться к компонентной архитектуре, в частности, к решениям на базе технологии CORBA. Партнеры (кстати, члены Консорциума OMG, который и занимается развитием и координацией стандарта CORBA) организовали ряд семинаров для различных категорий пользователей: руководителей ИТ-подразделений, разработчиков, специалистов по технической поддержке. Первый семинар, прошедший 2-3 декабря и ориентированный на руководителей ИТ-служб, был посвящен основам CORBA.

В центре этой архитектуры — брокеры объектных запросов (ORB — object request broker), которые общаются между собой, передавая друг другу с машины на машину запросы клиентов к объектам и возвращая назад результаты этих запросов.

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

Общение между удаленными брокерами происходит посредством протокола IIOP (Internet Inter-ORB Protocol). Для поиска удаленных объектов применяется механизм, аналогичный тому, который используется в системе DNS. О том, какие существуют «вокруг» объекты и какие услуги они могут предложить, клиентские модули «узнают» из хранящегося в репозитарии набора спецификаций объектов — описаний на языке IDL. С помощью компиляторов эти спецификации могут быть оттранслированы в один из языков широкого спектра: Си, Си++, Ада, Smalltalk, Java, Кобол и Objective C.

Что очень ценно — CORBA позволяет относительно легко интегрировать существующие приложения в эту архитектуру. Для этого достаточно «облечь» приложения в интерфейсную оболочку CORBA, как бы вложить внутрь шара, с которым может «общаться» другой шар — брокер (примечательная деталь: аббревиатура ORB совпадает с английским словом, которое переводится как «шар, сфера»). После этого приложение сможет взаимодействовать с другими программами посредством брокеров. Таким образом, старые работающие приложения не придется выбрасывать, их можно будет использовать до тех пор, пока это необходимо. По мнению Аншиной, это свойство очень важно для системных интеграторов, которым зачастую приходится наращивать ИТ-инфраструктуру, встраивая новые системы в уже имеющуюся информационную среду. Естественно, CORBA — не панацея, но там, где предприятия нуждаются в создании гибких прикладных систем, способных полнее использовать вычислительные ресурсы предприятия за счет организации распределенных вычислений, эта архитектура наверняка будет востребована.

Диалектика выбора

В рамках семинара состоялся круглый стол «Технологическая культура построения современных информационных систем и пути ее достижения». Его участники обсудили объективные и субъективные факторы выбора и использования новых технологий.

Говоря об объективных факторах, то есть возможностях технологий, участники круглого стола сосредоточивались в основном на технологии CORBA и ее оппоненте — Microsoft DCOM. Преимущества и недостатки видны лучше всего в сравнении, и они есть у обеих технологий, хотя Марина Аншина подчеркнула, что принципиальное различие технологий состоит в том, что первую поддерживает международный консорциум OMG, в который входит около 400 команд, а вторую — одна, хотя и гигантская, корпорация. До сих пор CORBA уступала с точки зрения интеграции с инструментарием, но сейчас все большее количество инструментов начинают ее поддерживать.

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

— Татьяна Грачева, Computerworld Россия