K004534 Дипломная работа Промежуточное програмное обеспечение

Содержание

Введение 3

1. Промежуточное програмнное обеспечение 6

1.1 Языковые платформы. Perl 6

1.2 Архитектурные модели разработки 7

1.4 ПО межпрограммного взаимодействия 9

1.5 Специфика промежуточного ПО 16

1.6. Постановка задачи 17

Глава 2. Специфика проектирования 19

2.1. Особенности разработки 19

2.2. Взаимодействие с клиентами 19

2.3. Система подписки 22

2.4. Особенности криптоалгоритма 25

2.6. Фреймворк разработки Mojolicious 31

Глава 3. Разработка проекта 32

3.1. Устанавливаем зависимости 32

3.2. Запускаем сервис 32

3.3. Запуск клиента, получающего данные 33

3.4. Запуск клиента, отправляющего данные 33

3.5. Анализ результатов 34

Заключение 35

Список использованной литературы 37

Приложения 39

Приложение 1. Код демона. Главный класс Mojo.pm 39

Приложение 2. Код демона. Контроллер управления Root.pm 42

Приложение 3. Код демона. Модель шифрования Coder.pm 45

Приложение 4. Код демона. Модель отправки данных Sender.pm 48

Приложение 5. Код клиента получающего данные 51

Приложение 6. Код клиента отправляющего данные 53

Введение

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

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

Объект исследования - использование языка Perl для обеспечения безопасного взаимодействия гетерогенных программных систем на базе симметричных криптоалгоритмов.

Предмет исследования - особенности языка Perl.

Цель работы - проанализировать особенности использование языка Perl для обеспечения безопасного взаимодействия гетерогенных программных систем на базе симметричных криптоалгоритмов.

Задачи исследования:

 - изучить специфику языка Perl;

 - ознакомиться с архитектурными моделями разработки;

 - освоить функции и классификация промежуточного ПО;

 - разработка проекта для обеспечения безопасного взаимодействия гетерогенных программных систем на базе симметричных криптоалгоритмов;

 - проанализировать особенности использование языка Perl для обеспечения безопасного взаимодействия гетерогенных программных систем на базе симметричных криптоалгоритмов.

1. Промежуточное програмнное обеспечение

1.1 Языковые платформы. Perl

Для создания ПО промежуточного слоя необходимо использовать достаточно гибкие, мультиплатформенные языки, поэтому интерпретируемые языки программирования подходят как нельзя кстати, например:

-Java;

-Ruby;

-Python;

-Perl;

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

Perl был создан Ларри Уоллом в середине 1980-х годов. Наиболее часто название языка расшифровывают так:  “Practical Extraction and Report Language”(практический язык выборки данных и построения отчетов). Но мистер Уолл изначально придумал название для языка, а его расшифровку уже позже.

Perl изначально создавался как язык, который заменит системные инструменты UNIX систем, когда их применение становится слишком громоздким или невозможным. Но ведь можно сказать что существует огромное количество других языков. В то время выбор был только между “уродливыми” языками( С, С++, ассемблер) и медленными, но простыми в использовании утилитами (awk, grep, sort и т.д.). Ларри Уолл попытался заполнить пробел между ними, создав свой язык, который в меру быстродейственен и “уродлив”.

В итоге Perl стал обладать следующими преимуществами:

• Прост в использовании. 10-20 строк кода на С или С++ зачастую можно заменить одной строкой на Perl.

• Полная обратная совместимость и мультиплатформенность. Код написанный на Perl будет работать годами, а при надобности и десятилетиями.

• CPAN(Comprehensive Perl Archive Network) - сеть полных архивов Perl. В случае, если разработчик не знает как решить какую-то проблему, ему просто нужно обратиться к CPAN, скорее всего его задачу решили уже до него.

Хотя возможности использования Perl практически безграничны(разве что не стоит писать программы, где быстродействие критично, в таких случаях С++ или подобные языки будут лучшим вариантом), нас все таки интересует применение Perl для связи гетерогенных систем. Поэтому в начале нужно разобраться как с помощью промежуточного ПО осуществляются подобные связи.

1.2 Архитектурные модели разработки

Применение классической двухзвенной клиент-серверной модели может быть допустимо лишь в малых компаниях с небольшой загруженностью серверов, ввиду отсутствии или малой масштабируемости таких систем и обновлении клиентских приложений, при изменении внутренней логики работы сервера (рис. 1.1). Многозвенные решения позволяют нам отделить логику работы серверного оборудования от клиентского (рис. 1.2). Но тогда зачастую возникает проблема интеграции приложений или вопрос: “Как заставить старые системы работать с компонентами новой?”. Для решения этой проблемы используется специальное промежуточное ПО (middleware).

Рисунок 1.1. Двухзвенная структура

Рисунок 1.2. Многозвенная структура

1.3 Функции и классификация промежуточного ПО

Промежуточное ПО предоставляет различные функции, которые, в отличии от “классических” приложений должны обеспечивать:

