Рефлексивный Интернет

Реферат

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

Введение

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

На сегодняшний день парк вычислительных машин, имеющих выход в Интернет, представлен сравнительно малым числом суперкомпьютеров и мейнфреймов, множеством серверов, а также огромным числом персональных, мобильных и встроенных компьютеров. Суперкомпьютеры заняты решением прикладных задач, требующих большого объема вычислений. Мейнфреймы в основном используются для хранения и обработки бизнес информации больших компаний. Системы этих двух типов, как правило, имеют уникальные операционные системы (ОС), достаточно сильно привязанные к аппаратной архитектуре машины. Подавляющее количество серверов работает под управлением систем семейства Unix. Такие системы используются и в персональных компьютерах, однако, большая часть этого сектора привязана к Windows NT. Широким спектром представлены ОС, управляющие мобильными и встроенными компьютерами. К ним относятся системы семейств Unix, Windows CE, QNX, Palm, Symbian и другие.

Каждая из вышеперечисленных ОС поддерживает свои системные вызовы, собственные форматы данных и исполняемых файлов, специальные библиотеки прикладных функций и многое другое. Эти различия сильно затрудняют взаимодействие компьютеров друг с другом. На протяжении лет предпринимались шаги в сторону нивелирования различий ОС путем утверждения и стандартизации различных сетевых протоколов. В результате появились и получили повсеместное распространение протоколы HTTP, FTP, SMTP, POP, Telnet, и многие другие. Эти протоколы решают проблему обмена данными между компьютерами, а также позволяют осуществлять удаленные вызовы, что во многом способствует интеграции Интернета. Однако, несмотря на развитые коммуникационные возможности распространенных ОС, доступ к удаленным ресурсам в них не является прозрачным.

1. Разобщенность современного Интернета

На сегодняшний день большинство услуг Интернета можно условно разбить на четыре сектора. К первому относится Всемирная паутина (WWW), с которой связаны блоги, форумы, социальные сети, поисковые системы, и многое другое. Всемирная паутина в основном опирается на прикладные протоколы HTTP и HTTPS, через которые пересылается текст в формате HTML или XML. Ко второму сектору можно отнести электронную почту, использующую, как правило, прикладные протоколы IMAP, POP3 и SMTP. Третий сектор услуг связан с возможностью скачивания файлов и представлен как централизованными сервисами, основанными на протоколах семейства FTP, так и файлообменными одноранговыми (P2P) сетями с собственными протоколами поверх TCP/UDP (такими как BitTorrent или eDonkey). К последнему сектору отнесём услуги пересылки данных в реальном времени. К ним относится обмен мгновенными сообщениями, IP-телефония, Интернет-телевидение и Интернет-радио. Этот сектор представлен разнообразными службами, сильно разнящимися структурой даже внутри своего класса и базирующимися на собственных прикладных протоколах (также поверх TCP/UDP).

В нынешние дни в рамках WWW большую популярность приобретает сервисно-ориентированная архитектура (SOA), предполагающая клиент-серверную модель взаимодействия поставщиков услуг (web-служб) и их потребителей (web-приложений или других web-служб), обменивающихся XML-данными [1]. В какой-то мере SOA можно рассматривать в качестве упрощённого варианта распределённой архитектуры CORBA, базирующегося на нейтральных к платформе форматах SOAP и WSDL. Успех SOA стимулировал развитие многих производных от неё прикладных архитектур. К ним можно отнести сервисно-ориентированную архитектуру баз данных (SODA) [2], архитектуру открытых GRID-сервисов (OGSA) [3] и другие. Учитывая появившийся язык гипертекстовой разметки на основе XML (XHTML) и развивающиеся технологии визуализации XML-данных (например, стилевые таблицы XSL), можно сказать, что SOA начинает претендовать на роль универсальной инфраструктуры WWW.

