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

Как значится в словаре Free Online Dictionary of Computing, «тонкий клиент — это клиентское устройство (или программа), передающее большую часть исполняемых им функций серверу». Толстый клиент определить намного проще: это все клиенты, не являющиеся тонкими. Противопоставление чего-то «тонкого» чему-то «толстому» невольно вызывает ассоциацию с персонажами известного чеховского рассказа, в котором, как известно, толстый был богатым и благополучным, а тонкий — его противоположностью. Эта параллель, оказывается, как нельзя более точно соответствует современному положению дел с «толстыми» и «тонкими» устройствами, устанавливаемыми на рабочих местах.

Действительно, по отношению к «толстым» объем производства, суммы инвестиций, объем накопленных знаний и опыта на порядки выше и больше. В силу сложившихся стереотипов и инерции мышления маловероятно, что в ближайшей перспективе положение тонких клиентов на рынке радикально изменится — и это несмотря на то, что вот уже без малого десять лет некоторые вендоры и аналитики упорно предсказывают им светлое будущее. Стоит вспомнить широко разрекламированную, но, увы, не слишком удавшуюся совместную акцию IBM, Oracle, Sun Microsystems и Netscape Communications по продвижению Сетевого компьютера (Network Computer, NC). Не менее показательна и ошибка в предсказаниях IDC. В 1999 году, когда идея NC уже потерпела крах, аналитическая компания в своем отчете прогнозировала, что в 2004 году будет произведено 9,5 млн тонких клиентов. На деле же, вероятно, в нынешнем году их будет выпущено лишь 1,8 млн, поскольку в 2003 году изготовлено 1,5 млн тонких клиентов, а ежегодный прирост их производства составляет примерно 20%. В прошлогоднем отчете в IDC, корректируя свои прежние прогнозы, говорят теперь всего о 3,4 млн в 2007 году.

Многие профессионалы и в середине 90-х годов достаточно скептически относились к перспективе быстрой замены персональных компьютеров терминалами. Оптимизм рождался преимущественно из принятия желаемого за действительное, а сомнения возникали из понимания того, что противостоять натиску ПК невероятно сложно. Так было и десять лет назад, и особенно сейчас, когда заметно подешевели ноутбуки, и появилась реальная возможность пользоваться ими на рабочих местах. Тем не менее, пока еще немногочисленные компании, связавшие свой бизнес с идеей тонких клиентов, могут смотреть в будущее с осознанным оптимизмом. На их стороне — экономическая эффективность, в то время как толстые клиенты (те самые ПК на рабочем месте), становясь все толще и толще, не прибавляют особенно заметно в функциональности, а их администрирование превращается в серьезную проблему. В общем, все это похоже на проблему роста популяции сверхтолстых людей в Соединенных Штатах из-за злоупотребления «фастфудом», ведь персональный компьютер, оснащенный Windows, в конечном счете, — тот же гамбургер.

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

Централизация администрирования — характерная для последнего времени тенденция, явно наблюдаемое логическое сближение двух очень далеких направлений в развитии компьютерных систем. Одно представляет классический мэйнфрейм с его всеобъемлющей централизацией, другое — распределенные системы. Поначалу они казались столь многообещающими, что мэйнфреймам предрекали скорую кончину, но по мере усложнения распределенных систем обнаружились их многочисленные слабости, в том числе связанные с архитектурой «клиент-сервер». Как следствие, началось движение в сторону централизации. Среди его проявлений — многозвенные программные системы, использующие серверы приложений, разнообразные подходы к виртуализации, консолидация и многое, многое другое.

Приходится признать, что с помощью новых технологий строятся своего рода «виртуальные мэйнфреймы», и таким системам вовсе не требуется толстый клиент в качестве терминального устройства. Не помешает вспомнить, что в качестве рабочих мест первыми стали использоваться (если не учитывать печатающие на бумаге телетайпы) простейшие терминалы с монохромной электронно-лучевой трубкой, которые называли dumb («немой») или green («зеленый»). Все, что они могли, — передавать на компьютер набранные на клавиатуре символы и отображать их на экране. Вершиной создания таких устройств и стандартом де-факто стал терминал VT-100, входивший в комплектацию мини-ЭВМ компании DEC. Для виртуального мэйнфрейма нужен аналог терминала, — естественно, соответствующий текущему моменту, то есть обеспечивающий графический режим взаимодействия и потенциальную возможность беспроводного доступа.

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

Наконец, еще одна причина заключается в том, что использование толстого клиента в качестве устройства для оперирования данными предприятия приводит к увеличению непродуктивного трафика в корпоративной сети, а сокращение трафика особенно актуально в связи с распространением беспроводных устройств. Разумеется, применение толстого клиента в качестве рабочего места может быть обоснованным, если на нем выполняется значительный объем вычислений (например, для CAD/CAM).

Современный рынок тонких клиентов очень напоминает рынок ПК до появления IBM PC или рынок локальных сетей до установления монополии Ethernet. Он невелик, разнороден, на нем отсутствуют общепринятые стандарты, предлагаемые устройства трудно классифицировать, а конкурирующие предложения невозможно сравнивать с достаточной объективностью. Поэтому сложно точно сказать, что такое «тонкий клиент». Можно лишь утверждать, что система с тонким клиентом состоит из трех основных компонентов: собственно клиента, сервера и коммуникационных средств, связывающих клиента с сервером.

Еще сложнее провести сравнительный анализ имеющихся решений. В качестве клиентов могут использоваться Windows-терминалы, наладонные устройства (КПК), сетевые компьютеры и различные Java-устройства, прежде всего Sun Ray. Некоторые авторы также относят к тонким клиентам сетевые ПК (Network PC, или NetPC), такие как WebPC (компания Dell) и e-Vectra (Hewlett-Packard). Однако в NetPC имеются жесткие диски и Windows, хотя нет ни флоппи-дисководов, ни слотов расширения, а для подключения внешних устройств могут применяться порты USB. Скорее, это все же усеченная версия ПК.

