В конце апреля компания Sun Microsystems провела в Москве крупную конференцию, на которой несколько пленарных докладов сделал ведущий Java-архитектор Sun Джон Крупи (John Crupi). Он любезно согласился ответить на наши вопросы о проблемах развития платформы Java и ее перспективах.
Джон Крупи
PC Week: Первый вопрос - об эволюции Java. Она возникла как чисто клиентская технология, затем стала практически целиком серверной, а клиентский аспект почти отмер. Но сейчас у Sun Microsystems много конкурентов и в серверной области, к коим относится, в частности, технология Microsoft.NET, включающая похожий на Java язык C#. Каким вы видите в этой связи будущее Java?
Джон Крупи: Вы правы, сразу после своего появления Java продвигалась как технология для выполнения аплетов в браузере. Затем она стала более развитой и начала смещаться в серверную область. Сейчас же, думаю, мы наблюдаем еще один переход - к портативным устройствам (handhelds) и устройствам широкого применения (pervasive devices). Это отражает ее зрелость и показывает, что новые технологии - облегченные и более быстрые виртуальные машины, JIT-компиляторы и т. п. - дают заказчикам возможность лучше использовать Java. Виден громадный прогресс в применении Java в приложениях масштаба предприятия, серверных (back-end) приложениях, мобильных устройствах.
PC Week: Какие шаги предпримет Sun Microsystems для распространения Java на малые устройства? Пару лет назад ваши попытки в этом направлении были не очень успешными, поскольку JDK (Java Development Kit) был слишком велик для подобных целей. Решена ли эта проблема?
Дж. К.: Действительно, во многих случаях дело сводилось к попытке взять существующий JDK или J2SE (Java2 Standard Edition) и перенести его на такие устройства, но ввиду ограниченных возможностей процессоров и меньшего объема памяти это было не вполне уместно. Сейчас принят другой подход: пакеты J2ME (Java2 Micro Edition), MIDP (Mobile Information Device Profile) и новая виртуальная машина KVM требуют существенно меньших ресурсов.
В результате попыток обеспечить выполнение Java-кода в любой среде мы осознали, что для сохранения целостности Java-инфраструктуры на малых устройствах достаточно использовать подмножества структур данных и основных механизмов. Далее стояла инженерная проблема - найти наименьшее подмножество языка Java, сохранив при этом целостность. Кроме того, чтобы технология была более применимой, нужно было сократить и время выполнения. Думаю, что новая KVM, не нуждающаяся в больших ресурсах, знаменует движение в правильном направлении.
PC Week: Не могли бы вы назвать пример устройств, которые сейчас используют KVM или другие машины Java?
Дж. К.: Sharp Zanrus - довольно быстрый и мощный КПК, использующий Linux и J2ME. Применяют Java и многие производители мобильных телефонов. Это можно рассматривать по меньшей мере как доказательство возможности использования технологии. На это у нас ушло на год или два больше времени, чем ожидалось, но думаю, сейчас мы добились цели.
PC Week: Для мобильных устройств имеет место проблема недостатка приложений. Как вы планируете решать ее в отношении машин, поддерживающих Java?
Дж. К.: Ключевой является концепция “edge computing”. Индивидуальные приложения (если не считать игр) становятся не так важны, а устройства используются как точки для оперативного доступа к серверным системам масштаба предприятия. Именно этого сейчас пытается добиться Sun.
PC Week: Сегодня много говорят о низкой прибыльности Java как коммерческого проекта. Как бы вы это прокомментировали?
Дж. К.: Конечно, Java распространяется бесплатно. Однако у Sun есть и лицензиаты - поставщики ПО на базе J2EE (Java Enterprise Edition). У нас также имеется большой комплект собственных программных продуктов. Находить равновесие здесь очень непросто: ведь мы хотим обеспечить прогресс Java за счет ее открытости. Эта открытость обеспечивается процессом JCP (Java Community Process), в котором на равных участвуют все поставщики. Когда выходят спецификации, то и BEA, и IBM, и Sun, да кто угодно может их реализовать. Мы думаем, что заработаем деньги на этом, поскольку считаем, что наши продукты будут лучшими. Кроме того, они прекрасно будут выполняться под Solaris на аппаратном обеспечении Sun.
PC Week: Аналитики отрасли говорят, что продукты многих лицензиатов Java лучше, чем продукты Sun Microsystems на базе Java. Как вы собираетесь совершенствовать их, чтобы более успешно конкурировать с партнерами?
Дж. К.: Думаю, мы можем пойти несколькими путями. У нас есть приложения, операционная система и аппаратное обеспечение. Но даже если продукты других поставщиков будут лучше всего выполняться на аппаратном обеспечении Sun и под нашей операционной системой, то и в этом большая наша победа.
В дальнейшем мы будем усиливать свои продукты. Например, очень важное направление - Sun ONE: мы по сути переносим Java в область Web-сервисов. Думаю, вы увидите большую интеграцию большего числа пакетов, и я полагаю, что в этом Sun будет иметь серьезное конкурентное преимущество.
PC Week: Давайте поговорим о Web-сервисах. Есть технология Microsoft .NET и, как ее часть, .Net Framework. Они включают пакеты для поддержки технологий SOAP и т. п., облегчающие создание Web-сервисов. Будет ли что-нибудь подобное в JDK?
Дж. К.: Как вы, несомненно, знаете, Web-сервисы - это очень широкий и перегруженный термин. Некоторые под этим понимают просто передачу XML-сообщений при помощи протокола HTTP. Мы же будем понимать под Web-сервисами набор технологий, включающий как минимум WSDL, UDDI и SOAP.
Набор Java-API уже содержит пакет JAX. В первую очередь он включает JAXR (Java API for XML Registry) - API для поддержки репозитория и реестра сервисов на базе технологий UDDI и ebXML. Для SOAP мы создали два API: JAXM (Java API for XML Messaging), позволяющий создавать сообщения, и JAX-RPC (Java API for Remote Procedure Call), дающий возможность посылать SOAP-сообщения с вложениями (attachments). Мы думаем, что именно JAX-RPC в каком-то смысле сводит все воедино, поскольку он дает возможность осуществлять SOAP RPC-вызовы для получения WSDL-описаний. И это будет стандарт. Сейчас многие заказчики используют частные расширения SOAP для генерации WSDL-описаний, но спецификация JAX-RPC поможет делать это стандартным образом. И наконец, в пакете JSR реализована поддержка ebXML. Версия 1.09 этого пакета позволит работать с Web-сервисами.
Все эти пакеты для Web-сервисов будут объединены в J2EE версии 1.5 - всеобъемлющем наборе спецификаций. Определить, что войдет в J2EE и не войдет в J2SE, непросто. Мы хотим обеспечить возможность использования Web-сервисов в J2SE, но нам также нужна родная поддержка Web-сервисов в J2EE. Для J2EE 1.5 это будет означать более тесную интеграцию между SOAP и фактическими Web-компонентами.
PC Week: Таким образом, как бы вы сформулировали основные преимущества проекта Sun ONE перед Microsoft .NET?
Дж. К.: Для начала позвольте объяснить, что такое Sun ONE. На самом деле это четыре вещи: продукты, платформа, знания и опыт, а также концепция.
PC Week: Microsoft говорит то же самое о .NET...
Дж. К.: В этом плане мы сходимся, но есть и отличие. В рамках Sun ONE мы предлагаем комплекты продуктов, которые позволяют развертывать Web-сервисы немедленно, но не закрывают вам возможность обращаться к партнерам или другим поставщикам для интеграции с нашими приложениями. Sun ONE полностью основана на стандартах, открытых спецификациях, так что вы не поймаете нас на том, чтобы мы модифицировали какие-либо стандарты, тогда как за Microsoft подобное замечается.
Опять же мы считаем, что решения на базе Sun ONE и Web-сервисы будут выполняться лучше на нашем ПО и нашем аппаратном обеспечении. Но ключевыми являются открытость и возможность интеграции, которую обеспечивает открытая технология. Web-сервисы являются набором технологий. То, что стоит за ними и что действительно важно, - это архитектурный стиль нового типа, и корпорациям предстоит принять его.
Однако для этого требуются архитектура, опыт и знания, которые могут предоставить профессиональные организации - поставщики услуг. Мы разрабатывали образцы, оптимальные методики, типовые проекты и каркасы решений (frameworks) и теперь можем помочь заказчикам фактически интегрировать все эти системы и использовать Web-сервисы эффективно. Понимаем мы и то, какое значение это имеет для руководителей подразделений технологии или информации (CTO, CIO), что им нужно сделать со своими приложениями сегодня и куда их двигать завтра, чтобы освоить новый подход. Ведь речь не о том, что компании просто перейдут к Web-сервисам, а о том, чтобы они поняли, что значит обеспечить поддержку Web-сервисов.
PC Week: Продолжим сравнение технологий Java и. NET. Корпорация Microsoft заявляет, что разработанный ею язык C# лучше, так как она создала его для своих нужд, а Sun Microsystems разработала Java для других.
Дж. К.: Язык C# очень похож на Java - я не знаю, в чем там новаторство. Кроме того, C# - язык для .NET, в то время как Java не является языком для какой-то одной технологии, его можно использовать для чего угодно. Это технология с открытыми спецификациями, и мы проводим дополнительную работу для того, чтобы можно было вызывать системы “вне Java”, написанные на языках Си, C#, Си++, а также унаследованные системы.
C# будет выполняться только в .NET. Так что если ваша компания собирается заниматься только .NET, вы, возможно, проявите интерес к этому языку, что не помешает вам использовать и Java. Я полагаю, разработчики задумаются, что им дает C# такого, чего не дает Java, и что он отнимает. Ведь он добавляет сложность и ограничен средой .NET.
PC Week: Сейчас много говорят о технологии JCA (Java Connection Adapter). Не объясните, что это такое?
Дж. К.: Идея состоит в следующем. Обращение к ресурсам J2EE - СУБД с доступом по JDBC, к EJB-компонентам и т. п. - происходит через контейнер, управляющий безопасностью и правами доступа пользователя, организующий поточную обработку (threading) и т. п. При наличии унаследованных приложений (например, SAP R/3 или CRM-системы Siebel) вы должны написать коннектор, фактически являющийся “договором” с контейнером, так как в нем определяется, какие API должны использоваться для того или иного действия.
Таким образом, текущая версия JCA отвечает за распространение транзакций, этим она похожа на JDBC. Новая версия 1.5 учитывает требования многопотоковости и асинхронности. Она даст больший контроль над контейнером, а также позволит писать коннекторы, в которых будет сообщаться, сколько приложению нужно потоков, что оно, например, посылает запросы или прослушивает асинхронный порт на предмет ответов. Пользователи смогут просто писать свои EJB-компоненты, а весь обмен информацией будет происходить за кулисами. JCA 1.5 - очень интересная технология. Я думаю, она действительно сделает спецификации коннекторов открытыми.
PC Week: Вендоры часто жалуются на то, что процесс Java Community Process - очень медленный и не позволяет своевременно разрабатывать спецификации. Клиентам же нужны спецификации, и многие ваши партнеры создают нестандартные технологии и встраивают их в свои приложения. В итоге, когда рождается новый стандарт, заказчики сталкиваются с проблемой несовместимости. Как Sun планирует ускорить процесс JCP?
Дж. К.: Все, что вы сказали, верно. Но я думаю, что такое положение дел полезно - ведь это почти двухсторонний процесс. Насколько я понял, вы говорите о традиционном пути, когда Sun и партнеры заявляют, что возникла такая-то потребность, в связи с чем мы разработаем соответствующую спецификацию JSR (Java Specification Requests).
Но часто происходит так: компания осуществляет новый тип обработки данных, в котором используются фирменные разработки и который нравится заказчикам. Однако из-за того, что разработка является фирменной, заказчики начинают нервничать. Они требуют от вендоров соответствия J2EE, и те вынуждены либо переделывать свои продукты, удовлетворяя требования этого стандарта, либо инициировать новые JSR. И если они представляют эталонную реализацию в качестве исходной точки для JSR, этот процесс ускоряется.
В отличие от других консорциумов, где все собираются вместе и принимают решение, здесь ситуация иная. Компания представляет свою фирменную разработку как эталонную реализацию для JSR и предлагает сделать ее стандартом. Таким образом, по существу вы не начинаете с нуля, вы уже прошли 30-40% пути, и ваши партнеры обсуждают преимущества и недостатки первоначальной реализации. Такой процесс стандартизации идет намного быстрее любого другого - ведь хотя в его рамках действуют комитеты, есть еще и лидер, который имеет право на окончательное решение.
PC Week: Вы сказали чуть выше, что J2EE 1.5 - это набор пакетов, которые были выпущены ранее. Будет ли там что-то новое? И что будет в J2EE 1.6?
Дж. К.: Пока я могу высказать только предположения. Сейчас вышли некоторые интересные спецификации, например, на портлеты, спецификация 109 на Web-сервисы или 110 - JSR на библиотеку JSWL, обеспечивающую API для работы с WSDL. Есть и новая JSR на новый тип компонентов “процесс”. Мы еще не знаем, как она будет развиваться, но идея интересна. Эта спецификация должна помочь обеспечить более тесную интеграцию - так же, как управляемый сообщениями компонент JavaBeans стал значительно сильнее интегрирован с JMS. Вы непременно увидите и более тесную интеграцию компонентов с помощью SOAP. Возможно, начнется определенное развитие в отношении поддержки ebXML.
Думаю также, что, вероятно, появятся более абстрактные типы - портлет (Portlet), процесс (Process). Фактически акцент смещается с создания отдельных компонентов на их агрегирование.
В отношении Web-сервисов главными вопросами остаются обеспечение безопасности и стандартизация коллективной работы всех этих компонентов. Существуют такие спецификации, как Web Service Flow Language (язык управления потоками заданий для Web-сервисов), и т. п. Я думаю, вы увидите больше Java API, связанных с Web-сервисами и различными другими спецификациями, и они в конечном счете попадут в спецификации. Так что я бы сказал, что версия 1.6 будет содержать полный набор спецификаций для поддержки Web-сервисов, в то время как версия 1.5 будет содержать хотя и многое из них, но далеко не все.
PC Week: Благодарю вас за беседу.
