Выпуском окончательного релиза Visual Studio .Net (13 февраля) Microsoft перешла к очной фазе борьбы против Java. До этого работали в основном пиаровские и маркетинговые орудия. Теперь у Microsoft есть продукт, который может потеснить J2EE. У Java, несомненно, есть определенное преимущество, де-факто J2EE - платформа номер один для корпоративных распределенных приложений. Microsoft изо всех сил пытается задавить ее с помощью .Net. Кто победит в этой схватке? Кого предпочтут разработчики и корпоративные пользователи?

Java первой фазы

Когда в конце 1995 года почти без всякой рекламы Sun выпустила бета-версию Java, новый язык ждал королевский прием. Пресса буквально захлебывались от восторга, превознося его потенциал. Дошло даже до того, что журнал Time включил предварительный выпуск Java в список продуктов года, и это был единственный компьютерный продукт во всем списке.В 1995--1996 годах Java -- это было модно, это было круто.

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

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

Однако вскоре выяснилось, что портативность с клиентской стороны -- это хорошо, но есть и серьезные проблемы. Первой проблемой была скорость исполнения приложения, что привело к решению вернуться к HTML в качестве пользовательского интерфейса и использовать Java на сервере. Второй проблемой оказалась firewall-защита - системные администраторы не хотели открывать другие порты помимо HTTP, HTTPS и FTP из соображений безопасности. Выходом стало преобразование в HTTP или HTTPS (с SSL), поскольку этот порт уже открыт, программисты умеют с ним работать и это достаточно просто. То есть Java вынужден был еще больше переместиться на серверную сторону.

Если вернуться к непомерным восторгам по поводу Java и разобраться в их причинах, то в первую очередь их следует приписать тому обстоятельству, что этот язык был выпущен не Microsoft. По сути в восторгах относительно Java в 1995-1996 годах воплотилась вся ненависть компьютерного и некомпьютерного мира (или, по крайней мере, значительной его части) к детищу Билла Гейтса.

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

Тезис о том, что Java - это незрелый продукт, был верен многие годы. Однако Sun и Java-сообщество активно развивали язык, снабжая его все новыми и новыми функциями и возможностями. В результате на протяжении последних пяти лет Java сильно повзрослел и как язык и как платформа для клиентских и серверных приложений. Для клиентских приложений Java сегодня предлагает высокий уровень связности при подключении к базам данных, работающим на различных платформах. Они гладко интегрируются с традиционными системами. Они позволяют осуществлять быструю разработку и реализацию клиентских приложений, используя компонентную модель JavaBeans, входящую в Java Developers Kit (JDK). Поскольку эти компоненты могут быть распределены по многим компьютерам в разных частях сети, они являются ключевым элементом при разработке распределенных корпоративных компьютерных технологий. Это подготовило почву для перевода Java на распределенные приложения и для начала серверных разработок.

С клиентов - на серверы

Сегодня Java - это прежде всего язык для серверной стороны. Некоторые до сих пор используют его на клиентской стороне с Swing или AWT, а некоторые пишут апплеты, однако в основном Java сейчас используется с Enterprise Java Beans (EJB) и Servlets - технологиями серверной стороны.

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

Еще с появлением компонентной модели JavaBeans на платформе Java прочно закрепились передовые объектно-ориентированные технологии, основанные сразу на двух различных архитектурах программных компонентов для распределенных систем: стандарте CORBA, разработанном индустриальным консорциумом Object Management Group, и RMI (Remote Method Invocation) компании Sun Microsystems. CORBA и RMI предоставляют основу для постройки компонентных приложений, которые исполняются на различных серверах сети.

Возможно, сейчас мы снова имеем сильную антимайкрософтовскую коалицию. Пока союзники по Java-коалиции вместе, шансы Microsoft малы. Но как долго они будут оставаться вместе?

Наличие CORBA и RMI позволило разработчикам гладко переходить на EJB -- Enterprise JavaBeans. EJB -- модель распределенных компонентов для Java, которая расширяет возможности JavaBeans для использования в распределенных корпоративных приложениях, обеспечивая поддержку транзакций, моделей безопасности и управления. Обеспечивая работу подобных общих услуг и прочих низкоуровневых системных компонентов корпоративной платформы, EJB освобождает время разработчиков для того, чтобы они могли сконцентрироваться на создании бизнес-логики для своих корпоративных приложений.

Технологии Java Native Interface и "утилизация мусора" (garbage collection) повзрослели и окрепли настолько, что разработка сетевых распределенных приложений стала значительно проще. Хотя Perl и CGI всегда будут иметь сторонников для создания приложений на основе веб-технологий, если мы говорим о надежных объектно-ориентированных и, что главное, ремонтируемых приложениях, подавляющее большинство компании склоняются к использованию J2SE и J2EE. Вдобавок Java имеет гигантскую библиотечную базу. Вы можете найти класс практически для любых нужд, что позволяет избежать специального программирования. Трудно переоценить то количество времени, которое такой фундаментальный объектно-ориентированный подход может сэкономить разработчикам.

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