Главное в том, что тонкий клиент является лишь устройством отображения и ввода данных. Точно так же, как когда-то алфавитно-цифровой терминал обеспечивал символьный обмен, современный тонкий клиент обеспечивает обмен графическими данными — т.е. в принципе, можно сказать, что это графический терминал. Он запускается с сервера (будь то сервер под управлением Windows NT, Novell Netware, Unix или мэйнфрейм), с него же загружается необходимый фрагмент операционной системы, причем из-за отсутствия жесткого диска загрузка выполняется в ROM. В терминалах Sun Ray от Sun Microsystems и этого не требуется. В определенном смысле они аналогичны древним алфавитно-цифровым терминалам (правда, для терминалов Sun Ray обязателен цветной графический режим). На презентационном уровне для Windows-терминалов используются протоколы RDP (Microsoft) или ICA (Citrix), для Unix-приложений — протокол X11, а Sun Ray 1 имеет собственный протокол Sun Ray. На сетевом уровне могут применяться протоколы DHCP, Bootp, TFTP, SNMP, но чаще всего — TCP/IP и UDP/IP.

Старый добрый X

Почти всю функциональность современных тонких клиентов когда-то удалось воплотить в оконной системе X Window System (ее еще называют X11 или просто X), реализованной в Unix, а также в Linux и других Unix-подобных операционных системах. X Window System дает основу для графического пользовательского интерфейса, предоставляя возможности рисования, создания окон, применения мышки и клавиатуры, но не определяет интерфейс как таковой, позволяет оперировать пользовательским программным обеспечением, являясь «механизмом, а не политикой».

Система Х была создана в 1984 году в Массачусетском технологическом институте при участии компании DEC. Своими корнями она уходит в студенческий проект, известный как Project Athena (он, к слову, дал толчок к появлению и протокола аутентификации Kerberos). В рабочем названии системы первоначально вполне закономерно значилась буква W, но потом по каким-то причинам ее заменили на X. Первая версия системы, X10, была выпущена в 1986 году, а нынешняя, X11, — в 1987-м. Проект поддерживает организация X.Org Foundation, но если судить по тому, что последнее обновление датировано 2001 годом (релиз X11R6.6), в настоящее время особенной активности в X.Org не наблюдается.

Система X появилась раньше, чем архитектуры «клиент-сервер» в их традиционном понимании. Поэтому она опирается на своеобразную и, на первый взгляд, странную для уха большинства специалистов трактовку ролей сервера и клиента. Здесь все наоборот: клиентом является обслуживающая программа, расположенная на физическом сервере, а сервером — программное обеспечение, размещенное на терминале. Известно несколько реализаций Х, в том числе система Motif, принятая в качестве промышленного стандарта IEEE 1295; ее основным приверженцем является компания Sun Microsystems. Стоит привести примеры и современных разработок, реализующих X.

  • GNOME (GNU Network Object Model Environment). Выпущена в августе 1997 года молодым мексиканским программистом Мигелем де Икаса в качестве свободного программного обеспечения для операционной системы GNU/Linux.
  • KDE (K Desktop Environment). Создана в 1996 году Матиасом Эттрихом, в ту пору студентом Тюбенгенского университета. Работает в среде ОС Unix и Unix-подобных систем (такие как Linux и Mac OS X) и даже под Microsoft Windows с использованием Cygwin (средства, позволяющие выполнять Windows-приложения в среде Unix без перекомпиляции).

Сегодня система Х представляет наибольший интерес для тех, кто создает дешевые компьютерные конфигурации (например, для учебных заведений), поскольку позволяет строить работоспособные системы с использованием устаревших ПК в качестве X-терминалов (рис. 1). Надо отметить, что в свое время X-терминалы были дорогими устройствами, существенно дороже ПК, но они больше не производятся: теперь в качестве X-терминалов чаще всего применяются обычные устаревшие ПК (например, с процессором 486) без жестких дисков.

Рис. 1. Подключение Х-терминала

И великим свойственно ошибаться

Размах пропагандистской кампании, развернутой в середине 90-х совместными усилиями IBM, Sun, Oracle и Netscape, вполне мог заставить поверить в то, что «сетевой компьютер» если не вытеснит, то уж заметно потеснит ПК. Первым этот термин произнес президент Oracle Ларри Эллисон — в конце 1995 года, на конференции IDC в Париже. Появившиеся вслед за тем радужные прогнозы подкреплялись буквально фантастическими успехами только что возникшего, но успевшего завоевать популярность языка программирования Java и упоением возможностями, которые предоставило сочетание WWW и Internet. Казалось, компьютерный мир вступает в новую эпоху.

Компьютер, который еще до его появления на свет назвали сетевым, не планировали использовать как тонкий клиент в полном смысле слова. Это была бездисковая рабочая станция, мощность процессора которой была достаточной для работы виртуальной машины Java; предполагалось, что на нее будет скачиваться необходимое программное обеспечение, написанное на Java, для последующего выполнения в локальном режиме. В Sun такой компьютер назвали Java Station и разрабатывали для него специализированные процессоры picoJava, microJava и другие.

Идея была красивой, но непрактичной: ее авторы не учли два критически важных обстоятельства. Во-первых, пакеты для офисной работы нелюбимой ими корпорации Microsoft успели стать стандартом де-факто, и без наличия совместимых с ними программ рассчитывать на успех не приходилось. Во-вторых, в 1996 году пропускная способность имевшихся даже в США каналов связи была недостаточной для запуска в жизнь подобной технологии. В 1998-м и 1999 годах участники кампании под лозунгом Network Computer постарались сделать все возможное, чтобы об их неудаче поскорее забыли. Со своей стороны, в Sun Microsystems поработали над ошибками: теперь ставка делается на пакет офисных приложений StarOffice и терминал Sun Ray.

С подачи конкурентов