Новизна SOA заключается в использовании порта HTTP для обмена сообщениями в XML-формате. Данный порт удобен для взаимодействия из-за своей доступности практически на любом хосте, а язык XML является дружественным человеку, и поэтому его обработка достаточно просто реализуется на любой платформе. Кроме этой технологии SOA не предлагает ничего нового, а её конкретные реализации уступают некоторым предшествующим системам, как в плане производительности, так и по уровню безопасности. Важно понимать ограничения в применимости web-служб, в частности, невозможность передачи мультимедийных данных в формате SOAP. Такие данные передаются с помощью технологий, которые опираются на бинарные протоколы, не имеющие ничего общего с XML. Поскольку Всемирная паутина уже не мыслима без мультимедиа, SOA не может служить полноценной инфраструктурой для WWW.

Интеграция ресурсов во многом опирается на возможность и удобство поиска необходимой информации. Рассмотрим вкратце существующие на сегодняшний день возможности глобального поиска в Интернете. Главный поисковый сервис предоставляют т. н. поисковые машины, индексирующие содержание web-страниц Всемирной Паутины. Главенствующим принципом их поиска является нахождение в содержании web-страницы текстовых соответствий символьным последовательностям поискового запроса (в более продвинутых системах имеются эвристические анализаторы, учитывающие словоформы лексем и неточные совпадения). Поисковые машины помогают также находить файлы, однако такой поиск не является эффективным в силу своей текстовой природы (бинарным файлам дают имена, часто несоответствующие их содержанию). Главенствующим файловым ресурсом сегодня становятся файлообменные P2P сети. Для поиска файлов внутри таких сетей, как правило, применяется хеширование. Имени и некоторым фиксированным атрибутам реплик файла ставится в соответствие хэш-код его содержимого. Таким образом, эти сети обеспечивают лишь поиск по строгому соответствию, не учитывая сходства по каким либо признакам.

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

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

Легко видеть, что широко распространённая файловая модель хранения данных плохо удовлетворяет поставленным требованиям структурирования. В самом деле, любая непрерывная последовательность байтов может рассматриваться в качестве файла, т. е. за структурирование данных внутри файла ответственен программист, а не сама система. Таким образом, файловая система структурирует информацию лишь на уровне иерархии файлов и директорий на диске. Для большинства из существующих форматов файлов соответствующая метаинформация представлена в неформальной форме, в виде текста документации на естественном языке, что не позволяет её использовать поисковыми алгоритмами.

Итак, перед нами Интернет раскрывается не в качестве единого информационно-вычислительного пространства, а в виде множества совершенно разрозненных виртуальных образований, базирующихся на инфраструктуре IP + TCP/UDP. Эта инфраструктура создавалась под влиянием файловой парадигмы ОС Unix и ориентирована на обмен плоскими байтовыми потоками, без поддержки структурирования и рефлексии. Поэтому в Интернете невозможен единый информационный поиск по метаданным.

2. Инфраструктура для будущего Интернета

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

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

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

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

На наш взгляд, объектно-ориентированный подход к представлению и хранению данных и алгоритмов является одним из предпочтительных. На самом деле, несложно представить инфраструктуру, основной единицей которой будет являться объект, как экземпляр некоторого класса (алгоритмы и метаданные классов могут инкапсулироваться в экземпляры класса типов). В некотором роде такое представление можно рассматривать в качестве отображения классической реляционной модели. Так классы уподобляются таблицам, их экземпляры – записям, методы – хранимым процедурам, а триггеры - событиям. Следовательно, многие принципы, применимые к проектированию и реализации баз данных будут работать и при данной системе хранения. Так, например, для ускорения поиска объектов можно применять индексирование, подобно тому, как это делается в реляционной СУБД.

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

В предлагаемой инфраструктуре хосты обмениваются объектами по специальному протоколу. Вопреки популярности протокола HTTP, передающего данные в текстовых форматах HTML и XML, авторы отдают предпочтение бинарному протоколу. Текстовые форматы удобны для обмена данными между различными несовместимыми друг с другом платформами. Так, на любой из них можно открыть присланный текстовый файл простым редактором. Подобную функцию сможет выполнять универсальный браузер объектов, читающий их метаданные. Таким образом, в рамках предлагаемой инфраструктуры единый бинарный формат обладает главным преимуществом стандартных текстовых форматов, будучи лишён их недостатков. К последним относятся избыточность и сложность обработки, что не всегда является приемлемым для обмена данными с маломощными или мобильными хостами (например, для обмена с мобильным телефоном через низкоскоростную радиосеть). Кроме того, текстовые форматы не подходят для пересылки больших объёмов данных (например, видео), а также налагают значительные ограничения на обмен информацией в реальном времени.