Наступление J2EE было стремительным. За короткий срок были созданы серверы приложений стандарта J2EE, и язык "пошел". Сведения о том, что J2EE работает хорошо, распространялись достаточно быстро. Более дюжины серверов приложений совместимы с J2EE, и совместимость стала обязательным условием для серверов приложений, если они хотят остаться на плаву.

Функционально богатые корпоративные Java-приложения сегодня разрабатываются в разнообразных индустриях. Например, брокерская фирма с Уолл-стрита использует Java-сервер для того, чтобы позволить своим пользователям легко и просто получать доступ к информации, хранящейся в различных базах данных фирмы. Другая исследовательская фирма по информационным технологиям использует Java-сервер для обработки самых сложных клиентских запросов на поиск информации одновременно в Lotus Notes, базах данных SQL и поисковой системе Verity.

Сегодня Java играет ключевую роль в обработке клиентских запросов и предоставлении доступа к различным разбросанным по сети серверам и услугам.

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

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

В глубь корпоративных систем

Sun и сообщество Java делают все, чтобы на следующем этапе развития Java стал играть центральную роль в обработке корпоративной информации, в том числе в создании веб-услуг корпоративного уровня. Sun постоянно включает в J2EE много новых спецификаций. Последний релиз Java -- J2EE версии 1.3, представленный в конце 2001 года, включил в себя долгожданные возможности Enterprise JavaBeans 2.0, что превратило его в целую платформу для создания сетевых приложений, работающих со всевозможными устройствами - от ноутбуков до мэйнфреймов.

В будущем корпоративные Java-приложения должны научиться управлять данными согласованно с базами данных. Это приведет к тому, что Java-процедуры начнут также храниться в качестве компонентов непосредственно в базах данных. Базы данных Java обещают стать заметным явлением. Такие базы данных, как PointBase (www.pointbase.com) являются стопроцентно базами данных Java - они негромоздки и имеют изящные механизмы репликации. Вероятно, в одной из будущих версий в J2EE войдут спецификации для балансировки нагрузок и восстановления после сбоев, поскольку эта концепция реализуется в большинстве серверов приложений, однако пока что она не стандартизирована. Что касается ближайшей новой версии -- J2EE 1.4, то она должна включить полную поддержку стандартов веб-сервисов, чтобы наверстать отставание от .Net.

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

Java отнюдь не собирается уходить с серверной арены, однако мы наблюдаем тенденцию по переводу Java на мобильные устройства. Предельно развитая и гибкая поддержка различных клиентских устройств -- следствие ее клиентоориентированного прошлого -- очень сильный козырь Java. Java будет работать на различных сотовых телефонах и PDA-устройствах в версии J2ME. Сегодня версия J2ME готова к работе, однако лишь небольшой набор аппаратов обладают достаточной памятью, чтобы поддерживать другие языки программирования помимо WML и WML Script. Созданная в декабре 2001 года коалиция компаний вокруг разработки стандарта подключения сотовых телефонов и других мобильных устройств к интернету (с участием IBM, Sun, BEA, HP, Borland, Oracle и ряда других) активно ведет работу над новым стандартом и надеется включить его уже в следующую версию (1.4) J2EE, которая должна выйти в конце 2002 или начале 2003 года.

.Net как платформа

На протяжении всего 2001 года Microsoft не сходила с первых сраниц специализированных изданий, неуклонно продвигая свою концепцию построения распределенных корпоративных приложений через веб-услуги на основе XML-контента, удаленных коммуникаций на основе SOAP и поиска услуг на основе UDDI. Microsoft.Net -- это титанический проект, это единая концепция разработки нового ПО; набор продуктов для постройки такого ПО; и набор веб-услуг под названием .Net My Services. Не надо думать, что это стопроцентно новая технология. Часть технологий, включенных в .Net, используется уже многие годы. Однако "для Microsoft это революционный подход. Я видел как создавались и уходили в прошлое многие продукты Microsoft, и это станет самым значительным скачком за целое поколение", - считает Билл Эвьен, веб-разработчик и основатель организации в St. Louis .Net User Group. Gartner Group также полагает, что .Net -- действительно новая платформа, а не очередная версия Windows и не COM++ (хотя и тесно связана с нынешней COM+), как новая версия Visual Studio -- не Visual Studio 7.0. Упрощенно можно представить старую платформу как Win API + COM+, а новую -- как CLR + XML Web-services.

XML широко используется в веб-услугах Microsoft, потому что .Net имеет весьма слабосвязанную архитектуру. Чтобы веб-услуги работали, они должны быть слабосвязанными. Слабосвязанными или асинхронными системами называются такие, в которых один конец транзакции не дожидается отклика с другого конца. Хороший пример асинхронного приложения представляют собой клиенты электронной почты. Синхронные коммуникации, использовавшиеся в старых клиент-серверных приложениях, могут привести к тому, что клиент окажется заперт в ожидании отклика. Например, системы запросов баз данных часто поддерживают синхронные транзакции; это означает, что для продолжения работы с приложением вам нужно дождаться, пока данные запроса будут возвращены.

