Sun ONE и Microsoft .NET в борьбе за Wеb-службы

При обстоятельном изучении информационных материалов компании Sun Microsystems, касающихся представления в России новой маркетинговой программы Sun ONE, мне невольно приходили в голову ассоциации с другой весьма рекламируемой системой — Microsoft .NET, ведь обе они базируются на схожих технологиях. В конце концов вместе с коллегами мы пришли к выводу, что для полноценного ознакомления читателя с Sun ONE необходимо провести сравнение этих двух самых перспективных и наиболее известных платформ сетевого взаимодействия. Но сначала познакомимся поближе с Wеb-службами — технологией, на развитие которой Sun и Microsoft тратят огромные средства и которая является основой Sun ONE и Microsoft .NET.

Что такое Web-службы

История Web-служб началась задолго до того, как мы впервые услышали этот термин, активно пропагандируемый корпорацией Microsoft. И формально, и по сути развитие Web-служб (Web-service) вполне можно ассоциировать с развитием Интернета, в частности c Web-серверами (Web-server) и Web-страницами (Web-site). Пытаясь модернизировать статические Web-страницы, разработчики постепенно внедряли все новые технологии как для динамического их отображения на стороне клиента, так и для динамического создания на стороне сервера. Таким образом, на Web-сервер постепенно стали возлагаться задачи не только пересылки файлов по запросу клиента, но и выполнения приложений в виде SSI-скриптов (Server Side Include) и программ специального формата CGI (Common Gateway Interface), на лету создающих Web-странички. Подобные изменения стали прослеживаться почти десять лет назад. К примеру, один из наиболее популярных языков программирования для Web-серверов — PHP, а точнее, его реализация — появился на свет еще в 1995 г., в одно время с Windows 95 и Java.

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

1) формирование запроса клиента к серверу;

2) отправку этого запроса;

3) получение запроса Web-сервером;

4) выполнение приложения на стороне сервера (сервером приложений);

5) отправку клиенту результата работы серверного приложения;

6) обработку ответа клиентом.

Вместе с тем в этой области происходили и происходят эволюционные изменения и усовершенствования, привносимые как отдельными компаниями, так и целыми альянсами. В частности, в последние годы были созданы стандарт LDAP (Light Directory Access Protocol) для обеспечения защищенного доступа к файлам серверов и, следовательно, Web-служб, интерфейс UDDI (Universal Description Discavery Interface) — интерфейс публикации Web-служб в Интернете, а также множество серверов, поддерживающих эти стандарты разных разработчиков.

Наряду с общими чертами, сближающими SSI, CGI и Web-службы, последние имеют и принципиальные отличия. Это расширение списка протоколов взаимодействия (сейчас разрабатывается поддержка FTP и SMTP), организация взаимодействия на основе XML и возможность публикации. Именно они и определяют те особенности, которые отделяют Web-службы от их предков в виде SSI и CGI.

Особенности Web-служб

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

В Интернете, и в частности для Web-служб, XML становится незаменимым. Одним (программным клиентам) он позволяет упаковывать запросы в XML-совместимый формат и анализировать результат XML-совместимых ответов, другим (программным серверам) — обрабатывать эти запросы и формировать ответы, третьим (средам разработки) — анализировать файлы описания доступных Web-служб. Но XML — это лишь способ структурирования данных. Для их однозначного понимания все же требуются дополнительные спецификации, предназначенные для определенных практических задач. В случае Web-служб такими специализированными спецификациями являются SOAP (Simple Object Access Protocol), предназначенная для упаковки запросов, и WSDL (Web Service Description Language), описывающая собственно Web-службы. В принципе разработчик может анализировать содержимое WSDL-файла, чтобы получить описание Web-службы, но эти операции максимально автоматизированы, так что не требуется знать данный формат. (Впрочем, то же самое справедливо и для SOAP.)

Еще один важный элемент Web-служб — их транспортный протокол. Сейчас основным средством доставки запросов Web-службам и получения отклика являются протоколы HTTP, FTP и SMTP. Все они давно используются в Интернете, и выбор пал на них неслучайно. Именно под эти протоколы была реализована вся инфраструктура Интернета, с их помощью клиент из ЮАР может воспользоваться Web-службой, хранящейся на сервере, скажем, в Иране.

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

Платформа Microsoft .NET

