Никаких революций

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

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

Структура программ

Помните то время, когда еще не было объектно-ориентированного программирования? А кто вспомнит первые попытки структурного программирования? Ведь когда-то Дейкстра сказал, что правильные программы не должны использовать оператор GOTO, а быть структурированными. И пошло развитие: подпрограммы, функции, параметры.

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

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

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

Архитектура приложений

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

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

Начав делить приложение на «уровни», трудно остановиться. Быстро стало очевидным, что бизнес-логика приложения — слишком «чувствительная» вещь, чтобы доверять ее клиенту, размещая на его персональном компьютере. Здесь и риск потери транзакций, и риск несанкционированного доступа, риск нарушения целостности из-за несогласованности версий. Кроме того, темпы роста «тяжести» приложений легко обогнали темпы роста мощности компьютеров, сделав клиентские части приложений совсем уж неподъемными.

Так в начале 90-х появилась «трехзвенная архитектура» — технология разделения приложения на систему доступа к данным, бизнес-логику и средства представления. Клиентская часть заметно полегчала, оставив в себе лишь элементы интерфейса и средства пользовательского ввода-вывода. Бизнес-логика была перенесена на сервер приложений, обеспечивая необходимый уровень производительности и безопасности, а сервер баз данных стал выполнять присущие ему функции: работу со структурированными данными на уровне запросов.

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

Средний слой

Построение трехзвенных приложений потребовало соответствующих технологий. Должен существовать средний слой (middleware), обеспечивающий выполнение программ бизнес-логики, управление ими, их взаимодействие и т.п. Так появились серверы приложений.

Одним из «классических» представителей middleware являются мониторы транзакций. В мире мэйнфреймов это был CICS, в Unix-мире — Tuxedo. Работа с ними требовала достаточно высокой квалификации, приложения должны были разрабатываться с учетом использования библиотек мониторов транзакций, как правило, без использования языков четвертого поколения (4GL); в случае Tuxedo приложения разрабатывались на Си. Но все эти затраты стоили того.

Параллельно развивалась технология объектных брокеров. Флагманом здесь, пожалуй, можно назвать компанию IONA, реализовавшую систему взаимодействия распределенных объектов на базе стандарта CORBA. В то же время появились и другие варианты программного обеспечения промежуточного слоя.

Технология

Information Bus компании Teknekron познакомила нас с методом передачи сообщений, реализовавшим концепцию подписка-публикация».

В 1995 году появилась Java, первое время развлекавшая публику веселыми картинками на Web-страницах. Картинки со страниц постепенно исчезли, что дало повод для заявлений об угасании интереса к платформе. Однако Java просто переместилась ближе к серверам, оказавшись как нельзя кстати. Прошло некоторое время, и появилась платформа J2EE (Java 2 Enterprise Edition), вобравшая все наработанные за предыдущие годы технологии.

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

Переносимость программ

Одной из несомненных причин успеха Java явилась ее переносимость между платформами. Посмотрим, какой трудный путь пришлось пройти, прежде чем мы получили такой результат.

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

Прошло немного времени, компьютеров стало больше, возникла потребность в том, чтобы использовать одну и ту же программу на разных компьютерах. Впервые стали говорить о переносимости программ. Тогда появилась запись машинных команд и адресов на языке, уже немного похожем на человеческий («move», «load», «add» в различных вариантах и их русские аналоги). Такие программы уже стало возможным переносить между компьютерами, преобразуя их в машинные коды с помощью программы-ассемблера. Первый шаг в сторону переносимости был сделан, появилась переносимость по крайней мере в рамках одной аппаратной архитектуры, одного набора машинных команд.

Следующий шаг был сделан создателями операционной системы Unix. Они поставили перед собой задачу научиться переносить Unix между разными аппаратными платформами. Для этого был разработан язык Си, на котором была переписана почти вся операционная система. Язык был спроектирован удачно, ОС Unix, шагнув от PDP-7 к PDP-11, стала завоевывать популярность, демонстрируя переносимость в действии. На сегодня не осталось, пожалуй, аппаратной платформы, на которой не была бы реализована та или иная версия Unix. Другие программы, написанные на языке Си, переносились тоже без особых проблем, требовались лишь небольшие настройки и перекомпиляция под конкретную платформу.

