Конференция была организована по инициативе Митчелла Керцмана, основателя компании Powersoft.

Керцман, занимающий ныне пост вице-президента компании Sybase, начал свое выступление с того, что заявил: переход к технологиям, разработанным специально для Internet, произойдет быстрее, чем аналогичный переход к вычислениям в модели клиент-сервер, имевший место в начале девяностых годов. Он поспешил заверить слушателей, что распространение сетей Intranet будет "не столь разрушительным и более эволюционным", чем тенденция к "оптимизации размеров" (rigthsizing) мэйнфреймов.

При этих словах докладчика собравшиеся испустили вздох облегчения. Но облегчение это было лишь временным: Керцман привел слова Марка Андриссена, основателя компании Netscape Communications и одного из тех, кто определил современный облик Сети. Андриссен сказал недавно, что архитектура клиент-сервер в том виде, в каком мы ее сегодня знаем, очень скоро будет вытеснена архитектурой на основе Internet. "До некоторой степени это действительно так", - признал Керцман.

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

Настоящий взрыв деловой активности в World Wide Web породил параллельное движение и в сетях Intranet - стремление использовать программы просмотра Web, серверы и сетевые протоколы типа TCP/IP и HTTP (Hypertext Transfer Protocol, протокол передачи гипертекстовых сообщений) в качестве стандартной платформы для внутрикорпоративных приложений.

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

  • Если раньше приходилось устанавливать различное ПО в зависимости от типа операционной системы клиента и приложения на сервере, то теперь будет достаточно единственной клиентской программы просмотра Web.
  • Если раньше в системе использовался набор разных транспортных протоколов, то теперь при передаче данных все компоненты системы будут использовать для связи протоколы TCP/IP и HTTP.
  • Если раньше так называемые "толстые" клиенты выполняли свою работу локально, то теперь "тонкому" клиенту будет достаточно выполнять программу просмотра Web и операционную систему, а на долю сервера придется большая часть нагрузки по обработке запросов, передаче сообщений и представлению данных.
  • Если раньше системным администраторам приходилось конфигурировать, а затем устанавливать на пользовательских системах всех имеющихся типов новое ПО, его новые версии и "заплатки", то теперь можно создавать новые приложения на языке Java и устанавливать их на сервере Web и предоставлять конечным пользователям возможность по мере необходимости подключаться к этим приложениям.

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

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

Согласно опубликованным не так давно оценкам компании Gartner Group, затраты на содержание традиционной локальной сети составляют 44 254 долл. за период в пять лет. 85% этих расходов составляют затраты на оплату труда по управлению, организации сети, учету, различных операций по перемещению информации, внесению изменений и добавлений, а также организации службы помощи пользователям настольных систем. Если же в информационную систему входят ПК различных типов, то к этой сумме нужно добавить еще от 10 до 40% в зависимости от того, насколько разнородной является среда пользователей.

Однако системных администраторов, рассчитывающих на непосредственную экономию при переходе на использование сетей Intranet, возможно, ожидает очень неприятное удивление. Такого мнения придерживается Джудит Гурвиц, президент компании Hurwitz Group. "Я считаю, что сложность сетей Intranet и затраты на их обслуживание будут стремительно увеличиваться с расширением их использования; кроме того, в них придется обеспечивать такие функции как безопасность и возможность управления транзакциями, - говорит Гурвиц и добавляет: Все это очень похоже на то, как пользователи некогда говорили: "Посмотрите, насколько архитектура клиент-сервер дешевле архитектуры мэйнфреймов!""

Первые шаги

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

Тем не менее, технология Intranet развивается быстро, и компании-производители продуктов для Internet вместе с традиционными разработчиками программ для архитектуры клиент-сервер торопятся заполнить пробелы в ее функциональных возможностях, предлагая новые инструменты и новые версии своих старых программ. Доклад, опубликованный Gartner Group, предсказывает, что системы Intranet для коллективной работы масштаба предприятия и соответствующие прикладные платформы должны появиться примерно между 1998 и 2000 годами.

Конечно, самым большим достижением стало появление таких объектно-ориентированных архитектур для разработки Web-приложений как язык Java. Их рождение позволяет надеяться, что исполняемые фрагменты приложений, или апплеты, переместятся с сервера на клиента. Клиент сможет использовать эти приложения для проведения вычислений, обработки данных и локальной генерации отчетов, а за информационной системой останутся функции централизованного контроля и управления работой программ на сервере Web. Ожидается, что примерно такими возможностями будет обладать среда разработки приложений ActiveX, о создании которого недавно сообщила компания Microsoft. Она предназначена для того, чтобы объекты, созданные с использованием технологии Microsoft OLE, могли быть использованы также и в рамках Web. Если архитектура Java ориентирована на поддержку целого ряда различных клиентов, то ActiveX пока поддерживает только операционные системы Microsoft.

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

