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

1 Объектно-ориентированные подходы в веб- программировании Разработка методов и средств для решения задач интеграции и взаимодействия распределенных ресурсов

2 Цель работы 1. изучение существующих подходов для решения проблемы интеграции и взаимодействия распределенных ресурсов; 2.разработка, на основе их анализа и синтеза, собственных подходов для интеграции внутри университетских ресурсов; 3. проектирование и построение корпоративной системы для работы преподавателей и студентов Учреждения образования Гродненский государственный университет имени Янки Купалы в рамках единого информационного пространства.

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

4 Обзор и анализ существующих технологий и решений веб-сервисы (web services) CORBA EJB RPC, XML-RPC DCOM Load balancing

5 Принципы, лежащие в основе веб-сервисов, удивительно просты. И они ничего не добавляют нового в мир распределенных вычислений и Интернета: –лицо, ответственное за веб-сервис, определяет формат запросов к своему веб-сервису и его ответов; –любой компьютер в сети делает запрос к веб- сервису; –веб-сервис обрабатывает запрос, выполняет какое- либо действие, а затем отправляет ответ.

6 Основа веб-сервисов В основе веб-сервисов лежат стандарты, открытые протоколы обмена и передачи данных. Протокол Simple Object Access Protocol (SOAP) является стандартным протоколом, разработанным W3C [4]. Он определяет формат запросов к веб- сервисам. Вот как выглядит простой SOAP- запрос, который отправляется через HTPP к веб-сервису: BY А ответ будет выглядеть вот так: Yes

7 Universal Description, Discovery and Integration UDDI. Система UDDI позволяет компаниям представить свой веб- сервис для общего пользования. Этот каталог работает как телефонная книга всех веб-сервисов. Регистрация в каталоге UDDI осуществляется бесплатно, и основатели проекта надеются, что этот каталог будет содержать описания всех веб-сервисов по всей Сети, так что для поиска нужного веб-сервиса достаточно будет обратиться лишь к одному каталогу UDDI

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

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

10 Технология CORBA и ее роль в построении распределенных систем Спецификация Common Object Request Broker Architecture (CORBA) лежит в основе всех стандартов, разработанных OMG. CORBA определяет механизм, обеспечивающий взаимодействие приложений в распределенной системе. Главными компонентами стандарта CORBA являются: –объектный брокер запросов (Object Request Broker); –язык определения интерфейсов (Interface Definition Language). В спецификацию CORBA включено также несколько дополнительных, но очень важных сервисов: сервис динамического формирования запросов (DII); сервис репозитория интерфейсов (IR); сервис динамической обработки запросов (DSI); сервис различных брокеров запросов (GIOP).

11 Концептуально спецификация CORBA относится к двум верхним уровням семиуровневой модели взаимодействия открытых систем. Характерные особенности проведения разработок в технологии CORBA заключаются в следующем: язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка реализации; высокий уровень абстракции CORBA в семиуровневой модели OSI избавляет программиста от работы с низкоуровневыми сетевыми протоколами; программисту не требуется информация о месте сервера в сетевой ИС и способе его активации; разработка клиентской программы не зависит от серверной операционной системы и аппаратной платформы.

12 Объектная модель CORBA определяет взаимодействие между клиентами и серверами. Клиенты – это приложения, которые запрашивают сервисы, предоставляемые серверами. Объекты-серверы содержат набор сервисов, разделяемых между многими клиентами. Операция указывает запрашиваемый сервис. Интерфейсы объектов описывают множество операций, которые могут быть вызваны клиентами определенного объекта. Реализации объектов – это приложения, исполняющие сервисы, запрашиваемые клиентами Спецификация CORBA разработана для обеспечения возможности интеграции разных объектных систем. На рисунке показано место главного компонента спецификации – брокера объектных запросов. Задачей брокера является предоставление механизма выполнения запроса объекта-клиента: поиск объекта, к которому относится данный запрос, передача необходимых данных, подготовка объекта к обработке. Брокер объектных запросов обеспечивает прозрачное взаимодействие клиентского и серверного приложений. Для разработчика вызов методов удаленных объектов не отличается от обычных локальных вызовов.