Кому-то покажется странным, но от затеи с сетевым компьютером нескольких очень крупных компаний больше всех выиграли не они, а корпорация Microsoft, в пику которой все и задумывалось. Если говорить на языке хоккея, Microsoft великолепно освоила тактику игры от обороны, которая особенно эффективна при наличии достаточной массы. В свое время необходимость выйти из-под удара предложенного Apple графического интерфейса и сетевых возможностей ОС Unix заставила корпорацию сформировать облик Windows 3.1. Далее последовала угроза сетевых услуг от AOL, но она была отбита средствами операционной системы Windows 95. Наконец, появился браузер Netscape Navigator, который, казалось, вот-вот захватит весь рынок, но он был сметен контрнаступлением Internet Explorer.

Нечто подобное произошло и с идеей тонкого клиента, которая раскручивалась в противовес Microsoft: именно ей в известной мере удалось то, на что так яростно, но неудачно посягали ее конкуренты. Она купила у компании Insignia Solutions программный продукт NTRIGUE, который обеспечивал удаленный доступ к Windows, и включила его в состав Windows NT 4. В результате, тонкие клиенты смогли вступать во взаимодействие с сервером, на котором работало программное обеспечение Windows Terminal Server, примерно так же, как это прежде делала X Window System в среде Unix.

Когда Microsoft представила собственную технологию работы с тонкими клиентами, проповедники альтернативных решений поначалу не отнеслись к этому начинанию достаточно серьезно, но, вопреки скепсису, технология оказалась удачной. В 1995 году корпорации сделала неплохую подачу компания Citrix. Разработанный ею программный продукт WinFrame превратил Windows NT Server в многопользовательскую систему, доступ к которой осуществлялся с простейших терминалов Winterm. Тогда Citrix получила лицензию на исходные тексты NT Server 3.51 и на некоторое время стала партнером Microsoft. Но позже ей не была предоставлена лицензия на код NT 4.0, и Citrix пришлось создать собственную многопользовательскую архитектуру MetaFrame.

С тех пор близкие идеологии Citrix и Microsoft существуют параллельно. Общим для них является то, что передаются только обновления экрана, сигналы от мыши и клавиатуры, а соединение поддерживается по TCP/IP. При этом используются разные протоколы: Citrix опирается на протокол ICA (Independent Computing Architecture — «независимая вычислительная архитектура»), а Microsoft — на RDP (Remote Desktop Protocol — «протокол удаленной настольной системы»). Детальный сравнительный анализ приведен в обзоре Microsoft RDP & Citrix ICA Feature Overview (www.microsoft.com/windows2000/server/ evaluation/features/rdp.asp).

Поддержка тонких клиентов началась с операционной системы Windows NT Server 4.0. Доступная в ее составе редакция Terminal Server Edition поддерживает, в том числе, «сверхтонкие» (по терминологии Microsoft) клиенты, обеспечивая выполнение приложений с настольных устройств разных типов, включая специализированные Windows-терминалы, рабочие места на ПК, на которых установлена 32-разрядная операционная система Windows 95 и выше, рабочие места под управлением 16-разрядной ОС Windows 3.11.

Программное обеспечение Windows NT Server 4.0, Terminal Server Edition состояло из трех основных компонентов.

  • Терминальный сервер — ядро, которое обеспечивало выполнение нескольких клиентских сеансов одновременно. Стандартные Windows-приложения для выполнения под управлением терминального сервера модернизировать не требовалось.
  • Протокол доступа с удаленной настольной машины — ключевой компонент, обеспечивавший взаимодействие между терминальным сервером и тонким клиентом. По замыслу, RDP наследовал стандартный протокол ITU T.120, ранее использовавшийся в продукте для проведения онлайновых конференций Microsoft NetMeeting.
  • Тонкие клиенты — Windows-терминалы и персональные компьютеры.

Эти компоненты обеспечивали выполнение приложений на сервере и их распределение между клиентами; приложение выполнялось на сервере «от лица» клиента. На рисунке 2 показана схема взаимодействия клиента с сервером в рамках базовой концепции, которую можно развить, дополнив ее средствами компании Citrix.

Рис. 2. Взаимодействие терминального сервера Windows Terminal Server с клиентом

Последующие редакции Windows 2000/2003 Terminal Server поддерживают протокол RDP 5.1 и имеют целый ряд дополнительных возможностей, повышающих удобство работы. При этом они остаются в той же технической и рыночной нише, которую занимает Windows NT Server 4.0.

Microsoft ввела собственную классификацию тонких клиентов, разделив их на три категории (впрочем, устройства двух последних типов скорее следует назвать NetPC, чем тонкими клиентами):

  • простой терминал (Basic Terminal) имеет наименьшую функциональность и может использоваться вместо взамен старых алфавитно-цифровых терминалов; рекомендуемая операционная система — Windows CE .NET;
  • Internet-терминал (Browser Terminal) в основном предназначен для обеспечения доступа к ресурсам Web, а от простейшего терминала отличается наличием Windows-подобного пользовательского интерфейса; рекомендуемая операционная система — Windows CE .NET или Windows XP Embedded;
  • бизнес-терминал (Line-of-Business Terminal, LOB) дает возможность локального выполнения ограниченного количества функций; рекомендуемая операционная система — Windows XP Embedded.

В Microsoft признают, что при использовании терминального сервера и протокола RDP можно подключать только Windows-терминалы, которые выпускаются Wyse, Tektronix и рядом других компаний. Для обеспечения более широкого спектра периферийных устройств в Microsoft рекомендуют использовать программное обеспечение Citrix MetaFrame. В таком случае можно будет подключаться по протоколу ICA, который позволяет строить более гибкие конфигурации (рис. 3).

MetaFrame + Windows 2000 Server

Отношения между Microsoft и Citrix напоминают встречающийся в природе симбиоз большого с малым (невольно вспоминается картинка, на которой неприметная птичка выклевывает паразитов из шкуры носорога). Основной продукт Citrix, который называется MetaFrame, является логическим «продолжением» Microsoft Windows Server. Его терминальные сервисы расширяют возможности соответствующих сервисов Windows Terminal Services.