У Java несомненно есть определенное преимущество, но долго ли Java продержится на вершине?

В ядре структуры .Net лежит Common Language Runtime (CLR), набор библиотек классов, которые исполняют приложения и поддерживают безопасность и целостность приложений, а также управляют взаимосвязью между компонентами. В технологии CLR Microsoft смогла реализовать несколько действительно существенных новинок.

1. Более совершенная модель безопасности. CLR предлагает гораздо более детальную систему безопасности по сравнению с тем, что было раньше, когда пользователь мог делать выбор между полномасштабной защитой и полным ее отсутствием. Новая модель безопасности позволяет приложениям запрашивать наборы разрешений для выполнения своих функций. Затем CLR сравнивает действия, которые пытается произвести приложение с установленным набором разрешений. Если они не совпадают, CLR немедленно блокирует приложение как недейственное либо содержащее вирус.

2. Повышенное удобство работы. Microsoft удалось наконец избежать DLL-ада, который является проклятием для многих администраторов. Проверяя свои собственные зависимости, приложение определяет, все ли необходимые для работы компоненты установлены в системе. Если зависимость не выполнена, CLR может получить необходимые классы из надежного источника, скачать и установить их. Другим устраненным неудобством будет реестр, что само по себе уже оправдывает установку .Net. Microsoft поддерживает концепцию "no-touch deployment" -- это означает, что системе не требуются компоненты реестра, поскольку приложения описывают себя самостоятельно и могут находить свои собственные компоненты.

3. Многоплатформность. Точнее, многоплатформность в трактовке Microsoft.

CLR выполняет роль универсального механизма исполнения кодов разработчиков. В отличие от других "движков", которые привязаны к своим собственным языкам или платформам, Common Language Runtime сможет исполнять программы, написанные на любом языке. Это происходит оттого, что программисты пишут приложения, опираясь на CLR, а не на Win32 API. CLR предлагает межъязыковую наследственность, межъязыковую отладку приложений и межъязыковое исправление ошибок. Теоретически (на практике пока это не было сделано) компонент, написанный на Коболе, сможет наследовать свойства PERL-приложения и наоборот. Это происходит посредством обертывания XML-парсера вокруг существующего объекта, так, чтобы объект мог взаимодействовать с обложкой, преобразовывать данные в XML и посылать их объекту-получателю, также имеющему XML-обложку.

".Net несомненно упростит процесс интеграции, поскольку это полноценный комплект для компаний, которые хотят реализовывать многочисленные новые технологии, - говорит Роб Эндерл, вице-президент Giga Information Group. - Он позволяет добиться более тесной интеграции стандартов, нежели даже сами органы по определению стандартов, работающие над данной проблемой, - Microsoft продемонстрировала завидную способность поддерживать эти стандарты".

Кроме того, для .Net Microsoft разработала новый язык программирования C# (произносится Си-шарп), который вошел в набор Visual Studio.Net. C# создан на основе C и C++; к ним Microsoft добавила поддержку XML и SOAP, однако без некоторых возможностей, вроде множественной наследственности, делавших C++ такой головной болью. C# разработан для слабосвязанных сред, какую представляет собой.Net. Традиционные модели распределенных объектов, такие как COM, DCOM, CORBA и EJB, являются сильносвязанными и потому не очень хорошо работают (если вообще работают) в сочетании с firewall. C# работает с firewall-защитой и поддерживает асинхронные коммуникации между приложениями, если они оба поддерживают SOAP и XML. C# может использоваться для создания приложений .Net или для обертки старых приложений, чтобы они могли взаимодействовать со средой .Net. Новый язык также включает возможности "сборки мусора", чтобы программистам не нужно было заботиться об управлении памятью и автоматической инициализации переменных, что позволило преодолеть еще два недостатка C++.

J2EE или .Net?

Только что появившийся новый язык разработки C#, гордость и надежда Microsoft, пока не занимает и микроскопической доли рынка, тогда как Java -- язык программирования номер один в мире. Однако после выхода C# разработчикам придется решать вопрос доверия к .Net и выбора платформы.

Некоторые специалисты считают, что C# несет погибель Java, что разработчики перейдут на него и виновата в этом будет Sun. "Сегодня Java начинает понемногу сдавать, по мере того как C# занимает доминирующие позиции, -- считает Роберт Крингли из Public Broadcasting Company. -- Я бы не хотел, чтобы это было так, но каждый получает по заслугам". Часть специалистов считает, что интерес сообщества программистов уверенно движется от Java к C# и .Net. Попробуем проанализировать проблему выбора с трех сторон.

В технологическом плане сейчас .Net слабее, но каково будет развитие событий, пока неясно.

