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

Наверное, впервые соединяя два компьютера, и помыслить было невозможно, сколько проблем внесет это в столь гармоничный и таинственный мир программных систем. Те старые программы называют теперь монолитными, и, возможно, некоторые поклоняются им как долменам и кромлехам компьютерного мира. Что у нас там на дворе? Рококо или барокко? И какие капители нынче в моде? Ведь правда, слово «архитектура» отлично чувствует себя в компьютерном мире?

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

Элементы распределенных систем должны уметь взаимодействовать. А если один из этих элементов вышел из строя? А если его вывел из строя злоумышленник? С одной стороны, появляются новые возможности: рост вычислительных мощностей, средства распараллеливания нагрузки, кластерные решения, — позволяющие строить многофункциональные системы уровня ERP и CRM и системы реального времени, а с другой — к таким системам выдвигаются и совершенно новые требования.

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

А теперь? Даже возмужавший и похорошевший Visual Basic столь тесно интегрирован в .NET, что это уже не столько язык, сколько часть этой технологии. Java же объединяет в себе уже такое количество взаимосвязанных технологий, что даже не все из них поместятся в эту книгу. Жить стало труднее, но зато намного интереснее.

В этой главе мы попытаемся рассказать вам о современных тенденциях в устройстве распределенных компьютерных систем. Представьте, что вы стоите на дороге, а перед вами (да-да!) так хорошо известный по сказкам столб с тремя указателями. Чтобы никого не обидеть, пусть будет так: туда пойдешь — CORBA найдешь, сюда пойдешь — J2EE найдешь, а сюда — получишь .NET. И мы постараемся, чтобы у вас не возникло ощущения, что при всем богатстве выбора другой альтернативы нет. Ведь без здоровой конкуренции мы получим: вы прекрасно знаете, что.

1.1. Технология CORBA OMG

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

Все началось в 1989 году, когда группа компаний, в которую входили HP, Sun, American Airlines, Canon и некоторые другие производители, а также — что очень важно — и потребители программных продуктов, организовала некоммерческое сообщество, которое назвали Object Management Group (OMG). Стратегическая задача, которую поставило перед собой это сообщество, состояла в создании технологии, позволяющей объединить программные приложения, выполняющиеся на различных программных и аппаратных платформах, взаимодействующие по различным протоколам, написанные на разных языках программирования, созданные в различных уголках мира совершенно разными группами разработчиков. При этом были сформулированы два важнейших концептуальных момента.

Прежде всего отметим, что это не первый подход к больной теме интеграции и унификации. Приведем в пример хотя бы попытку General Motors в начале 80-х создать однородный протокол для связи с полевым оборудованием. Забытый нынче MAP (Manufacturing Automation Protocol — протокол промышленной автоматики), представляющий собой стандартный коммуникационный стек для передачи сообщений в едином унифицированном формате, не нашел всеобщего признания, на которое рассчитывали его создатели. И это несмотря на вес GM на мировом рынке. Возможно, это произошло не только потому, что протокол очень сложен и требует больших вычислительных ресурсов. Мы также не будем останавливаться на технических преимуществах и недостатках ни этого протокола, ни других способов интеграции до-CORBA. Мы лишь хотим сказать несколько слов о пользе стандартизации.

1.1.1. Pro и contra стандартов

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

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

Именно поэтому OMG занимается только стандартами и принципиально не разрабатывает готовые продукты.

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

У OMG, конечно, нет возможности навязывать свои стандарты. Поэтому им пришлось сделать такой стандарт, который использовать выгодно. Впрочем, путь к тому положению, которое занимает OMG сегодня, далеко не был усеян розами без шипов. Мы достаточно давно следим и какое-то время даже участвуем в деятельности сообщества. Так вот, примерно до 1998 года все публикации о CORBA, включая достаточно серьезные книги, повторяли вопрос: «Быть или не быть? Примут или не примут стандарт?» Пока этот вопрос зрел, OMG росла. Начавшись с 13 членов, сообщество сейчас насчитывает более 900 компаний, среди которых, кроме производителей и поставщиков программных решений и компьютерного оборудования, — крупные промышленные и финансовые предприятия, государственные и учебные организации, консалтинговые фирмы и системные интеграторы. Возможно, именно такая сила привела к тому, что с 1999 года нам уже не встречались подобные сомнения.

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