Архитектура и протокол ICA, на которых основан MetaFrame, обеспечивают доступ к клиентским устройствам, использующим Windows или построенных на других принципах, без дополнительных изменений в программном обеспечении. В MetaFrame включены инструментальные средства, обеспечивающие простоту развертывания и администрирования, что, в конечном счете, позволяет легче масштабировать системы в соответствии с требованиями пользователей. Программа Neighborhood, являющаяся частью MetaFrame, дает системному администратору возможность передавать приложения отдельным пользователям и их группам. Предназначенная для этого портальная технология позволяет настраивать приложения так, что они выполняются непосредственно в среде Web-браузера. При этом портал может быть персонализирован в соответствии со спецификой конкретных пользователей и приложений.

Протокол (или, точнее говоря, архитектура) Independent Computing Architecture — краеугольный камень технической политики Citrix. Он включает в себя три компонента: серверное ПО, сетевой протокол и клиентское ПО. Важное преимущество ICA, благодаря которому эту архитектуру можно использовать в качестве расширения Windows 2000/2003 Terminal Server, состоит в возможности отделить логику приложения от пользовательского интерфейса на серверной стороне и выполнять приложения на все 100% на сервере. Сетевой компонент ICA позволяет «транспортировать» вводимые с клавиатуры символы, перемещения мыши и изменения изображений на экране, занимая лишь 20-килобитную полосу пропускания. На клиентской стороне пользователь видит только прикладной интерфейс. Архитектура ICA реализована на системном уровне, поэтому удается добиться эффективности и значительной компактности использования полосы пропускания.

Citrix предлагает свое решение в виде программного пакета MetaFrame Access Suite, который включает в себя следующие составляющие.

  • Презентационный сервер. MetaFrame XP Presentation Server представляет собой программную инфраструктуру, которая обеспечивает доступ к приложениям, размещенным на сервере и работающим под управлением Windows 2000 Server или Windows Server 2003. Данная инфраструктура реализует две основные функции: обеспечивает доступ к приложениям со стороны практически любых устройств и централизованное управление ими.
  • Презентационный сервер для ОС Unix. MetaFrame Presentation Server for Unix обеспечивает аналогичные возможности, но для приложений, работающих в среде Unix, и для Java-приложений.
  • Сервер конференций. С помощью MetaFrame Conferencing Manager команды исполнителей могут координировать свою работу с общими для них приложениями и документами.
  • Менеджер паролей. MetaFrame Password Manager — еще одна инфраструктура, созданная для регламентации доступа по паролям к приложениям, работающим в среде Citrix MetaFrame Access Suite.
  • Менеджер безопасности доступа. MetaFrame Secure Access Manager служит для обеспечения безопасности при доступе с помощью Web-средств.

Перечисленные компоненты Citrix MetaFrame Access Suite поддерживают доступ к корпоративным ресурсам, сохраняя управляемость гетерогенной среды. Иными словами, обеспечивается развертывание приложений под Windows и Unix, управление ими и безопасный доступ к ним. Доступ сотрудников компаний, их партнеров, клиентов и поставщиков может осуществляться посредством Internet, intranet и extranet, глобальных, локальных и беспроводных сетей.

Гетерогенная среда, совмещающая Web, Windows, Unix, Linux, Sun Solaris, IBM AIX, HP-UX, разнообразные другие платформы, при всей своей разнородности может быть объединена гомогенным решением для управления приложениями. Преимущества такого подхода очевидны: более развитая технология позволяет снижать издержки, а получаемая при этом гибкость управления — реализовывать актуальные сегодня идеи вычислений по требованию.

Реальные виртуальные сетевые вычисления

До последнего времени название Virtual Network Computing (VNC) связывали с известным инструментом дистанционного администрирования, с помощью которого «рабочий стол» сервера можно отображать на дисплее клиентского компьютера независимо от серверной операционной системы. На самом деле, инструмент этот являлся лишь частью более обширной разработки лаборатории AT&T в Кембридже (Великобритания), которая ранее была совместной исследовательской лабораторией компаний Oracle и Olivetti.

Программный продукт, предназначенный для администрирования, открыли для свободного доступа. По утверждению его авторов, он повсеместно использовался в самых крупных организациях и с 1998 года разошелся в 20 млн копий. Так ли это, проверить невозможно. После непонятной административной перестройки ряд сотрудников лаборатории создали компанию Real VNC, полностью сосредоточив свои усилия на разработке технологий для тонких клиентов; пока же ее программные продукты тоже можно загружать бесплатно.

В трактовке вновь созданной компании Virtual Network Computing — это программное обеспечение, которое позволяет с одного компьютера (клиента) получать доступ и вступать во взаимодействие с другим компьютером (сервером), расположенным где угодно в Internet, при помощи простенькой программы просмотра (рис. 4). Взаимодействующие компьютеры не обязаны быть однотипными. Скажем, сервер в офисе может работать под управлением ОС Linux, а доступ к нему из дома сотрудника — осуществляться с использованием настольного ПК, оснащенного Windows.

Рис. 4. VNC обеспечивает связь одного клиента с одним сервером. Виртуальное изображение, формируемое на сервере, отображается на клиенте

Такую универсальность обеспечивает протокол удаленного доступа к графическому пользовательскому интерфейсу удаленного кадрового буфера RFB (Remote Frame Buffer). Он позволяет серверу изменять содержимое кадрового буфера, воспроизводимого программой просмотра. Кадровый буфер с равным успехом доступен любой операционной системе, любой оконной системе и любому приложению, благодаря чему возможна совместная работа компьютеров, управляемых самыми разными ОС. Могут использоваться любые формы коммуникаций (естественно, включая протокол TCP/IP).

С определенным допущением можно утверждать, что VNC — логическое продолжение идеи X-терминалов. Однако, в данном случае клиент находится на естественном для него физическом клиентском месте, а сервер (его иногда даже называют Xvnc-сервер) — на физическом сервере. Подсоединение Remote Desktop Connection представляет собой клиентское приложение, позволяющее наблюдать за сеансом и даже управлять им с другой машины, которая выполняет функции VNC-сервера. Это, в полном смысле, протокол тонкого клиента, предъявляющий весьма скромные требования к программе просмотра.