13 Базовый объектный адаптер BOA Основная функция объектного адаптера, используемого для реализации CORBA-объекта, обеспечение доступа к сервисам брокера объектных запросов

14 IDL язык описания интерфейсов Язык описания интерфейсов (IDL) ключевой элемент спецификации CORBA. Язык описания интерфейсов представляет собой средство, с помощью которого могут быть определены операции, вызываемые клиентами в удаленных серверных объектах. IDL полностью объектно- ориентированный язык, поддерживающий инкапсуляцию, наследование (в том числе множественное) и полиморфизм [2]. IDL является мощным языком, позволяющим описывать интерфейсы CORBA объектов любой сложности. В язык описаний введены все конструкции, необходимые для отражения объектных свойств проектируемых приложений.

15 Репозиторий интерфейсов (Interface Repository) С помощью репозитория интерфейсов (IR) приложения во время выполнения могут получать информацию о структуре и форматах IDL- интерфейсов, необходимую для генерации динамических запросов. Физически репозиторий интерфейсов является программным компонентом, имеющим собственный IDL-интерфейс. Через этот интерфейс различные приложения и получают данные о других CORBA- объектах.

16 Основные объектные сервисы стандарта CORBA Сервис именования (Naming service) служит для управления ссылками на CORBA-объекты и их хранения Сервис событий (Event service) обеспечивает поддержку асинхронного взаимодействия приложений Сервис хранения объектов (Persistence service) предоставляет набор универсальных интерфейсов для сохранения экземпляров объектов в долговременной памяти Сервис управления транзакциями (Transaction service) поддерживает множество моделей транзакций, включая вложенные транзакции Сервис взаимодействия (Relationship service) реализует логические связи между CORBA-объектами. Сервис управления разделяемыми ресурсами (Concurrency control) service позволяет клиентам координировать свои действия при использовании разделяемых ресурсов.

17 Построение корпоративных информационных систем на основе технологии Enterprise Java Beans (EJB) Обратимся к трехуровневой модели разработки программного обеспечения Такой подход имеет свои плюсы и минусы. Трехуровневая модель EJB – это модель создания и управления серверными объектами, оптимального использования ресурсов серверов, управления правами доступа и безопасностью, управления транзакциями и взаимодействия с базами данных различных видов.

18 JAVA продвигает 5 уровневую архитектуру на основе EJB

19 Сервер приложений

20 Контейнер предоставляет среду, в которой могут функционировать компоненты EJB. Контейнер осуществляет следующие функции: разбор XML-описания компонента EJB (deployment descriptor) и поддержка конфигурации, описанной в этом XML-файле; управление жизненным циклом компонента EJB, т.е. для предоставления услуг компонента прописанных в его интерфейсе и зарегистрированном на JNDI, необходимо создавать, уничтожать и кэшировать реализации (объекты), которые будут отвечать на запросы клиентов; разбалансировка нагрузки между реализациями (объектами) обслуживающими компонент EJB и управление пулом таких объектов; управление транзакциями в компонентах EJB. В случае с компонентами, которые работают с СУБД, управление транзакциями сильно связано с механизмом синхронизации состояния компонентов с состоянием СУБД; управление безопасностью доступа к компонентам. Опционально эта функция может быть отключена и проверку прав доступа к методам компонента придется реализовывать своими руками в самом компоненте.

21 Преимущества от использования EJB для создания корпоративных систем: отпадает необходимость иметь в штате (или привлекать к работам в рамках проекта) квалифицированных специалистов в системных областях; разработчик проекта может не беспокоиться о возможных проблемах с точки зрения функционирования системы на разных платформах, в разных операционных системах и при взаимодействии с различными СУБД, поддерживающими технологию JDBC; EJB демонстрирует высокую эффективность и уровень масштабируемости создаваемых приложений; системы получаются открытыми в том смысле, что с ними могут взаимодействовать CORBA-клиенты, написанные на любом из языков, поддерживающих CORBA; при использовании EJB снижаются (по сравнению с традиционными подходами) требования к квалификации основной массы программистов, зато очень важно иметь грамотных менеджеров проекта; следует иметь в виду, что требуется предварительный анализ, насколько технология EJB оптимальна для решения именно вашей задачи.

