Закономерность революций в компьтерных технологиях

Дата: 13/10/05;  Автор: Рубаха Юрий; 


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


  Рассмотрим некую систему, состоящую из 4 программных компонентов (рис 1). Каждый компонент – кубик, полупрозрачные трубки – это функциональные связи. Это могут быть программируемые интерфейсы, форматы файлов, сетевые протоколы разных уровней и прочее. Красная стрелка указывает направление роста производительности компонентов (будем считать, что компоненты со временем только улучшаются). Сейчас система находится в своем первичном состоянии – все компоненты имеют минимальную производительность и примерно соответствуют друг другу. В системе явных «узких мест» не наблюдается. Узким местом будем здесь называть компонент системы, резко снижающий какую-то важную характеристику системы: производительность, надежность, безопасность, экономичность по отношению к ресурсам.


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


  Перейдем сразу к ситуации, которая произойдет после последовательного обновления всех остальных компонентов (рис 3). Здесь в глаза сразу бросаются «провисающие» интерфейсы. Да, все компоненты системы уже изменены и улучшены, но интерфейсы остались теми же, что и в самой первой реализации системы. Это произошло опять же по нескольким причинам.
  Во-первых, переход на новые интерфейсы требует одновременного перевода «на новые рельсы» сразу нескольких компонентов системы, а как уже отмечалось раньше, часто они находятся в ведении разных (коммерческих) структур. В противном случае в каждый момент времени каждый элемент вынужден поддерживать тот же интерфейс, что и смежные с ним компоненты. Математическая индукция показывает, что этим интерфейсом будет именно первоначальный (кроме случая поддержки нескольких интерфейсов одним компонентом, но об этом позже).
  Во-вторых, часто интерфейсы оказываются очень инертными по причине того, что от них зависит не только эта система, а и много других, изменяющихся намного медленнее. Если роль интерфейса выполняют файлы, то остро стоит проблема обратной совместимости, и если совместимость снизу вверх чаще всего может быть обеспечена, то совместимость сверху вниз часто становится очень сложной задачей. Кроме того, существует уже большое количество документов старого формата, и производители приходят к решению лишний раз не подвергать стрессу беспокойного западного пользователя и оставляют все как есть.
  Компоненты изменились, а интерфейсы остались старыми. Вполне вероятно, что форматы данных используемые для обработки в самих компонентах уже будут отличны от передаваемых, поэтому некоторые компоненты «обзавелись» дата-адаптерами. Это усложнение также отражено на рисунке.
  Еще одно интересное явление – это дрейф требований к системам и документам. Форматы и методы обработки информации, идеально подходившие ранее, могут уже не являться такими сейчас. Например одним из основных прогнозируемых вариантов использования mp3 было использование его в бытовых проигрывателях, поэтому одним из основных требований к формату была простота и экономичность алгоритма декомпрессии, чтобы он мог быть распакован даже на устройствах со слабым процессором с очень небольшим количеством макрокоманд. Сейчас же мощность компьютеров такова, что допустимо и более ресурсоемкое декодирование в пользу большей степени сжатия. И действительно появились соответствующие этим признакам OGG и WMA. Но по некоторым причинам все же наиболее используемым сейчас форматом все еще является именно MP3.
  Примером другого массового сверх инертного интерфейса являются почтовые протоколы SMTP и POP3. Которые давно не выдерживают никакой критики по поводу безопасности (они даже не гарантируют достоверности поля «отправитель») и к тому же передают все данные в текстовом виде (даже текстовые вложения), иными словами «разжимают» содержимое. Словом протоколы никуда не годные, но с трудом подлежащие замене, виду массовости их использования. Меняются почтовые клиенты, меняется серверное ПО, но протоколы остаются неизменными. Их можно считать «узким местом» всей почтовой системы.


  Рассмотрим четвертый этап развития системы (рис 4). Возникла возможность расширить возможности системы, организовав связь между компонентами 1 и 3. Между ними может быть организован адекватный своему времени интерфейс, но каждый должен быть совместим и со старой версией парного компонента. Система усложнилась еще раз…
  Итак, мы видим, что в процессе эволюции системы на ней накапливается «исторический балласт» прошлых совместимостей, снижающий производительность на лишних преобразованиях информации, и увеличивающий ее вес и сложность, мы видим, что компоненты не могут отвязаться от старых интерфейсов и форматов, мы видим, что некоторые интерфейсы в принципе не могут быть изменены при постепенных и обратносовместимых изменениях компонентов программных систем. Иногда требуется одновременное изменение сразу многих компонентов. Похоже, это можно сделать только с новой операционной системой, только с ней можно принести в мир новые протоколы, форматы и технологии обмена командами и данными. Поэтому особенно важно при разработке новой системы максимально наполнить ее поддержкой новых технологий и стандартов, наиболее эффективных и соответствующих текущему технологическому уровню форматов. Это может стать залогом начального успеха системы у пользователей и обеспечить операционной системе долгую жизнь.