Оставалось только сделать следующий очевидный шаг — реализовать переносимость программ между платформами непосредственно в исполняемых кодах, чтобы процесс не требовал перекомпиляции, чтобы одну и ту же программу можно было сразу запускать и под IBM AIX, и под Sun Solaris, и под Windows. Тогда-то и появится возможность создавать объекты, «путешествующие» по Сети и выполняющиеся без изменения на разных платформах.

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

Переносимость данных

Вместе с потребностью в переносимости программ развивалась потребность и в переносимости данных. Началось с кодировок. EBCDIC, ASCII, КОИ-7, КОИ-8, «основная», «альтернативная», CP-1251... Уж где-где, а России этот вопрос знают не понаслышке. А в мире еще имеются японский, корейский и китайский (как минимум два варианта), которые вообще в 8 бит не укладываются! Выходом стала кодировка Unicode, охватившая все существующие и многие уже не существующие языки.

Следующий шаг — разметка документов. Теперь-то мы знаем, как важно отделять смысловую разметку от разметки представления, но какого долгого пути это потребовало! Теперь мы понимаем, как важно обозначить, что «Переносимость данных» является заголовком раздела второго уровня, а не просто текстом, написанным полужирным шрифтом Times размером 16.

Путь, который мы прошли, включает и troff, и TeX с LaTeXом, и MS Word, и Frame Maker, и многое-многое другое. Несовместимость между версиями, непереносимость между платформами, трудности автоматизированной обработки и тому подобные проблемы... Стало ясно, что, пока не будет разработан устойчивый переносимый стандарт хранения документов, мы будем обречены поддерживать старые DOS-овские персоналки и приложения только потому, что документы, написанные на них, больше ничем прочитать нельзя.

Кажется, что сейчас самое время сказать — и вот пришел XML. Нет, не так. XML не пришел сам по себе, он тоже явился результатом многолетнего эволюционного развития языков разметки, берущих свои корни в SGML. А сам SGML — не поверите — существует уже более 30 лет (http://www.sgmlsource.com/history/roots.htm)! И корпорации, заботившиеся о длительном хранении своих документов, перешли на этот язык разметки давно. Были разработаны «наследники» SGML для работы в различных областях промышленности и обороны, средства представления (стили и средства печати).

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

И вот — XML. Язык разметки, построенный на фундаменте опыта трех десятилетий. Интересно, что в его разработке и развитии участвуют именно те люди, которые работали над SGML. Опыт не только технологический, но и человеческий.

Логическим следствием стало использование XML и его наследников не только для хранения и обработки документов, но и для обмена сообщениями. Это естественно: ведь объекты, которые взаимодействуют в Сети, должны обмениваться друг с другом информацией, параметрами, методами. При этом здесь должен быть достигнут тот же уровень переносимости, который был достигнут для программ благодаря Java. Очевидно, что для построения этих протоколов ничего лучше XML и придумать нельзя. На основе XML были разработаны SOAP, UDDI, WSDL, ebXML и многие другие протоколы, аббревиатуры которых теперь все чаще мелькают в статьях, посвященных сетевым службам.

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

Пользовательский интерфейс

Сделаем еще один «исторический виток» — на этот раз обратимся к истории пользовательского интерфейса.

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

Экранный интерфейс совершенствовался, появлялись curses для Unix, первые оконно-менюшные системы в текстовом режиме для MS-DOS. Пользователи вошли во вкус, потребности возросли, простых терминалов и текстовых экранов стало мало, пришли графические оконные системы. Появление Windows задало новые стандарты пользовательского интерфейса: графика, окна, меню, кнопки.

Система X Window, распространенная на Unix, добавила пользовательскому интерфейсу сетевую природу: стало возможным иметь интерфейс на одном компьютере, а задачу запускать на другом.

Все стало хорошо, не хватало одного — переносимости интерфейса. Чтобы перенести задачу с одного компьютера на другой (пусть даже оба они работают под Windows, пусть даже под одной версией!), необходимо перенести целый ворох библиотек, настроечных файлов, иконок и прочего хозяйства. И, скорее всего, все это так и не заработает.

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

Итак, пользовательский интерфейс — Web, только Web. Буйство фантазии Web-дизайнеров в корпоративных приложениях надо было как-то укротить, представив пользователям понятный и предсказуемый интерфейс. Идеалом стала возможность унифицированного доступа к корпоративным приложениям через единый интерфейс (разумеется, через Web). Так появилось то, что стало называться «порталом»: единый интерфейс к набору приложений и служб с возможностью персонализации, учета и контроля.

Результат

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

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