Не секрет, что именно Microsoft больше других компаний концентрирует свои усилия на развитии Web-служб, и, видимо, продвижение этой технологии для Microsoft является приоритетным. Такая тенденция прослеживается на протяжении последних двух-трех лет. Так, сначала был выпущен инструментарий для создания Web-служб на базе DCOM-архитектуры. Используя его, разработчики могли создавать DCOM-объекты, взаимодействующие с клиентскими приложениями посредством протоколов WSDL, SOAP и HTTP. И хотя подобный подход стал существенным усовершенствованием DCOM-архитектуры, все же сама разработка Web-служб оставалась довольно трудоемким занятием, поскольку приходилось создавать все те же весьма сложные DCOM-компоненты, а также дополнительные интерфейсы для Web-служб. В 2002 г. была выпущена в свет новая среда для выполнения приложений в Windows — .NET Framework, позволившая не только существенно упростить создание Web-служб и сетевых приложений, но и взглянуть на разработку программ под Windows с принципиально иной точки зрения (впрочем, знакомой разработчикам на Java).

В то же время платформа .NET — нечто большее, чем просто среда выполнения Web-служб. Microsoft позиционирует .NET как готовую инфраструктуру для создания Интернет-приложений. В нее входят и средства разработки (в виде Visual Studio .NET), и операционная система Windows, и множество серверов, поддерживающих работу в Интернете (в частности, работу Web-служб). Более того, на корпоративном сайте Microsoft довольно определенно сказано, что .NET содержит и различные рабочие среды, вплоть до Microsoft Office и MSN, т. е. к .NET можно отнести практически любое современное приложение, выполняющееся в Windows, которое хоть каким-то образом взаимодействует с Web-службами.

Это настолько размывает понятие .NET, что становится довольно трудно дать определение данной платформе. Мы остановимся только на основных нововведениях, касающихся разработки Web-служб, — на собственно Web-службах, на Visual Studio .NET (ее мы рассмотрим в следующей статье) и на .NET Framework.

Среда .NET Framework

.NET Framework — это среда выполнения для специальных (управляемых) приложений .NET. Принципиальное отличие приложений .NET Framework от обычных Windows-приложений заключается в его независимости от аппаратного обеспечения, на котором работает .NET Framework. Это обусловлено тем, что приложения .NET Framework не содержат машинно зависимый код, а транслируются в специальный двоичный, соответствующий спецификации MSIL (Microsoft Intermediate Language). Следовательно, разработчики решили убить сразу несколько зайцев.

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

Во-вторых, была решена давняя «болезнь» COM-технологии — невозможность создавать объекты-наследники для COM-компонентов. Значит, если имеется какой-либо COM-компонент, то при отсутствии его исходного текста нельзя организовать свой объект, унаследовав все возможности COM-компонента. Теперь это стало реальным, потому что приложения .NET Framework компилируются в некий двоичный код, который среда может проанализировать, чтобы извлечь из него все необходимые параметры каждого из объектов с помощью технологии Reflection. Иными словами, вы можете приобрести коммерческий компонент и создать на его основе свой, унаследовав все функции коммерческого.

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

Платформа Sun ONE

Платформа Sun ONE, как и .NET, возникла не на пустом месте. Еще в 1997 г. Sun выдвинула идею о создании сервера приложений на базе Java. После этого в течение трех лет разрабатывались спецификации J2EE (Java 2 Enterprise Edition), и в 2000 г. был выпущен первый J2EE-совместимый сервер приложений. То был серьезный технологический прорыв, ведь появилась объектно-ориентированная среда разработки корпоративных компонентов на весьма простом и универсальном языке программирования — Java. Довольно быстро J2EE-технология приобрела популярность и на корпоративном рынке, но активное продвижение технологии Web-служб несколько затеняло достоинства J2EE, поэтому в 2002 г. Sun выпустила Java WSDP (Web Services Developer Pack). Этот пакет позволял, в сущности, только одно — упростить разработку Web-служб (SOAP, WSDL). Платформа J2EE и так предоставляла возможность пользоваться всеми преимуществами Web-сервисов, просто не делалось никакого акцента на протоколы Web-служб, так как J2EE обладает более универсальной технологией адаптеров, посредством которой можно реализовывать сетевое взаимодействие на основе любых протоколов.

Сейчас платформа Sun ONE позиционируется как новая архитектура сетевого взаимодействия и как маркетинговая программа, собирающая воедино все продукты и услуги компании Sun, каким-либо образом связанные с Web-сервисами. Видимо, в Sun решили не отставать от Microsoft и потому приняли аналогичную маркетинговую программу. В Sun ONE входят и различные серверы для представления и использования Web-сервисов, и средства их разработки, и даже весьма нашумевший офисный пакет StarOffice. Но мы коснемся здесь только средств разработки и публикации Web-сервисов.