Визуализирующая сторона протокола построена с использованием единственного графического примитива, смысл которого сводится к следующему: «поместить прямоугольник, состоящий из пикселей, в позицию с координатами X, Y». На первый взгляд, такое решение может показаться малоэффективным, даже туповатым. Но поскольку для разных наборов пикселей существуют различные схемы кодирования, из них можно выбрать ту схему, которая наиболее точно соответствует полосе пропускания, клиентской скорости рисования и серверной скорости обработки. Содержание буфера обновляется при пересылке требуемой последовательности прямоугольников; оптимизация этого действия возложена на сервер.

Конечно, написание клиентской программы просмотра не является задачей большой сложности. Нужно уметь работать с транспортным протоколом (обычно это TCP/IP) и каким-то образом отражать на экране кадровый буфер. Существуют VNC-клиенты для платформ Unix, Windows, Macintosh, Java и целого спектра компактных устройств.

Сервер гораздо сложнее. Из стремления упростить клиента на сервер перенесли весь интеллект; к примеру, он «готовит» пиксели в формате, удобном для клиента (в данном случае сервер — это своего рода виртуальная машина, которая обеспечивает вывод на клиенте). Сервер не является многопользовательским, хотя на одной Unix-машине могут сосуществовать несколько Xvnc-серверов, каждый из которых предназначен для своего VNC-клиента. Создавать серверы категории WinVNC еще труднее, поскольку в ОС Windows меньше таких средств и мест, куда можно вставить мониторы управления отображением, и она имеет не столь строго определенную многопользовательскую модель.

Трехуровневая модель Tarantella

Пожалуй, наиболее совершенное решение для создания серьезных корпоративных систем с использованием тонких клиентов предлагает компания Tarantella, которая представляет собой один из осколков того, что когда-то называлось SCO. (На сайте www.tarantella.com можно найти всеобъемлющий набор документации с описанием функциональных возможностей решения, а также полноценное руководство по администрированию.)

В Tarantella на первом уровне (рис. 5) находится произвольное терминальное устройство, которое взаимодействует с остальной частью программной системы посредством браузера, поддерживающего Java, или клиента Tarantella Native Client. Работающее на этом устройстве клиентское программное обеспечение взаимодействует с Web-серверами и расположенными на втором уровне серверами Tarantella, отображая то, что предоставляет пользовательское приложение. Для связи между первым и вторым уровнем используется собственный протокол AIP (Adaptive Internet Protocol).

Рис. 5. Трехуровневая модель Tarantella

На втором уровне находятся один или несколько серверов Tarantella. Каждый из них отвечает за аутентификацию пользователей Tarantella, взаимодействие с серверами приложений, отображение на экране клиента необходимых изображений, использование Java-апплеты и или Tarantella Native Client, сохранение выполнения приложения при выходе пользователя из системы с возможностью снова включиться в работу приложения при повторном входе в систему.

Наконец, к третьему уровню относятся собственно приложения.

Современная версия этого программного продукта, Tarantella Enterprise 3, обеспечивает быстрый доступ к приложениям, расположенным практически на любом сервере, с рабочего места, которое может иметь любое географическое расположение. Все, что для этого требуется на клиенте, — это наличие браузера и сетевого подключения. Доступ контролируется и персонализируется в соответствии со служебным положением, рабочими функциями и местонахождением пользователя. В архитектуре Tarantella Enterprise 3 клиент и приложение взаимодействуют только с «брокером» в виде серверов Tarantella и никогда — между собой. Таким образом, данное решение реализует примерно те же преимущества, которые получают при использовании широко обсуждавшейся трехзвенной модели приложений, в которой роль брокеров играют серверы приложений.

Tarantella Enterprise 3 позволяет связать в единую систему приложения и клиентов, не требуя их дополнительного согласования. Основой решения является протокол Adaptive Internet Protocol; он назван адаптивным, поскольку не требует, чтобы изначально были сделаны какие-либо предположения о свойствах клиента и канала, а при соединении выполняются необходимые измерения и выбирается наиболее эффективный способ взаимодействия. Область действия протокола — между виртуальной машиной, реализующей протокол (Protocol Engine) на сервере Tarantella, и отображающей машиной (Display Engine), работающей на клиенте. Протокол обеспечивает передачу вводимых пользователем данных, отображение изображений, печать и доступ к файлам. Если он используется вместе с Tarantella Security Pack, весь трафик AIP шифруется.

Sun Ray — самый тонкий клиент

В решении Sun Ray, предложенном Sun Microsystems, идея тонкого клиента доведена до логического предела (рис. 6). Устройство не имеет собственного состояния (как, например, сотовый телефон без SIM-карты). В данном случае роль SIM-карты играет более интеллектуальная смарт-карта, которая содержит сверхминиатюрный компьютер с оперативной памятью и перепрограммируемой постоянной памятью (electrically erasable programmable read-only memory, EEPROM). Ее вычислительная мощность сопоставима с мощностью PC XT, первого персонального компьютера IBM. Столь мощный ресурс позволяет хранить на смарт-карте все необходимые данные о клиенте и сеансах его работы, что, в свою очередь, дает возможность перемещаться с одного устройства на другое без потери данных (вплоть до сохранения состояния экрана). При использовании других аппаратных платформ тонких клиентов добиться этого нереально.

Рис. 6. Тонкий клиент Sun Ray

В «родном» режиме подключения к среде Solaris управление терминалами Sun Ray осуществляется с помощью специализированного программного обеспечения Sun Ray Server Software. Оно выполняет несколько функций, в том числе реализует общую систему администрирования, схему аутентификации пользователей, обеспечивает мобильность сеансов смарт-карт, восстановление при сбоях и балансировку нагрузки. Данные функции распределены между несколькими модулями.

  • Менеджер аутентификации (Authentication Manager) не только проверяет регистрацию пользователя в соответствующих базах данных, но и обращается к менеджеру сеансов, чтобы определить, имеется ли у пользователя открытый сеанс. Если таковой есть, он восстанавливается, а если нет, открывается новый.
  • Менеджер сеансов (Session Manager) управляет процессами ввода/вывода после того, как пользователю открыт сеанс. Если сеанс закончен, этот менеджер приостанавливает все процессы ввода/вывода. Менеджер аутентификации и менеджер сеансов являются обязательными компонентами операционной системы, поддерживающей Sun Ray.
  • Менеджер группы устройств (Group Manager) работает на каждом из серверов Sun Ray, поддерживая топологию и распределение нагрузки.
  • Поддержка работы периферии (Peripheral Device Support) осуществляется размещенным на сервере драйвером. Конкретный драйвер выбирается в зависимости от метода подключения (по сети или через порт USB).
  • Инструменты администрирования (Administration Tools) реализуют политику работы с пользователями, со смарт-картами, с группами серверов и решают иные управленческие задачи.

