Geum.ru

Кафедра Автоматизации Систем Вычислительных Комплексов диплом

Вид материалаДиплом

Содержание


Постановка проблемы
Сведения об аналогичных решениях
Предлагаемое решение.
Подобный материал:
1   2   3
^

Постановка проблемы



Итак, мы увидели, каким образом можно в некоторых случаях решить проблему защиты ПО: вынесением участка системы для работы на отдельной ЭВМ, имеющей преимущества в защищенности перед «основной» машиной. Повторюсь, мы ведём речь не об обычных клиент-серверных приложениях, где подобное «выделение» натурально, а о приложениях, ранее, согласно своей природе, создававшихся исключительно локальными: графические и CAD-системы, среды разработки, моделирования, и т.п., либо локально-распределёнными: корпоративные системы документооборота, финансового учёта, ERP, CRM и т.п. Локально-распределённая система может являться клиент-серверной по архитектуре и с точки зрения пользователя, но является локальной с точки зрения разработчика (система работает автономно от разработчика и, соответственно, требует средств защиты от несанкционированного использования).

Разумеется, создание распределённых приложений не является для индустрии ничем новым, и для предложенного «разделения» программы на основную и «вынесенную» части существует множество подходов и технологий (собственные протоколы, COM, OLE, CORBA, RMI, WSOP, и множество других [1]). Однако, все эти технологии являются непрозрачными, т.е. требуют изначальной разработки приложения как распределённого с использованием выбранной технологии, либо глубокой переработки приложения для использования технологии распределения. Впрочем, в большинстве случаев это не является большой проблемой.

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

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

^

Сведения об аналогичных решениях



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

Существует схожий в технологическом плане проект Terracotta [9], решающий иную задачу – создание библиотеки распределённого хранения объектов в оперативной памяти кластера (Distributed Shared Objects). Но для её решения применяются подходы, во многом соответствующие применяемым в настоящей работе.
^

Предлагаемое решение.



Итак, мы решаем задачу о прозрачном разделении кода Java-проекта на две раздельные части, выполняющиеся на раздельных Java-машинах. Java – объектно-ориентированный язык, в котором основной единицей реализации программного кода является класс. Поэтому очевидно, что основным принципом нашего метода будет разделение проекта на уровне классов. Часть классов относится к одной части разделенного проекта, выполняющейся на своей Java-машине, а оставшаяся часть – к другой части, выполняющейся на другой Java-машине . Поскольку суть настоящей работы заключается в разработке прозрачного метода (т.е. не требующего модификации исходного кода), а вмешательство в объектный байт-код технически весьма сложно, напрашивается следующая основная идея: мы не будем модифицировать существующие классы проекта. Вместо этого классы, отсутствующие в соответствующей части проекта, будут замещать одноимённые классы-«заглушки», повторяющие их интерфейс, и делегирующие свои вызовы через канал связи настоящему классу во второй части проекта. Следует отметить, что эта идея ни в коей мере не претендует на новизну, подобным образом функционируют почти все современные технологии создания распределённых приложений в объектно-ориентированных платформах : COM, RMI, .Net Remoting и т.п.

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

При попытках обдумать функционирование вышеописанной системы из классов и заглушек, практически сразу становится ясно, что, на самом деле, разбиение проекта на уровне отдельных классов невозможно из-за принципа наследования классов. В самом деле, если класс AA наследует от класса A, и мы решаем в одной части разделенного проекта поместить настоящий класс A (реализующий свою функциональность), и заглушку класса AA (естественно, наследующую от A). Тогда легко возможна ситуация, когда какой-то метод создаёт объект aa класса AA (класс-заглушка при этом инициирует создание объекта настоящего класса AA на удаленной машине), и затем вызывает его метод, применив явное преобразование к родительскому типу A: ((A)aa).method(); В таком случае система попытается выполнить код A на локальной машине над объектом заглушки, в то время как нами ожидается, что действие произойдет на удаленной машине над тем объектом. Что, очевидно, заведомо некорректно. Отсюда очевидный вывод: единицей размещения через границу раздела проекта для нас будет являться не отдельный класс, а множество классов, образующее дерево наследования, чей корень наследует только от java.lang.Object.

Сразу возникает следующие вопросы: как быть с классами базовой библиотеки Java (JRE)? Что делать с классами, наследующими от классов JRE? На какой из двух Java-машин будут существовать объекты классов JRE? Как они будут передаваться в качестве параметров методов через границу раздела? Принципиальный ответ прост. Мы не будем делать различия между классами проекта и классами базовой библиотеки, вмешаемся в библиотеку JRE, и также разделим её на две части. Подробнее о возникающих при этом сложностях и подходах к их решению – в следующих подразделах.