С другой стороны, стандарты — это не догма. Они тоже должны развиваться, и OMG это понимает. Естественно, раз цикл развития длиннее, поддержание плавной смены стандартов становится совсем уж трудной задачей. Мы расскажем далее, как удается решать эту задачу OMG.

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

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

Конечно, не все программные продукты, поддерживающие стандарт CORBA, одинаковы. Многие производители вносят что-то свое. Зачастую эти новаторские решения оказываются столь успешны, что попадают в основной стандарт. Так, на наших глазах это происходит с интерсепторами, которые придумала компания Borland. Разные реализации поддерживают разные версии стандарта, некоторые не поддерживают отдельные особенности. Разобраться в этом не так сложно, и здесь вам поможет страница сайта OMG http://www.corba.org/vendors/b.htm и технические описания этих продуктов.

Напоследок заметим, что стандарт CORBA — это живой стандарт, чья третья версия появилась совсем недавно (в июне 2002 года), так что нам неизвестны1 полностью поддерживающие ее программные продукты. Несомненно, основой CORBA 3 является компонентная модель, которой посвящена глава 11 нашей книги.

1.1.2. Философия CORBA и политика OMG

CORBA создавалась как технология, призванная объединить разрозненные сообщества компьютерных приложений. Архитектуру OMA, которая является основой CORBA, OMG назвала «архитектурой для объединения мира». С одной стороны, CORBA старается научить приложения общаться, причем не делает различия между «правоверными» объектно-ориентированными или «еретиками», написанными на Коболе. CORBA — демократическая технология и, несмотря на заведомую сложность (если не сказать — невыполнимость) подобной задачи, OMG всегда твердо стояла на своем:

1. Объединяются приложения как новые, так и наследуемые (legacy).

2. Эти приложения могут выполняться на различных операционных платформах (вплоть до самых экзотических, типа Open VMS, Digital UNIX или OS390).

3. Стандарты не стоят ничего — их может получить и использовать любой желающий.

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

Возможно, именно поэтому, не поступаясь принципами, CORBA к концу XX века заняла подобающее место, а не стала еще одним печальным опытом построения «компьютерного коммунизма».

В OMG входят сотни компаний. Но компании состоят из людей, и развитие OMG определяется добровольной и самоотверженной работой сотен и тысяч специалистов — как лидеров компьютерной науки, так и их добросовестных помощников. Мы надеемся, что по мере чтения этой книги вы увидите, какие полезные и передовые идеи открыла для нас OMG. Мы не будем перечислять имен из боязни кого-то пропустить, а всех перечислить просто невозможно. В следующих главах вам встретятся некоторые известные фамилии, другие вы можете увидеть на сайтах OMG http://www.omg.org, http://www.corba.org и на других сайтах по технологии CORBA.

В этой главе два следующих раздела отводятся прямым конкурентам CORBA — технологиям Java и .NET. В конце главы мы планируем привести короткое сравнение этих технологий. Но сейчас речь не о том, кто лучше — кто хуже, а о том, как обстоит дело со здоровой конкуренцией. Прежде всего, родители конкурентов также являются членами OMG. Sun Microsystems Inc. является одним из основателей сообщества, а Microsoft присоединилась к OMG в 1997 году. Это произошло после того, как в CORBA были стандартизованы мосты CORBA-COM и COM-CORBA. Вскоре появились и соответствующие программные продукты. Возможно, именно присоединение Microsoft помогло утверждению CORBA.

Вы увидите в дальнейшем, как тесно переплетены CORBA и Java. Это и RMI поверх IIOP, о котором вы прочитаете в следующей главе и который нашел столь широкое применение. Это и симбиоз двух компонентных моделей — J2EE (Java 2 Enterprise Edition) и CСМ (CORBA Component Model), о котором вы сможете узнать из глав 9 и 11. Очевидно, что один из тезисов OMG — это принцип Кота Леопольда: «Давайте жить дружно!»

