Архивы: по дате | по разделам | по авторам

Java vs .NET

Архив

автор : Андрей Драница 13.11.2003

Начнем по порядку — с упрощения администрирования клиентского ПО. Самый логичный ответ: проще всего управлять тем, чего нет. Нет программы — нет проблемы. А как же тогда работать с нашей БД? Через браузер.

Какие новые товары
Вступили нынче в карантин?
Пришли ли бочки жданных вин?
И что чума? и где пожары?
И нет ли голода, войны
Или подобной новизны?
А. С. Пушкин. «Евгений Онегин»

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

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

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

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

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

Казалось бы, панацея найдена, по крайней мере, с производительностью проблем уже не будет. Как бы не так — проблемы приходят оттуда, откуда не ждали. Однажды к вам заглядывает ваш заместитель и обращает внимание на некоторые «странности» в отчетности. Оказывается, в нашей многострадальной базе по неизвестным причинам периодически происходят странные изменения: исчезают и появляются «задним числом» заказы; менеджеры устраивают словесные потасовки по поводу принадлежности того или иного заказа; иногда изменяется статус, даты и цены уже выполненных заказов; по фирме поползли слухи, что кто-то «слил» базу данных по клиентам на сторону… Конечно, можно немного изменить программу, например, запретив указывать дату ранее сегодняшнего дня, но кто помешает недобросовестному сотруднику просто переставить время на своем компьютере? И как быть с другими вопросами? Кажется, выхода нет, хоть обратно к тетрадке возвращайся! Да и программист тут вроде бы не поможет — дело-то не в программах, а в людях.

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

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

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

Итак, нужно:

- еще больше упростить администрирование клиентского ПО;
- как-то связать рабочие места второго офиса с нашей БД;
- предоставить клиентам возможность связываться с нами (приобретать товары, отслеживать заказы, просматривать каталоги и т. д.) через Интернет.

Каково решение? Тонкие клиенты и веб-технологии. Начнем по порядку — с упрощения администрирования клиентского ПО. Самый логичный ответ: проще всего управлять тем, чего нет. Нет программы — нет проблемы. А как же тогда работать с нашей БД? Через браузер.

Вторая проблема — связь удаленного офиса с нашей БД. Вместо дорогостоящей выделенной линии офис-офис покупаем во вторую контору обычный модем, Интернет-карту и наслаждаемся современными технологиями за 20 долларов в месяц. При чем здесь Интернет? Смотрите дальше.

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

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

1 На самом деле, 99 процентов этих проблем можно решить и при работе в клиент-сервере. Другое дело, что «трехзвенка» позволяет локализовать модуль управления бизнес-логикой, и при внесении изменений в бизнес-логику не придется переустанавливать клиентские программы на всех компьютерах в компании. — Прим. ред.
2 Отчасти этим и объясняется высочайшая популярность Delphi в России — идеального средства как для клиент-серверного, так и трехзвенного решения.
3 Можно ограничиться и более дешевым вариантом — платным хостингом.

Веб-сервисы

Будь милостив, доступен к иноземцам,
Доверчиво их службу принимай.
А. С. Пушкин. «Борис Годунов»

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

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

Можно сказать, веб-сервисы — это способ программного доступа к веб-серверам, объединивший несколько давно используемых протоколов и технологий⁴: передача данных — HTTP, формат представления данных — XML, вызов методов и передачи данных в сервисах — SOAP (Simple Object Access Protocol), описания сервисов — язык WSDL (Web Service Description Language), структурирование, каталогизирование и поиск сервисов — служба UDDI (Universal Description, Discovery, and Integration).

Как это все работает?

Теперь коснемся технических аспектов. Можно, обойтись и без этого, работает и пусть себе работает, но здесь мы имеем дело как раз с тем случаем, когда технический момент достоин внимания. Дело в том, что практически все предшественники веб-сервисов были основаны на закрытых стандартах и отчасти поэтому не снискали славы. В основе же веб-сервисов лежат открытые стандарты и протоколы: SOAP, UDDI и WSDL.

SOAP (Simple Object Access Protocol), разработанный консорциумом W3C, определяет формат запросов к веб-сервисам. Сообщения между веб-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes; иногда их еще называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ — результат выполнения этого действия.

