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

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

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

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

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


Rambler's Top100

  

Настоящее и будущее средств разработки

Брайан Уолш

За последние месяцы я в полной мере смог оценить не только элегантность самой архитектуры, но и достоинства конкретных реализаций языка Java. Эта оценка стала результатом моего опыта работы со средствами разработки Java и Visual Basic (VB).

Приблизительно один раз в четыре года менеджеры корпоративных информационных проектов сталкиваются с проблемой выбора нового средства разработки. В настоящий момент наиболее подходящими претендентами на эту роль являются Java и VB. Оглянувшись назад в прошлое, мы увидим, что корпоративные разработчики пользовались разными средствами, к примеру, с языка Cobol перешли на язык Clipper, а затем — на PowerBuilder и VB. В свое время каждое из этих средств соответствовало как техническим требованиям к проектам, так и требованиям бизнеса. Тем не менее в результате эволюционного процесса менялся только инструмент разработки; сами же программисты по-прежнему применяли все те же старые подходы, т. е. просто “переводили” алгоритмы на новый язык.

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

Священные войны

Прежде всего оставим в стороне всяческие вопросы, касающиеся “истинной веры”. Как бы там ни было, но сегодня отрасль разделена на два слепо враждующих между собой лагеря, с одной стороны — компания Microsoft и ее сторонники, а с другой — все остальные. Microsoft настаивает на “непродуктивных” изменениях в объектной модели Java, тогда как все остальные утверждают, что только “чистое” Java-программирование “завоюет весь мир”. В то же время и сторонники и противники идеи “чистоты” дружно игнорируют тот факт, что пока еще никто не купил готового бизнес-приложения, целиком написанного на Java. Честно говоря, у меня нет желания обсуждать эту тему, поскольку я не владею акциями ни Sun Microsystems, ни Microsoft.

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

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

Все приветствуют Java

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

Возможно, одним покажется, что SmallTalk, Си++ и аналогичные языки обладают более элегантными и совершенными объектно-ориентированными средствами. Других, вероятно, заинтересует новое ключевое слово “implements” в VB и его использование для разработки серверов DCOM (Distributed Component Object Model). Все это так, однако, исходя из накопленного опыта в области программирования, следует признать, что SmallTalk и Cи++ остаются языками элитных (читай: высокооплачиваемых) разработчиков, а концепция VB, неважно по какой причине, не поощряет создание и развертывание многократно используемых объектов.

Культура программирования на Java требует, чтобы разработчики (как сторонние, так и штатные) предлагали решения в виде классов, которые могут наследоваться и использоваться, — в противоположность библиотекам DLL (Dynamic Link Library), OCX (OLE Custom Control) и прочим “штучкам”, получаемым от сообщества программистов на VB.

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

Прощай, VB!

В конце концов VB “окажется на полке” рядом с PowerBuilder и Clipper (и, возможно, вместе с Perl и Tcl). Симпатии большинства будут тяготеть к Java. Впервые мнение корпоративных разработчиков, поставщиков коммерческого ПО и академических кругов оказалось единым относительно общего языка и инструментария. Более того, сам конечный продукт является переносимым, объектно-ориентированным и приспособленным для работы в сети.

Компания IBM использует Java для создания структуры, позволяющей классам Java передаваться через сеть в форме агентов (aglet), автономно выполняющихся как при подключении к сети, так и без него. Чтобы эффективно работать с мобильными компьютерами и соединениями с ограниченной полосой пропускания, эти агенты могут загружаться и выполнять свою работу без использования сетевых ресурсов, а затем, если возникнет необходимость, “отправляться” на другой компьютер. За исключением очевидного применения для документооборота и обмена сообщениями, это имеет мало общего с сегодняшним нашим видением деловых приложений. Тем не менее подумайте о будущих потребностях бизнеса в таких областях, как выставление счетов, электронная коммерция (ЭК), выполнение сложных запросов и транзакций, и картина сразу изменится. Все это разрабатывается с применением инструментальных средств Java и поставляется в виде классов, которые может использовать любой более или менее обученный Java-программист вашего предприятия. Вряд ли то же самое можно сделать с помощью VB.

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

А как же Microsoft?

Мне бы очень хотелось включить сюда и пример фирмы Microsoft, однако она, как ни одна другая компания, приложила все свои силы, чтобы окончательно запутать вопрос с Java. С одной стороны, цена и производительность продукта Microsoft J++ замечательны, но с другой — Microsoft потратила гораздо больше сил и средств на пропаганду, оплату услуг юристов и сомнительные изменения в интерфейсе API классов Java, что привело к единственно возможному результату — созданию продукта, не обладающего переносимостью. Фирме Microsoft необходимо уяснить, что, имея выбор, заказчики отдадут предпочтение переносимому решению. Усилия Microsoft свели на нет эту возможность для Java-разработчиков, использующих API ОС Windows как замену переносимого API языка Java. И что взамен? Более эффективный способ доступа к буферу обмена?

Microsoft располагает необходимыми талантами и возможностями, чтобы сделать свою платформу первой среди многих. Действительно, в плане “голой” производительности, цены и поддержки таких стандартов, как сервлеты, Microsoft сделала очень многое. Однако вместо того чтобы сосредоточиться только на технологии, она позволила взять верх реакционным соображениям маркетинга. Microsoft должна пересмотреть этот пункт своей стратегии. Только приняв стандарты IP, ей удалось вытеснить Novell. Ирония заключается еще и в том, что при огромной популярности Java, Microsoft не удастся вытеснить Unix, не отказавшись от претензий на “собственный путь” для развития Java. Microsoft добьется успеха, если сконцентрирует свои усилия на том, чтобы сделать ОС Windows NT устойчивой и масштабируемой, прекратит борьбу со стандартами Java и займется разработкой по-настоящему эффективных методов использования возможностей этого языка.





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

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

• Виртуальный Госснаб для реальной экономики

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

• Устанавливаемые в стойку серверы

• СКС категории 6: за и против

• Избежать полировки наконечников оптических разъемов пока не удается

• Коаксиальный кабель: кому сухарь, а кому хлеб с маслом

• Nortel Networks: объединение на всех уровнях

• Балансировка загрузки «многозадачных» руководителей

• На заводе APC в Галвее

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

• Настоящее и будущее средств разработки

• XML: эсперанто для приложений

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

• Как внедрить SMB в среде Unix

• Управление уровнем обслуживания с разных точек зрения

• Подключение филиала по выделенной линии. Практические советы

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

• MSDSL: технология на все случаи жизни

• Маленькие и большие шлюзы IP-телефонии

• GSM on the Net: мобильность и интеграция обслуживания

• Операторы связи на рубеже столетий

системы учрежденческой связи

• Микросотовые системы стандарта Dect

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

• Средства антивирусной защиты серверов

• С такими друзьями...

новые продукты

• HP для инженеров, дизайнеров и поставщиков информационных услуг; Никто не хочет класть все яйца в одну корзину; Сatalyst 2924M XL: больше портов для сетевых штормов



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