22 EJB, RMI и CORBA Многие CORBA-средства сознательно положены разработчиками EJB в фундамент этой технологии. В первую очередь, это протокол обмена IIOP и Служба Управления Транзакциями (в EJB используется отображение на Java Объектного Сервиса Транзакций, OTS, CORBA). Кроме того, на использовании инфраструктуры и возможностей CORBA часто основаны многие сервисы EJB - например, служба имен JNDI работает поверх Службы Именования (Naming Service) CORBA. Составной частью EJB может быть только то, что соответствует стандартам как RMI, так и CORBA. Такое подмножество обычно называют RMI/IDL.

23 Концепция удаленного вызова процедур (RPC) Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Характерными чертами вызова локальных процедур являются: 1.асимметричность, то есть одна из взаимодействующих сторон является инициатором; 2.синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры. Идея, положенная в основу RPC, состоит в том, чтобы сделать вызов удаленной процедуры выглядящим по возможности также как и вызов локальной процедуры Использование XML-RPC протокола в ZOPE для обмена информацией между серверами факультетов

24 Distributed Component Object Model (DCOM) Distributed Component Object Model (DCOM) – программная архитектура, разработанная компанией Microsoft для распределения приложений между несколькими компьютерами в сети Архитектура DCOM

25 Балансирование нагрузки Load balancing – балансирование нагрузки, распределение процесса выполнения заданий между несколькими серверами сети с целью увеличения общей производительности. Виды: DNS-балансирование Аппаратное Программное Смешанный тип

26 DNS-балансирование нагрузки DNS-балансирование – один из самых легких способов создать веб-сайт, который может обрабатывать большее количество посещений Любой DNS-сервер хранит пару "имя хоста/IP-адрес" для каждой машины в определенном домене Этот список выглядит примерно так: grsu.byxxx.xxx.xxx.2 Помимо этого любому имени можно назначить несколько IP-адресов. В результате чего список будет выглядеть так: grsu.byxxx.xxx.xxx Минусы кругового DNS "Refresh" "Server too busy" "Server Unavailable Многие DNS-сервера кэшируют у себя таблицы соответствий. Для балансировки нагрузки на веб-серверы у Apache существует специальный модуль mod_rewrite, который предоставляет мощный инструментарий для манипуляции URL-ом.

27 Программное/Аппаратное балансирование нагрузки Программное и аппаратное балансирование загрузки подобно методу DNS, только вместо обращения к множеству IP-адресов, обращение происходит только к одному. Машина установлена, чтобы прервать запросы HTTP к этому IP-адресу, она распределяет запросы среди многократных серверов. Обычно это распределение происходит на уровне маршрутизации TCP/IP. Аппаратные распределители нагрузки используют алгоритмы, которые базируются на наблюдениях за работой сети.

28 Смешанные решения Существуют также смешанные схемы, когда работают вместе аппаратные и программные распределители нагрузки. В системе используется один аппаратный распределитель нагрузки (и еще один запасной) и два кластера серверов, в которых используются программные распределители нагрузки. Аппаратный распределитель понятия не имеет о том, что за двумя IP-адресами скрывается целый набор машин. Точно также, каждый из кластеров понятия не имеет о существовании своего соседа. Используя смешанную схему, можно превысить предел в 32 машины, устанавливаемый программным распределителем. По сути, если предположить, что аппаратный распределитель способен работать с 256 отдельными узлами (вполне реальное предположение), то мы можем расширять мощность своего сайта вплоть до безумного количества машин – 8192 серверов.

