Начальник говорит: «Это отраслевой стандарт».
Перевод: «У нас нет ни малейшего представления, почему мы делаем это именно так».
 |
| Боб Льюис работает консультантом в компании Perot Systems. Пишите ему по адресу bob_lewis@csi.com, или присоединяйтесь к дискуссии на странице http://www.infoworld.com. |
Готово? Могу поспорить, что вы использовали один из двух наиболее распространенных способов разметки. Центральный круг, скорее всего, наверняка превратился в «мэйнфрейм», «хост» или «сервер», а те круги, что расположились по бокам, стали «терминалами», «ПК» или «сетевыми компьютерами»; или же центральный круг вы пометили аббревиатурой «ПК», оставив для обозначения боковых кругов метки типа «мэйнфрейм», «сервер», «Web» и прочие словечки, касающиеся ресурсов, доступных посредством персонального компьютера.
Если вы предпочитаете схему, в центре которой находится мэйнфрейм, это говорит о том, что вы сторонник тяжеловесной сетевой архитектуры, в основе которой лежит модное, но таящее в себе массу заблуждений понятие тонкого клиента. С другой стороны, вы, как и я, могли в середину схемы современной сетевой архитектуры поместить конечного пользователя с его персональным компьютером, который используется для доступа ко всем необходимым ресурсам. Тогда, вероятно, вы разделяете мое настороженное отношение к методу сетевого проектирования, основанному на использовании тонких клиентов за счет «утяжеления» инфраструктуры сети.
Сети, построенные по такому принципу, существуют в двух вариантах. В первом случае конечные пользователи имеют дело с Windows-терминалами, во втором — с типичными для Web интерфейсами и программными средствами. Интересно то, что между этими двумя разновидностями одной архитектуры нет ничего общего, кроме того, что и в том и в другом случае имеется в виду использование предельно упрощенных клиентов.
Подход, в основе которого лежит применение Windows-терминалов, примечателен как раз тем, что абсолютно ничем не примечателен. Предоставляя альтернативную по отношению к традиционным ПК платформу для работы с теми же самыми старыми программами, он предполагает полное игнорирование архитектуры приложения. На самом деле термин «архитектура» в данном случае вообще неприменим, поскольку Windows-терминалы, по сути, лишь позволяют максимально отодвинуть клавиатуру и монитор от рабочего компьютера. Тем не менее, поскольку при таком подходе центральную позицию занимает главный компьютер, информационная служба способна жестко контролировать все ресурсы, доступные конечным пользователям.
Идея привлечения типичных для Web средств при общении конечного пользователя с компьютером представляется более интригующей. При создании приложений, которым предстоит работать в подобной среде, в распоряжении пользователя оказывается богатый ассортимент браузеров, сценариев JavaScript, загружаемых Java-апплетов и приложений, служебных компонентов, страниц Active Server, приложений Notes/Domino, сценариев Perl, а также множество других вещей, способных замедлить процесс реализации любого проекта, поскольку немало времени уйдет на то, чтобы во всем этом разобраться.
Использование Web-архитектуры означает, что часть кода выполняется на настольном компьютере, а часть — на сервере. Единственное, чего при этом нельзя делать, так это хранить программное обеспечение (кроме «небольшого», мегабайт на 50 или около того, браузера) на локальном жестком диске. Другими словами, вы лишаетесь возможности использования самого дешевого и быстродействующего информационного носителя. Это имеет смысл... если решено во главу угла поставить центральный компьютер.
Забудьте на мгновение о деньгах, и вы обнаружите, что Web-приложения и приложения настольных компьютеров, снабженные классическим графическим пользовательским интерфейсом, не исключают друг друга. Для того чтобы работать с приложениями обоих типов, вам потребуется прибегнуть к помощи многозвенной и, скорее всего, объектной архитектуры.
Обычно мы ориентируемся на работу с визуальным интерфейсом при использовании приложений, рассчитанных на вполне конкретные платформы. К числу таковых относится, например, программное обеспечение, помогающее служащим выполнять свои непосредственные обязанности.
При этом следует придерживаться простых правил, которые существенно облегчат вам жизнь: не трогайте системный реестр; ничего не помещайте в системную папку Windows; проверяйте, корректно ли работают с памятью устанавливаемые программы, и проводите тестирование всех приложений в рамках экспериментальной среды перед их установкой. Кроме того, стремитесь сделать каждый программный модуль переносимым на другие платформы и учитывайте возможности администрирования.
Если вы не знаете заранее, какие программы конечные пользователи будут запускать на своих компьютерах, а также при необходимости быстро распространить по сети какое-либо ранее не предусмотренное приложение, стоит присмотреться к Web-архитектуре. В подобной ситуации возможности графического пользовательского интерфейса, требующего локальной установки, вряд ли сопоставимы с преимуществами в скорости распространения новых программ.
Если вы ориентируетесь на Web, не забывайте, что вы не в силах повлиять на пропускную способность Сети, так что заставьте разработчиков проверять работоспособность своих приложений на системах, характеристики которых соответствуют минимально допустимым. Вы еще не забыли все то, что мы говорили о тестировании и администрировании? Так вот, это остается в силе и по отношению к Web-архитектуре.
При разработке (или покупке уже готовых) приложений для развертывания в вашей внутрикорпоративной сети intranet не забывайте о вынужденном «утяжелении» сети. То, что вы отводите центральное место конечному пользователю, еще не значит, что вы хотите затруднить доступ к хранилищам корпоративной информации.