Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Java готовится к штурму предприятий
(окончание)

Кристина Хаджинс-Бонафилд

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

Лидирующими средствами разработки можно назвать Jbuilder компании Inprise, среду разработки для серверов приложений компании SilverStream, Visual Cafeў компании Symantec и VisualAge for Java корпорации IBM.

Подход Microsoft к Java

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

Visual J++ 6.0 — это новейшее инструментальное средство Microsoft для разработки управляющих элементов ActiveX, исполняемых программ для Windows, сценариев Java и апплетов Java для ее собственных платформ. Оно не только поддерживает версию Java от Microsoft, но и обеспечивает прямой доступ к платформе Windows (см. www.microsoft.com/ visualj).

Специалисты подразделения технологии Java в Microsoft надеются, что к 2000 г. Visual J++ будет так же широко использоваться в качестве средства разработки для Windows, как Cи++ и VB сегодня. По их мнению, лучшим вариантом было бы 25% всех разработок для архитектуры COM выполнять на Java и 50% — на VB. Однако специфика стратегии Microsoft заключается в том, что языку Java отводится роль средства обеспечения распределенных вычислений в COM, а для использования на клиенте отдается предпочтение Dynamic HTML. По данным Microsoft, в настоящее время около 3 млн разработчиков используют VB, и лишь 150 тыс. — Java.

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

Так, по мнению тех же специалистов Microsoft, для разработки требовательных к быстродействию систем лучше всего подходит Visual C++; там же, где необходима быстрая разработка, уместно использовать Visual Basic, а лучшее средство создания приложения для Windows и Web в рамках единой среды — это Visual J++. Они считают, что производительность Java вряд ли когда-либо сравнится с производительностью Cи++, однако, чтобы поднять ее у Java-приложений, Microsoft активно исследует возможность создания Java-компилятора, генерирующего код для Windows.

Интерфейсы распределенных вычислений: вавилонское столпотворение

Как раз в тот момент, когда крупные предприятия, казалось, были готовы приступить к применению распределенных вычислений, сделав выбор между технологиями COM фирмы Microsoft и CORBA консорциума OMG, появилась и начала «мутить воду» технология Enterprise JavaBeans (EJB).

Однако путаницы в технологии распределенных вычислений хватает и без EJB. Хотя независимые поставщики ПО с нетерпением наблюдают за COM и COM+ компании Microsoft, большинство крупных предприятий, похоже, решили использовать и COM, и CORBA, а теперь еще растет поддержка EJB как набора API, который предприятия будут применять в своих распределенных приложениях.

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

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

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

В ближайшем будущем ожидается появление большого разнообразия стандартных и фирменных интерфейсов и платформ распределенных вычислений, предназначенных для унификации несовместимых сред. Фирменные API должны будут обеспечить уровень абстракции прикладного программного интерфейса для CORBA, COM и EJB, чтобы упростить задачу разработки приложений для различных сред или увеличить их возможности. Они также расширят ограниченные функциональные возможности EJB.

В скором времени консорциум OMG примет стандарт CORBA 3, который позволит рассматривать CORBA как платформу для объединения различных объектных моделей. Он также учитывает наличие расширенных API для серверов приложений, начиная от NetDynamics компании Sun до продуктов компаний Novera Software и ObjectSpace, предоставляющих собственные средства доступа к различным средам распределенных вычислений.

Однако способы реализации этих API только подчеркивают серьезные различия в мире серверов приложений. Такие поставщики, как, например, BEA Systems, планируют поддерживать и расширенные API и подход, основанный на репозитории, обеспечивающий прямой доступ к API для сред, подобных EJB. Продукт NetDynamics компании Sun ориентирован на поддержку EJB в рамках фирменного набора прикладных программных интерфейсов BusinessBeans.

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

Заслуживающим внимания представителем другого типа новых платформ интеграции с фирменными API является серия продуктов Voyager компании ObjectSpace, использующих популярный посредник запросов к объектам (Object Request Broker) этой же компании. Voyager обеспечивает совместимость с CORBA и RMI, а в будущей его версии обещана совместимость и с DCOM.

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