Преимущество корпорации Sun в области Web-сервисов заключается в том, что ее технология на базе J2EE существует уже не один год и вполне успешно эксплуатируется. К тому же технология Java Connector позволяет безболезненно перейти на протоколы Web-служб, фактически лишь реализовав необходимые адаптеры и почти не изменяя сам код бизнес-приложений. Единственное, что пришлось сделать Sun, так это выпустить специальный инструментарий разработчика WSDP, значительно упрощающий разработку Web-служб.

Кроме того, сама J2EE-платформа построена на базе технологии Java, активно развивающейся на протяжении последних восьми лет. Ее успех косвенно подтверждает и Microsoft, также начавшая продвигать собственный продукт .NET Framework, в технологическом плане являющийся аналогом Java Platform, хотя и с некоторыми усовершенствованиями.

Для лучшего понимания идеологии платформы Sun ONE нужно обратиться к ее основе — платформе Java и спецификации серверов приложений. Вся технология Java базируется на трех китах:

• J2SE (Java 2 Standard Edition) - базовая платформа, на которой можно разрабатывать буквально все: клиентские программы, серверы, игры и др.;
• J2ME (Java 2 Micro Edition) - платформа разработки программ для устройств с ограниченными возможностями (мобильные телефоны, КПК и пр.);
• J2EE (Java 2 Enterprise Edition) - платформа для разработки серверных программ промежуточного уровня.

Платформа J2EE — всего-навсего спецификация Java-серверов промежуточного уровня. Практически все технологии Java — это спецификации, а не конкретные продукты, созданием которых занимаются самые разные компании: Sun, IBM, BEA, Oracle и др. Но главное, спецификации разрабатывает не только Sun, но и специальное сообщество — JCP (Java Community Process). В его состав входят и крупные компьютерные компании из разных точек земного шара, и отдельные разработчики.

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

Кроме того, Sun активно поддерживает выпуск некоммерческих продуктов (все технологии Java доступны для свободного получения на сайте www.java.sun.com). Существует и немало проектов с открытым исходным кодом. Среди них сервер приложений TomCat, виртуальная машина Java для Linux под названием Kaffe, кроссплатформная среда разработки NetBeans и др.

Немало споров ведется на тему жесткой позиции Sun в отношении языка Java, выражающейся в многократных судебных исках против Microsoft, а также в запрете создавать иные версии Java, отличающиеся от разработанного в Sun стандарта. На мой взгляд, эти вопросы не обнажают каких-либо противоречий. Если вспомнить историю UNIX и Linux, то полная анархия и отсутствие стандартов привели практически к потере рынка системами UNIX. Разработчики Linux, помятуя о прошлом, сейчас группируются и пытаются разрабатывать общие стандарты (United Linux, ELC Platform Specification, Linux Standard Base). Подобные процессы происходят и с Java. По мнению идеологов Java, чтобы технология имела шанс выжить, стандарт должен быть один.

Вернемся к обсуждению J2EE-серверов. Сервер приложений, совместимый с J2EE, служит основой платформы Sun ONE и вообще Web-служб на базе Java. Сейчас существуют реализации J2EE-серверов практически для любых аппаратных и программных серверных платформ. Кроме того, имеются J2EE-серверы, полностью созданные на базе J2SE-платформы, что в еще большей степени способствует не только решению проблем переносимости, но и быстрейшему развитию J2EE-подходов. Сам J2EE-сервер обеспечивает выполнение серверных приложений трех типов: JSP (Java Server Page), сервлеты (Servlets) и EJB (Enterprise Java Beans).

Первые являются серверными Java-скриптами, которые могут размещаться внутри HTML-страниц. При компиляции они преобразуются в сервлеты — полноценные серверные приложения, вызываемые посредством HTTP-протокола. И те и другие предназначены для расширения функциональности корпоративных Web-серверов. Сходное назначение имеет технология ASP .NET корпорации Microsoft.

Расширять возможности J2EE-серверов позволяют EJB-компоненты, более универсальный инструмент сетевого взаимодействия, не привязанный ни к Web-серверам с их протоколом HTTP, ни к стандарту SOAP. И потому EJB-компоненты во многих ситуациях оказываются эффективнее своих младших братьев — сервлетов. Иногда EJB-компоненты в качестве низкоуровневых средств сетевого взаимодействия сравнивают с COM-технологией компании Microsoft, что во многом оправданно благодаря сходным функциональным возможностям. Но все же по удобству применения EJB-компоненты значительно превосходят COM-объекты. Это касается и проблем наследования, описанных выше, и, естественно, языка разработки Java, который неоспоримо проще любого транслируемого языка программирования. (К примеру, основным языком разработки COM-объектов является Cи++.)

Чего нам ждать от Web-служб

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

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