WSDL. Интерфейс веб-сервиса описывается в WSDL-документах (а WSDL — это подмножество XML). Перед развертыванием службы разработчик составляет ее описание на языке WSDL, указывает адрес веб-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.

UDDI (Universal Description, Discovery, and Integration) — протокол поиска веб-сервисов в Интернете (www.uddi.org). Представляет собой бизнес-реестр, в котором провайдеры веб-сервисов регистрируют службы, а разработчики находят необходимые сервисы для включения в свои приложения.
Как и у любой технологии, у веб-сервисов есть и продолжение достоинств — недостатки.

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

История Java

Придет ли час моей свободы?
Пора, пора! — взываю к ней.

А. С. Пушкин. «Евгений Онегин»

Есть забавная байка о зарождении Java. Где-то в начале 90-х одному из сотрудников компании Sun Патрику Нотону (Patrick Naughton) так опостылела его работа, что он решился на переход в Next, о чем и доложил исполнительному директору Скотту Макнили (Scott McNealy). Макнили не хотелось терять способного работника, поэтому он пошел на небольшую хитрость и предложил Патрику составить список причин его недовольства и, самое главное, возможных решений, причем без оглядки на авторитеты и какие-либо ограничения. Нотон отнесся к затее ответственно и раскритиковал в хвост и гриву общую ситуацию в компании и ее софтверные инициативы в частности (речь шла о новой архитектуре NeWS).

Сейчас уже трудно сказать, что же конкретно произошло с письмом Патрика, но большие боссы в лице Билла Джоя (Bill Joy) и Джеймса Гослинга (James Gosling) обратили внимание на предложения Нотона, что в конечном счете вылилось в создание небольшой команды, которая должна была придумать что-нибудь революционное.

К чести исследователей, они решили разгрызть крепкий орешек: сделать легкой и единообразной поддержку сотен различных платформ и интерфейсов программ. Задача, надо сказать, весьма нетривиальная — ведь устройства, которые необходимо (или хотелось бы) программировать, только с виду одинаковы. Никакой доминирующей платформы, которая занимала бы хоть сколько-нибудь заметное место на рынке встроенных устройств, не было, — как следствие, даже телевизоры одного производителя содержали в себе различные управляющие микросхемы, что уж говорить о бесчисленных типах устройств от разных поставщиков! Естественным для программистов решением было, как нетрудно догадаться, создание нового языка программирования, названного Oak (дуб) в честь дуба, росшего под окном дома Джеймса Гослинга. Задуманный как интерпретируемый диалект Си++ для программирования встроенных приложений, язык был весьма передовым, но, как часто бывает, решить поставленную сверхзадачу он не помогал, и практического применения ему тогда не нашлось.

На этом история Java могла бы и закончиться, если б не счастливое стечение обстоятельств и дар предвидения Билла Джоя, решившего не хоронить, а переориентировать Oak на иные задачи — создание компактной ОС. В спешном порядке был сверстан другой проект, LiveOak, который буквально через несколько месяцев по инициативе Патрика Нотона был вновь переориентирован, на сей раз на Интернет. К началу 1995 года были разработаны браузер WebRunner и компилятор Oak — прародители современного Java⁵. Правда, Нотон в этом уже не участвовал — он таки уволился.