1. Рыночный вес. Это огромный, наверное, даже главный аргумент в пользу Microsoft. Многие считают, что у Microsoft нет достойный конкурентов, "поскольку им не хватает сил и целеустремленности", и что "Microsoft покажет Java, где раки зимуют". Но может статься, что вес Microsoft сыграет с ней злую шутку. "Интернет -- это еще одна вещь, которую во имя будущего прогресса необходимо оградить от единоличного контроля Microsoft ", -- заявил президент Sun Эд Зандер во время открытия конференции JavaOne. Очевидно, Sun разыгрывает карту "Microsoft -- империя зла и Java -- единственное оружие в борьбе с ней". Здесь монстрообразность Microsoft весьма кстати и эта логика действует на многих.

Кроме того, огромные рыночные преимущества Microsoft привели к тому, что против нее выступают почти все остальные крупные игроки рынка. Возможно, Sun и менее уверена в своем проекте Sun ONE (Open Net Environment), и имеет меньше ресурсов, чем Microsoft, однако она совсем не одинока. Вокруг Java объединилась не только разработчики открытого ПО, но и индустриальные гиганты, такие, как IBM, Oracle, BEA, HP, Borland и ряд других. Эта коалиция несомненно обладает большим рыночным весом, чем Microsoft.

В восторгах относительно Java в 1995-1996 годах воплотилась вся ненависть компьютерного и некомпьютерного мира к Microsoft.

Но внутри нее происходит серьезная борьба. Тот факт, что в спецификации J2EE 1.3 не было веб-услуг, сильно играет на руку Microsoft. По существу все лидирующие производители платформ J2EE были вынуждены предлагать для работы с веб-услугами собственные фирменные расширения. Это позволило некоторым аналитикам предположить, что Java-платформа может рассыпаться на части, поскольку независимых поставщиков инструментов для разработки больше интересуют закупки своего ПО и вертикальные интегрированные решения, построенные на основе их собственной интеллектуальной собственности, вместо развития известного кредо Java "написать один раз и использовать повсюду".

Так, например, IBM запустила проект Eclipse, который нацелен на то, чтобы обеспечить такую интеграцию инструментов разработки на Java, чтобы можно было совместно использовать инструменты от разных поставщиков ПО. Этот проект поддерживают почти все разработчики Java-инструментария, кроме Sun, которую, по ее словам, "даже не пригласили" и которая чуть позже представила свой аналогичный проект -- NetBeans (по заявлениям его автора, все того же Джеймса Гослинга, он начал его раньше Eclipse и ему последний кажется подражанием).

Похоже, что IBM вела игру на вытеснение Sun с позиций куратора Java. Отчасти это понятно. Да, Sun отказалась сделать из Java собственное закрытое ПО и передала его открытому сообществу, но сохранила за собой последнее слово при лицензировании этой технологии, таким образом получив контроль за многими ключевыми решениями. Такая привелигированная позиция Sun в мало кому нравится в Java-сообществе, поэтому отчасти правы те, кто, как Джон Монтгомери, менеджер платформы .Net, утверждает, что в "сообществе разработчиков Java нет единства".

С другой стороны, картина разногласий по поводу Java наблюдается совсем не всегда. Например, в декабре 2001 года IBM, Sun и ряд других компаний сплотились вокруг создаyия стандарта подключения сотовых телефонов и других мобильных устройств к интернету. Альянс направлен, естественно, против Microsoft. Возможно, некоторое охлаждение отношенией IBM и Sun, наступившее в начале 2001 года, было обусловлено тем, что компании посчитали битву с Microsoft выигранной и занялись дележом доставшегося куска рынка. Однако, весь 2001 год Microsoft проявляла такую активность, что о распрях следовало бы забыть. Если дело обстоит именно так, то мы снова имеем сильную антимайкрософтовскую коалицию. Пока союзники по Java-коалиции вместе, шансы Microsoft малы. Но как долго они будут оставаться вместе?

2. Внимание к нуждам разработчиков. C# вытеснит Java с позиции доминирующего языка программирования, потому что Microsoft более внимательно относится к своим предложениями, чем Sun, считает часть аналитиков. Чтобы получить поддержку для .Net, Microsoft воспользовалась классическим подходом и начала работу с наиболее преданной категории пользователей -- разработчиков. Многие аналитики согласны с тем, что разработчики являются ключом к успеху .Net. "Если Microsoft удастся воссоздать прошлую модель стимулирования разработчиков к использованию их инструментов для разработки этих услуг, то она сможет укрепить свои позиции. Это проверенная модель, которая очень и очень часто выручала корпорацию раньше, - говорит Гарри Хейн, аналитик Burton Group. -- Microsoft имеет весьма значительную сеть разработчиков. Возможно, самую лучшую".