В связи с появлением большого числа API становится ясно, что крупным корпоративным пользователям имеет смысл выбирать платформы, которые обеспечивают поддержку по крайней мере нескольких сред. Sun и OMG сделали в этом отношении первые шаги навстречу друг другу, выпустив спецификацию RMI over IIOP. Данная спецификация дает возможность отображать RMI на язык Interface Definition Language (IDL) архитектуры CORBA. Протокол RMI over IIOP позволяет программе, использующей RMI, «общаться» с объектом CORBA, не требуя от Java-программиста знания языка IDL. Основным преимуществом названной спецификации является устранение необходимости переписывать приложение, с которым работает CORBA, чтобы сделать его доступным из среды Java. Хватает ли кофеина в Javа? Если быстрота разработки приложений — это лучшая сторона языка Java, то его производительность — худшая, причем как реальная производительность, так и субъективное ее восприятие пользователями.

Java работает медленно, поскольку основана на интерпретации и необычайно требовательна к памяти.

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

Более разумным, чем создание микросхемы, способом повышения производительности является использование динамических компиляторов (Just-In-Time — JIT), которые могут довести производительность Java до 80% от производительности приложений Cи++.

Однако с этой позицией согласны не все. Руководители Microsoft считают, что производительность приложений Java составляет лишь 10—15% от производительности Cи++. Первые тесты виртуальной Java-машины, основанной на версии 2 JDK (Java Development Kit) компании Sun, дают надежду на ее увеличение. В JDK 2 используется компилятор JIT фирмы Symantec и имеется возможность подключать ускоритель HotSpot фирмы Sun.

Разработчики из компании Volano, поставляющей ПО для интерактивного обмена сообщениями, оценив производительность Java с помощью созданных ими средств измерений, утверждают, что ближайшие версии виртуальных Java-машин обеспечат производительность, сравнимую с производительностью машинного кода данной платформы для сервера классической сети (см. www.volano.com). Согласно их исследованиям, предварительные версии JVM от Microsoft, Novell и JavaSoft и появившаяся ранее JVM компании IBM в ходе тестирования были способны обеспечить обработку свыше 1200 сообщений в секунду.

Кроме того, они отмечают, что производительность JVM за последние три года возросла более чем в 30 раз, причем SunSoft «ускоряет» свою JVM в десять раз каждые несколько месяцев, с языком Cи ничего подобного не происходило. На производительность приложений также влияет, насколько хорошо написан код, а многие программисты еще только изучают Java.

Наилучшую производительность в вышеуказанных тестах показала виртуальная Java-машина TowerJ компании TowerTechnology, которая обрабатывала более 1700 сообщений в секунду. Однако эта JVM распространяется за деньги и, кроме того, может отпугнуть многих сторонников Sun: скорость TowerJ обеспечивается компиляцией в машинный код, что может сказаться на переносимости Java. Руководители Microsoft, а также многие аналитики убеждены: такая характеристика, как производительность, особенно на серверах, настолько важна, что использование компиляторов, генерирующих машинный код, неизбежно, даже если при этом ухудшается переносимость. Средство VisualAge for Java компании IBM, в частности, можно использовать для генерации машинного кода серверов IBM.

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

Итак, когда же скорость выполнения Java можно будет считать приемлемой? Аналитический центр Gartner Group считает, что производительность — понятие относительное и Java уже достаточно быстро работает для сетевых коммуникаций, встраиваемого кода, компиляции байт-кода Java в машинный код, JIT-компиляции, доступа к данным, пользовательского интерфейса и простых деловых приложений, выполняющихся на виртуальной машине. В то же время производительности Java недостаточно для загрузки апплетов из сети, кода системного уровня, математических вычислений с плавающей запятой, сбора мусора и Java-микросхем. Эксперты Gartner Group ожидают, что к 2001 г. производительность Java будет достаточной для выполнения всех этих процессов, за исключением загрузки апплетов. Они также предсказывают, что к этому времени производительность Java перестанет быть основным препятствием для ее применения более чем в 95% случаев.

