Какими свойствами не обладает открытая архитектура

Открытая архитектура компьютера: сущность и принципы построения

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

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

Готовые работы на аналогичную тему

Получить выполненную работу или консультацию специалиста по вашему учебному проекту
Узнать стоимость

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

Основными принципами открытой архитектуры считаются следующие положения:

1. Она предполагает вероятность и возможность дальнейшего совершенствования конструкции.
2. Применение известных технологических и технических решений не ведёт к затратам на лицензирование.
3. Эксплуатационные возможности системы допускают модификацию базовой комплектации устройства непосредственно пользователем.

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

Модульная компоновка компьютера

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

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

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

Общей системной шиной управляет центральный процессор, который выделяет время остальным модулям для выполнения обменных операций с данными.

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

Открытая архитектура компьютера подразумевает следующие правила модульности:

• Центральный процессор наиболее часто применяется от компании Intel или аналогичные ему, кроме того могут использоваться совместимые с ними программно процессоры других производителей.
• В память материнской платы зашит BIOS (базовая система ввода-вывода).
• Начальный системный запуск изначально регламентирован.
• Организация памяти представлена в виде набора модулей, которые имеют разные параметры.
• Работает процедура выполнения операции определения конфигурации.
• Персональный компьютер снабжён системным реестром и специальным разделом памяти для сохранения параметров конфигурации.
• Организована работа механизма прерывания программы и прямого доступа к памяти.
• Каждый модуль компьютера имеет свой индивидуальный адрес.
• Для операции ввода данных и отображения её на экране дисплея применяется специальное кодирование.

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

Открытая архитектура персонального компьютера подразумевает своими базовыми составляющими две части:

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

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

Общие сведения

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

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

Готовые работы на аналогичную тему

Получить выполненную работу или консультацию специалиста по вашему учебному проекту
Узнать стоимость

Принцип открытой архитектуры компьютера

Революционным событием стало решение ведущей компьютерной фирмы IBM спроектировать и собрать компьютер с указанной в его паспорте архитектурой. Это был компьютер IBM PC (на основе процессора Intel-8086), поступивший в продажу в 1981 году. Отдельно было подчёркнуто, что этот компьютер возможно подвергнуть модернизации, устанавливая разные дополнительные блоки и устройства периферии или просто меняя их на более совершенные.

Затем другие компании стали проектировать компьютеры, которые были совместимы с IBM PC, и это возвело его в ранг стандарта компьютерной техники. Существует, однако, мнение, что этот, по сути революционный, поступок погубил компанию IBM. Сегодня её часть компьютерного рынка бесконечно маленькая, но зато термин «IBM-PC-совместимый», навечно вписал имя этой компании в историю развития компьютерной техники.

Говоря иначе, если пользователь хочет улучшить параметры компьютера, то ему достаточно искать модуль (деталь) с лучшими характеристиками, не обращая внимания на то, кто является производителем (конечно, при условии, что этот модуль принадлежит к IBM-совместимым устройствам). Около 85% на рынке компьютеров принадлежит компьютерам, разработанным на базе открытости архитектуры.

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

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

В целях безопасности личных данных, пользователям необходимо помнить об этих свойствах открытой архитектуры компьютера и тщательно отстраивать доступ к периферийным устройствам. К примеру, все жёсткие диски или какие-либо каталоги на них могут стать доступными через внешние сети при помощи закладки «Доступ» в разделе «Свойства». Таким же образом может быть открыт доступ и к другому различному оборудованию (принтеру, сканеру и тому подобное). Естественно, глупо предполагать, что кому-то потребуется распечатать что-то на удалённом принтере без возможности забрать распечатки, но вот данные с жёсткого диска вполне вероятный объект кражи. Там может быть чья-то личная информация, пароли доступа и тому подобное, что не обязательно должно быть доступно широкому кругу людей. Возможен также вариант случайного доступа, когда, к примеру, системный программист, обслуживая компьютер, открыл для себя доступ к памяти компьютера, а затем позабыл выключить его по завершению всех процедур по обслуживанию.

Комплектация компьютера

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

В любом более или менее серьезном проекте по созданию программного обеспечения на одном из первых этапов производится выбор архитектуры будущего решения. Трудно переоценить важность этого этапа, особенно если речь идет о большой системе, рассчитанной на длительную эксплуатацию: на разработку подобной системы будут затрачены значительные ресурсы, и вложения окажутся эффективными лишь в случае, если система не станет «унаследованной» уже с момента ввода в эксплуатацию, а будет допускать модернизацию не только с минимально возможными затратами, но и без потери архитектурной целостности и, соответственно, надежности. К сожалению, часто разработчики программных систем делаются заложниками изначально неверно выбранной архитектуры, а развитие функционала системы становится невозможным или приводит к потере производительности и надежности. С другой стороны, верно выбранная архитектура решения позволяет системе эволюционировать, продолжительное время обеспечивая требуемый функционал. Опыт компании «Стек Софт» в создании программной платформы Onyma xRM согласно с предложенными ею принципами «Открытой архитектуры информационных систем» показал, что такая архитектура может служить хорошей основой для разработки масштабных информационных систем с длительным жизненным циклом, эксплуатируемых как в традиционных областях (в том числе CRM, BPM, ERP, АСУ), так и в только формирующихся, таких, например, как Интернет вещей или киберфизические системы [1].

Само понятие архитектуры программного обеспечения довольно размыто; часто под ним скрываются разные области программной инженерии. Стандарт ISO/IEC/IEEE 42010 не дает единого определения, а для описания архитектуры предлагает использовать так называемые виды (view) — то есть смотреть на архитектуру решения с нескольких разных точек зрения, раскрывающих принципы построения системы. В одних случаях наиболее полное представление о системе может дать структурный вид, в других — процессный. Строгий набор видов стандартом не регламентируется — предлагается выделить наиболее заинтересованные в создании системы стороны, определить их интересы и взглянуть на систему с их позиций. Практика показывает, что именно такой путь позволяет всесторонне оценить архитектуру будущего решения, не перегружая заинтересованных лиц несущественной информацией. Для формального представления видов стандарт предлагает использовать языки описания архитектуры (Architecture Definition Language, ADL), однако фактическим стандартом здесь стал язык UML, который языком ADL не является.

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

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

Рассмотрим, как с точки зрения программной организации выглядит большинство современных информационных систем, спроектированных под влиянием сервисной архитектуры [2], отчасти отвечающей сформулированным требованиям.

Рис. 1. Общая архитектура современной информационной системы

Компонент Business Logic реализует основной функционал системы (рис. 1). Компонент UI — интерфейс к основному функционалу для пользователей системы, а компонент API предназначен для интеграции с другими системами, возможно с использованием ESB [3]. Именно компонент API обеспечивает сервисность, предоставляя внешним потребителям интерфейсы к готовым бизнес-сервисам, реализованным на базе основного функционала системы из компонента Business Logic. Причем реализация сервисов может быть инкапсулирована как в компоненте API (c использованием функций основного функционала), так и в компоненте Business Logic. Компонент UI предоставляет пользователям удобный для них интерфейс и редко оперирует готовыми бизнес-сервисами — современные требования к эргономике этого не позволяют, и всегда требуется специфический функционал, находящийся за пределами основного функционала по обработке данных и предназначенный исключительно для решения интерфейсных задач. Исходя из различных решаемых компонентами задач, чаще всего в SOA компонент Business Logic реализуется в виде своеобразного ядра системы, предоставляющего низкоуровневый интерфейс к функционалу. Дальше на основе этого интерфейса реализуются пользовательский интерфейс и сервисы для предоставления внешним системам. Процессы разработки пользовательского интерфейса и сервисов зачастую не синхронизированы, кроме того, разработчики часто с большим вниманием относятся к требованиям своих непосредственных пользователей, чем к требованиям партнеров по интеграции. В результате функционал, предоставляемый непосредственным пользователям системы, может сильно отличаться от того, что доступно внешним системам в виде сервисов, а это, в свою очередь, не позволяет использовать хорошо зарекомендовавшую себя при работе в автономном режиме систему столь же эффективно и в едином информационном пространстве предприятия.

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

Рис. 2. Переход к «Открытой архитектуре»

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

• Синхронность функционала, предоставляемого непосредственным пользователям и внешним системам.
• Использование единого кода, реализующего сервис, как для пользовательского интерфейса, так и для внешних систем, что позволяет сократить время разработки, модификации и тестирования.
• Единый подход к обеспечению информационной защиты. Часто сервисы, предназначенные для интеграции с внешними системами, обладают слабой защитой из-за того, что внешняя система не транслирует индивидуальные полномочия конечных пользователей, а использует общий для всех операций механизм аутентификации и авторизации с максимальными полномочиями, достаточными для выполнения всех запланированных операций. При этом предполагается, что более детальный контроль полномочий будет обеспечен внешней системой или шиной, но, к сожалению, зачастую этого не происходит.
• Высокий уровень прозрачности использования сервисов системы. «Родной» интерфейс является по сути руководством по правильному использованию сервисов, предоставляемых внешними системами, и при должном уровне диагностики стороннему разработчику для реализации той или иной функции системы достаточно посмотреть, как этот функционал реализован в «родном» интерфейсе.

Однако уравнивание возможностей пользовательского интерфейса и интерфейсов внешних систем может привести, например, к деградации производительности пользовательского интерфейса вследствие необходимости применения более защищенных и крупно скомпонованных сервисов, предназначенных для медленных интеграционных протоколов RPC [4]. Лишение «родного» интерфейса привилегии использования низкоуровневых методов функционального ядра системы, безусловно, приведет к деградации производительности, однако негативный эффект можно минимизировать, правильно организовав взаимодействие компонентов API и Business Logic и грамотно выбрав уровень гранулированности сервисов.

Рис. 3. «Открытая архитектура»

Рассмотрим более подробно, как может быть организовано взаимодействие компонентов системы в «Открытой архитектуре» (рис. 3).

Предлагается выделить четыре основных уровня:

• DBMS / Data Provider — управление данными;
• Core — функциональное ядро системы, реализующее основную бизнес-логику;
• API — готовые к использованию сервисы;
• UI / Protocol Logic — RPC-протоколы вызовов готовых сервисов API-слоя и компонентов, реализующих на основе API-сервисов логику работы пользовательского интерфейса.

В ядре системы реализуются служебные компоненты, отвечающие за разделение полномочий, аудит и организацию работы непосредственно с поставщиком данных (Tools). Следует отметить, что для эффективной работы с большими объемами данных как в пользовательском интерфейсе, так и при интеграции (например, с системами бизнес-аналитики) недостаточно просто предоставить методы работы с данными системы — необходимо дать возможность непосредственной работы со структурами базы. Поэтому в ядре предусматривается специальный компонент, предоставляющий на уровне СУБД или иного источника данных безопасный доступ к структурам (Safe Data Provider). В реляционной СУБД это может быть, например, отдельная схема с полномочиями на чтение данных из специальных представлений, созданных таким образом, что они будут содержать только ту информацию, которая доступна текущему авторизованному пользователю. Современные СУБД предоставляют несколько различных технологий для реализации подобного механизма; важно, что такой подход позволяет обеспечить эффективную интеграцию различных систем на уровне взаимодействия баз данных, при этом ничего не потеряв с точки зрения информационной защиты.

Основная бизнес-логика системы реализуется условным компонентом ядра Logic, опирающегося на компонент Tools в части работы с данными и информационной защиты. Для компонента Logic автоматически генерируется безопасный интерфейс Safe Logic, разрешающий исполнение метода только в том случае, если это разрешено текущему авторизованному пользователю системой разделения полномочий. Фактически проверяется возможность обращения к каждому конкретному методу, что позволяет построить гибкую систему разделения полномочий. Принципиально то, что этот интерфейс, как и Safe Data Provider, должен создаваться системой поверх незащищенных методов автоматически. В результате интерфейс Safe Logic сам по себе является набором готовых к использованию бизнес-сервисов, а также основой для создания расширенных комплексных сервисов (Extention), при построении которых можно использовать еще и безопасный доступ к структурам данных (Safe Data Provider).

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

Разработчики внешних систем, так же как и разработчики пользовательского интерфейса, могут использовать различные способы обращения к данным и вызова сервисов: это может осуществляться посредством медленных, но универсальных RPC-протоколов, а может — прямо на уровне сервера приложений (Safe Logic) или СУБД (Safe Data Provider). Для увеличения производительности RPC, особенно в протоколах, не поддерживающих сессии (например, при работе с веб-сервисами), внешние разработчики могут скомпоновать на основе предоставленных Safe Logic сервисов требуемый композитный сервис в компоненте Extention и обращаться к нему, вместо того чтобы последовательно вызывать атомарные сервисы, каждый раз получая накладной расход на обработку протокола. Такой подход развязывает руки и разработчикам основной логики: на уровень API можно автоматически выносить атомарные сервисы, все необходимые композиты можно реализовать уже там, разные для разных задач, оставляя возможность работы и с базовыми сервисами. При этом открытая реализация композитных сервисов в API-слое, сделанная «родными» разработчиками, является одновременно и руководством по правильному использованию атомарных сервисов для внешних разработчиков.

***

На основе «Открытой архитектуры» реализована платформа Onyma xRM, которая, в свою очередь, стала базой для создания комплекса продуктов Onyma Billing, Onyma OSS и Onyma CRM, работающих в телекоммуникационных компаниях «Ростелеком», «Транстелеком», МТТ и позволивших обеспечить необходимую гибкость разработки и внедрения новых бизнес-сервисов, а также их интеграцию в информационный ландшафт предприятий. Кроме того, ряд компаний используют данные продукты в режиме SaaS.

Литература

1. Леонид Черняк. Киберфизические системы на старте // Открытые системы.СУБД. — 2014. — № 2. — С. 10–13. URL: https://www.osp.ru/os/2014/02/13040038 (дата обращения 20.3.2015).
2. Даниил Фейгин. Архитектуры и средства интеграции приложений // Открытые системы.СУБД. — 2005. — № 2. — С. 38–45. URL: https://www.osp.ru/os/2005/02/185300 (дата обращения 20.3.2015).
3. Леонид Черняк. Общая шина предприятия // Открытые системы.СУБД. — 2003. — № 4. — С.18–19. URL: https://www.osp.ru/os/2003/04/182897 (дата обращения 20.3.2015).
4. Леонид Черняк. Сервисы и сложные системы // Открытые системы.СУБД. — 2007. — № 10. — С. 30–33. URL: https://www.osp.ru/os/2007/10/4705804 (дата обращения 20.3.2015).

Дмитрий Волков (vdv@stacksoft.ru) — директор по развитию компании «Стек Софт» (Москва).