Однако, по оценкам аналитиков Gartner, только 30--40% существующего сегодня кода можно будет относительно легко перенести на новую платформу, а остальное придется переписывать и перепроектировать. И Microsoft отнюдь не собирается заниматься созданием утилит для автоматизации преобразования кода. Как обычно, инструменты, предлагаемые Microsoft для .Net, вряд ли можно назвать лучшими, однако ими легче всего пользоваться. "Сегодня у Microsoft лучше инструменты для создания простых веб-услуг", - считает Ренди Хеффнер, аналитик Giga Information Group. Но хотя Java-инструментами пользоваться сложнее, многие разработчики предпочитают именно их, потому что они более гибки, а это зачастую самое важное.

Парадигма Microsoft это "одна платформа - несколько языков", в то время как философия Java - "один язык - много платформ".

Почти все специалисты считают, что Microsoft серьезно усложнила себе жизнь атмосферой сумбура вокруг .Net. "С этим проектом не так-то просто разобраться, - говорит Билл Эвьен, основатель St. Louis .Net User Group, насчитывающей 500 членов, -- потому что.Net ужасно огромный". Часть специалистов считает, что неразбериха возникла оттого, что .Net связан со множеством идей и технологий. ".Net вовсе не так загадочен, как многие думают. Это напоминает историю о слоне и слепцах, - сказал Вилл Закманн, аналитик Meta Group. -- Мы имеем скопление всевозможный вещей, которые для разных людей означают разное". В Microsoft согласны с этим. "Потребители, несомненно, не понимают всех аспектов .Net. Ясно, что нам придется с этим поработать", - заявил Кристофер Пейн, вице-президет Microsoft.

Однако, очень многие считают, что Microsoft сама, в неуемном желании побыстрее задавить Java, породила эту неразбериху. Действительно, рекламщики компании быстро подхватили новый ярлык и начали налеплять его куда попало, например на корпоративные серверы. Представители компании стали приклеивать ярлык ".Net Enterprise Server" ко многим своим серверным программным продуктам (например, SQL Server, Exchange Server и даже Windows XP), хотя у них нет с .Net ничего общего. Более того, компания не сформулировала четко ту грань, которая отделяет текущую платформу Windows от .Net.

Еще один важный фактор -- вопрос многоплатформности, в котором у Java несомненные преимущества, но и у Microsoft кое-что есть. Парадигма Microsoft -- это "одна платформа -- несколько языков", для .Net можно вести разработки на Visual Basic, C++, C# и даже на вырожденной версии Java. Философия Java -- "один язык -- много платформ". C точки зрения Sun и Java-сообщества, это предпочтительнее, так как позволяет единообразно разрабатывать программы для разных систем, не переписывая их каждый раз. Правда, для выполнения программ в системе требуется виртуальная машина Java.

С другой стороны, Microsoft упоминала о намерении встроить CRL в другие свои платформы или, по крайней мере, опубликовать интерфейсы, чтобы другие могли писать собственные CRL для различных платформ. Если интерфейс CLR будет опубликован, вы теоретически сможете создать собственную CRL-среду для не-Windows-платформы. Microsoft все еще не решила, выпускать ли CLR в качестве продукта open source или же самой создать интерфейсы для подключения к другим платформам. Если будут созданы CLR-среды для других платформ, разработчики .Net смогут писать приложения сразу для различных платформ, в результате чего у .Net появятся межплатформные возможности, которыми так гордится Java и которые так удобны для разработчиков. Однако сегодня в отношении .Net это только фантазии, а Java уже имеет проверенную многоплатформность.

3. Технологическое лидерство. Sun упустила свое технологическое лидерство, кричат адепты Microsoft. "Несмотря на то, что C# пока что существует только в бета-версии, он уже работает лучше, чем Java. Его производительность шустрее", -- не моргнув глазом заявляют они. В ответ Джеймс Гослинг, как, впрочем, и положено вице-президенту Sun и изобретателю Java, пренебрежительно отзывается о технологичности C#: "Подражание -- чистейшая форма подхалимства, так что большое спасибо. Все же у вас, ребята (это о Microsoft), ничего не вышло, так как это тот же Java, но лишенный надежности, продуктивности и защищенности. С одной стороны, они скопировали Java, а с другой -- добавили всякие неуместные глупости".

Но это просто петушиные крики, не более того. Аргумент в пользу .Net, приводимый аналитиком Gartner Марком Драйвером, гораздо серьезнее. Спецификация J2EE 1.3 заслуженно подверглась критике за то, что в ее рамках не предлагалось возможностей работы с веб-услугами. "Они просто отстали. У них представления о Microsoft десятилетней давности, -- говорит Драйвер о Sun. -- Они стали слишком самодовольны и опоздали с выдвижением стратегии веб-вервисов". Драйвер считает, что в области веб-вервисов Sun отстала примерно на год.

Однако веб-сервисы -- это все-таки будущее, а разработками заниматься надо сейчас. Апу Шах, консультант из Бомбейской компании Mumbai, разрабатывающей ПО на заказ, говорит: "Дайте мне хотя бы одну достойную причину для перехода на C#. Более тесная интеграция с Windows? Нет, я предпочитаю межплатформную функциональность. Легкость доступа к объектам COM? Нет, на Java COM-шлюз прекрасно работает. Скорость? Но как C# может быть намного быстрее, если он использует интерпретированный рабочий цикл? Простота использования? Да ведь придется заново изучать синтаксис, ошибки компилятора, IDE и философию языка.

