Файл: Распределенная технология обработки информации (Архитектурное построение систем распределенной обработки информации).pdf
Добавлен: 04.04.2023
Просмотров: 221
Скачиваний: 1
СОДЕРЖАНИЕ
Глава 1. Принципы организации распределенной обработки информации
1.1 Требования, предъявляемые к свойствам систем распределенной обработки информации
1.2 Логические слои прикладного программного обеспечения вычислительных систем
1.3 Архитектурное построение систем распределенной обработки информации
Глава 2. Модели и технологии распределенной обработки информации
Глава 3. Распределенная обработка информации на основе технологий обмена сообщениями.
Глава 4. Распределенная обработка информации на основе моделей согласования.
Данная технология обычно эквивалентна архитектуре Common Object Request Broker (CORBA) с точки зрения предоставления набора распределенных сервисов. Можно сделать вывод, что DCOM - это подход Microsoft к общесетевой среде для программ и объектов данных. CORBA спонсируется остальной отраслью информационных технологий под эгидой Группы управления объектами (OMG).
2.4 Технологический СТАНДАРТ. COM
До появления технологического стандарта COM существовало множество разрозненных сервисов, выполняемых в среде MS Windows. Каждый из них выполнял или выполняет лишь свои узкие задачи. Чаще всего эти сервисы были совершенно несовместимы друг с другом и требовали от программиста знания сразу нескольких технологий, например, при статической компоновке с исполняемым модулем, запуске приложением другого приложения либо вызовом программным модулем функций операционной системы
Таким образом, из разрозненных частей, таких как Windows API, DDE, VBX практически невозможно собрать единую, бесперебойно работающую систему, обеспечивающую реальный повторное использование исходного кода. С приходом технологии COM все изменилось.
COM представляет собой универсальный способ взаимодействия программных модулей. В этой спецификации, разработанной компанией Microsoft, описаны требования, следуя которым становится возможным создание компонентов, которые предоставляют свои сервисы единообразно.
Технологическая модель COM определяет бинарный (двоичный) стандарт для построения компонентов приложений, а также принципов их взаимодействия друг с другом. Физическим воплощением является скомпилированный двоичный модуль, полностью соответствующий требуемым стандартам.
Способ взаимодействия, который определяет COM, дает программисту прочный фундамент для создания легко расширяемого, модульного и переносимого программного обеспечения.
Многие службы ОС Windows основаны на использовании COM, например, к Windows Explorer можно получить доступ через COM.
Объект или компонент – представляет собой закрытую сущность, скрывающую в себе нужную функциональность. Компонент может логически представлять собой реально существующее устройство (например, звуковая карта), либо быть некоторым абстрактным понятием.
Напрямую обратиться к объекту нельзя. Связь с ним возможна лишь при помощи интерфейсов, указатели на которые и может получить конкретная программа.
Команды, которые программа может отправлять компоненту COM через интерфейс, называются методами. Каждый интерфейс содержит фиксированное число методов. Зная имя интерфейса соответствующего компонента, программа (либо другой компонент) может получить указатель на этот интерфейс и пользуясь им для вызова конкретного метода, заставить компонент выполнить действия, определённые этим методом.
После того, как интерфейсы COM были созданы и опубликованы, они не должны изменяться. Требование неизменности опубликованных интерфейсов является обоснованным и защищает существующее ПО от возможных проблем: если производителю нужно добавить какую-то новую функциональность к уже существующему объекту, он просто создаст новый интерфейс, не затрагивая старые. Этот принцип также обеспечивает обратную совместимость с ранее созданными приложениями. Так, например, игра, созданная под DirectX версии 6 или 7, будет работать и под управлением более поздних версий этой библиотеки (8 или 9 версии). А все из-за того, что каждая новая версия DirectX полностью сохраняет функциональность своих предыдущих версий.
Как результат, вновь созданные программы смогут воспользоваться новейшими возможностями компонента, а старые программы сохранят свою работоспособность. В отдельных случаях такой подход даже позволяет изменять внутреннюю реализацию старого интерфейса (хотя это делать не рекомендуется). Программа "не почувствует" изменения, так как в ответ на вызовы методов будут выполняться все те же ранее оговорённые действия.
Компоненты DirectX, которые появились в первых версиях этой бибилотеки, как правило, пытались скрыть свою COM-сущность (например, путем внедрения специальных функций, которые брали на себя всю работу по инициализации среды и созданию нужного интерфейса). Появившийся позднее DirectMusic и некоторые другие компоненты не имеют подобных функций, и для работы с ними требуется понимание основ используемой модели COM вцелом.
Все компоненты DirectX реализованы как внутрипроцессные серверы и физически содержатся в DLL-файле. Такой подход позволяет обеспечить самую высокую производительность. А все из-за того, что при работе с интерфейсом отсутствуют посредники, которые выполняют, например, преобразование адресов. Библиотеки DLL, содержащие компоненты DirectX, подключаются напрямую к адресному пространству процесса (выполняемого приложения).
В документации DirectX SDK прототипы методов для всех интерфейсов приведены в виде объявления методов классов.
В языках, отличных от C++, необходимо явно передавать методу указатель на его интерфейс.
В составе Windows 2000 впервые была выпущена технология COM+, которая стала новой версией Microsoft Transaction Server.
Технология расширяла возможности разработчиков COM-компонентов, предоставляя им некоторые готовые услуги, например:
– автоматический пул потоков, создаваемый стандартным процессом-загрузчиком mtx.exe;
– доступ к контексту, в котором выполняется компонент (например, компоненты, используемые в ASP, могут с этой возможностью получить доступ к внутренним объектам той страницы, на которой они выполняются);
– интеграция с транзакциями монитора MS DTC (контекст COM+ может автоматически содержать в себе транзакцию MS DTC).
MTS/COM+ использовался внутри ряда версий веб-сервера MS IIS для загрузки и исполнения веб-приложений, как бинарных по технологии ISAPI, так и скриптовых по технологии ASP (сама asp.dll есть ISAPI-приложение).
COM+ объединяет компоненты в так называемые приложения COM+, что упрощает администрирование и обслуживание компонентов. Безопасность и производительность — основные направления усовершенствований COM+. Некоторые идеи, заложенные в основу COM+, были также реализованы в Microsoft .NET.
NET - это технология от Microsoft, от которой в будущем будут зависеть все остальные её технологии её. Это серьезное технологическое изменение, представленное Microsoft, чтобы завоевать рынок от Java SUN. Несколько лет назад у Microsoft были только VC ++ и VB, чтобы конкурировать с Java, но Java очень быстро завоевывала рынок. Поскольку мир все больше зависит от Интернета, а инструменты, связанные с Java, становятся лучшим выбором для веб-приложений, Microsoft, похоже, отходит на задний план в рамках данного вопроса. Как итог - тысячи программистов перешли на Java из VC ++ и VB.
Microsoft привлекла своих лучших людей к работе над секретным проектом под названием Windows Services следующего поколения (NGWS) под непосредственным руководством Билла Гейтса.
Результатом проекта является то, что мы теперь знаем как NET. Несмотря на то, что NET позаимствовал большинство своих идей у J2EE от Sun, он действительно превзошел своих конкурентов.
Платформа NET была разработана для осуществления следующих целей:
– возможность объединить весь спектр вычислительных устройств и автоматически обновлять, и синхронизировать пользовательскую информацию на всех них.
– расширение интерактивных возможностей для веб-сайтов, благодаря более широкому использованию XML (расширяемого языка разметки), а не HTML.
– премиум-сервис онлайн-подписки, который будет обеспечивать индивидуальный доступ и доставку продуктов и услуг пользователю из центральной отправной точки для управления различными приложениями, такими как электронная почта, например, или программным обеспечением, таким как Office .NET
– централизованное хранение данных, что повысит эффективность и удобство доступа к информации, а также синхронизирует информацию между пользователями и устройствами.
– возможность интеграции различных средств связи, таких как электронная почта, факсы и телефоны.
– для разработчиков предусмотрена возможность создания многоразовых модулей, что должно повысить производительность и уменьшить количество ошибок программирования.
J2EE - это платформа для бизнес-вычислений, на которой возможна профессиональная разработка распределенных бизнес-приложений на многоуровневой архитектуре, написанных на языке программирования Java и выполняемых с сервера приложений.
Таким образом, J2EE - это программная платформа, первоначальная спецификация которой была разработана Sun Microsystems, хотя в 2000 году ее взяла под контроль компания Oracle.
Версия J2EE берет свое начало на языке программирования Java, а его аббревиатура «EE» соответствует «Enterprise Edition». Эта технология Java позволяет разработчикам и программистам создавать (писать) приложения только один раз и быть совместимыми на любом компьютере, поскольку они взаимодействуют напрямую с виртуальной машиной, а не с операционной системой.
Позже, потребность в средствах и инструментах, представленных сектором разработки программного обеспечения для разработки бизнес-приложений, уступила место этой платформе под названием Java 2 Enterprise Edition, способной предоставлять технические спецификации, описывающие язык, одновременно облегчая или обеспечивая необходимые инструменты, позволяющие реализовать приложения (программные продукты) на основе этих спецификаций. Это именно то, что мы изучаем в Java-курсе J2EE, который ориентирован на компании.
Таким образом, J2EE - это не что иное, как набор спецификаций, то есть каждая из этих спецификаций является подробным описанием технологий на платформе J2EE; набор правил или руководящих принципов, в соответствии с которыми это приложение должно разрабатываться таким образом, чтобы его можно было развернуть и выполнить.
Основные технологии, которые включает в себя Java Enterprise Edition:
– Enterprise JavaBeans (EJB).
– JavaServer (JSP)
– Стандартная библиотека тегов JavaServer Pages (JSTL).
– JavaServer Faces (JSF)
– Служба сообщений Java (JMS).
– API транзакций Java (JTA).
– JavaMail API и JavaBeans Activation Framework (JAF).
– XML-технологии (JAXP, JAX-RPC, JAX-WS, JAXB, SAAJ, JAXR) JPA, JDBC API
– Java Naming and Directory Interface (JNDI)
– Служба аутентификации и авторизации Java (JAAS) й.
Глава 3. Распределенная обработка информации на основе технологий обмена сообщениями.
Message Oriented Middleware или как принято сокращать MOM довольна молодая и динамично развивающаяся категория систем промежуточного слоя. Согласно этой модели, приложения обмениваются байтовыми строками – сообщениями, обращаясь к API-интерфейсу системы MOM, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от ранее рассмотренных моделей промежуточного ПО, MOM реализует равноправные, а не подчиненные (клиент-сервер) отношения между модулями приложений.
Message Oriented Middleware можно считать гибкой системой поскольку системы данного типа поддерживают одновременно синхронные и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения. По способу обмена сообщениями все продукты MOM могут быть разделены на три подгруппы систем:
– с передачей сообщений, c очередями сообщений;
– c очередями сообщений, с передачей сообщений;
– типа публикация/подписка.
Системы с передачей сообщений (Message Passing – MP) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для такой логической связи необходимо установить соединение между программными модулями. Отсюда мы можем сделать вывод, что данная реализация не подходит для слабосвязанных программ, которые работают в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей.
Многочисленная часть МОМ-систем реализует асинхронный механизм очередей сообщений (Message Queuing – MQ). В отличие от передачи сообщений, данная модель межпрограммного взаимодействия не нуждается в поддержке непосредственного соединения одного прикладного модуля с другим, однако гарантирует доставку сообщения даже в том случае, если программа-адресат в этот момент не доступна. Программа-отправитель выполняет две функции: передача сообщения MQ-системе и продолжение выполнения. Сообщение помещается в локальное промежуточное хранилище – очередь сообщений, которая находится в оперативной памяти или на диске. Отсюда данное сообщение может быть передано программе-получателю. Эту функцию можно выполнить незамедлительно или через какое-то время. Мы можем сделать вывод, что, приложения, использующие данную модель связи, способны работать практически независимо друг от друга без временной синхронизации. В следствие этого механизм очередей сообщений считается достаточно удачным решением для приложений, которые предназначены для мобильных пользователей, для реализации потоков работ и поддержки приложений в глобальных сетях с медленными и не очень надежными соединениями.