Заключение

Из далеко не полного перечня решений, связанных с использование тонких клиентов, видно, что в этой области пока еще не сформировался более или менее общий подход, а технологии разделены на несколько заметно различающихся «кланов». Сравнивать столь разные решения непросто. Пожалуй, единственное подобное исследование выполнила Лаборатория сетевых вычислений Колумбийского университета. Результаты исследований опубликованы в отчете «A Comparison of Thin-Client Computing Architectures», который (как и несколько близких по содержанию материалов) можно найти в Сети по адресу www.ncl.cs.columbia.edu/publications/cucs-022-00.pdf.

Как Windows стала многопользовательской

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

Из истории Windows хорошо известно, что изначально эта операционная система не задумывалась как многопользовательская, в отличие, скажем, от ОС Unix. Лишь много позже ее адаптировали к обслуживанию множества пользователей в форме терминальных сервисов. Первым этапом на пути к многопользовательскому режиму ОС Windows стал выпуск NT 4.0 Server в редакции Terminal Server Edition (TSE). В своем оригинальном виде — так, как она была реализована в NT 4.0 Server, — поддержка терминальных сервисов обеспечивались решением MultiWin, лицензированным у компании Citrix. С тех пор каждый из партнеров, Microsoft и Cirix, развивал технологии терминальных сервисов независимо, используя собственные решения, но родственность между их подходами сохраняется. Реализация терминальных сервисов в современных операционных системах Windows 2000 и Windows 2003 заметно отчается от того, как это было сделано в Windows NT 4.0. Однако следует учитывать, что эти системы не поддерживают 16-разрядные приложения, поэтому в случаях, когда есть необходимость в подобного рода приложениях, NT 4.0 остается единственным выбором. И хотя система эта морально устарела, начать рассказ о терминальных сервисах следует с нее: в первоначальном исполнении они выполнены проще и прозрачнее.

Терминальные сервисы NT 4.0

Для того чтобы адаптировать любую однопользовательскую операционную систему (в том числе, и Windows) к задачам управления многопользовательскими прикладными средами приходится внести существенные изменения в ее ядро. В Windows NT 4.0 Server работа по модификации заключалась в интеграции существовавшего ядра технологии MultiWin, разработанной в компании Citrix. Под интеграцией в данном случае понимается добавление или изменение нескольких компонентов, сервисов и драйверов в ядре NT 4.0. В частности, для обеспечения многопользовательского режима был изменен менеджер виртуальной памяти Virtual Memory Manager (VMM), а также Object Manager (OM).

В Windows NT 4.0 для обеспечения мультизадачности в основном используются три механизма.

  • Менеджер виртуальной памяти в TSE служит для решения одной из важнейших задач — отображения виртуальных адресов в адресном пространстве процессов в физические адреса в адресном пространстве физических страниц компьютерной памяти. В Windows NT отведенное процессу адресное пространство поделено на два подпространства размером по 2 Гбайт каждое; одно из них является пользовательским (область адресов, специфичная для данного процесса), другое — подпространством ядра (область системных адресов). Роль VMM заключается в установлении соответствия между пользовательским адресным подпространством и физической памятью, причем таким образом, чтобы пользовательские подпространства не пересекались, а системные вызовы внутри процессов обращались только в область собственной памяти данного процесса, но не других.
  • Необходимость в создании специального пространства сеансов (SessionSpace) возникает в связи с тем, что адресное пространство ядра является общим для всех процессов, происходящих в системе. Из-за большого количества процессов вероятно одновременное достаточно большое количество обращений по этим адресам, что приведет к неизбежной перегрузке. Такую опасность можно предупредить, выделив в TSE специальное адресное пространство в ядре, которое будет служить своего рода расширением адресного пространства самого ядра. Соответствие между собственной областью ядра и соответствующей ему областью SessionSpace устанавливается на основании индивидуальных идентификаторов процессов. Следует отметить, что каждому процессу в момент входа пользователя в системе присваивается уникальный идентификатор SessionID, который в данном случае и используется для установления соответствия между двумя областями памяти. Кроме того, в Windows NT 4.0 сервер Terminal Server виртуализирует все приложения и системные программы с тем, чтобы несколько процессов или пользователей могли обращаться к ним одновременно. Для этой цели также применяются идентификаторы. На рисунке 1 показаны примеры использования идентификаторов SessionID.
  • Для разделения одной копии исполняемого кода между несколькими процессами используется механизм разделения кода (Code Sharing или Copy on-Write Page Protection). На рисунке показано, что несколько пользователей могут обращаться к одному коду, находящемуся в части памяти, куда запись запрещена. А редактируемые пользователями документы находятся в разделенных областях памяти, куда запись возможна, но между ними нет никакой интерференции.
Рис. 1. Использование идентификаторов сеансы

Протокол RDP

Взаимодействие терминальных сервисов Microsoft Terminal Services с клиентами основывается на протоколе Remote Desktop Protocol (RDP) изначально разработанном для Microsoft NetMeeting. Протокол RDP спроектирован для поддержки сетевого протокола TCP/IP в локальных или глобальных сетях. RDP — производный от телекоммуникационного протокола ITU T.120, являющегося стандартом для многоканальных конференций. T.120 приспособлен для корпоративной среды и, будучи по своей природе мультисеансовым, нуждается в расширении RDPWSX, которое позволяет получать все клиентские пакеты. Это расширение управляет сеансами и вызывает модуль WINLOGON, реализующий аутентификацию пользователей. Если сеанс установлен, то управление передается в подсистему MultiWin, которая создает виртуальную локальную копию WIN32K.SYS со всеми необходимыми драйверами устройств. Драйвер терминала TERMDD поддерживает среду исполнения, а для поддержания взаимодействия с клиентом с использованием клавиатуры и мыши каждая сеансовая копия WIN32K.SYS загружает драйвер RDPWD.