Недостающие фрагменты

Одним из очень важных элементов, отсутствие которого в скором времени обещает восполнить Sun Microsystems, являются библиотеки ODBC. С помощью этих библиотек апплеты смогут устанавливать связь с любым сервером баз данных, а составители Java-приложений будут избавлены от необходимости создавать стыковочные программы с нуля. Подобную стыковку посредством интерфейса CGI (Common Gateway Interface) обеспечивают страницы Web, но Java кажется свободной от зависимости от страниц Web, равно как и от ограничений HTML.

Следующим серьезным достижением будет обеспечение в языке Java поддержки технологии ORB (Object Request Broker, брокер объектных запросов), отвечающей за взаимодействие многочисленных распределенных систем и приложений. Хотя Java-приложения и могут подключаться к этим ресурсам через локаторы URL на странице Web, но такой способ работы с истинно распределенными приложениями очень неэффективен. Достаточно сказать, что такие ссылки приходится задавать и корректировать вручную.

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

Sun и ее партнеры активно работают сейчас над тем, чтобы заполнить пробелы, имеющиеся в архитектуре Java. Вот наиболее перспективные из разработок:

  • Недавно компания Sun объявила о создании Java ORB Environment (JOE) - одного из нескольких продуктов, призванных обеспечить взаимодействие Java со службами распределенных вычислений, совместимыми со стандартом CORBA (Common Object Request Broker Architecture, единая архитектура брокера объектных запросов). Независимые производители ПО, например, компания Iona Technologies, уже начали создавать соответствующие продукты.
  • Sun объявила также о появлении Java Database Connectivity - интерфейса прикладного программирования на базе Java, аналогичного ODBC.
  • Компания Novell объявила о приобретении лицензии на Java и о том, что она собирается включить данную технологию в свою сетевую ОС NetWare. Это позволит разработчикам создавать приложения на Java с использованием таких возможностей NetWare как службы распределенных каталогов NetWare Directory Services.

Еще одно перспективное направление - совмещение модели разработки приложений, основанной на World Wide Web, с аналогичной моделью для n-звенной архитектуры клиент-сервер. Одним из примеров такого объединения может служить продукт WebObjects, выпущенный компанией Next Computer. Программы-адаптеры, размещенные между источником данных и собственно приложением, позволяют выполнять приложение в сети. Механизм, работающий с бизнес-правилами, следит за взаимодействием клиента с ресурсами, расположенными на сервере. Адаптеры как бы разъединяют клиентскую и серверную части приложения, позволяя разработчику переходить с одного языка программирования на другой (например, с С++ на Java), не внося изменения в сами бизнес-правила и серверную часть программы.

Подводные камни

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

Но именно тогда и начнут возникать главные проблемы у администраторов информационных систем.

С одной стороны, что совсем неплохо, - освоение правил работы в сети Intranet обещает быть куда проще, чем тот процесс обучения, через который приходилось пройти при знакомстве с технологией клиент-сервер. По словам Митчелла Керцмана сеть Intranet - это, до некоторой степени, надстройка над уже существующими платформами. Еще до появления Web многие компании начали принимать протокол TCP/IP в качестве своего внутреннего сетевого стандарта. Корпоративные и индивидуальные пользователи продолжают работать с Unix, Macintosh и Windows 95, просто добавляя к этим операционным системам программу просмотра Web в качестве основного пользовательского интерфейса и средства для формулирования запросов. Действительно, некоторые пользователи сетей Intranet сообщают о значительном снижении затрат на обучение персонала.

По некоторым оценкам, если пользователь уже знаком с программой просмотра, то для освоения построенного на ее основе приложения ему потребуется на 70% меньше времени, чем для освоения нового приложения с теми же возможностями. Кроме того, освоение языка Java - сравнительно нетрудное дело для всякого, кто уже знаком с программированием на С++.

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

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

Персонал информационной службы компании National Semiconductor, например, изучает различные продукты для сетей Intranet и их соответствие единой стратегии. Между тем, многие подразделения корпорации стихийно создают свои собственные сети Intranet. "Нам приходится работать изо всех сил, чтобы не отстать, - говорит Бреннан из National Semiconductor. - Самое трудное - это обеспечить пользователям возможность эффективной работы и вместе с тем управлять развитием системы так, чтобы не нарушить права интеллектуальной собственности, требований закона и не выпустить за пределы брандмауэра информацию, которая не предназначена для внешних пользователей".