На пути всеобщей интеграции OMG пришла к логической точке создания Model-Driven Architecture, которой посвящена глава 15. Эта архитектура объединяет все вышеприведенные платформы под сенью очевидной идеи, что бизнес-логика программных приложений по большому счету не зависит от технологической основы. Поэтому первый этап моделирования приложений не должен учитывать специфику выбранной (а возможно, еще и не выбранной к этому моменту) платформы.

Конечно, каждая из технологий имеет свои полезные особенности, которые приложение может и должно использовать. Но их уместно подключать на втором этапе создания прикладных моделей. Что это — соглашательская позиция OMG? Нет, это постоянные и твердые попытки не позволить компьютерному миру распасться на враждебные лагеря ни на уровне людей и компаний, ни на уровне приложений и систем.

1.1.3. Область ответственности CORBA

Мы достаточно часто рассказываем о CORBA на семинарах и конференциях. И достаточно часто слышим от собравшихся: «Технология CORBA сложна и требует больших вычислительных ресурсов. Мы прекрасно обходимся без нее и уже съинтегрировали все, что нам надо». Мы пожимаем руки всем успешным интеграторам, как использующим CORBA, так и избегающим ее. 

Любую технологию, сколь бы полезна она ни была, нельзя использовать во всех ситуациях. Посмотрите, что произошло, например, с Интернетом. После бума — резкий спад. Хорошо, что с помощью CORBA еще не переносят данные из Excel в MS SQL.

CORBA — это «тяжелая артиллерия», которая позволяет реализовать интеграцию приложений с требуемым уровнем сервисов: надежности, безопасности, целостности, производительности и т. д. Вы можете обмениваться файлами, использовать EDI, конвертировать данные или делать, что вам заблагорассудится, если вас это устраивает. Но если вам понадобится добиться серьезной производительности или реализовать гарантируемую передачу сообщений из одного приложения в другое, то, возможно, без CORBA вам не обойтись.

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

В области EAI (Enterprise Application Integration) существуют два направления, которые по очереди одерживают верх друг над другом. В соответствии с первым из них интеграцией занимается отдельно выделенный функциональный элемент. Второе направление возлагает эту обязанность на программных агентов, расположенных на каждом узле системы. Первое — область интеграционных серверов, второе — CORBA. В реальной жизни обычно используют некоторую комбинацию обеих возможностей. В любом случае при выборе технологии надо исходить из конкретной задачи и имеющихся в наличии возможностей. К последним относится знание и опыт использования той или иной технологии.

Стандарт для анализа и проектирования программных систем — язык моделирования Unified Modelling Language (UML) — используется повсеместно в различных областях компьютерных технологий. Постепенно приобретает популярность средство описания метамоделей и репозитариев — Meta Object Facility (MOF). Мы опишем эти стандарты в последней главе книги вместе с Model-Driven Architecture, которая только выходит в свет и судьба которой, надеемся, сложится так же удачно.

1.2. Технология J2EE Sun

Технология J2EE (Java 2 Enterprise Edition), формально объявленная в декабре 1999 года, представляет собой первый стандарт для создания корпоративных распределенных многозвенных приложений. Избежав обычно печальной участи «первого блина», J2EE получилась на редкость гармоничной, удобной и полезной. Впитав, как губка, другие стандарты, среди которых важнейшими являются CORBA и XML, J2EE позволяет существенно упростить труд системных архитекторов, проектировщиков и разработчиков, предлагая ясную и гибкую архитектуру и набор взаимосвязанных стандартов для использования важнейших системных сервисов. J2EE объединяет такие стандарты, как компонентная модель Enterprise JavaBeans, стандарты Web-приложений для формирования динамических откликов на действия пользователей — Java Servlets и JavaServer Pages, стандарт для доступа к базам данных JDBC. Мы посвятим каждому из этих стандартов по отдельной главе, здесь же хотим показать их взаимосвязь и место в общей картине J2EE и в области распределенных компьютерных приложений.

1.2.1. Семейка Java