Схема проведения сеанса по протоколу RDP упрощенно выглядит так. В процессе загрузки первой загружается системная консоль; ей присваивается SessionID со значением 0. Консольный сеанс запускает системную загрузку, конфигурирующую Windows NT и загружающую драйверы дисплея, клавиатуры и мыши. Затем Terminal Server входит в контакт с менеджером сеансов SMSS.EXE; тот загружает RDP в пользовательском режиме и создает два незанятых сеанса, которые прослушивают порт 3389 TCP и принимают пакеты.

В RDP пакеты формируются на презентационном уровне модели OSI. Пакеты оформляются и шифруются в соответствии с требованиями сетевых протоколов (в настоящее время RDP поддерживает только TCP/IP). Содержимое передаваемых сообщений состоит из символов, вводимых с клавиатуры, координат перемещения мыши, графических битовых образов и данных, направляемых на принтер. Для того чтобы оптимизировать формируемый трафик, используется целый ряд приемов.

  • Упаковка передаваемых графических образов. Дисциплина передачи графических образов устроена так, чтобы минимизировать трафик: клиентскому устройству сообщается только то, что нужно перерисовать с момента получения последнего сообщения; иначе говоря, передаются лишь изменения.
  • Кэширование глифов и битовых образов. Глиф — термин, заимствованный из архитектуры и полиграфии; в данном случае под ним понимается графическое представление символа в определенном шрифте, которое ставится в соответствие коду символов. RDP-клиент может автоматически резервировать как минимум 1,5 Мбайт памяти для кэширования требуемого текста в виде готового массива глифов. Битовые образы также кэшируются в памяти. При выполнении команды, посланной сервером, клиент может перерисовать изображение на дисплее очень быстро, используя содержимое кэша.
  • Компрессия. Для работы с клиентами по низкоскоростным каналам используются методы компрессирования, сокращающие размеры пакетов примерно вдвое.
  • Алгоритм кодирования. В RDP использован эффективный алгоритм кодирования экранных данных, аналогичный используемому в протоколе X Window System. Большая часть наиболее общих и часто повторяющихся элементов графики передается в форме команд, а не в форме битовых образов. Такой подход заметно сокращает количество передаваемых данных.

Терминальные сервисы Windows 2000 Server

В Windows 2000 Terminal Services механизм SessionSpace сохранился, но изменилась карта распределения памяти. Это предпринято с тем, чтобы сделать Windows 2000 более универсальной, независимой от того, инсталлированы или нет в конкретной информационной системе терминальные сервисы.

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

В Windows 2000 служба Terminal Services ответственна за управление сеансами, инициацию и завершение пользовательских сеансов, за извещение о событиях. Сервисы в измененном сервере Terminal Server теперь не зависят от протокола, может быть использован как «родной» RDP, так и сторонний протокол (например, Citrix ICA). Подобная независимость достигается за счет расширения пользовательского режима протокола, обеспечивающего работу сервера Terminal Server. В него вынесена специфичная для определенного протокола функциональность (например, лицензирование, управление сеансами и т.д.). Каждый из протоколов (в данном случае — RDP и ICA) имеет собственное расширение.

Терминальные сервисы Windows 2003 Server

Основной серверной операционной системой, поддерживающей терминальные сервисы, в современных условиях стала Windows Server 2003. Ее отличает, прежде всего, новая программа соединения с клиентом. Эта программа впервые появилась в Windows XP и носит название Remote Desktop Connection (RDC). Обеспечиваемый ею интерфейс проще, но эффективнее. RDC можно использовать для подключения настольных компьютеров, работающих под управлением Windows XP Professional, и для подключения к более ранним версиям TSE в составе Windows NT 4.0 и Windows 2000 Server. В RDC используется новая версия протокола RDP и новая модель лицензирования.

Операционная система Windows Server 2003 выпускается в четырех «изданиях»: Web, Standard, Enterprise и Datacenter. Эти варианты различаются между собой по функциональным возможностям, связанным с поддержкой терминальных сервисов. Наибольшими возможностями обладает Server 2003 Datacenter, а наименьшими — Server 2003 Web. Вариант Datacenter, предназначенный для наиболее крупных серверов, поддерживает от 8 до 32 процессоров. Помимо этого, есть еще две 64-разрядные разновидности изданий Enterprise и Datacenter, созданные под процессор Intel Itanium для работы с большими СУБД и в крупных транзакционных системах.

С появлением Windows 2000 в Microsoft значительно улучшили реализацию терминальных сервисов в ядре. Однако изменения коснулись и клиентов; в основном, они затронули RDP, позволив повысить функциональность и производительность многопользовательских систем. Между выпуском Windows 2000 Server и Windows Server 2003 корпорация представила усовершенствованные терминальные сервисы Terminal Services Advanced Client (TSAC). Эти сервисы по-прежнему основаны на функциональных возможностях протокола RDP 5.0, но поступают в форме управления ActiveX. Производительность TSAC сопоставима с предыдущим клиентом, но развертывание значительно проще. В Windows Server 2003 также появились средства дистанционного управления клиентом (Remote Desktop Client, RDC).

Лицензирование

Использование терминальных сервисов предполагает, что, помимо обычной лицензии на операционную систему, требуются еще два типа программных лицензий. Первая лицензия является стандартной лицензией для клиентов Microsoft Client Access License, которая требуется для доступа к файлам и сервисам печати Windows NT. Вторая лицензия, Windows Terminal Services License, поддерживает подключение клиентов. Со времен NT 4.0 до Windows Server 2003 система лицензирования претерпела серьезные эволюционные изменения и в своем нынешнем виде намного удобнее, чем прежде.

Не тонким клиентом единым