Если поместить Java бок о бок с C#, то мы не увидим ничего нового, революционного или достаточно привлекательного, что могло бы оправдать переход. Факты остаются фактами: Java еще многие годы будет оставаться более надежным, более открытым, более зрелым и более оригинальным языком, чем C#. Специалисты по технологиям предпочитают взвешивать возможности, вместо того чтобы идти на поводу у голословных обещаний".

Однако это сейчас. А аналитик Meta Group Вилл Закманн вспоминает, как в начале 1980-х годов Microsoft выходила на рынок текстовых процессоров, находясь на смехотворно низких позициях (тогда WordPerfect имел около 80% рынка). И Microsoft стала методично, версию за версией, предлагать свой пакет Word, пока он наконец не стал доминировать на рынке. "Microsoft предлагает вам одну версию, и вы говорите, что это интересная идея, хлопаете их по плечу и отправляете обратно в Редмонд. Они предлагают вам следующую версию, и вы говорите им, что уже гораздо лучше, но я не думаю, что я бы когда-нибудь стал этим пользоваться. Однако они продолжают предлагать вам все новые и новые версии, каждый раз чуть-чуть лучше, - говорит Закманн. - Они их улучшают, они уделяют этому внимание. По-моему, то же самое будет происходить с .Net". В технологическом плане сейчас .Net слабее, но каково будет развитие событий, пока неясно.

Вряд ли из вышеприведенных доводов можно сделать какое-либо однозначное заключение. У Java несомненно есть определенное преимущество, но долго ли Java продержится на вершине? Microsoft изо всех сил пытается задавить его с помощью C#. Если Java хочет остаться на высоте, Sun и Java-сообщество должны продолжить его совершенствование. Точно так же должна действовать и Microsoft. Сложность и напряженность конкурентной ситуации позволяют предположить, что развитие обеих технологий пойдет ускоренными темпами.

Сегодня у той и у другой стороны есть существенные преимущества и недостатки, хотя Java сейчас все-таки несколько предпочтительнее. Самое правильное -- подождать дальнейшего развития событий. Если же проблема выбора стоит сейчас, то каждый разработчик должен решить ее сам, основываясь на собственных предпочтениях и симпатиях.

Язык программирования номер один

В глубине души все были уверены, что когда-нибудь Java станет языком программирования номер один в мире. И вот это случилось. По данным Evans Data Corp., в 2002 году 55% разработчиков в Северной Америке уделят по крайней мере часть времени работе с Java. Прирост числа сторонников Java произойдет за счет сегодняшних приверженцев C/C++ и Visual Basic, считает вице-президент Evans по разработкам Джанел Гарвин. В 2002 году, по ее оценкам, лишь около 51% разработчиков будут по-прежнему работать с C и C++. Кроме того, процесс перехода на Java будет достаточно активным. Согласно оценкам Evans, к концу 2002 года доля Java-разработчиков среди всего программного населения будет составлять 60%.

Молодые разработчики, оканчивающие средние школы или местные университеты, теперь изучают Java в первую очередь. Да, они, конечно, уделят какое-то внимание C и C++, а некоторые займутся изучением Visual Basic, однако большинство новоиспеченных программистов, с которыми мне приходится общаться, гораздо лучше знают Enterprise JavaBeans, чем Microsoft Foundation Classes.

Кроме того, похоже, что Java не просто популярен - теперь он охватывает весь спектр компьютерных устройств. Evans обнаружила, что 32% разработчиков беспроводных технологий работают с Java-устройствами и J2ME, 24,5% с Palm OS, а 22,3% - с Windows CE.

Преодолевая кавардак С++

Сегодня Java - язык программирования номер один в мире. Не надо долго думать, чтобы понять, почему Java приобрел такую популярность.

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

С точки зрения удобства для разработчика Java тоже несовершенен. Если, например, я хочу создать инструмент регистрации, то что лучше использовать - Log for J проекта Jakarta Open Source или logger из JDK 1.4? Я не знаю и полагаю, что большинство разработчиков также не смогут дать ответа на этот вопрос.

Тем не менее в существующем сегодня виде J2EE гораздо более строен, чем C++. Более того, частично своим успехом он обязан именно недостаткам C и C++. Поймите меня правильно: если вы пишете программы системного уровня, то вам никуда не деться от использования C и C++. В сущности, C++ можно называть ассемблером 2000-х годов. Если мне нужно будет осуществить программирование для конкретных "железок", то также стоит выбрать именно C или C++. Однако следует признать: оба они, особенно C++, стали чересчур перегруженными языками программирования.