4 На практике — да. В теории, в определении веб-сервиса упоминается только XML (www.w3.org/TR/2002/WD-ws-arch-20021114/#whatisws). — Прим. ред.
5 История появления самого слова «Java» тоже окутана тайной. При выпуске нового продукта всегда встает вопрос о его названии, которое, с одной стороны, должно быть уникальным (дабы не возникло юридических проблем), с другой — легко запоминающимся и ярким. От названия Oak пришлось отказаться из-за «занятости» имени (Oak Technologies), «заказывать» имя у сторонней компании, специализирующейся на разработке имен, тоже не стали — имя родилось внутри Sun. Сейчас уже трудно сказать, кто его автор. В результате коллективного мозгового штурма появился целый выводок возможных имен — Silk, Pepper, NetProse, Neon, Lyric, Greentalk, Ruby, WRL, WebDancer, WebSpinner, Java, но в конце концов выбрали последнее. Логотип для Java (чашечка с дымящимся кофе) разработан Марком Андерсеном, перу которого принадлежат логотипы для Sun и Macintosh. Браузер WebRunner был переименован в HotJava, а 23 мая 1995 года на выставке SunWorld было официально объявлено о рождении нового языка.

Что такое Java

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

В принципе, Java и претендует на роль эсперанто для компьютеров. Переводчиком, с помощью которого каждый конкретный компьютер переводит Java-эсперанто на свой родной язык, является виртуальная Java машина — JVM.

Проблемы Java

Один среди своих владений,
Чтоб только время проводить,
Сперва задумал наш Евгений
Порядок новый учредить.
А. С. Пушкин. «Евгений Онегин»

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

Итак, что было не сделано или сделано неправильно.

- Отсутствие международной стандартизации. Как ни странно, Java до сих пор не имеет международного стандарта ни в рамках ISO, ни в рамках ECMA. Напротив, Microsoft, несмотря на фору во времени, уже заполучила и европейский стандарт ECMA, и на язык C#, и на языковую инфраструктуру CLI (Common Language Infrastructure), и сертификаты ISO на обе технологии.

- Совместимость и кроссплатформность. Один из ключевых принципов Java «написано однажды — работает везде» на самом деле не совсем верен и соблюдается рамочно, что подтверждается выпуском разных платформ — J2EE (серверный вариант — для предприятий), J2SE (локальный вариант — для настольных компьютеров) и J2ME (усеченный вариант — для бытовой техники). Имеются вопросы по совместимости разных библиотек (например, Sun Swing и IBM SWT) и разных релизов JDK. Возможны проблемы с работой приложений, созданных на другой платформе (так, приложение, созданное для встроенной системы на базе J2ME, порой не работает на ПК под J2SE и наоборот, даже при наличии необходимых аппаратных ресурсов). В такой ситуации нет ничего удивительного — платформы (сам язык и библиотеки) развиваются, однако проблема гораздо шире: неполной совместимостью грешат даже специализированные аппаратные Java-процессоры (процессор DeCaf компании Aurora VLSI поддерживает 95% всех возможных инструкций байт-кода Java, а процессор Jazelle компании ARM менее 70%). Единственное, что радует, это относительно простая переносимость в рамках одной платформы, так что перенос софта между серверами или настольными компьютерами вроде бы решаем. К сожалению, на рынке встроенных систем, систем реального времени и бытовой электроники ситуация гораздо проблематичнее.

- Производительность. Несмотря на очевидный прогресс в этой сфере, приемлемого уровня удалось достичь только в серверном сегменте⁶ — при исполнении программ 30% времени уходит на управление процессами и ввод-вывод, 25% — на генерацию кода и 15% — на сборку мусора. С настольными системами и того хуже — 5% на обработку ввода-вывода и процессы, трансляция и выполнения байт-кода занимают 75% времени, 20% уходит на сборку мусора. А для J2ME ситуация вообще не идет ни в какое сравнение⁷.

- Ориентация только на один язык. Если б за основу платформы взяли какой-нибудь из существующих на то время языков — С, С++, Basic, наконец, это было бы полбеды. Но в Sun замахнулись на создание нового языка, что автоматически отсекло все программистское сообщество и вызвало огромный временной лаг между анонсом и реальным широкомасштабным внедрением, связанный с необходимостью обучения. Позднее в правильности такого подхода не раз сомневались, но время было упущено, и теперь конкурирующая платформа — .NET, подхватив знамя многоязыковой поддержки, ринулась завоевывать рынок, опираясь на уже сформированные сообщества программистов. Microsoft сразу спроектировала .NET как мультиязычную платформу — язык MSIL (Microsoft Intermediate Language) в сочетании с CTS (Common Type System) и VOS (Virtual Object System) стал эффективным инструментом, во многом благодаря поддержке разных языков программирования. Теперь различные языки объединяются не просто универсальным промежуточным кодом, а единой системой типов, наследования и унифицированным механизмом обработки исключений.

Java 2 Platform, Enterprise Edition

Прежде чем рассказывать о J2EE⁸, нужно развенчать распространенный миф — J2EE не является программным продуктом в обычном понимании слова. Это набор стандартов и спецификаций, которые устанавливают, как должны работать и взаимодействовать различные компоненты из состава J2EE. Sun хоть и является прародителем платформы, конечно, не одинока на этом рынке, так что конкретный продукт, соответствующий спецификациям, вы можете приобрести у одного из нескольких именитых поставщиков⁹ (на лицензировании продуктов которых Sun и зарабатывает).

При разработке J2EE-приложений используется компонентный многоуровневый подход, при котором внешне монолитное приложение состоит из нескольких разнесенных модулей (см. рис. на стр. 30). J2EE-клиентом может быть либо обычная программа (тогда веб-уровень не нужен), либо веб-браузер (выступающий в роли так называемого тонкого клиента), поддерживающий JVM. J2EE-сервер — это комплект ПО, обеспечивающий собственно сервисные функции (может включать в себя веб-сервер для генерации и обработки JSP-страниц, а также модуль бизнес-логики, преобразующий данные в ответ на запросы пользователя). Несмотря на то что приложение может насчитывать три или четыре уровня, такую структуру принято называть трехзвенной: клиентская машина, J2EE-сервер и СУБД.

Любое J2EE-приложение состоит из компонентов — законченных, относительно самостоятельных программных модулей, которые написаны на Java. На клиентской машине выполняются клиентские компоненты — апплеты или обычные приложения. На сервере соответственно серверные — Java-сервлеты и JavaServer Pages (веб-компоненты), и корпоративные — ответственные за бизнес-логику.

6 По данным BEA WebLogic JRockit — The Server JVM. Increasing Server-Side Performance and Manageability // BEA Systems, 2002.
7 По объявленным в 2002 году результатам тестов производительности виртуальной Java-машины в рамках проекта Monty (с прицелом на использование для Palm и Pocket PC), быстродействие возросло в 8–10 раз (!) по сравнению с K-машиной Java (K Virtual Machine) версии 1.03, применяемой в J2ME. Данный «прорыв» вполне характеризует уровень проблем с производительностью.
8 Существует три разных издания платформы Java:
- Java 2 Platform, Enterprise Edition. Используется на предприятиях и предназначена для разработки многоуровневых приложений.
- Java 2 Platform, Standard Edition — для кроссплатформных приложений.
- Java 2 Platform, Micro Edition — для аппаратно ограниченных (по объему памяти, вычислительной мощности) устройств — телефонов, КПК и др.
Существует и еще одна платформа — Java 2 Card. Она предназначена для смарт-карт и находится пока в зачаточном состоянии.
9 Список компаний, получивших лицензию, можно найти на java.sun.com/j2ee/licensees.html.

Платформа .NET

И снова, преданный безделью,
Томясь душевной пустотой,
Уселся он — с похвальной целью
Себе присвоить ум чужой…
А. С. Пушкин. «Евгений Онегин»

Прежде чем мы рассмотрим платформу Microsoft.NET, уместно разобраться, каким путем компания пришла к идее веб-сервисов. В конце 1995 года, стремясь наверстать упущенное время, Microsoft обратила внимание на Интернет. К тому моменту на рынке браузеров царствовал Netscape Navigator. Тем не менее, мобилизовав все свои резервы, Microsoft смогла-таки оспорить лидерство Netscape. Примерно тогда же она начинает активно раскручивать такие технологии, как Active Server Pages (ASP). Хотя с точки зрения объектно-ориентированного подхода этот скриптовый язык являлся скорее шагом в сторону (если не вспять), компания целенаправленно вкладывала средства в его развитие и популяризацию, что, безусловно, принесло свои плоды.

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

Фактически за продвижение самой идеи веб-сервисов мы можем благодарить только Microsoft, Sun в этом смысле практически бездействовала. Теперь же можно ожидать, что большое число компаний выделят веб-сервисы в своих приложениях и смогут продавать их другим компаниям, образуя громадный рынок, у истоков которого будет стоять Microsoft (и, естественно, снимать сливки). Чего, например, стоят веб-сервисы HailStorm — своеобразные строительные блоки для технологии .NET, выполняющие такие задачи, как обмен сообщениями, временная синхронизация и нотификация. И хотя один из самых известных среди сервисов HailStorm — .NET Passport, обеспечивающий идентификацию и аутентификацию пользователей, периодически подвергается нападкам в связи с новыми обнаруженными уязвимостями, в настоящее время он используется очень интенсивно, выполняя более 1,5 млрд. операций аутентификации в месяц (по статистике Microsoft). Впрочем, в большой степени такой успех обусловлен использованием Passport в другой популярной службе — Hotmail.

Надо сказать, у .NET, как и у Java, знаменитые родители. Во-первых, отметим самую яркую личность — Андерса Хейлсберга (Anders Hejlsberg), одного из ведущих инженеров Microsoft, руководившего проектом создания и развития языка программирования C#, участника разработки Microsoft .NET Framework. В свое время Андерс был архитектором системы разработки Visual J++ и Windows Foundation Classes, а до перехода в Microsoft (в 1996 году) занимал должность главного инженера компании Borland International, где был главным архитектором Delphi (кроме того, Андерс являлся автором компилятора Turbo Pascal). Во-вторых, Брэд Ловеринг (главный архитектор систем разработки Visual Basic, Visual J++ и Visual Studio .NET) и Клеменс Шиперски (идеолог компонентной архитектуры в Oberon, перешел из ETH в Microsoft Research). Кроме того, своеобразными «неформальными родителями» .NET можно считать Бертрана Мейера (работал над языком Eiffel, ныне трудится в ETH) и Юрга Гуткнехта (работал над Oberon, ETH). Естественно, столь представительная команда не могла сделать заурядный продукт.

Основу среды составляют: платформа — операционная система, под управлением которой работает среда исполнения (CLR, Common Language Runtime); службы (библиотеки классов: базовой логики, манипуляции данных, обеспечения безопасности, отображения информации, электронной почты, Интернета и многие другие), поверх которых работают веб-сервисы, веб-формы (WebForms) и формы локальных приложений (WinForms).

Помимо этого в .NET входят:

- среда разработки Visual Studio.NET;
- серверные продукты — СУБД, сервер приложений, интеграции, почтовый и веб-сервер и др.;
- сетевые сервисы типа Passport.

Java versus .NET

Меж ими все рождало споры
И к размышлению влекло:
Племен минувших договоры,
Плоды наук, добро и зло…
А. С. Пушкин. «Евгений Онегин»

По мнению аналитиков Gartner, именно .NET и Java будут в ближайшие пять лет основными платформами для разработки веб-приложений, а к 2005 году их суммарная рыночная доля перевалит за 80%. В таких оценках нет ничего нового, ведь никто и не ждет, что Linux и PHP отхватят столь лакомый кусок. Тем не менее для многих небольших компаний одновременная поддержка обеих платформ является чрезмерной и непозволительной роскошью, они просто обязаны сделать выбор. Именно поэтому стоит детально рассмотреть каждую из платформ, чем мы сейчас и займемся.

Хочу сразу огорчить некоторых воинственно настроенных читателей — никаких выводов, типа технология XYZ много круче ABC, а поэтому за ней будущее, не будет. А будет попытка ответить на кажущиеся простыми вопросы: Если Java и .NET так близки, зачем вообще нужна .NET? Каковы шансы последней занять свое место под солнцем и что будет с Java?

Сначала определимся с методикой — как будет происходить сравнение. Ясно, что без анализа технологического аспекта не обойтись. Однако ограничиваться только этим нельзя — в истории ИТ есть масса примеров, когда хорошие с технологической точки зрения решения были угроблены неумелым или недостаточным маркетингом (OS/2, Next, Be и т. д.). Таким образом, нужно учесть и рыночное поведение основных игроков, и сложившиеся (складывающиеся) сообщества разработчиков, — то есть обратиться к целому пласту бизнес-составляющих успеха.

Кроссплатформность

Java: J2EE и идейно и, что гораздо важнее, фактически является кроссплатформной средой. Если для необходимой платформы существует JDK, то и J2EE будет функционировать. С другой стороны у Java в этом аспекте есть определенные проблемы (см. раздел «Проблемы Java»).

.NET: Тоже заявлена как кроссплатформная, для чего есть все технологические предпосылки. Но на сегодняшний день единственной платформой является только Windows. Хотя некоторые должностные лица Microsoft, например старший вице-президент Эрик Раттер (Eric Rutter), иногда прозрачно намекают о портировании .NET на другие ОС, в частности FreeBSD, в ближайшее время на это не стоит надеяться. В подтверждение можно сказать, что однажды Microsoft уже делала подобные заявления в отношении DCOM (Distributed Component Object Model), однако обещания не сдержала. Аналогичной точки зрения придерживаются и аналитики: по прогнозам Gartner, вероятность того, что к 2004 году Microsoft самостоятельно создаст клон .NET, — менее 10%, через какого-либо партнера — около 20%. В то же время весьма вероятно (около 70%), что некоторая базовая реализация (эмулирующая ядро .NET) будет создана независимым поставщиком. С другой стороны, на недавнем форуме Novell демонстрировалась пока не законченная, но уже работающая под Linux среда Ximian Desktop 2 — результат труда одноименной компании и еще 150 сторонних разработчиков. В настоящий момент готовы компоненты виртуальной машины, а также компиляторы C# и VB.NET, так что первые Linux приложения могут появиться к концу года (см. «КТ» #511, стр. 49 и, конечно, www.go-mono.com).

Многоязычность

Java: Здесь между J2EE как платформой и Java как языком программирования можно смело ставить знак равенства. Использование других языков программирования нетривиально¹⁰.

.NET: Платформа является, если так можно выразиться, языконезависимой. Если для данного языка программирования создан механизм отображения в MSIL, то его можно смело применять в разработке. Фактически, помимо уже упоминавшихся, близки к окончательному релизу NetCOBOL от Fujitsu, Visual Perl и Visual Python от ActiveState и еще несколько языков (включая J# — своеобразный клон Java).

Транзакции

Java: У разработчика всегда есть выбор — либо управлять всем процессом вручную (на всех стадиях от начала, через выполнение [Commit] или отмену [Abort] до завершения), либо отдать управление транзакциями контейнеру EJB, что в целом надежнее, но требует больших ресурсов.

.NET: CLR также поддерживает и ручное управление и автоматический менеджмент, при котором достаточно лишь определить объект и его атрибуты (что опять же требует несколько больших ресурсов).

10 Возможно через механизм интерфейсов, например через Java Native Interface, но повторюсь, нетривиально и часто себя не оправдывает.

Управление удаленными объектами

Java: Как и оппонент, J2EE предоставляет инструменты для прозрачного менеджмента удаленных объектов. Сервис поиска JNDI обеспечивает унифицированный интерфейс к различным сервисам каталогов и имен, предоставляя компонентам приложения доступ к этим сервисам.

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

Веб-сервисы XML

Java: Можно сказать, что Java Web Services Developer Pack имеет все необходимое для создания веб-сервиса. Помимо всего прочего, существующие спецификации (Java Specification Request) позволяют расширить функционал, предоставляя некоторые дополнительные услуги, такие как lookup.

.NET: Фактически веб-сервисы XML являются одним из основных компонентов .NET-платформы. Microsoft не только поддерживает последние стандарты (в частности, XML Schema Standard), но и активно продвигает другие — те, что необходимы, например, вертикальным рынкам.

Доступ к данным

Java: Имеющиеся в настоящий момент Java-пакеты предоставляют доступ практически ко всем возможным источникам данных. Особенность J2EE заключается в возможности выбора модели доступа — container-managed или bean-managed.

.NET: В распоряжении разработчиков имеется стандартный набор инструментов для доступа к данным из различных источников, включая, естественно, XML. Фактически ADO.NET, являясь преемником RDO, обеспечивает не только прозрачный доступ к данным, но и их транспортировку через Интернет.

Среда исполнения

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

.NET: Схема работы .NET-платформы во многом схожа. Выполнением программы заведует CLR (аналог JVM). При этом программа должна быть предварительно скомпилирована в Microsoft Intermediate Language — MSIL-код (аналог байт-кода).

Может показаться, что среды исполнения J2EE и .NET весьма близки, если вообще не являются близнецами. Это верно, но только отчасти. Например, в то время как JVM лишь интерпретирует байт-код¹¹, .NET транслирует MSIL-код в машинный, что положительно сказывается на производительности. .NET, в отличие от Java, поддерживает технологию доменов приложений (application domains). По сути, это метод изоляции приложений, в чем-то схожий с применением процессов, но с тем отличием, что практически отсутствуют системные издержки, связанные с межпроцессными вызовами и необходимостью переключения между ними.

Стандарты

Java: Sun жестко контролирует собственно технологию и сам язык. Нельзя сказать, что такая непреклонность неуместна, вполне возможно, что если б компания пошла на поводу у Microsoft, J2EE была бы так же фрагментирована, как и браузеры.

.NET: Microsoft тоже ревностно относится к стандартизации, но тем не менее, пошла на открытую стандартизацию C#, фактически отказавшись от монопольного права на внесение изменений, что можно только приветствовать.

Дополнительные инструменты

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

.NET: В настоящий момент практически весь инструментарий для .NET выпускает только Microsoft. Конечно, у компании богатый опыт в этой области, но, в любом случае, альтернативы не помешали бы¹².

Поддержка со стороны производителя

Java: J2EE не является монопольной территорией Sun. Таких монстров отрасли, как IBM, BEA Systems или Oracle, ни в коем случае нельзя сбрасывать со счетов.

.NET: Платформа .NET является прерогативой Microsoft, и в ближайшее время никаких существенных изменений не предвидится.

Производительность

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

- Microsoft® .NET vs. Sun® Microsystem’s J2EETM: The Nile Ecommerce Application Server Benchmark. October 21, 2001.
- «Кто сегодня самый шустрый» (www.optim.ru/ cs/2001/3/compar/compar.asp).

Рыночное положение

Можно сказать, что вялотекущие судебные процессы по поводу монопольного положения Microsoft имеют хотя бы одну положительную сторону — вера в рыночное лидерство компании распространяется не только на юристов, но и на обывателей. Многие считают, что именно умелый маркетинг, а не передовые технологии являются залогом успеха гиганта из Редмонда. Впрочем, доминирование Microsoft заставило конкурентов сомкнуть ряды. Возможно, Sun не смогла бы вести борьбу в одиночку, но сейчас вокруг Java объединились гиганты под стать Microsoft — IBM, Oracle, BEA, HP и целый рой компаний помельче.

Разумеется, у такой коалиции есть и недостатки. Как известно, любой союз, в котором больше одного участника, по определению неустойчив, вот и внутри Java-сообщества идет перманентная борьба. Показательно, что в спецификации J2EE 1.3 не было веб-сервисов, так что все ведущие производители платформ J2EE были вынуждены предлагать собственные фирменные расширения. Потенциально это может привести к разделению платформы на части, как в свое время произошло с Linux, и первые робкие шажки в этом направлении уже делались: например, IBM запустила проект Eclipse, нацеленный на обеспечение интеграции инструментов Java от разных поставщиков ПО. Этот проект поддержали почти все ведущие разработчики Java-инструментария, кроме… Sun, которая представила свой аналогичный проект — NetBeans. Рискну предположить, что если и дальше IBM будет теснить Sun, вполне возможен раскол на два лагеря, что, безусловно, на руку Microsoft.

Резюме

Кого ж любить? Кому же верить?
Кто не изменит нам один?
Кто все дела, все речи мерит
Услужливо на наш аршин?
А. С. Пушкин. «Евгений Онегин»

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

Что касается вопроса, какую платформу применять в конкретном проекте, то здесь стоит исходить из конкретных приоритетов, например, что для вас важнее — реальная кроссплатформность или возможность привлечь С++ и VB-программистов? с программным обеспечением какого производителя придется интегрировать будущий продукт? И т. д. Если же кратко изложить сильные стороны обеих платформ, то получится примерно следующее.

За Microsoft .NET

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

За Sun Java

- реальная кроссплатформность;
- конкурентность рынка поставщиков;
- сложившееся сообщество Java-программистов.

11 Впрочем, нельзя забывать, что в Java могут применяться (и активно применяются) компиляторы just-in-time.
12 Конечно, определенный прогресс в этой области есть. Так, в ближайшее время могут появится альтернативные среды разработки, но в любом случае отставание от Java-сообщества пока велико.