Возврат к тонкому клиенту можно назвать очевидным и наиболее прямым решением проблемы сложности, порожденной архитектурой клиент-сервер. В конечном счете, оно сводится к консолидации всех ресурсов в одном месте. Однако любое решение имеет свои свойственные ему подводные камни — так и на пути к реставрации централизованной инфраструктуры есть несколько серьезных препятствий. Среди таких препятствий — невозможность вынести все без исключения приложения с клиента на сервер. Очевидно, что в целом ряде случаев именно локальный характер вычислительной мощности является необходимым условием; следовательно, и толстому клиенту уготована долгая жизнь. Ключевым фактором остается системная организация. Новейшие технологии позволяют найти далеко не тривиальные альтернативы «типовому» тонкому клиенту; одну из таких альтернатив предлагает компания Softricity.

Softricity относится к разряду начинающих компаний. Ей менее пяти лет, но в отличие от подавляющего большинства своих «сверстниц», появившихся на свет в эпоху Intranet-бума, она создана не «юными дарованиями» с заметными спекулятивными интересами, а вполне зрелыми специалистами, которые были движимы целью материализации накопленного ими профессионального опыта. Сложившаяся вокруг Softricity обстановка необычна. Название компании и название ее программного продукта, SoftGrid, не слишком известны компьютерной общественности. Напротив, практически все серьезные отраслевые аналитики — Forrester Research, Enterprise Management Associates, Grid Technology Partners, IDC, Nemertes Research, Yankee Group — пророчат компании и продукту большое будущее. Все они сходятся во мнении, что новая версия SoftGrid 3.0 окажет заметное влияние на развитие модного ныне направления utility computing.

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

В качестве выхода из подобной ситуации предлагаются разнообразные подходы к адаптивным инфраструктурам, к различным вариантам виртуализации — от серверов с динамическими разделами до grid-инфраструктур. Единого представления о том, что такое адаптивность или grid, не существует. Каждый производитель преподносит собственное видение этих концепций, и у Softricity также имеется своя трактовка того, что такое grid и что такое виртуализация. Ее необычность заключается в том, виртуализации подвергается не среда, в которой выполняются приложения, а сами приложения.

Сердцевиной платформы SoftGrid является запатентованная технология SystemGuard, позволяющая выполнять приложения локально, на толстых клиентах, но — что чрезвычайно важно — без, казалось бы, неизбежной процедуры локальной установки, без каких-либо изменений в операционной системе. Плюсы такого подхода состоят в том, что централизация управления совмещается с возможностью полноценного использования локальных ресурсов. Возможность такого неожиданного поворота обеспечивается своего рода пакетированием приложений. Аналогия с передачей данных заключается в том, что приложение, как пакет данных в сети, несет с собой свою собственную конфигурационную обвязку. Эта внешняя оболочка приложений позволяет выполнять их в некоторой виртуальной песочнице (sandbox). Приложения оказываются несвязанными с конкретными машинами. Впрочем, это утверждение нуждается в ограничивающей детализации: все, что сделано в Softricity, работает только в среде Windows. Программное обеспечение SoftGrid трансформирует Windows и приложения, работающие на Terminal Server, в виртуальные сервисы, распространяемые по локальным или даже глобальным сетям.

Сравним два подхода к инсталляции приложений — стандартный и тот, который предлагает Softricity. В первом случае системные требования и установки приложения переносятся в области хранения операционной системы, вследствие чего приложение оказывается жестко привязано по месту (hard-coding). Во втором случае приложение помещается в виртуализованную среду, нечто вроде многоуровневой операционной системы.

Сравнение обычного Windows-приложения (а) с приложением, работающим в среде SoftGrid (б)

Основную работу по преобразованию приложений выполняет компонент SoftGrid, который называется Softricity Sequencer (что можно перевести как «синтезатор»). Этот компонент упаковывает приложения, превращая их в сервисы, предоставляемые по требованию. Модуль Sequencer выполняет две основные функции.

  • Формирование виртуальной среды исполнения. С этой целью Sequencer использует специальный монитор SystemGuard, который фиксирует все параметры приложения, требуемые для инсталляции, в том числе, установку системного реестра, используемые файлы, внешние переменные, файла с расширением .ini и другие компоненты операционной системы, требуемые для инсталляции, в том числе DLL. Затем Sequencer использует эти данные для создания виртуального пакета приложения SoftGrid.
  • Преобразование исполняемого кода приложения в блоки кодов, приспособленные для передачи по требованию. Далее Sequencer вырабатывает необходимую последовательность блоков для передачи клиенту.

Подготовка приложения к работе в среде SoftGrid сводится к четырем этапам.

  1. Оператор запускает Sequencer, а затем инсталлирует приложение так же, как он бы это делал в обычном режиме на компьютере пользователя. Sequencer следит за этим процессом, фиксируя все необходимые данные.
  2. Оператор запускает приложение на том компьютере, где установлен Sequencer, проверяя корректность, а сам Sequencer тем временам делит приложение на блоки.
  3. Модуль Sequencer создает файл SFT, содержащий оптимизированные для выполнения в виртуальной среде блоки кода и снабжает их дескрипторами на языке XML.
  4. Приложение публикуется на сервере SoftGrid Server, откуда оно может быть вызвано по требованию. Упаковка блоков обеспечивает безопасность и оптимальное использование трафика.

Таким образом SoftGrid обеспечивает поставку приложений по требованию. Кроме того, решаются и другие задачи администрирования, в том числе автоматическое конфигурирование настольных компьютеров, аутентификация и регистрация пользователей в режиме реального времени. Система централизованного управления построена на фундаменте Web-сервисов Microsoft .NET и большинства стандартов, принятых для Web-сервисов (в том числе, SOAP, UDDI).

Программный инструментарий SoftGrid разработан в согласии с технологиями управления программным обеспечением, принятыми в Microsoft, включая System Management Server, и может быть интегрирован в Citrix MetaFrame. Решения, предлагаемые Softricity, рассчитаны на очень скромные аппаратные ресурсы: все компьютеры могут быть оснащены процессорами Pentium III, причем с весьма скромными параметрами.