Рефлексивность хранимой информации сама по себе не гарантирует мощные поисковые возможности. Данные одной и той же природы могут иметь различные формальные типы. Предположим, что система учёта почтовых отправлений оперирует адресами получателей в виде кортежей типа “(индекс, страна, город, улица, дом, квартира)”. Представим автоматизированную систему кредитования некоторого банка, работающую с адресами заёмщиков. Эти адреса представлены в виде кортежей типа “(страна, город, улица, дом, квартира, индекс)”. Ясно, что кортежи обоих типов означают одно и то же, однако, поскольку те проектировались разными организациями, они не являются совместимыми друг с другом. Так, например, при автоматизированной проверке факта почтовой пересылки дорогостоящих покупок на адрес неплательщика придётся учитывать это различие представлений адреса в обеих системах, что усложнит поиск. В данном случае метаданных обоих типов будет недостаточно – понадобится дополнительная информация о преобразовании типов. Введение новых типов для такого преобразования не может являться общим подходом к интеграции, поскольку их число должно квадратично возрастать при возрастании числа основных типов.

Некоторые простые универсальные типы данных используются разработчиками в качестве стандартных, например, size_t в стандартной библиотеке Си или интерфейс System. Array в библиотеке классов Microsoft . NET Framework, однако большинство типов разрабатываются и используются несогласованно. Такая разобщённость типов хранимых данных существенно препятствует возможности поиска информации. Другими словами, построение мощной поисковой системы требует принятия некоторых организационных мер, направленных на стандартизацию типов.

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

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

Вопросы устройства и администрирования базы типов, а также начального мотивирования к её использованию нетривиальны и выходят за рамки данной статьи. Мы рассмотрим лишь некоторые аспекты работы такой базы. Кроме обеспечения открытого доступа к типам (любой желающий вправе получить хранящиеся интерфейсы и классы реализации, а также разместить собственные) управляющая организация время от времени проводит итерации стандартизации интерфейсов. В процессе стандартизации выявляются интерфейсы, уже являющиеся в сообществе разработчиков стандартами de-facto. Другими словами, в процессе эксплуатации нестандартные интерфейсы будут ”бороться” друг с другом в конкурентной борьбе. Можно предположить, что с течением времени разработчики начнут ориентироваться на наиболее удачные интерфейсы с точки зрения продуманности функционала и наличия качественных классов реализации. Таким образом будут “выкристаллизовываться” de-facto стандартные интерфейсы, которые и перейдут в официальный стандарт при очередной итерации стандартизации. Каждая такая итерация предполагает пересмотр множества стандартных интерфейсов путём добавления новых и удаления устаревших.

Наличие множества стандартных интерфейсов позволит проводить эффективный поиск на основе метаданных. Так, например, для нахождения фильмов Педро Альмодавара, созданного режиссером в период с 1998-го по 2001 год, может быть составлен формальный запрос со следующей семантикой: ”найти экземпляр A класса B, поддерживающего стандартный интерфейс System. Multimedia. IVideoDocument, причём для A значение свойства IVideoDocument. Director = ‘Pedro Almodavar’, а значение свойства IVideoDocument. ReleaseDate > 31.12.1997, но < 01.01.2002”.

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

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

Ссылки:

1. Understanding SOA with Web Services, Newcomer, Eric, Lomow, Greg. Addison Wesley, 2005;

2. Microsoft SQL Server 2005. Why Consider a Service-Oriented Database Architecture for Scalability and Availability, Microsoft. November 2005;

3. Open Grid Services Architecture, I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich. 24 July 2006;