Предположим, например, что вы решили программировать на C++ в Windows. Тогда вам нужно будет знать, скажем, Win32, Microsoft Foundation Classes, Active Template Library и COM+. И это так, для начала. Скоро, по мере роста популярности интернет-приложений, вам еще придется изучать Common Language Runtime. Сколько компонентных абстракций вам под силу разгрести на одном низкоуровневом языке? Попробуйте-ка использовать их все вместе. Microsoft просто издевается над нами!

Еще хуже быть руководителем таких проектов - где же найти программистов, которые знают все эти вещи и способны завершать проекты, ну, скажем, за полгода? Моей первой настоящей любовью среди языков был C, но покажите мне хотя бы одного C-программиста, которому не приходилось убиваться над задачей, по всем признакам тривиальной. Думаю, таких нет. Конечно, и Java-программисты тоже не всегда делают проекты в срок, и тем не менее, если бы мне поручили разработать приложение с жестким сроком сдачи, я бы выбрал только Java. По крайней мере пока не повзрослеет C#. Даниил Фертф

Месть Microsoft

Забавно вспомнить историю взаимоотношений Microsoft и Java. Когда Java только появился, Microsoft использовала свою обычную стратегию: сначала она игнорировала Java, затем высмеяла его, а после попыталась прибрать к рукам. Это ей удалось с помощью API J/Direct, который позволил Java-программам обращаться к Win32 API, и использования специфических для Windows функций в своей Java Virtual Machine. При этом Microsoft всегда подчеркивала, что, с ее точки зрения, код Java не является межплатформным, и она докажет это тем, что версия Java для Windows будет несовместима с остальными. Безупречная позиция, если конечно не учитывать вопросы совести и... право.

Оскорбленная до глубины души Sun подала в суд и выиграла дело. По завершении судебной тяжбы в 1997 году Microsoft была признана виновной в нарушении лицензионного соглашения. Компании не позволили модифицировать JVM так, как ей хотелось (это привело к тому, что ее инструмент Visual J++ был заброшен после версии 1.1) и обязали выплатить Sun $35 млн. Кроме того, в январе 2001 года Microsoft лишилась лицензии на использование новых версий Java в своих продуктах, а существующую версию она может использовать еще семь лет -- весьма чуствительный удар по компании, которая стремиться стать лидером на корпоративном рынке.

Ответ из Редмонда последовал быстро. В июле 2001 года Microsoft объявила об исключении JVM из Windows XP и браузера Internet Explorer. JVM была встроена в Windows 98 и Windows 2000, а в XP JVM--нет. (Однако вы всегда можете взять JVM у Sun и установить, если возникнет необходимость.) Ни у кого не было и тени сомнения, что это месть. Но Microsoft не остановилась на достигнутом. В середине 2001 года, спустя три года после начала судебного процесса по Java, Microsoft объявила о новом языке, прямом конкуренте Java -- C#. Хотя компания и заявила, что C# -- это развитие C и C++, однако многие специалисты считают, что это слегка переиначенная и подпорченная версия идей, заложенных в Java.

И, наконец, осенью 2001 года компания выпустила тестовую версию инструментария Visual J#.Net, которая позволяет программистам создавать Java-приложения, работающие, однако, только с платформой .Net. Аналитики предупреждают, что разработчикам надо быть крайне осторожными с Visual J#.Net. "Это незаконнорожденная версия Java, -- считает Крис Дил, аналитик Forrester Research. -- Microsoft применила лицензию на старую версию Java, которая у нее есть, но результат не отвечает текущей спецификации Sun. В этом инструменте нет поддержки J2EE". Хорошо понятно раздражение Sun по поводу этой вырожденной версии Java. "Язык Java -- это одно, а платформа -- совсем другое. Язык и виртуальная машина Java обеспечивают кросс-платформную совместимость, -- говорит Дэвид Хара из Sun. -- Однако, насколько я знаком с планами Microsoft, язык Java в них рассматривается как любой другой язык. Может быть, его и можно использовать внутри .Net, но это не означает, что он принесет те же выводы, что и платформа Java". Несмотря на формальную логичность такого шага, связанную с плавным переводом разработчиков, использующих умерший Visual J++, на .Net, многие аналитики усмотрели в этом шаге все ту же самую попытку -- дискредитировать идею кросс-платформности Java. Microsoft снова бьет в ту же точку, что и API J/Direct в 1996 году. Такая вот месть.

J2EE или .Net: прогнозы

Giga Information Group. Согласно последним двум исследованиям Giga Information Group, в ближайшие два года .Net захватит лишь около 35% рынка корпоративных разработок, оставив основную долю рынка в руках J2EE. Решающими факторами станут технологическая зрелость и гибкость в работе с различными поставщиками, сообщает отчет. То есть в двух из трех основных факторах успеха Java имеет перевес. "Потенциальным пользователям следует учитывать масштабируемость, функции восстановления после сбоев, "привязку" к поставщикам и технические требования отдельных приложений, - заявил вице-президент Giga Ренди Хеффнер. -- .Net несомненно укрепляет платформу Microsoft и позволяет ей принимать более активное участие в корпоративном рынке, однако не настолько, чтобы значительно изменить баланс. Другими словами, .Net не станет концом J2EE".