Существует еще одна проблема, не менее важная, чем предыдущая, — это масштабируемость технологии. Три наиболее масштабируемые JVM, сохранившие также прежнюю производительность в новом тесте на масштабируемость VolanoMark фирмы Volano, должны начать поставлять в этом году Novell, Microsoft и JavaSoft. Каждая из этих виртуальных Java-машин может обрабатывать 900 сообщений в секунду при количестве соединений, достигающем 900. Обработка каждого сообщения размером 60 символов состоит в его рассылке всем остальным клиентам в данной группе.

Предположения

Что могло бы способствовать продвижению Java на рынке? Очевидно — это приложения для предприятий, разрабатываемые третьими фирмами. Если предприятия до сих пор не разрешили проблему стандартизации средств разработки для Java, неудивительно, что Java-приложения никак не могут появиться. Летом 1997 г. компании Sun и IBM определили число Java-приложений третьих фирм равным 1200. Это, вероятно, одна из причин, почему примерно половина компаний, отвечая на опрос журнала Network Computing по поводу доступности в настоящее время Java-приложений для предприятий, так низко оценили ее.

Специалисты из Sun полагают, что сегодня число Java-приложений намного превышает указанную оценку, поскольку она не отражает ситуации с использованием Java как интегрирующей платформы для традиционных приложений фирм SAP и PeopleSoft с целью разработки специфичных для предприятий приложений. Однако, по расчетам аналитиков, готовые к использованию на предприятиях продукты на основе технологии Java начнут появляться лишь в начале 1999 г.

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

Другой фактор, который будет определять успех Java на предприятиях в долгосрочной перспективе, — введение единой эталонной модели для компонентов Enterprise JavaBeans (EJB). Без такой модели, считают пользователи, нет уверенности в прозрачной работе EJB на гетерогенных платформах. Корпорация IBM подготовила для модели EJB эталонную реализацию Java Transaction Service, которую лицензирует Sun. Последняя, со своей стороны, выпустила эталонную модель Java Servlet Engine, лицензируемую IBM. Очевидно, общее согласие в том, что для всего множества функций EJB необходима единая эталонная модель, найдено.

Пользователи и аналитики склонны считать причиной появления эталонной модели EJB лишь одно обстоятельство: компания Sun просто «задыхается» под тяжестью своих обязательств по Java. Почему бы тогда ей не передать полностью эту работу какому-нибудь партнеру, например IBM? Обещания Sun, что она действительно собирается работать с партнерами, вряд ли кого-нибудь удовлетворят. Аналитики считают, что, поскольку ведение проекта исключительно внутри Sun обеспечивает контроль над эталонной реализацией, компания будет сопротивляться передаче такой важной работы на сторону. А это, в свою очередь, замедлит внедрение Java на предприятиях.

Что будет с Java?

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

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

Компании с самыми крупными командами Java-разработчиков решают свои кадровые проблемы, переучивая программистов, работавших на языках Cи и Cи++ и организуя наставничество более опытных разработчиков над начинающими.

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





  
2 '1999
СОДЕРЖАНИЕ

колонка редактора

• Гонка порталов

локальные сети

• Пригодна ли существующая проводка для Gigabit Ethernet?

• Две тысячи и одна проблема

• Многопроводные телекоммуникационные кабели (витые пары и экранирование)

• NAS: простота и эффективность

• Как выбрать концентратор Fast Ethernet

бизнес

• Этапы сделки. Все по полочкам

интернет и интрасети

• Java готовится к штурму предприятий (окончание)

• Web-аутсорсинг

корпоративные сети

• Системы обмена сообщениями на новом витке развития

• Комплексные решения по управлению информационной средой предприятия

• Эх, прокачу! или Модемы стандарта V.90

услуги сетей связи

• Sync Research поднимает управление сетями Frame Relay на новый уровень

• Система сигнализации B-ISDN UNI 3.x: функционирование и тестирование. Часть 1

• Развитие фиксированной спутниковой связи в России и странах СНГ

• Система абонентского радиодоступа из России, для России

• «Тупая сеть» как светлое будущее телекоммуникаций. Часть 1

защита данных

• Семь межсетевых экранов масштаба предприятия



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх