Кросс-платформенные и многозвенные технологии

Кросс-платформенные и многозвенные технологии

2-е издание, исправленное

Степанов Е.О.

Национальный Открытый Университет “ИНТУИТ”
2016

2

Кросс-платформенные и многозвенные технологии/ Е.О. Степанов - М.: Национальный Открытый
Университет “ИНТУИТ”, 2016

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

(c) ООО “ИНТУИТ.РУ”, 2010-2016
(c) Степанов Е.О., 2010-2016

3

Основные платформы и технологии

В данной лекции рассматриваются аппаратные и программные платформы, а также
тенденции их развития

Введение

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

Основные аппаратные и программные платформы

Рост компьютерных и информационных технологий за сравнительно недолгое время,
прошедшее с момента появления первых компьютеров (конец 1940х гг.) был
невероятно стремительным и пока не проявляет никакой тенденции к замедлению.
Считается, что каждые 10 лет происходит полная смена технологий в этих областях. В
результате невероятно большое число аппаратных и программных технологий и
платформ, которые, казалось бы, еще недавно были самыми передовыми и
повсеместно используемыми, в настоящее время осталось лишь в памяти тех, кому с
ними пришлось работать. Новые поколения разработчиков программного обеспечения,
как правило, не знают даже техники и технологий десятилетней давности (а если и
знают, то только из специальных ВУЗовских курсов), поскольку состояние дел в
области компьютерных и информационных технологий успело полностью поменяться
несколько раз за эти годы. Такие стремительные изменения, кстати, делают весьма
неустойчивым компьютерный бизнес: на наших глазах многие фирмы-производители
оборудования или программного обеспечения, имевшие, казалось бы, сверхустойчивое
положение на рынке, в считанные годы проигрывали конкуренцию и иногда
полностью исчезали, а на их месте появлялись новые “звезды”. Так, к примеру, всего
несколько лет назад произошло с одной из крупнейших в компьютерном мире фирмой
DEC,долгие годы в значительной мере определявшей пути развития вычислительной
техники и программного обеспечения, и сумевшей построить вполне самобытную
“цивилизацию” компьютерных и программных решений - фирмы уже больше не
существует, а про ее супербрэнды PDP, VAX и соответствующее программное
обеспечение помнят весьма немногие. Учитывая все сказанное, представляется
практически нецелесообразным давать сколько-нибудь подробный обзор аппаратных и
программных архитектур, имеющихся в настоящее время - их срок жизни весьма мал.
Ограничимся поэтому лишь весьма схематическим изложением основных платформ, с
которыми приходится иметь дело современному разработчику. Весьма условно можно
классифицировать основные встречающиеся в наше время аппаратные платформы
следующим образом.

4

Платформы на базе процессоров Intel и их аналогов ( AMD ).
Высокопроизводительные сервера и рабочие станции SUN (на базе процессоров
SunSparc ).
Высокопроизводительные сервера HP (на базе RISC -процессоров).
Платформы Apple.

Архитектура процессора: RISC или CISC?

В 80-х годах прошлого века была предложена архитектура процессора с сокращенным
набором машинных команд ( RISC - Reduced Instruction Set Computer ). Дейв Паттерсон
и Карло Секуин сформулировали четыре основных принципа архитектуры RISC:

1. Любая операция должна выполняться за один такт, вне зависимости от ее типа.
2. Система команд должна содержать минимальное количество наиболее часто

используемых простейших инструкций одинаковой длины.

3. Операции обработки данных реализуются только в формате “регистр-регистр”

(операнды выбираются из оперативных регистров процессора, и результат
операции записывается также в регистр; а обмен между оперативными регистрами
и памятью выполняется только с помощью команд чтения/записи).

4. Состав системы команд должен быть “удобен” для компиляции операторов языков

высокого уровня

Создатели RISC -процессоров взяли набор из очень простых наиболее часто
используемых команд, которые выполняются быстро, и объединили его с такими
технологиями, как конвейерная обработка. В результате получился процессор,
который имеет лучшую производительность для большинства приложений и
теоретически стоит меньше, поскольку сам он небольшой и его производство
обходится дешевле. По аналогии процессоры традиционной архитектуры стали
называть CISC - Complex Instruction Set Computer.

В список основных поставщиков RISC -систем входят компании Hewlett-Packard (PARISC), Sun Microsystems Computers (SPARC), Digital Equipment (Alpha), Silicon Graphics
- модуль MIPS (R210000) и союз IBM и Motorola (PowerPC).

С другой стороны, семейство Pentium компании Intel продолжает реализацию более
традиционной вычислительной архитектуры с полным набором машинных команд
(CISC). CISC -процессоры содержат в сотни раз больше команд, чем RISC -процессоры,
и используют от 8 до 12 способов адресации памяти по сравнению с 2-3 способами в
RISC.Однако технические различия между RISC и CISC в последние годы становятся
все менее четкими, особенно в том, что касается общей производительности систем.
Одна архитектура заимствует хорошие идеи у другой. Раньше RISC -процессоры
определялись как микропроцессоры с количеством команд меньше 128, сейчас же они
имеют 200 команд - сравните с набором из 300 и более команд в CISC.Сегодня CISC процессоры используют конвейеризацию и другие современные технологии. Оба
лагеря применяют большую кэш-память для повышения производительности.

Основные программные платформы можно классифицировать условно следующим

5

образом:

Платформы Microsoft (Windows NT/XP/…)
Платформы на базе Unix.В последнее время среди версий Unix наиболее
популярен Linux разных модификаций. К версиям Unix относятся и системы
Solaris (для платформ Sun),а также весьма своеобразный “гибрид” Unix и Windows
для платформ Apple - Mac OS.

Следует отметить, что операционные системы Unix и созданный вокруг них универсум
программных продуктов, идей и технологий, являются одними из едва ли не самых
“долгоживущих” в мире программного обеспечения. Первая система Unix,практически
ничем принципиально не отличающаяся от ее современных “клонов”, была создана
более 30 лет назад!

Состояние корпоративной программной среды типичной
организации

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

Основная масса компьютеров базируется на платформе Intel или AMD,возможно
имеются несколько компьютеров Compaq, Sun и т.п.
Используемые операционные системы MS Windows, Linux,другие UNIXподобные ОС. Основная операционная система, установленная на рабочих местах
пользователей - MS Windows.Большинство серверов работает также под
Windows.Часть серверов работает под Linux или другими UNIX- подобными ОС.
Основное офисное программное обеспечение - MS Office.
Основная почтовая программа MS Outlook, MS Outlook Express или специальный
почтовый клиент (популярность набирает Mozilla Thunderbird).
Основной интернет-браузер MS Internet Explorer (сейчас набирает популярность
браузер Mozilla Firefox,иногда используется браузер Opera).
Основная система документооборота работает на основе Windows и MS Exchange.
Основной Web-сервер Apache или IIS на платформе UNIX или Windows.
Основная корпоративная СУБД MS SQL Server или Oracle,также дополнительно
используется MS Access или другие СУБД,но исключительно как локальные. В
малых компаниях бывают популярны MySQL и PostgreSQL.

1.3. Кросс-платформенные технологии

Кросс-платформенные технологии обеспечивают совместную эксплуатацию различных
аппаратных и программных платформ в интересах организаций-потребителей.

Основные архитектуры программного обеспечения

Автономные (standalone) приложения

6

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

Двухзвенная архитектура “клиент-сервер”

Эта архитектура получила распространение с начала 1990-х годов на фоне роста рынка
персональных компьютеров и снижения спроса на мэйнфреймы. В архитектуре
“клиент-сервер” программное обеспечение разделено на две части -клиентскую часть и
серверную часть. Задача клиентской-части (программы-клиента) состоит во
взаимодействии с пользователем, передаче пользовательского запроса серверу,
получение запроса от серверной части (программы-сервера) и представление его в
удобном для пользователя виде. Программа-сервер же обрабатывает запросы клиента и
выдает ответы. Классические примеры: Web -технологии (клиент-браузер, сервер- Web сервер), работа с распределенными СУБД (клиент - специальная программа, сервер сервер базы данных). Развитие архитектуры “клиент-сервер”, а особенно появление
современных графических интерфейсов, привело сначала к появлению разновидности
архитектуры клиент-сервер, называемой “архитектура с толстым клиентом”.Здесь
логика представления данных и бизнес-логика размещаются на клиенте, который
(скажем, в случае, когда сервером является СУБД ) общается с логикой хранения и
накопления данных на сервере, используя язык структурированных запросов
SQL.Однако необходимость установки “толстых клиентов“, требующих
значительного количества специальных библиотек и специальной настройки
окружения, на большое число пользовательских компьютеров с различными
операционными средами, как правило вызывает массу проблем. Как альтернатива
поэтому возникла также двухзвенная архитектура “с тонким клиентом”.При этом в
идеале программа-клиент реализует лишь графический интерфейс пользователя (GUI)
и передает/принимает запросы, а вся бизнес-логика выполняется сервером. В идеале
клиентом является просто интернет-браузер, который имеется в стандартной
операционной среде любого пользовательского компьютера и не требует специальной
настройки, установки специализированного ПО и т.п. К сожалению, такая схема тоже
не свободна от недостатков, хотя бы уже потому, что серверу приходится брать на себя
иногда не свойственные для него функции реализации бизнес-логики приложения
(например, серверу СУБД приходится выполнять расчеты!)

Многозвенная (multitiered) архитектура

Начало процессу развития корпоративного программного обеспечения в многозвенной
архитектуре было положено еще в рамках технологии “клиент/сервер”. В них наряду с
клиентской частью приложения и сервером баз данных появились серверы приложений
(Application Servers).В идеале:

программа-клиент реализует GUI,передает запросы серверу приложений и
принимает от него ответ,

7

сервер приложений реализует бизнес-логику и обращается с запросами к серверу
“третьего уровня” (например, серверу базы данных за данными),
сервер третьего уровня обслуживает запросы сервера приложений.

Программа-клиент, таким образом, может быть “тонкой”. Преимущества такой
архитектуры очевидны:

изменения на каждом из звеньев можно осуществлять независимо;
снижаются нагрузки на сеть, поскольку звенья не обмениваются между собой
большими объемами информации;
обеспечивается масштабирование и простая модернизация оборудования и
программного обеспечения, поддерживающего каждое из звеньев, в том числе
обновление серверного парка и терминального оборудования, СУБД и т.д.;
Приложения могут создаваться на стандартных языках третьего или четвертого
поколения ( Java, C/C++ ).

Следующий логический шаг - дальнейшее увеличение числа звеньев, причем возрастет
не только за счет разбиения, когда “утоньшается” каждое из известных технических
звеньев, но вся бизнес-модель строится как многозвенная. Современные
корпоративные программные системы представляют собой, как правило, сложные
системы взаимодействующих между собой на разных уровнях компонентов, каждые из
которых могут являться клиентами для одних компонентов и серверами для других.

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

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

При вызове удаленной процедуры, программы RPC производят преобразование
форматов данных клиента в промежуточные машинно-независимые форматы, и затем

8

преобразование в форматы данных сервера. При передаче ответных параметров
производятся обратные преобразования. Таким образом, если система реализована на
основе стандартного пакета RPC,она может быть легко перенесена в любую открытую
среду.

Технология CORBA

CORBA (Common Object Request Broker Architecture) - это набор открытых
спецификаций интерфейсов, определяющий архитектуру технологии межпроцессного и
платформо-независимого манипулирования объектами. Разработчиками данных
интерфейсов являются OMG и X/Open.

Object Management Group, Inc. (OMG) - это интернациональная организация, основана
в 1989 г., состоящая более чем из 800 членов: поставщиков информационных систем,
разработчиков программного обеспечения и пользователей. OMG продвигает теорию и
практику объектно-ориентированной технологии в область практической разработки
программного обеспечения. Этот процесс включает в себя разработку промышленных
стандартов и спецификаций управления объектами с целью создания общей базы для
разработки программного обеспечения. Первоочередными задачами являются:
повторное использование, переносимость и интероперабельность объектноориентированного программного обеспечения в распределенных, гетерогенных средах.
Поддержка данных стандартов создает возможность разрабатывать гетерогенные
приложения, работающие на всех основных платформах и операционных системах.

X/Open - независимая всемирная открытая организация, поддерживаемая
большинством крупнейших поставщиков информационных систем, пользовательских
организаций и компаний-производителей программного обеспечения. X/Open
разрабатывает на основе существующих и создающихся стандартов всеобъемлющее и
интегрированное системное окружение - Common Applications Environment
(CAE).Компоненты CAE определены в стандартах X/Open CAE.Основная цель CAE создание пакетов программных интерфейсов (API) которые могут применяться на
практике с сохранением максимальной переносимости на уровне исходных кодов
программ. API также повышают уровень взаимодействия приложений при помощи
предоставления определений и ссылок на протоколы и их профили.

Вышеназванные спецификации тщательно тестируются, выдержавшим тестирование
присваивается X/Open trademark (XPG brand),лицензированная X/Open.

Концептуальной инфраструктурой, на которой базируются все спецификации
OMG,является Object Management Architecture (OMA).В состав OMA входят
разнообразные стандартизованные или в настоящий момент стандартизируемые OMG
службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and
vertical CORBAfacilities),язык определения интерфейсов распределенных объектов IDL
(Interface Definition Language),стандартизованные или стандартизируемые отображения
IDL на языки программирования и, наконец, объектная модель CORBA.

Реализовать технологию в соответствии со спецификациями может кто угодно.

9

Созданные программные продукты, естественно, уже не являются открытыми, а
становятся коммерческими продуктами.

Архитектура CORBA

CORBA определяет, каким образом программные компоненты, распределенные по
сети, могут взаимодействовать друг с другом вне зависимости от окружающих их
операционных систем и языков реализации. Центральным элементом архитектуры
CORBA является ORB (Object Request Broker) - программное обеспечение,
обеспечивающее связь между объектами, в том числе позволяющее

найти удаленный объект по Объектной Ссылке (IOR - Interoperable Object
Reference),
вызвать метод удаленного объекта, передав ему входные параметры (marshaling
parameters),
получить возвращаемое значение и выходящие параметры (unmarshaling
parameters).

Тем самым ORB является связующим звеном между распределенными частями
основанной на технологии CORBA системы, позволяя одной части системы не
заботиться о физическом расположении других частей (объектов) системы. На рынке
представлены ORB разных производителей (например, VisiBroker, WebLogic),но все
они соответствуют единой спецификации CORBA. Поэтому в принципе CORBA
позволяет строить распределенные системы, одновременно используя ORB разных
производителей, и строя систему одновременно на различных платформах и различных
сетевых протоколах (это в терминологии CORBA называется интероперабельностью interoperability).В архитектуре CORBA каждый объект, методы которого доступны
другим объектам (обычно его называют CORBA -объектом) имеет уникальную по всей
доступной сети Объектную Ссылку (IOR - Interoperable Object Reference),по которой к
нему можно обратиться. Искать CORBA -объекты можно как по IOR, так и по
символическим именам, если они зарегистрированы (обычно при создании) в
специальном сервисе имен (NameService).Для обращения к методам CORBA -объекта
последний имеет открытый для всех остальных CORBA -объектов интерфейс.
Интерфейсы CORBA -объектов принято описывать на специальном, определенном
спецификацией CORBA языке IDL (Interface Definition Language). Производители ORB
поставляют вместе с ORB также и утилиты, преобразующие описания интерфейсов

CORBA -объектов в конструкции соответствующих языков программирования.

Основой интероперабельности является протокол GIOP - General inter-ORB
Protocol,предназначенный для связи между объектами и ORB в сети. Стандартизация
коммуникационного протокола позволяет разработчикам различных частей
корпоративной системы совершенно не заботиться об используемых ORBах в других
частях ( ORB доменах)

системы. Почти все современные ORBbi строятся на основе IIOP - Internet inter-ORB
Protocol (это версия общего протокола GIOP,предусматривающая использование в

10