Когда конечные пользователи начали эксплуатировать новые возможности сети, информационная служба National Semiconductor отметила "огромный рост нагрузки на сеть, на который она не была рассчитана, - рассказывает Бреннан. - Даже 100-мегабитный Ethernet не выдерживает".

Эта проблема высвечивает отсутствие еще одного важного элемента в общей картине сетей Intranet, а именно - инструментов управления, которые должны обеспечить планирование емкости сети, анализ производительности и поиск неисправностей. Имея в своем распоряжении подобные инструменты, корпорация типа National Semiconductor смогла бы удовлетворить растущие требования к объему передаваемой по сети информации, не прибегая к установке более скоростного оборудования в каждой локальной сети.

К счастью, подобные инструменты для сетей Intranet появляются гораздо быстрее, чем то было при формировании сетей клиент-сервер. Например, компания NetCarta объявила недавно о выпуске целой серии инструментов для навигации, отображения и и управления серверами Web. Такие компании как Computer Associates, IBM и Cabletron Systems очень активно развивают свои платформы управления сетями, стремясь сделать так, чтобы их разработки годились как для внутрикорпоративных сетей, так и для Internet.

В большинстве упомянутых программных продуктов делается попытка решить задачу управления большим количеством узлов Web. Поэтому серьезные разработчики приложений на языке Java, вероятнее всего, столкнутся с целым новым комплексом нерешенных еще задач управления. Сейчас нужны такие инструментальные программы, которые могли бы придать совершенство новой платформе, поскольку с увеличением размеров и сложности Java-приложений вероятность сбоя в программе из-за какой-нибудь глупой ошибки увеличивается экспоненциально. Язык Java еще настолько нов, что по сравнению с С или Cobol в нем еще очень немного готовых библиотек, которыми может воспользоваться программист. Однако такие инструменты уже начинают появляться. Например, компания Symantec недавно объявила о создании Cafe, интегрированной среды для разработки приложений на языке Java со встроенным компилятором, системой управления проектами и графическим отладчиком.

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

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

"Два мира..."

Трехзвенная архитектура клиент-сервер (ориентировочно 1997 г.)

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

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

Архитектура Internet/Intranet (ориентировочно 1998 г.)

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

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

Вести с переднего края

Вот что сообщают пользователи о проблемах, наиболее часто встречающихся в работе сетей Intranet и ждущих своего разрешения:

Безопасность. Не думайте, что если сети Intranet надежно укрыты за брандмауэром предприятия, то все проблемы обеспечения безопасности решены. Большинство случаев несанкционированного доступа к информации происходит внутри системы. Можно надеяться, что к концу года компании-производители достигнут всеобщего соглашения о промышленном стандарте обеспечения безопасности в Internet. Следует также иметь ввиду, что брандмауэры служат довольно плохой защитой от неаккуратных или неграмотных пользователей, без разбора загружающих в свои компьютеры разные страницы Web и Java-приложения, не проверяя при этом их источник. Тщательно продуманные и строго соблюдаемые правила безопасности совершенно необходимы.

Поддержка производителей. Недостаточная помощь со стороны производителей - довольно частый источник скрытых затрат при создании сети Intranet. Некоторые администраторы информационных систем привели недостаточную зрелость компаний, считающихся ведущими в области технологий Intranet, в качестве причины, заставляющей их не торопиться с переходом на новую платформу. Один из ярких примеров - компания Netscape Communications: как считают некоторые пользователи, стремительный рост этой компании мешает ей осуществлять качественную поддержку своих клиентов. "От такой компании как Microsoft можно получить подробные описания продуктов и хорошую консультацию специалиста, - говорит один из пользователей. - Руководство же программиста по продукту Netscape Commerce Server хотя и занимает 69 страниц, включая оглавление, но большую его часть занимают пустые места".

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

Миграция от традиционной архитектуры клиент-сервер. "Если информационная система написана на С или С++, то такой переход не слишком труден, - говорит один из пользователей. - Но если ваша система состоит из десятков тысяч операторов на Cobol или Visual Basic, то переход потребует значительных усилий".

Быстродействие Java. Даже компания Sun признает, что программы на языке Java работают примерно в 10 раз медленнее, чем аналогичные программы на С++. Пользователи же очень по-разному оценивают, насколько сильно этот недостаток сказывается на работе реального приложения.