ZDNet. Похожую картину показывают опросы британского отделения Tech Update ZDNet: по данным на 21 декабря 2001 года, более 34% опрошенных собирались использовать Java для построения веб-сервисов, тогда как только 21,5% предполагали использовать для этого .Net. (Заметим, что в связи с этим Microsoft нарвалась на очередной скандал, так как уже 5 января ситуация резко изменилась - три четверти голосующих предпочли .Net. Удивленные такой переменой, специалисты ZDNet UK провели расследование, в результате которого раскрылись махинации Microsoft с голосованием. Ничего удивительного, если учесть, что в августе 2001 года в кампании по убеждению правительства отказаться от антимонопольного преследования Microsoft приняли участие два покойника. -- Прим. ред.). Опрос показывает также, что разработчики разделяются на два непримиримых лагеря -- только 6,8% специалистов собираются использовать обе платформы, и, судя по всему, они из очень крупных корпораций и в силу крайнего разнообразия задач их не может устроить одна платформа.

Gartner Group. Аналитики Gartner Group рисуют совсем другую картину. По их мнению, доля решений на .Net в области Интернет-приложений и систем для электронного бизнеса будет неуклонно расти и к 2005 году достигнет своего максимума, заняв 80% рынка. По прогнозам Gartner, к концу 2003 года платформу .Net будут использовать 30% разработчиков в среде Windows. Остальные по-прежнему будет работать на COM++. Однако уже к середине 2004 года доля использующих .Net вырастет до 70%, а к концу 2004 года -- до 95%. Учитывая поистине огромную сеть разработчиков Microsoft, которую оценивают примерно в 4 млн., это колоссальная цифра, которая и должна обеспечить 80% рынка всех интернет-разработок.

Вместе с тем Gartner советует компаниям придерживаться консервативной политики и не рисковать с применением .Net для критических приложений. Кроме того, по ее оценкам, в течение ближайших четырех лет соотношение Visual С++ и C# станет равно 2:3. Gartner отмечает, что эти разработчики будут использовать С++ на уровне системного программирования, т. е. очень значительная часть разработчиков останется верна старой платформе. Не говоря уже об адептах Java.

Сложность разработки распределенного Java-приложения

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

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

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

1. Им придется запустить код вручную и убедиться в том, что "контекст" приложения поддерживается во всех частях приложения, располагающихся на различных платформах. Поскольку не существует RAD-инструментов для разработки распределенных приложений, нужно будет писать много различных кодов.

2. Разработчики будут вынуждены работать с "инфраструктурными" проблемами, а не с проблемами приложений, которые они хотя решить в первую очередь. В идеале разработчики должны иметь возможность свободно сфокусироваться на творческих задачах, например на реализации бизнес-правил. Однако разработка распределенных приложений требует утомительной и слаборентабельной работы по созданию приложений для различных платформ - NT-серверов, UNIX-серверов, тонких клиентов-браузеров, ПК и т. д.

3. Поэтому, разработчикам недостаточно знать только Java. Понадобятся еще SQL, Visual BASIC, C, C++ или какой-либо другой язык для разработки инфраструктуры, которая позволит приложению работать на разных платформах на разных уровнях корпоративной сети. При нынешней яростной конкуренции на IT-рынке спрос на разработчиков, обладающих навыками работы с несколькими языками, значительно превышает предложение. Их сложно найти и дорого содержать.

4. Все вышеперечисленные проблемы влияют на производительность разработчиков, однако, вероятно, самой сложной задачей при разработке распределенных приложений является отладка. При совершении вышеописанной транзакции с кредитной карточкой, большая часть кодов, работающих на четырех машинах, взаимосвязана. Часто при исполнении приложения до момента сбоя разработчикам приходится анализировать и отлаживать данные на каждой машине.

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

Не конкуренты?

Спектр мнений относительно того, кто и когда победит, Java или .Net, очень широк. Находятся даже специалисты, которые считают, что противопоставлять Java и .Net неправильно - это явления двух разных уровней, взаимно дополняющие друг друга и посему не могут быть прямыми конкурентами. "Microsoft выбрала путь, противоположный Java, выбрала позицию языковой независимости для .Net вместо платформной независимости, - говорит Том Гутшмидт, ИТ-консультант из Нью-Йорка. - Это означает, что вы по-прежнему можете писать на C и даже на Java, а затем компилировать код на .Net. Я также слышал о компиляторах для Perl, CGI и т. д. Таким образом жизнеспособность конкурирующих языков увеличивается. Платформа .Net основана на XML, с которым могут работать все. Я считаю, что .Net открывает возможности для конкуренции, особенно для Sun, поэтому они могут ее спокойно игнорировать". Хотя возможно, это просто временный хитрый маневр Microsoft, ведь всем известна ее бульдожья хватка.