29 Привязка Несмотря на то, что HTTP – это stateless (не имеет состояния) протокол, уже изобретено множество хитростей и уловок, что бы сохранять состояние приложения между запросами одного и того же клиента. Например, с помощью сессий можно сохранить все переменные и их значения для данного клиента и потом восстановить их при следующем запросе. При использовании одной машины как web-сервер никаких проблем нет, разве что при пиковой нагрузке она может упасть. А вот при использовании простых переключателей нагрузки возникает проблема. Соединения равномерно распределяются между машинами, значит, что соединение определенного клиента с определенным сервером просто не гарантируется. Для статических web-серверов этот тип соединений вполне удовлетворителен. К сожалению, эта простая схема не срабатывает при использовании в е-коммерции SSL и апплетов. Для всех систем е-коммерции и информационных приложений требуется постоянное соединение между клиентом и определенной машиной пока не будет завершена определенная операция Для устранения этого недостатка была придумана технология, которая называется "привязка" (affinity). Она отсутствует в переключателях нагрузки (load director), но есть в распределителях (load balancer) как в аппаратных, так и в программных. "Привязка" означает, что по началу сессии клиент направляется на любую машину, и на протяжении всей сессии поддерживает соединение только с ней.

30 Решение проблемы загрузки сервера 1.система, в которой объекты каждого факультета расположены на выделенном сервере ZOPE; 2.система, с балансированием нагрузки между несколькими идентичными серверами; 3. корпоративная система, включающая в себя сервер управления, который содержит нормативные документы университета.

31 Система, в которой каждый факультет расположен на своем отдельном сервере ZOPE

32 Система, с балансированием нагрузки между несколькими идентичными серверами (Load balanced system)

33 Корпоративная система, включающая в себя сервер управления, который содержит нормативные документы университета Ожидаемые результаты от введения сервера управления: Разгрузка объектной базы ZODB примерно на 70% и увеличение скорости обработки запроса сервером. Увеличение скорости поиска нормативных документов сервер управления поиск объектов централизованное хранение пользовательских профайлов (информации о пользователях) систему авторизации построена на основе любой из системы с распределением нагрузки Корпоративная система:

34 Проект корпоративной системы университета 1. Наличие системы аутентификации и авторизации 2. Сервер управления 3. Компонент ZDocument, инкапсулирующий работу с нормативными документами, хранящимися на сервере управления 4. Поддержка системы балансировки 5. Поиск информации Требования к системе: Цели системы: 1. работа (хранение, поиск) с документами сервера управления; 2. поиск объектов сервера университета; 3. авторизация и контроль доступа, централизованное хранение пользовательских профайлов;

35 Система аутентификации и авторизации

36 Сервер управления Централизованное хранилище документов Информационно-справочная система Функции сервера управления: Разгрузка объектной базы данных ZODB сервера факультета Централизованное хранение нормативных документов Повышение скорости поиска документов Создание всевозможных отчетов Цели и задачи:

37 Архитектура сервера управления Определим понятие документа, который будет храниться на сервере управления. Документ – это некая абстрактная сущность с прикрепленным к нему файлом, заранее определённым набором обязательных атрибутов и произвольным числом необязательных атрибутов. Атрибут – это некое свойство документа, отличающее его от других себе подобных. Роли пользователей в системе для работы с документами : читатель; редактор; владелец.

38 Хранение документов

39 Модель представления документов Положим, что модель представления документов агрегирует некий граф состояний – граф представления. Состояние определяется связанным логическими операциями списком кортежей (атрибут, значение, логическая операция между атрибутом и значением) Переходы между состояниями – показывают некую связь между состояниями. Связь может быть как логической, так и интуитивной Иерархическая модель (граф представления – дерево) Сетевая модель

40 Варианты использования состояний

41 Пример использования состояния состояние 1: список программ курсов, проводимых факультетом. состояние 2: список программ курсов, проводимых кафедрой 1. состояние 3: список программ курсов, проводимых кафедрой 2. При создании нового состояния на основе уже существующего следует иметь в виду, что существует две возможности: 1. наследование (State2) 2. копирование (State3)

42 Поиск и редактирование документов Редактирование состояния через графическое представление Преобразование графического представления в структурное Преобразование структурного представления в SQL и отображение документов

43 Список найденных документов

44 Основные задачи, которые были решены в ходе выполнения работы Рассмотрены существующие подходы к решению проблемы взаимодействия распределенных ресурсов. На основе их анализа и синтеза разработаны собственные подходы для интеграции ресурсов университета. Создан проект корпоративной системы университета, который находится в стадии разработки. ВЫВОДЫ