Не удивительно ли, что в последнее время совсем не появляется языков программирования в чистом виде? Собственно, совсем молодых два: C# и Java. Если первый представляет собой важный элемент машины под названием .NET, о которой мы поговорим в следующем разделе, то назвать вторую просто языком язык не поворачивается (простите за невольный каламбур). Нам не кажется, что это случайность.

Современное программирование давно перестало быть просто написанием кода (пусть даже довольно заковыристого). По оценкам экспертов сама функциональность занимает только около 20–30 % программного кода, а все остальное отводится системному хозяйству и поддерживает должное поведение программного обеспечения. И такой перевес нарастает. Действительно, современные приложения, на которых основывается производственная, финансовая и организационная деятельность предприятий, очень сильно отличаются от более старых собратьев. Они должны поддерживать одновременные обращения сотен и тысяч клиентов, функционировать в режиме 8?24?365, предоставлять доступ в соответствии с определенными полномочиями, обеспечивать динамический и богатый интерфейс.

Все рассматриваемые в этой главе технологии стараются освободить разработчиков от этого бремени. И если в рамках CORBA описаны стандарты для 17 системных сервисов, то в этом отношении J2EE существенно скромнее.

Мы не смогли охватить необъятное и поэтому апплеты, JavaMail (API для создания приложений, связанных с обменом и обработкой сообщений электронной почты) и коннекторы (API для взаимодействия с legacy-приложениями) не нашли отражения в этой книге. В свое оправдание хотим сказать, что про первые написано слишком много, а про последние слишком мало, чтобы мы могли надеяться описать их должным образом.

Прикладная модель J2EE состоит из четырех слоев, каждый из которых может функционировать на одном или нескольких узлах распределенной системы. В отличие от традиционной трехзвенной архитектуры, появился слой Web-серверов, который занимается подготовкой презентационной части для клиентов. Модель состоит из четырех уровней:

Приложения, удовлетворяющие стандарту J2EE, состоят из компонентов, которые в процессе выполнения приложений взаимодействуют друг с другом. Спецификация определяет компоненты следующих типов:

Эти компоненты общаются с помощью различных средств: HTML, XML, RMI — и взаимодействуют через различные протоколы: HTTP, HTTPS, IIOP. Они устанавливаются и выполняются в специальной прикладной среде — контейнерах, которые берут на себя груз системной поддержки и переговоры с клиентами. Для взаимодействия с существующими приложениями в рамках J2EE стандартизована модель коннекторов.

Все компоненты J2EE имеют одно общее свойство: они должны быть написаны на языке Java. Исключением являются только клиентские приложения. Стандарт разрешает CORBA-клиентам взаимодействовать с серверными компонентами J2EE. Вместе с тем компоненты J2EE отличаются от других J2EE-приложений по нескольким параметрам:

Клиенты J2EE-приложений могут быть нескольких типов. Кроме упоминаемых выше CORBA-клиентов можно выделить Web-клиентов, которые взаимодействуют с серверными компонентами с помощью браузеров. Такие клиенты состоят из двух частей:

Мода на Web-клиентов вернула нас к тонким или даже сверхтонким клиентам.

Основным элементом J2EE, несомненно, является компонентная модель Enterprise JavaBeans. Можно сказать, что J2EE предоставляет стандартное API, инфраструктуру и набор типовых клиентов для EJB.

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

Архитектура J2EE через контейнеры поддерживает различные модели для прикладных сервисов: безопасности, транзакций и наименований. Контейнеры также отвечают за жизненный цикл компонентов J2EE и взаимодействие с хранимыми данными. Мы опишем соответствующие контейнеры в главах 9, 13 и 14, посвященных EJB, сервлетам и JSP.

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

В главе 9 вы сможете узнать про роли, относящиеся к созданию компонентов EJB, а в главе 10 вы более подробно познакомитесь со структурой серверной и клиентской частей J2EE-приложений и архивными файлами.

1.2.2. Область применения J2EE

Наши достоинства — продолжение наших недостатков. То, что технология J2EE ориентирована на один язык программирования, причем молодой и прогрессивный, позволило ей избежать многих проблем, с которыми столкнулась, например, CORBA. Все вы знаете, в каких муках рождалась компонентная модель CORBA, хотя, казалось бы, после появления стандарта EJB надо было только еще немного расширить эту модель.

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

Сертификация программных продуктов (серверов приложений) по J2EE выполняется с помощью набора тестов, разработанных компанией Sun, — J2EE Compatibility Test Suite. Тесты включают проверку всех классов и методов, упоминаемых в спецификации J2EE, а также проверку взаимодействия всех компонентов спецификации. Программные продукты, выполняющиеся на программных продуктах (серверах приложений), сертифицированных на соответствие одному и тому же релизу, должны быть портируемыми. Это позволяет переносить приложения с одного сервера приложений на другой без изменения исходного кода1. Список серверов приложений, прошедших тесты, вы можете найти на http://java.sun.com/j2ee/compatibility.html.

Серверы приложений наиболее активно используются для создания Web-приложений. Пережив всплеск повышенного спроса, Web-приложения постепенно занимают свое достойное место в компьютерном мире. Именно серверы приложений позволяют относительно быстро создавать гибкие, масштабируемые и производительные Web-порталы. На самом деле пока нет технологии, которая бы лучше подходила для этих целей. Но не будем ограничивать область применения серверов приложений только порталами. Нам известны успешные примеры создания J2EE-приложений корпоративного уровня, реализующих функциональность ERP- и CRM-систем. И мы верим, что количество подобных приложений будет расти вместе с развитием технологии J2EE.

1.3. Технология .NET

Мы с трудом преодолели соблазн обойти одиозную тему в нашей книге. Но по зрелому размышлению решили, что не сказать ничего просто не можем.

Можно по-разному относиться к компании Microsoft, но честно признаемся, что и в офисе, и дома мы используем именно операционную систему Windows2. И мы уверены, что не одиноки. Конечно, любая книга ограничена, да мы и не претендуем на роль экспертов в области .NET. Поэтому в этом разделе мы не будем углубляться в технические детали, а выскажем свой взгляд на технологию, которая является противовесом первым двум, рассмотренным в этой главе.

1.3.1. Краткий обзор технологии .NET

Компонентная идея заразила Microsoft еще в начале 90-х годов. Как и другим компаниям, ей стало очевидно, что скорость создания программных систем существенно отстает от предъявляемых бизнесом требований. Вместе с тем, из программы в программу повторяются общие элементы, которые программисты исправно пишут, каждый раз изобретая велосипед. Во многом повторяя идеи, заложенные в CORBA (в частности, язык описания интерфейсов), Microsoft создала технологию COM, первая версия которой появилась в 1993 году. Однако не секрет, что COM имеет существенные недостатки. Прежде всего, COM поддерживает взаимоотношение приложений, выполняющихся на одном компьютере, что, согласитесь, в современном распределенном мире не всегда удобно. Попытки Microsoft устранить этот досадный недостаток с помощью DCOM (Distributed COM), как и всякое латание дыр, не привело к ожидаемым результатам, и тогда Microsoft приняла единственно верное решение. На базе COM и сервера транзакций Microsoft Transaction Server была разработана специальная технология .NET. Впрочем, процесс разработки .NET продолжается.

В соответствии с определением, Microsoft .NET — это среда выполнения Web-приложений в ОС Windows 2000. Цель создания .NET все та же — сократить и упростить разработку, внедрение и поддержку распределенных программных систем, в данном случае — функционирующих на платформах Windows. Среда .NET добавляет к операционной системе Windows такие важные функции, как автоматическая сборка мусора и простой доступ к базам данных и Интернету, и расширяет компонентную модель COM+. Она развивает среду ASP (Active Server Page), созданную Microsoft в 1997 году как элемент Internet Information Server, который входил в Windows NT 4 Option Pack.

Основная идея .NET заключается в понятии управляемого кода, который выполняется не просто на операционной системе Windows, а под управлением ее дополнительного элемента — среды CLR (Common Language Runtime) — общей среды выполнения для программных приложений, написанных на различных языках. CLR очень похожа на Java Runtime Environment (JRE). При этом программы (с помощью, например, Visual Sudio .NET) компилируются в код на специальном языке Microsoft Intermediate Language (MSIL, или IL). Среда CLR, в частности, освобождает программистов от сборки мусора не хуже, чем Java, проводя автоматическую чистку неиспользуемой памяти (garbage collection). На нее также возложено управление доступом к программному коду.