• прозрачность (доступность API иных сервисов и приложений)

• самодостаточность (сервисы не должны зависеть друг от друга)

• надежность и постоянную доступность

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

• ПО обеспечивающее доступ к базам данных

• ПО обеспечивающее межпрограммное взаимодействие

1.4 ПО межпрограммного взаимодействия

Программы данного типа делают построение связей между различными процессами легче, также позволяя экспортировать и импортировать различные объекты во всей системе. Они позволяют “склеивать” ПО разного уровня сложности. Главными видами являются: ORB, RPC, MOM и TPM. Зачастую некоторые из них объединяют для лучшей работы всей системы.

Вызов удаленных процедур (RPC).

Компания XEROX разработала первую систему основанную на данном подходе в первой половине 1980-х годов, смысл которой заключается в том, чтобы предоставить программе выполнять не только скомпилированные на локальном компьютере функции и процедуры, но и позволить вызывать их дистанционно (например, с сервера) (рис. 1.3).

Рисунок 1.3. Работа RPC

При помощи специальных компонентов (client stub и server stub) устанавливается сеанс удаленной связи между приложениями. Клиент обращается к своей заглушке, которая упаковывает содержимое пакета (marshaling) и передает его такой же заглушке на сервере. Та же открывает эти данные (unmarshaling) и передает их серверным приложениям. Ответ сервера проходит те же самые шаги. Данная технология позволят инкапсулировать прикладные программы.

У классических RPC есть недостатки, такие как:

• Синхронность запросов – клиентская программа перестает работать, пока не получит ответ от сервера.

• Связь с методами заглушек происходит на этапе компиляции, что не позволяет видоизменять их во время работы.

Но сейчас применяются следующие решения данных проблем:

• Синхронность устраняется при помощи функций обратного вызова, которые предотвращают остановку работы клиентской программы.

• А динамически подключаемые библиотеки позволяют видоизменять функции и процедуры без отключения всей системы.

При неправильном использовании RPC может очень сильно замедлить работу системы. Например, если мы будем вызывать какую либо процедуру в большом цикле:

for (i=0, i<1000000, i++)

RPC_call();

Каждая итерация будет каждый раз устанавливать, затем разрывать соединение, что неминуемо приведет к большой нагрузке сети и ухудшит быстродействие системы. Но вынос установки и разрыва сеанса за пределы цикла невозможно, ввиду противоречия c архитектурой RPC.

Промежуточно ПО обработки сообщений (MOM – message-oriented middleware).

Асинхронное программное обеспечение, связь в котором осуществляется при помощи текстовых блоков – сообщений, в которых содержатся как управляющие команды, так и данные. Они передаются посредством прикладных протоколов, например: SMTP, HTTP и т.д.

Используя API сервиса MOM, приложения обмениваются сообщениями. Каждый запрос встает в очередь сообщений, порядок в которой определяется приоритетом и доступностью ресурсов (рис 1.4). Приоритеты позволяют доставлять важные сообщения вне очереди, а при помощи отложенной доставки осуществить отправление сообщения в то время, когда ресурс станет доступным. Также сервис отправляет сообщения-ответы информирующие клиентские приложения об успешной доставке.

Рисунок 1.4. Промежуточное ПО обработки сообщений

Программное обеспечение основанное на MOM часто используется в сетях с ненадежным и медленным соединением, в виду обеспечения такими системами уровня качества:

• reliable message delivery – система дает гарантию надежности доставки сообщений.

• guaranteed message delivery – сообщения доходят до конечных пользователей за определенный промежуток времени (при недоступности сети) или немедленно.

• assured message delivery – сообщения не будут дублироваться.

Очереди сообщений представляют собой мощный, гибкий и в то же время простой механизм межпрограммного взаимодействия.

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

Системы с непосредственной передачей сообщений (message passing) используют логическое сетевое соединение для обмена сообщениями между взаимодействующими приложениями. Эта схема удобна в тех случаях, когда клиенты и серверы сообщений используются в сильно связанной сетевой инфраструктуре и синхронизированы по времени.

Сервисы MOM, обслуживающие клиентов по подписке/публикации (publish&subscribe) работают по принципу, напоминающему почтовую рассылку: одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для получения необходимых данных. Взаимодействующие таким способом приложения полностью независимы друг от друга, что представляет возможности динамической реконфигурации всей распределенной системы.

Мониторы обработки транзакций (Transaction Processing monitors, TP-monitors).

Это промежуточное программное обеспечение, обеспечивающее контроль передачи данных от клиента при работе с распределенными базами данных. Монитор транзакций обеспечивает целостность данных, следя за тем, чтобы не было потерянных или незавершенных транзакций. Транзакция – это законченный блок обращений к базе данных, для которого гарантируется выполнение четырех условий ACID:

• Атомарность (Atomicity) – операции транзакции образуют неделимый, атомарный блок, который либо выполняется от начала до конца, либо не выполняется вообще. При невозможности выполнения транзакции происходит откат к исходному состоянию;