В настоящее время существует множество компиляторов программных языков в IL, в дополнение к предоставляемым Microsoft для Visual Basic, C#, JScript и C++. Такая унификация вынудила Microsoft сблизить языки, которые поддерживаются в Visual Studio .Net. Особенно это касается новой версии Visual Basic.

Для того чтобы выполняться на конкретной операционной платформе (которых в семействе Windows тоже предостаточно), код на IL должен быть обработан just-in-time-компилятором (JITter), после чего и получается соответствующий машинный код. В настоящее время существуют JITter для Windows 2000 и Windows XP.

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

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

Для динамического Web .NET предлагает модернизированную среду ASP .NET. В ней реализована идея отделения динамического кода от статического текста HTML-страниц, причем первый можно создавать и отлаживать в Visual Studio с помощью специальной модели Web Forms. Кроме того, ASP .NET выгодно отличается от просто ASP в возможностях сохранения состояния сессий. Конфигурационная информация Web-приложения хранится в специальном файле в формате XML, так же как и в J2EE.

Нельзя говорить о .NET и ни слова не сказать о Web-сервисах - новом направлении развития Интернета, которое по замыслу его создателей Microsoft и IBM позволит приложениям взаимодействовать, динамически отыскивая в глобальной сети необходимые сервисы и вызывая их по мере необходимости. Web-сервисы используют для передачи сообщений протокол SOAP (Simple Object Access Protocol), описываются на языке WSDL (Web Services Definition Language) и используют механизм UDDI (Universal Description, Discovery and Integration) для публикации и поиска сервисов. Все эти элементы представляют собой спецификации международной организации W3C и активно развиваются.

Для поддержки Web-сервисов Microsoft, опять же вместе с IBM, предложили новую архитектуру SOA (Service-Oriented Architecture), в основе которой лежит понятие сервиса как основы взаимоотношения приложений. Вокруг этого понятия можно очертить ролевой треугольник, в вершинах которого будут находиться Service requester (подписчик), запрашивающий сервис, Service provider, предоставляющий сервис, и Service broker, позволяющий подписчику найти провайдера.

Технологически .NET представляет собой семейство продуктов, основанное на известных стандартах в области бизнеса и Интернета, и объединяет следующие типы серверов, каждый из которых обладает собственной функциональностью и представляет собой отдельный продукт:

1.3.2. BizTalk, или Как легко интегрировать приложения

BizTalk является развитием идей, заложенных Microsoft в Commerce Interchange Pipeline и Commerce Interchange Pipeline Manager (дополнительные элементы Site Server 3.0 Commerce Edition). BizTalk использует ту же самую библиотеку Pipecomplib.tlb.

Сервер BizTalk представляет собой интеграционный сервер и набор эффективных средств для построения и развертывания бизнес-процессов для осуществления транзакций в области EAI (Enterprise Application Integration) и B2B (Business-to-Business). Он поддерживает разнообразные протоколы, среди которых HTTP, HTTPS, SMTP, SSL, S/MIME (Secure Multipurpose Internet Mail Extensions) и SOAP.

BizTalk позиционируется Microsoft как ключевой элемент для поддержки основанных на XML бизнес-процессов, в которых могут участвовать не только разные приложения, но и разные компании.

BizTalk включает графические средства. Перечислим некоторые из них.

Основными компонентами BizTalk являются Application Integration Component (AIC) и компоненты типа pipeline, которые напрямую происходят от pipeline component (типа Order Processing и Commerce Interchange) Microsoft Site Server 3.0. Другой важный элемент сервера — пользовательские препроцессоры, которые используются для предварительной обработки документов, если ее необходимо произвести до передачи документа BizTalk серверу.

BizTalk включает в себя так называемые сервисы передачи и обработки сообщений (Messaging Services), хотя в данном случае это касается не столько сообщений, сколько документов. Эти сервисы умеют:

Последняя версия BizTalk Server 2002 обладает рядом полезных особенностей. Для развертывания компонентов BizTalk используется Application Center 2000. Появился новый элемент — Windows Management Instrumentation (WMI), который позволяет управлять бизнес-процессами с помощью графического интерфейса. Новый сервер включает SOAP Toolkit 2.0, который может синхронизировать бизнес-процессы, включающие использование Web-сервисов.

В настоящее время уже создано некоторое количество адаптеров, позволяющих соединять BizTalk-сервер с различными корпоративными приложениями, например SAP, Oracle Financials, People Soft, Siebel, Remedy. Вы можете получить информацию о доступных адаптерах на странице www.microsoft.com/biztalk/evaluation/adapters.asp.

BizTalk привлекает своей простотой, доступностью, интеграцией с VisioStudio .NET и удобными средствами администрирования. Возможно, это решение будет наиболее популярным для интеграции Windows-приложений, основанной на обмене документами между приложениями, например, в области электронной коммерции, на ближайшие несколько лет.

1.4. Сравнение CORBA, J2EE и .NET

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

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

1.4.1. Сравнение идеологических подходов

Все три технологии представляют собой решение из области Enterprise Integration Application (EAI). Утвердившийся подход к интеграции приложений заключается в описании внешних интерфейсов, форматов сообщений и спецификаций, используемых для передачи этих сообщений. В процесс интеграции в современном понимании этой задачи также вовлечено понятие Quality-of-Service, в особенности все, что касается сервисов безопасности, надежности и транзакционной целостности. Но создатели всех трех технологий почувствовали, что этого недостаточно. Интеграция программных приложений, так же как и сами приложения, реализует потребности бизнеса, поэтому необходимо привлечь в интеграционную модель элементы описания бизнес-процессов.

Пожалуй, как и во многих других случаях, первопроходцем выступило OMG, которое в конце 90-х годов выпустило несколько спецификаций, формализующих понятие бизнес-объекта, средств управления бизнес-объектами и среды их функционирования (Business Object Facility (BOF) и Business Object Component Architecture (BOCA)). Стандарты моделирования OMG (UML, MOF, MDA) также позволяют связать бизнес-модель распределенной системы с техническими средствами CORBA и ее компонентной модели.

Технология J2EE пока не стандартизовала средства моделирования и проектирования бизнес-процессов. Но в реальности большинство средств разработки содержат встроенные средства моделирования, которые позволяют автоматически генерировать компоненты J2EE на основе бизнес-моделей. Приведем в качестве примера JBuilder 6 Enterprise Edition компании Borland.

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

Еще одна важная особенность всех трех технологий связана с их местом в общей иерархии программного обеспечения. По сути, любая из рассмотренных нами сред представляет собой промежуточное программное обеспечение. Однако для всех трех (хотя для CORBA в меньшей степени) характерно постепенное сращивание с операционными платформами. И если .NET можно рассматривать как новую версию Windows 2000, то Sun One, недавно анонсированная Sun Microsystems, интегрирована и с аппаратной платформой.

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

Вы можете увидеть отчетливую аналогию между ASP и JSP, недаром их названия настолько созвучны. Обе технологии: и J2EE, и .NET — придерживаются сходных подходов к созданию и обработке динамических Web-страниц. И это нас совершенно не удивляет.

Мы можем также проследить аналогию между другими Web-компонентами: сервлетами и Web Forms Server Control (серверные элементы управления динамическими страницами в ASP .NET). Но надеемся, что вы уже поняли, насколько схожи идеи, лежащие в основе соперничающих технологий.

1.4.2. Сравнение с точки зрения применения

Как же выбрать тогда технологию, наилучшим образом подходящую к решению конкретной задачи? Можно, конечно, обратиться к результатам тестов на производительность. В этом случае можем отослать вас к тестированию любимого примера Sun для J2EE, а именно магазина Pet Shop на платформе Oracle 9i Application Server. Результаты теста производительности приведены по адресу http://otn.oracle.com/tech/java/oc4j/content.html. Можно также попытаться оценить выбираемую стратегическую платформу по нескольким критериям. В качестве примера можем порекомендовать следующие:

Необходимо отметить, что по оценке Gartner Group по триаде «стоимость — риск — время на разработку» компонентная модель EJB уверенно побеждает COM. Gartner Group в отчете «Application Development Management Strategies» (декабрь 2001 г.) называют J2EE основной архитектурой для корпоративных приложений на ближайшие несколько лет. По их отзывам альтернативная технология Microsoft .NET и архитектура SOA (Service-Oriented Architecture) далеко еще не достигли ее уровня.

Аналитики Gartner Group прогнозируют завоевание технологией .NET мирового компьютерного рынка в конце 2003 года. По их мнению, именно тогда .NET достигнет необходимой зрелости и завершенности. Мы в этом смысле не столь категоричны и думаем, что к середине десятилетия две альтернативные платформы поделят рынок примерно поровну. При этом мы прогнозируем продолжение плодотворной конвергенции CORBA и J2EE.

Подведем некоторые итоги. На основе заключений экспертов, мнений пользователей и специалистов можно сделать некоторые выводы. Технология CORBA предоставляет уникальные возможности интеграции и поэтому должна применяться в сложных гетерогенных средах. Ее использование необходимо, например, при интеграции с legacy-приложениями. Технология .NET еще не окончательно доработана, поэтому применять ее надо осторожно, а лучше дождаться следующих версий. Добавим, что компонентная модель CORBA только-только появилась и поэтому никак не может конкурировать с компонентной моделью EJB, которая лежит в основе J2EE. Поэтому можно сделать вывод, что наиболее популярная, востребованная, используемая и доступная технология распределенных компонентных систем в настоящее время — это J2EE.

Основная претензия к технологии Java и, в частности, к J2EE — ее слабая производительность, которая особенно заметна на платформах Windows и вообще на любых платформах, отличных от Sun. Закон Мура, без упоминания которого не обходится ни одна компьютерная книжка (вот и мы не утерпели), гласит, что вычислительная мощность на единицу стоимости удваивается каждые восемнадцать месяцев. К чему это мы? Да к тому, что повысить производительность J2EE-приложений можно ведь и таким способом, что, собственно, весьма успешно и происходит на наших глазах.

1.4.3. Взаимное влияние

Мы уже много говорили о том, насколько похожи все три технологии. Мы с удивлением обнаружили в описании Web-сервисов от Microsoft упоминание протокола IIOP в одном ряду с DCOM и RMI. В рамках CORBA стандартизованы программные мосты CORBA-COM и COM-CORBA. J2EE активно использует стандарты CORBA, в частности IIOP (Internet Inter ORB Protocol) и системные сервисы. Как известно, в настоящее время CORBA-приложения и J2EE-приложения умеют взаимодействовать друг с другом практически в любой ситуации. И дальше в книге мы покажем, что компонентная модель CORBA включает компоненты EJB как полноправные составляющие (причем как в качестве клиента, так и в качестве сервера).

Мы уже останавливались на общих принципах и идеях, заложенных в каждую из технологий. Символично в этом смысле использование столь похожей на JVM CLR в .NET.

Новый стандарт OMG — MDA (Model-Driven Architecture) объединяет под своим крылом все три технологии. Построение независимой от платформы бизнес-модели позволяет в дальнейшем портировать такую модель на различные платформы middleware. Автоматическая генерация большей части кода сможет существенно сократить труд разработчика и повысить качество создаваемых программных систем. MDA упростит также интеграцию программных систем, функционирующих на различных платформах, с помощью построения отображения сходных сущностей. В рамках MDA уже стандартизован профиль CORBA, ведется работа над созданием аналогичных профилей для J2EE и .NET.

1.5. Заключение

На этом мы заканчиваем краткое описание трех технологий для распределенных программных систем. В дальнейшем в нашей книге вы встретитесь с двумя из них: CORBA и J2EE — прежде всего потому, что они очень тесно связаны друг с другом, причем не только идеологически, но и технически. Нам показалось особенно полезным объединить в одной книге описание современного состояния этих технологий и показать, как их можно использовать совместно.

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