• Согласованность (Consistency) – по завершении транзакции все задействованные ресурсы находятся в предопределенном и согласованном состоянии;

• Изолированность (Isolation) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы исключить их влияние друг на друга;

• Долговременность (Durability) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.

Монитор транзакций обеспечивает контроль над выполнением этих условий, выполняя функции концентрации и перенаправления запросов к БД в распределенной среде с множеством баз данных от различных поставщиков (рис 1.5).

Рисунок 1.5. Монитор транзакций

Распределенные объектные системы (Distributed object systems)

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

С точки зрения разработки, использование распределенных объектов оправданно при создании масштабных объектно-ориентированных систем. Фактически же, объектная «обертка» таких решений скрывает за собой ранее рассмотренные RPC, MOM и средства управления транзакциями. Поэтому, в первом приближении общий принцип взаимодействия распределенных объектов очень похож на RPC (рис. 1.6). Это сходство заметно и в средствах описания интерфейсов — объекты используют все тот же IDL. Однако, в сравнении с RPC, распределенные объекты могут компоноваться динамически, т.е. не на этапе компиляции, а во время выполнения приложений.

Рисунок 1.6. Распределенные объектные системы (stub и skeleton - клиентская и серверная заглушки)

Архитектура распределенных объектных систем стандартизована и наиболее распространены спецификации CORBA, COM/DCOM и EJB.

• CORBA (Common Object Request Broker Architecture, типовая архитектура брокера объектных запросов) — открытый стандарт, разработанный группой Object Management Group (OMG), который определяет интерфейсы между сетевыми объектами, позволяющие им работать совместно. Брокеры объектных запросов (object request brokers, ORB), созданные в соответствии с CORBA, представляют интерфейсы для разработки объектно-ориентированных систем «клиент-сервер».

• Microsoft COM (Component Object Model, компонентная объектная модель) — это семейство технологий, предназначенных для организации взаимодействия Windows-приложений (см. MSDN: The Component Object Model). В это семейство входят COM+, DCOM (Distributed COM) и ActiveX Controls. Microsoft позиционирует COM как платформу для разработки повторно используемых (re-usable) компонентов приложений. В случае DCOM — компонентов распределенных клиент-серверных систем.

• EJB (Enterprise JavaBeans) — технология, разработанная Sun Microsystems для корпоративных решений на платформе Java (Java EE/EJB). Спецификация EJB описывает архитектуру серверных компонентов и порядок их использования в клиент-серверных приложениях. Эта технология упрощает разработку распределенных систем на основе Java и обеспечивает наибольшую переносимость Java-приложений.

1.5 Специфика промежуточного ПО

Стек протоколов TCP/IP давно уже поддерживается на уровне операционных систем, средства RPC также доступны в сетевых ОС едва ли не "по умолчанию". Этот механизм практически не требует от разработчиков и интеграторов каких-либо новых знаний и навыков. Не требуется изучать специфические middleware API: вызов удаленной процедуры ничем не отличается от обращения к локальной подпрограмме, а все процессы преобразования данных и передачи их по сети выполняются клиентской и серверной заглушками. Использование RPC может быть наиболее подходящим решением для систем, где возможные проблемы, связанные с синхронностью протокола RPC, не являются критичными.

Промежуточное ПО обмена сообщениями предлагает большую, по сравнению с RPC, гибкость, так как ни одно из взаимодействующих приложений не блокируется в процессе обмена сообщениями. Такое решение лучше подойдет для автоматизированных систем, компоненты которых слабо связаны, работают в независимом временном режиме и используют разнородную сетевую среду. Однако, системы на основе MOM как правило не поддерживают автоматическое преобразование форматов (marshalling/unmarshalling), что требует от разработчика решения задач по преобразованию форматов данных.

Взаимодействие компонентов корпоративных приложений в объектно-ориентированной среде удобнее всего реализовывать с помощью объектных-же средств промежуточного ПО. В этом случае, разработчик использует объектную модель, четко описывающую бизнес-процессы. Высокий уровень абстракции объектов (будь то ORB или EJB) полностью скрывает от пользователя детали реализации взаимодействия между ними. Использование объектов позволяет строить корпоративные приложения словно лего город, из унифицированных «кирпичиков»объектов. Это справедливо, если вся система является объектно-ориентированной. Затруднения с использованием распределенных объектов появляются, когда компонентами автоматированной системы являются унаследованные приложения.

Мониторы транзакций ориентированы на сложные и высококритичные корпоративные системы. Они обеспечивают необходимый уровень сервиса для таких систем, включая управление процессами, балансировку нагрузки на серверы, средства резервирования восстановления данных. Для задач автоматизации небольшого предприятия возможности, представляемые TP-мониторами могут быть избыточны. К тому же, продукты этой категории имеют высокую стоимость, что может быть экономически не выгодно.

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