Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Виды обеспечений информационных систем: Программное обеспечение (ПО), совокупность программ, процедур и правил, а также документации, относящихся к функционированию системы обработки данных. Информационное обеспечение (ИО), автоматизированных системы управления, совокупность реализованных решений по объемам, семантике (значению), распределению и структурам (формам) организации содержательной информации, циркулирующей в АСУ при ее функционировании. Математическое обеспечение (МО), автоматизированной системы управления войсками, совокупность математических методов, алгоритмов и математических моделей, обеспечивающих эффективное функционирование АСУ. Техническое обеспечение ИС - информационных систем — это комплекс технических средств, обеспечивающих работу ИС, соответствующей документации на эти средства и технологические процессы. Лингвистическое – совокупность языков проектирования, включая термины и определения, правила формализации естественного языка и методы сжатия и развертывания текстов. Классификация ПО: По способу распространения (доставки, оплаты, ограничения в использовании):Commercial Software, Freeware, Shareware, Abandonware, Adware, Free Software,Careware и др. Классическое программное обеспечение принято подразделять по назначению: -Системное. -Прикладное. -Инструментальное. -системное ПО (программы общего пользования), выполняющие различные вспомогательные функции, например создание копий используемой информации, выдачу справочной информации о компьютере, проверку работоспособности устройств компьютера и т.д. -прикладное ПО, обеспечивающее выполнение необходимых работ на ПК: редактирование текстовых документов, создание рисунков или картинок, обработка информационных массивов и т.д. -инструментальное ПО (системы программирования), обеспечивающее разработку новых программ для компьютера на языке программирования. Операционная система, ОС (англ. operatingsystem) — базовый комплекскомпьютерных программ, обеспечивающий управление аппаратными средствамикомпьютера, работу с файлами, ввод и вывод данных, а также выполнениеприкладных программ и утилит. |
Системы программирования Системное программирование (или программирование систем) — род деятельности, заключающийся в работе над системным программным обеспечением. Основная отличительная черта системного программирования по сравнению с прикладным программированием заключается в том, что результатом последнего является выпуск программного обеспечения, предлагающего определённые услуги пользователям (например, текстовый процессор). в то время как результатом системного программирования является выпуск программного обеспечения, предлагающего сервисы по взаимодействию с аппаратным обеспечением (например, дефрагментация жёсткого диска), что подразумевает сильную зависимость таких программ от аппаратной части. В частности выделим следующее: (Интегрированная) среда разработки программного обеспечения (англ. IDE,Integrateddevelopmentenvironment) — система программных средств, используемая программистами для разработки программного обеспечения. В состав системы программирования входят следующие программные инструменты и библиотеки:
|
1 мобильное (без перекомпиляции) 2. переносимое (перекомпил.) Набор международных стандартов, обеспечивающих переносимость программ. |
Интерпретатор —Программа или техническое средство, выполняющее интерпретацию.[1] -Вид транслятора, осуществляющего пооператорную (покомандную) обработку и выполнение исходной программы или запроса (в отличие от компилятора, транслирующего всю программу без её выполнения).[2] -Программа (иногда аппаратное средство), анализирующее команды или операторы программы и немедленно выполняющее их.[3] -Языковый процессор, который построчно анализирует исходную программу и одновременно выполняет предписанные действия, а не формирует на машинном языке скомпилированную программу, которая выполняется впоследствии.[4] Типы интерпретаторов Простой интерпретатор анализирует и тут же выполняет (собственно интерпретация) программу покомандно (или построчно), по мере поступления её исходного кода на вход интерпретатора. Достоинством такого подхода является мгновенная реакция. Недостаток — такой интерпретатор обнаруживает ошибки в тексте программы только при попытке выполнения команды (или строки) с ошибкой.
|
Архитектура «файл-сервер» в информационных системах Исторически первыми появились информационные системы с использованием файл-сервера. Файл-сервер только извлекает данные из файла (файлов) базы данных и передает их клиенту для дальнейшей обработки (рис. 1.1). В процессе работы из базы данных клиенту передаются большие объемы информации. Значительный сетевой трафик иногда особенно сильно сказывается при одновременной работе даже уже нескольких клиентов, например вы скачиваете игры на Андроид Fruit Ninja или другие приложения. В файл-серверной архитектуре всегда передаются избыточные данные. Неважно, сколько записей из базы данных нужны клиенту — файлы базы данных передаются в самом общем случае целиком. Что касается MS Access, то нагрузку на сеть добавляют еще и объекты приложения, такие как формы, отчеты и т. д. Они вместе с данными хранятся в одном файле на компьютере-сервере. |
Трёху́ровневая архитекту́ра — архитектурная модель программного комплекса, предполагающая наличие в нём трёх компонентов: клиентского приложения (обычно называемого «тонким клиентом» или терминалом), сервера приложений, к которому подключено клиентское приложение, и сервера базы данных, с которым работает сервер приложений. -Клиент — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранитьсостояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал. -Сервер приложений располагается на втором уровне. На втором уровне сосредоточена бо́льшая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы (см.выше), а также погруженные в третий уровень хранимые процедуры и триггеры. -Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных. |
Клиент-сервер (англ. Client-server) — сетевая архитектура, в которой устройства являются либо клиентами, либо серверами. Клиентом (front end) является запрашивающая машина (обычно ПК), сервером (back end) — машина, которая отвечает на запрос. Оба термина (клиент и сервер) могут применяться как к физическим устройствам, так и к программному обеспечению. Термин "клиент-сервер" означает такую архитектуру программного комплекса, в которой его функциональные части взаимодействуют по схеме "запрос-ответ". Если рассмотреть две взаимодействующие части этого комплекса, то одна из них (клиент) выполняет активную функцию, т. е. инициирует запросы, а другая (сервер) пассивно на них отвечает. Заметим, что любая информационная система должна иметь минимум три основные функциональные части - модули хранения данных, их обработки и интерфейса с пользователем. Каждая из этих частей может быть реализована независимо от двух других. Например, не изменяя программ, используемых для хранения и обработки данных, можно изменить интерфейс с пользователем таким образом, что одни и те же данные будут отображаться в виде таблиц, графиков или гистограмм. В классической архитектуре клиент-сервер приходится распределять три основные части приложения по двум физическим модулям. Обычно ПО хранения данных располагается на сервере (например, сервере базы данных), интерфейс с пользователем - на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями. В этом-то и заключается основной недостаток двухуровневой архитектуры, из которого следуют несколько неприятных особенностей, сильно усложняющих разработку клиент-серверных систем. При разбиении алгоритмов обработки данных необходимо синхронизировать поведение обеих частей системы. Все разработчики должны иметь полную информацию о последних изменениях, внесенных в систему, и понимать эти изменения. Это создает большие сложности при разработке клиент-серверных систем, их установке и сопровождении, поскольку необходимо тратить значительные усилия на координацию действий разных групп специалистов. В действиях разработчиков часто возникают противоречия, а это тормозит развитие системы и вынуждает изменять уже готовые и проверенные элементы. Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух физических частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент, или архитектура, называемая "2,5- уровневый клиент-сервер"). Рассмотренные выше модели имеют следующие недостатки. "Толстый" клиент: -сложность администрирования; -усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе; -усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам; перегружается сеть вследствие передачи по ней необработанных данных; |
Универсальные серверы — особый вид серверной программы, не предоставляющий никаких услуг самостоятельно. Вместо этого универсальные серверы предоставляют серверам услуг упрощенный интерфейс к ресурсам межпроцессного взаимодействия и/или унифицированный доступ клиентов к различным услугам. Универсальные серверы часто используются для написания всевозможных информационных серверов, серверов, которым не нужна какая-то специфическая работа с сетью, серверов не имеющих никаких задач, кроме обслуживания клиентов. Файл-серверы представляют собой серверы для обеспечения доступа к файлам на диске сервера. Прежде всего это серверы передачи файлов по заказу, по протоколам FTP, TFTP, SFTP и HTTP. Протокол HTTP ориентирован на передачу текстовых файлов, но серверы могут отдавать в качестве запрошенных файлов и произвольные данные, например динамически созданные веб-страницы, картинки, музыку и т. п. Другие серверы позволяют монтировать дисковые разделы сервера в дисковое пространство клиента и полноценно работать с файлами на них. Это позволяют серверы протоколов NFS и SMB. Серверы NFS и SMB работают через интерфейс RPC. Серверы доступа к данным обслуживают базу данных и отдают данные по запросам. Один из самых простых серверов подобного типа — LDAP (англ. Lightweight Directory Access Protocol — облегчённый протокол доступа к спискам). Для доступа к серверам баз данных единого протокола не существует, однако все серверы баз данных объединяет использование единых правил формирования запросов — язык SQL (англ. Structured Query Language — язык структурированных запросов). Серверы удаленного доступа, через соотвествующую клиентскую программу, обеспечивают пользователя консольными доступом к удаленной системе. Для обеспечения доступа к командной строке служат серверы telnet, RSH, SSH. Язык SQL Большинство СУБД используют язык SQL (Structured Query Language — язык структурированных запросов), так как он удобен для описания логических подмножеств БД. Назначение SQL: Одна из ключевых особенностей языка SQL заключается в том, что с его помощью формируются запросы, описывающие какую информацию из базы данных необходимо получить, а пути решения этой задачи программа определяет сама. |
Архитектура с использованием сервера приложений (трехзвенная архитектура) По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры: -масштабируемость -конфигурируемость — изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней -высокая безопасность -высокая надёжность -низкие требования к скорости канала (сети) между терминалами и сервером приложений -низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон. Многоуровневые архитектуры клиент-сервер. Главное преимущество многоуровневой архитектуры перед монолитной архитектурой проявляются не столько на этапе начальной разработки, сколько на этапе сопровождения операционной системы. При использовании многоуровневой архитектуры, для внесения новой функциональности в операционную систему |
Физические представления наименее абстрактны и отражают компоненты конкретной реализации и связи между ними. Каждый из элементов в физическом представлении реализуется программно или аппаратно, как правило, в процессе проектирования или разработки. Подобное представление реализации обычно используется отделами разработки или эксплуатации; его рассмотрение выходит за рамки данного документа. Физическое представление Каждый элемент модели приложения должен соответствовать реальным технологиям. Таким образом, модели приложений реализуются в виде моделей реализации. Эта задача частично выполняется во время разработки, когда программисты подробно расписывают бизнес-логику в виде кода, однако основная деятельность по реализации направлена на формирование платформы — метода разработки, в котором большая часть инфраструктуры распределенных приложений и инфраструктуры управления данными представляет собой сложные платформы, расширяемые с помощью настраиваемой логики приложений и декларативных структур управления. Очевидно, что проектирование и построение таких моделей для организации на каждом уровне требует значительных усилий и трудозатрат. Кроме того, адекватность подобных моделей критически важна для организации. Неверная архитектурная модель практически всегда приводит к серьезным проблемам в проектировании и эксплуатации, в частности, к проблемам с масштабируемостью и надежностью, а в худшем случае — к срыву проекта и негативным последствиям для бизнеса. Существует два типа рекомендаций, которые можно дать архитекторам, чтобы помочь им ускорить разработку моделей и минимизировать риски. К первому типу относятся архитектурные концепции, которые предоставляют архитекторам следующие сведения: -общее понимание процесса; -рекомендации по использованию конкретных концепций и сведения об их атрибутах; -критерии реализации этих концепций как в терминах рекомендаций, так и в терминах реальных технологий. Ко второму типу относятся шаблоны, основанные на реальном опыте эксплуатации удачных распределенных приложений, в которых заложены данные фундаментальные концепции. В этих шаблонах заключены важные рекомендации по проектированию распределенных приложений и минимизации рисков срыва проекта. Успех достигается благодаря использованию проверенных архитектурных моделей. |
11_)_Синхронное и асинхронное взаимодействие между узлами распределенной системы. Основной характеристикой способа взаимодействия подсистем распределенной системы является его синхронность или асинхронность. По отношению к исследуемым системам точнее говорить о блокирующем или неблокирующем взаимодействии. Блокирующим называется взаимодействие, если вовлеченные стороны прежде, чем переходить к следующим работам, должны дожидаться окончания взаимодействия. Следует понимать, что параллельная работа фрагментов систем не имеет никакого отношения к асинхронности и неблокирующему взаимодействию. Сервер, получив запрос от одного из своих клиентов, может, обрабатывая запрос, работать параллельно другим своим клиентам, синхронность же относится к работе запрашивающего обслуживания клиента и того процесса в сервере, который этот запрос обрабатывает. Если работа клиента на время обработки запроса сервером приостанавливается - это синхронное взаимодействие. Если вместо блокировки клиент после выдачи запроса выполняет другие действия - это взаимодействие асинхронное. Синхронное взаимодействие (Рис. 1.3) обладает преимуществом простоты. Обрабатывая запрос, сервер может быть уверен, что состояние клиента во время этой обработки не изменится. В результате синхронное взаимодействие применяется в подавляющем большинстве систем промежуточного слоя. Эти преимущества являются одновременно и недостатками. Синхронное взаимодействие приводит к существенны м потерям времени, а значит и производительности. |
При программировании программы в языке С++ например Потоковая абстракция, это допустим когда вычисления какого-то говна можно разбить на две независимые части. И каждую часть можно посчитать самостоятельно в отдельном потоке Абстра́кция в объектно-ориентированном программировании — это придание объекту характеристик, которые чётко определяют его концептуальные границы, отличая от всех других объектов. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций, таким образом, данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня. Абстра́кция в объектно-ориентированном программировании — это придание объекту характеристик, которые чётко определяют его концептуальные границы, отличая от всех других объектов. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций, таким образом, данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня. |
|
13_)_Вызовы удаленных процедур. Маршалинг. Язык IDL. Схема клиент-серверного взаимодействия. Сложности реализации заглушек и переносимость. Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC)) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык специализации объектов (или структур, для необъектных RPC). Маршалинг — процесс преобразования представления объекта в памяти в формат данных, пригодный для хранения или передачи. Обычно применяется, когда данные необходимо передавать между различными частями одной программы или от одной программы к другой. Маршалинг задействуется при использовании различных механизмов RPC, где есть необходимость в передаче данных между процессами и потоками. Переход от неуправляемого типа в тип CLR, как, например, в процессах P/Invoke, используемых в платформе .NET Framework, является подходящим примером, демонстрирующим применение маршалинга. IDL, или язык описания интерфейсов (англ. Interface Description Language или Interface Definition Language) — язык спецификаций для описания интерфейсов, синтаксически похожий на описание классов в языке C++. -CORBA IDL — язык описания интерфейсов распределённых объектов, разработанный рабочей группой OMG. Создан в рамках обобщённой архитектуры CORBA. -IDL DCE, язык описания интерфейсов спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group)[1] -MIDL (Microsoft Interface Definition Language) — язык описания интерфейсов для платформы Win32 определяет интерфейс между клиентом и сервером. Предложенная от Microsoft технология использует реестр Windows и используется для создания файлов и файлов конфигурации приложений (ACF), необходимых для дистанционного вызова процедуры интерфейсов (RPC) и COM/DCOM интерфейсов.[2] -COM IDL — язык описания интерфейсов между модулями COM. Является преемником языка IDL в технологии DCE (англ. среда распределённых вычислений) — спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group)[1] Сложность переносимости: Однако далеко не все производители столь щепетильны, и далеко не все платформы могут похвастаться столь длительным сроком жизни. Нередко с рынка уходят не только сами системы, но и их создатели, так что труднодоступными становятся не только сами системы, но и все сведения об их архитектуре. Исчезновение тех или иных платформ приводит к появлению унаследованного ПО — программных продуктов, необходимых для функционирования той или иной организации, но требующих для работы устаревшей программно-аппаратной платформы. В случае выхода из строя аппаратного обеспечения может оказаться, что найти ему замену очень сложно, дорого, а иногда и попросту невозможно, так как устаревшая ОС не работает на современном оборудовании (либо по причине принципиальных отличий архитектуры, либо по более прозаическим причинам — например, ввиду отсутствия необходимых драйверов). |
14_) Прозрачность местонахождения сервера. Способы реализации. Сравнение DCOM и CORBA архитектур. В настоящее время для построения распределенных информационных систем имеются широко распространенные технологии CORBA и DCOM. В данной работе предлагается краткое описание обеих технологий и некоторый сравнительный анализ. CORBA (Common Request Broker Architecture) - архитектура для построения распределенных объектных приложений, предложенная консорциумом из более чем 700 ведущих компаний из отрасли разработки программного обеспечения. Ядром CORBA является брокер объектных заявок ORB, позволяющий объектам обмениваться запросами. Объекты в CORBA представлены для других объектов интерфейсами с набором методов. Отдельные объекты идентифицируются объектными ссылками. Клиентская программа использует объектную ссылку для вызова методов сервера, в случае если объект сервера удалён, объектный брокер распознает такую ситуацию и производит все необходимые коммуникации. Реализация объекта взаимодействует с объектным брокером через объектный адаптер или через интерфейсы брокера. DCOM - распределенное (Distributed) расширение технологии COM (Component Object Model), созданное Microsoft на базе DCE (Distributed Computing Environment) и механизме удал╠нного вызова процедур (RPC). Сервер COM может создавать реализации объектов из нескольких классов, каждый из которых представляет различные варианты поведения объекта. Интерфейс содержит множество функционально связанных методов. COM клиент взаимодействует с COM сервером через указатель на интерфейс и использует этот указатель для вызова методов сервера. COM определяет, что любой интерфейс должен удовлетворять стандартному распределению памяти, которое используется так же для организации таблиц виртуальных методов в C++. DCOM и CORBA основываются на коммуникации типа клиент-сервер. Запрашивая сервис, клиент вызывает метод, реализуемый удалённым объектом, действующим в роли сервера. Сервис, предоставляемый объктом, инкапсулируется с помощью интерфейса, определенного на языке IDL (Interface Definition Language). Некоторые возможности объектно-ориентированного программирования представлены в IDL: инкапсуляция данных, полиморфизм и наследование. CORBA IDL поддерживает множественное наследование. Для достижения тех же целей DCOM позволяет объекту иметь несколько интерфейсов. CORBA IDL так же позволяет определить исключения. Для обращения к удалённой функции клиент вызывает клиентский стаб (client stub). Стаб упаковывает параметры обращения в сообщение-запрос и передает управление транспортному протоколу для передачи сообщения серверу. На стороне сервера транспортный протокол передает сообщение серверному стабу, который его распаковывает и вызывает действительную функцию сервера. В DCOM клиентский стаб называется proxy, серверный - просто stub. В CORBA клиентский стаб обозначают stub, а серверный skeleton. В основном технологии CORBA и DCOM сходны. Они обе предоставляют распределенную объектную инфраструктуру для прозрачного взаимодействия распределенных объектов. Но между этими технологиями имеются следующие основные различия: DCOM поддерживает объекты с множественными интерфейсами и предоставляет стандартный метод QueryInterface() для навигации между интерфейсами. Это вызывает необходимость динамической загрузки proxy/stub на стороне удаленного объекта. Подобная концепция отсутствует в CORBA. |
15_)_Жизненный цикл локальных и распределенных объектов. Лицензии на время существования объекта. Жизненный цикл распределенных объектов Жизненный цикл включает в себя создание, существование и удаление объекта. В библиотеке распределенных обновляемых объектов (DRO) жизненный цикл полностью определяется разработчиком. Программист может делегировать задачу другой системе, например реляционной БД, создав соответствующие идентификаторы для классов. В этом случае, такой идентификатор должен уметь находить свои объекты (или сообщать об их отсутствии) всякий раз, когда это требуется DRO. Специфичные идентификаторы так же могут использоваться для управления жизненным циклом по различным алгоритмам, без необходимости делегирования этой функции другому ПО. Другой способ – использовать Последовательный Числовой Идентификатор взамен специфичного, и тем самым полностью автоматизировать жизненный цикл объекта. DRO не требует от разработчика экспортировать объект для удаленного использования, однако DRO не сохраняет ссылок на такой объект. Программист должен сохранять ссылки в памяти для того чтобы уберечь объект от удаления в случае использования Последовательного Числового Идентификатора. При использовании специфичного идентификатора не требуется сохранять ссылки, так как объект загружается по требованию. |
16_)_Передача удаленных объектов по значению и по ссылке. Объекты, передаваемые по ссылке или по значениюНи для кого не секрет, что объекты можно передавать как по ссылке (передается только объектная ссылка, с помощью прокси создается иллюзия работы с самим объектом), так и по значению (передаётся копия объекта). При работе в рамках одного процесса это часто не принципиально, но при разработке распределенных приложений этому стоит уделить пристальное внимание. При передаче копии объекта между процессами состояние объекта необходимо сначала сериализовать в некий поток данных, а затем, на стороне получателя, создать новую копию объекта и загрузить в нее полученное состояние. Мы чуть не забыли про еще один тип объектов – не сериализуемые, но представители этой группы в рамках данной статьи нас будут интересовать только как оказывающие влияние на сериализацию других объектов. Передав объект клиенту по значению, вы в дальнейшем избавляете себя от необходимости использования прокси-объекта. Кроме этого, этот объект может теперь производить все операции без необходимости в посылке сообщений через границы процесса. Таким образом, при небольшом объеме данных, характеризующих состояние объекта, вы минимизируете сетевой трафик. С другой стороны, если объект содержит большое количество данных, а вам нужен только небольшой результат их обработки, передавать все данные по сети нецелесообразно. Отрицательной стороной передачи объекта по значению является и то, что объект, хранящий информацию, специфичную для серверной машины, после передачи клиенту будет содержать ложные данные. Причиной использования передачи по ссылке могут быть и соображения безопасности (не всегда можно передавать данные клиенту), и наличие связей объекта с несериализуемыми объектами на сервере. Для того, чтобы создаваемый вами тип мог быть передан по значению, достаточно, чтобы он реализовывал интерфейс ISerializable или имел атрибут SerializableAttribute, например, следующий класс будет автоматически сериализоваться: [Serializable] public class Toy { public String ToyName; public int Price; } |
|
17_)_Технологии детерминированного уничтожения объекта и сборки мусора. Преимущества и недостатки каждого способа. Сборка мусора — одна из форм автоматического управления памятью. Специальный процесс, называемый сборщиком мусора (англ. garbage collector), периодически освобождает память, удаляя объекты, которые уже не будут востребованы приложениями — то есть производит «сбор мусора». Если бы память компьютера была бесконечной, можно было бы просто оставлять ненужные объекты в памяти. Сбор мусора — эмуляция такого бесконечного компьютера на конечной памяти.[3] Многие ограничения сборщиков мусора (нет гарантии, что финализатор выполнится; управляет только памятью, но не другими ресурсами) вытекают из этой метафоры. Основные принципы Сборка мусора — технология, позволяющая, с одной стороны, упростить программирование, избавив программиста от необходимости вручную удалять объекты, созданные в динамической памяти, с другой — устранить ошибки, вызванные неправильным ручным управлением памятью. В системе со сборкой мусора обязанность освобождения памяти от объектов, которые больше не используются, возлагается на среду исполнения программы. Программист лишь создаёт динамические объекты и пользуется ими, он может не заботиться об удалении объектов, поскольку это делает за него среда. Для осуществления сборки мусора в состав среды исполнения включается специальный программный модуль, называемый «сборщиком мусора». Этот модуль периодически запускается, определяет, какие из созданных в динамической памяти объектов более не используются, и освобождает занимаемую ими память. Периодичность запуска сборщика мусора определяется особенностями системы. Сборщик может работать в фоновом режиме, запускаясь при неактивности программы (например, когда программа простаивает, ожидая ввода данных пользователем). Скорость выделения и освобождения памяти Неперемещающий сборщик мусора быстрее освобождает память (поскольку эта операция сводится к пометке соответствующих блоков памяти как свободных), но тратит больше времени на её выделение (поскольку память фрагментируется, и при выделении необходимо найти в памяти нужное количество блоков подходящего размера).Перемещающий сборщик требует сравнительно больше времени при сборе мусора (тратится дополнительное время на дефрагментацию памяти и изменение всех ссылок на перемещаемые объекты), зато перемещение позволяет использовать чрезвычайно простой и быстрый (O(1)) алгоритм выделения памяти. Скорость доступа к объектам в динамической памяти Объекты, поля которых используются совместно, перемещающий сборщик позволяет размещать в памяти недалеко друг от друга. Тогда они вероятнее окажутся в кэше процессора одновременно, что уменьшит количество обращений к относительно медленному ОЗУ. Совместимость с инородным кодом Для работы с инородным кодом используются различные специальные приёмы, например, pinning — явная блокировка объекта, запрещающая его перемещение во время сборки мусора. Достоинства и недостатки[править По сравнению с ручным управлением памятью сборка мусора безопаснее, поскольку она предотвращает утечки памяти и возникновение висячих ссылок из-за несвоевременного удаления |
18_)_Обеспечение безопасности и кроссплатформенности распределенных систем. Введение в обеспечение безопасности Распределенная система представляет набор программных компонент, использующих те или иные промежуточные среды для своего взаимодействия. Каждая промежуточная среда использует так называемый транспортный протокол, в роли которого может выступать: -промежуточная среда (например, Remoting или COM+ поверх MSMQ); -протокол верхнего уровня модели OSI (например, HTTP или HTTPS); -протокол транспортного уровня модели OSI (например, TCP). Транспортный протокол промежуточной среды, в свою очередь, использует протоколы нижних уровней. Напомним, что обеспечение безопасного взаимодействия программных компонент включает в себя: -идентификацию пользователя сервисов компоненты (аутентификацию); -защиту передаваемой информации от просмотра и изменения (шифрование и цифровая подпись); -ограничение доступа пользователей к сервисам компоненты в соответствии с результатом их идентификации Обеспечение функций безопасности на уровне промежуточной среды имеет определенные преимущества. 1_Большая гибкость. Например, возможно шифровать только отдельные части сообщения, а цифровая подпись применять к целому сообщению. 2_Переносимость. Промежуточная среда с собственной поддержкой безопасности может работать с различными транспортами и не выдвигает каких либо требований к безопасности транспортного уровня. 3_Возможность аудита. При использовании систем с маршрутизацией сообщений (например, веб служб) промежуточные маршрутизаторы сообщений могут добавлять в него дополнительную служебную информацию. 4_Большое время защиты сообщения. Сообщение остается зашифрованным максимально возможное время, в то время как при обеспечении безопасности транспортом оно поступает в промежуточную среду уже в расшифрованном виде. Механизмы обеспечения безопасностиЭлектронные сертификаты В настоящее время наиболее распространенным базовым механизмом обеспечения безопасности являются цифровые сертификаты, используемые для организации инфраструктуры открытых ключей ( public key infrastructure, PKI). Наиболее распространенным стандартом сертификата является стандарт X.509. Инфраструктура PKI основана на использовании доверенных систем. Целью организации инфраструктуры открытых ключей является привязка сторон обмена к сертификатам, содержащих их открытые ключи. Это позволяет как идентифицировать пользователя по сертификату, так и использовать асимметричное шифрование с открытым и закрытым ключами при передаче информации (рис. 9.2). |
19_)_Метаданные и программирование через атрибуты. Языки с поддержкой метаданных Метаданные – это структурированные, кодированные данные, которые описывают характеристики объектов-носителей информации, способствующие идентификации, обнаружению, оценке и управлению этими объектами. Атрибуты предоставляют эффективный метод связывания декларативной информации с кодом C# (типы, методы, свойства и т. д.). Атрибут, связанный с сущностью программы, может быть запрошен во время выполнения с помощью метода, называемого отражением. Атрибуты предоставляют универсальные средства связи данных (в виде аннотаций) с типами, определенными на С#. Вы можете применять их для определения информации периода разработки (например, документации), периода выполнения (например, имя столбца БД) или даже характеристик поведения периода выполнения (например, может ли данный член участвовать в транзакции). Возможности атрибутов бесконечны. Поскольку вы можете создавать атрибуты на основе любой информации, существует стандартный механизм определения самих атрибутов и запроса членов или типов в период выполнения как связанных с ними атрибутов. Существует две формы атрибутов. -Атрибуты, которые определены в среде CLR. -Пользовательские атрибуты, которые можно создать, чтобы добавить в код дополнительные сведения. Затем эти сведения можно извлечь программным путем. Атрибуты имеют следующие параметры. -Атрибуты добавляют в программу метаданные. Метаданные представляют собой сведения о типах, определенных в программе. Все сборки .NET содержат заданный набор метаданных, описывающий типы и члены типов, определенных в сборке. Для задания необходимых дополнительных сведений можно добавить атрибуты. |
Интерфе́йс — семантическая и синтаксическая конструкция в коде программы, используемая для специфицирования услуг, предоставляемых классом или компонентом. Интерфейс определяет границу взаимодействия между классами или компонентами, специфицируя определенную абстракцию, которую осуществляет реализующая сторона. В отличие от концепции интерфейсов во многих других областях, интерфейс в ООП является строго формализованным элементом объектно-ориентированного языка и в качестве семантической конструкции широко используется кодом программы. Интерфейсы позволяют наладить множественное наследование объектов и в то же время избавиться от ромбовидного наследования. Описание и использование интерфейсов. Описание ООП-интерфейса, если отвлечься от деталей синтаксиса конкретных языков, состоит из двух частей: имени и методов интерфейса. -Имя интерфейса строится по тем же правилам, что и другие идентификаторы используемого языка программирования. Разные языки и среды разработки имеют различные соглашения по оформлению кода, в соответствии с которыми имена интерфейсов могут формироваться по некоторым правилам, которые помогают отличать имя интерфейса от имён других элементов программы. Например, в технологии COM и во всех поддерживающих её языках действует соглашение, следуя которому, имя интерфейса строится по шаблону «I<Имя>», то есть состоит из написанного с заглавной буквы осмысленного имени, которому предшествует прописная латинская буква I (IUnknown, IDispatch,IStringList и т. п.). -Методы интерфейса. В описании интерфейса определяются имена и сигнатуры, входящих в него методов, то есть процедур или функций класса. Использование интерфейсов возможно двумя способами: -Класс может реализовывать интерфейс. Реализация интерфейса заключается в том, что в описании класса данный интерфейс указывается как реализуемый, а в коде класса обязательно определяются все методы, которые описаны в интерфейсе, в полном соответствии с сигнатурами из описания этого интерфейса. То есть, если класс реализует интерфейс, для любого экземпляра этого класса существуют и могут быть вызваны все описанные в интерфейсе методы. Один класс может реализовать несколько интерфейсов одновременно. -Возможно объявление переменных и параметров методов как имеющих тип-интерфейс. В такую переменную или параметр может быть записан экземпляр любого класса, реализующего интерфейс. Если интерфейс объявлен как тип возвращаемого значения функции, это означает, что функция возвращает объект класса, реализующего данный интерфейс. |
|
Транзакции и целостность БД Транзакция — совокупность логически взаимосвязанных запросов, направленных на согласованное изменение некоторого множества строк в одной или нескольких таблицах БД. Обычно при выполнении транзакций обновляется несколько таблиц и индексов, связанных с этими таблицами. Для того чтобы гарантировать синхронизацию обновления и целостность данных, в серверах обычно используется принцип «все или ничего», означающий, что в БД вносятся либо все обновления или ни одно из них. С этой целью ведется журнал транзакций, в котором регистрируется информация обо всех затребованных изменениях. Традиционное решение - откат всех транзакций, которые не завершились к моменту аварии, и гарантированная запись во внешней памяти результатов завершившихся транзакций. Естественно, это можно сделать только после возобновления подачи питания в ходе специальной процедуры восстановления. В среде клиент/сервер последний играет намного большую роль, чем просто распределитель данных. Фактически сервер выполняет основную часть работы системы. Он в некоторой мере руководит клиентом, каким образом тот должен получать доступ и управлять данными. Реально клиентные приложения предназначены только для предоставления данных пользователю или для их доставки от конечного пользователя. Далее в этой главе обязанности клиента и сервера рассматриваются подробнее..Сервер предоставляет сервис клиенту. Он, по существу, ждет, пока клиент сделает запрос, а затем обрабатывает этот запрос. Сервер должен обладать способностью обрабатывать несколько запросов от нескольких клиентов, а также располагать эти запросы по приоритетам. Чаще всего сервер запущен постоянно для того, чтобы не прекращался доступ к его сервисам. Типичная архитектура клиент/сервер состоит из программы-клиента конечного пользователя, которая имеет доступ на удаленном компьютере-сервере. Не существует никакого стандартного определения, что такое клиент и чем занимается сервер. Однако можно полагать, что сервер обеспечивает сервис, а клиент запрашивает его у сервера. К одному и тому же серверу может обращаться множество клиентов с требованием предоставить им какой-либо сервис, и именно сервер решает, как обработать такие запросы. Принципы системной архитектуры "клиент-сервер". Система разбивается на две части, которые могут выполняться в разных узлах сети, - клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. Заметим, что в развитых системах сетевое обращение к серверной части может и не понадобиться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его следующий запрос. Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне). |
-слабая защита данных, поскольку сложно правильно распределить полномочия. "Толстый" сервер: -усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки; -производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, -что имеет важное значение для сложных систем; -программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных; -получившиеся таким образом программы полностью непереносимы на другие системы и платформы. Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер. Основной принцип технологии "клиент-сервер" заключается в разделении функций приложения на три группы: -ввод и отображение данных (взаимодействие с пользователем); -прикладные функции, характерные для данной предметной области; -функции управления ресурсами (файловой системой, базой даных и т.д.) Поэтому, в любом приложении выделяются следующие компоненты: -компонент представления данных -прикладной компонент -компонент управления ресурсом Связь между компонентами осуществляется по определенным правилам, которые называют "протокол взаимодействия". В заключение стоит отметить что архитектура клиент-сервер предоставляет разработчикам ПО исключительную свободу выбора и согласования различных типов компонентов для клиента, сервера и всех промежуточных звеньев. Информационные системы, использующие архитектуру <клиент-сервер>, обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД: -Снижение сетевого трафика при выполнении запросов. Например, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен, компилируется, оптимизируется и выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. -Возможность хранения бизнес-правил (например, правил ограничения целостности данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных может быть произведено только с учетом этих правил. -Для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей master/detail) часто используют так называемые CASE-средства (Computer-Aided System Engineering). Эти инструменты позволяют описать подобные правила на уровне логической и физической моделей данных без программирования, а затем сгенерировать код соответствующих серверных объектов . |
По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры: -масштабируемость -конфигурируемость — изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней -высокая безопасность -высокая надёжность -низкие требования к скорости канала (сети) между терминалами и сервером приложений -низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон. Трехуровневая архитектура "клиент/сервер" имеет многие преимущества перед одно- и двухуровневой моделями. Ниже перечислены некоторые их них: - Для "тонкого" клиента требуется менее дорогостоящее аппаратное обеспечение. - Централизация бизнес-логики для многих конечных пользователей на одном сервере приложения и, как следствие, централизация сопровождения приложения. Благодаря этому исключается необходимость развертывания программного обеспечения на множестве компьютеров, что представляет собой одну из самых сложных задач в двухуровневой модели "клиент/сервер". - Дополнительная модульность упрощает модификацию или замену программного обеспечения каждого уровня без оказания влияния на остальные уровни. - Отделение основной бизнес-логики приложения от функций базы данных упрощает задачу равномерного распределения нагрузки. Дополнительное преимущество заключается в том, что трехуровневая архитектура довольно естественно отображается на среду WWW, где Браузер играет роль "тонкого" клиента, а веб-сервер - сервера приложений. Трехуровневая архитектура может быть расширена до N-уровневой архитектуры с дополнительными уровнями, которые позволяют повысить гибкость и масштабируемость создаваемых приложений. Например, промежуточный уровень в трехуровневой архитектуре может быть расщеплен на два уровня, один из которых может выполнять задачи обычного веб-сервера, а другой - типичного сервера приложений. |
В MS Access 2010 у разработчика имеется возможность разделить данные и приложение, работающее с этими данными. В этом случае приложение тиражируется на компьютерах-клиентах, а база данных остается на компьютере-сервере. Применение архитектуры «файл-сервер» привлекает своей простотой, удобством использования и доступностью. Она представляет интерес для малых рабочих групп, а нередко до сих пор используется и в информационных системах масштаба небольшого предприятия. Двухуровневая архитектура - архитектура приложения, в которой прикладные и пользовательские сервисы реализованы на клиентской рабочей станции, а данные централизованно хранятся на сервере. В этой модели клиенты подключаются непосредственно к серверу, на все время работы приложения. Преимущества двухуровневой архитектуры: -Простота системы по сравнению с Трехуровневой архитектурой -Более высокая надежность, т.к. нет звена SOAS -Защищенность БД от несанкционированного доступа -Шифрование информации с использованием сертифицированных библиотек сторонних производителей -Поддержка работы системы в режиме 24 часа 7 дней в неделю -Поддержка сетевых протоколов: TCP IP, IPX, Named Pipes |
|
Это важный инструмент ООП наряду с полиморфизмом, наследованием и инкапсуляцией. Абстракция является основой объектно-ориентированного программирования и позволяет работать с объектами, не вдаваясь в особенности их реализации. Абстракция данных — популярная и в общем неверно определяемая техника программирования. Фундаментальная идея состоит в разделении несущественных деталей реализации подпрограммы и характеристик, существенных для корректного ее использования. Такое разделение может быть выражено через специальный «интерфейс», сосредотачивающий описание всех возможных применений программы[1]. Процедурная абстракцияПроцедурная абстракция или процедура - наиболее известный в программировании тип абстракции. Всякий, кто применял для выполнения функции подпрограмму, реализовывал тем самым процедурную абстракцию в применении к алгоритмам. Процедуры объединяют в себе методы абстракции через параметризацию и спецификацию, позволяя абстрагировать отдельную операцию или событие. Процедура представляет собой некий преобразователь (реализует нкоторое отображение) списка входных параметров в выходные по некоторым правилам, с возможностью пересечения этих списков (это когда входной параметр является одновременно и выходным), причем как один, так и оба списка могут быть пустыми. Соответственно, при процедурной абстракции одновременно используются абстракции как через параметризацию, так и через спецификацию. Применение процедурной абстракции наделяет проводимую на ее базе декомпозицию следующими качествами: -локальность; -модифицируемость; -многократность использования кода. |
Ожидающий процесс может, вообще, быть удален из оперативной памяти, что приведет к еще большим потерям времени. Однако не всегда требуется работать синхронно. Один из примеров асинхронной связи - электронная почта. Асинхронные распределенные системы строятся аналогичным образом. Вместо вызова и ожидания ответа выполняется отправка сообщении (Рис. 1.4), а через некоторое время программа может проверить, прибыл ли ответ. Это позволяет программе выполнить другие работы и делает ненужной какую-либо координацию между сторонами взаимодействия. Для асинхронного взаимодействия сообщения должны запоминаться в некотором промежуточном месте, откуда они впоследствии могут извлекаться сервером. Эта промежуточная память открывает возможности для новой функциональности, которую больше не требуется делать частью отдельных компонентов. Такие системы очередей теперь превратились в брокеры сообщений, которые фильтруют их и управляют потоком сообщении. Тем самым появляется возможность менять способы фильтрации, преобразовании и доставки сообщений без изменения самих компонентов, генерирующих и получающих эти сообщения. |
Любая система может рассматриваться с разных точек зрения – например, поведенческой (динамической), структурной (статической), логической (удовлетворение функциональным требованиям), физической (распределенность), реализации (как детали архитектуры представляются в коде) и т.п. В результате, мы получаем различные архитектурные представления (view). Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. В свою очередь, дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе. Логическая архитектура предоставляет высокоуровневое описание миссии предприятия, его функциональных и информационных требований, системных компонентов и информационных потоков между этими компонентами. Как видно из схемы система состоит из нескольких серверов и АРМ-ов пользователей. Система хранит все обрабатываемые и справочные данные в СУБД (в Системе ДБО поддерживаются следующие типы СУБД: MS SQL, Oracle, Sybase ASA). Кроме СУБД система содержит еще один сервер, необходимый для работы практически всех модулей - сервер лицензирования, который представляет собой DCOM-сервер, связанный с электронным ключом защиты Guardant и файлом лицензий. Задача сервера лицензий - отслеживание соблюдения ограничений, которые накладываются на работу системы приобретенной лицензией. Он отвечает на запросы всех модулей Системы, связанных с проверкой наличия лицензии или ее параметров. Система содержит в своем составе АРМы администратора или операциониста. Перечисленные АРМ выполнены по одинаковой технологии и отличаются только разным набором функционала, доступным из главной формы приложения. Каждый из этих АРМ может присутствовать в Системе ДБО в неограниченном количестве. Каждый из АРМ напрямую подключается к БД Системы для доступа к данным Системы. Помимо отдельно стоящих АРМ операционистов в системе также присутствует Web-АРМ операциониста, которое выполнено по тонкой технологии и использует web-доступ к системе. Этот АРМ не использует прямого подключения к СУБД, а вместо этого общается через Web-сервер и сервер приложений. Для обеспечения работы клиентов, подключающихся к системе через браузер, используется цепочка серверов. Запросы от браузера клиента поступают на WEB-сервер системы. Защита канала передачи запросов обеспечивается использованием протокола HTTPS. Web-сервер, принимающий запросы клиентов, содержит в себе библиотеку, обрабатывающую запросы на генерацию динамических страниц. Запросы, поступающие на BSI, обрабатываются сервером приложений, который отвечает за выполнение запросов и генерацию страниц. Он постоянно принимает по протоколу TCP/IP у BSI запросы, ожидающие обработки, выбирает и выполняет их. Сгенерированная по этому запросу страница передается BSI. Помимо подключений клиентов Web-сервер системы предоставляет Web-доступ к системе операционистам через Web-АРМ операциониста. Для выполнения сервисных задач, а также различных автоматических заданий в состав системы входит сервер автопроцедур. Сервер автопроцедур, в том числе, выполняет задачи по связи с различными внешними системами. |
достаточно внести изменения только в код отдельного уровня, при этом все остальные уровни могут быть оставлены без изменений. При переносе операционной системы на другую аппаратную платформу, аппаратно зависимый уровень может быть просто заменен. Однако, не смотря на видимые отличия, многоуровневая архитектура является прямым развитием монолитной архитектуры, в которую просто введена более четкая структуризация. Поэтому, по мере дальнейшего усложнения операционных систем и с ростом динамики их развития, обнаружились недостатки многоуровневой архитектуры. RPC: Впервые спецификация вызова удаленных процедур). RPC поддерживает синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером). Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам - клиентскому и серверному суррогатам (client stub и server stub). Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой суррогатный процесс. Если клиент вызывает удаленную процедуру, вызов вместе с параметрами передается клиентскому суррогату. Он упаковывает эти данные в сетевое сообщение (этот процесс называется marshaling) и передает его серверному суррогату. Тот, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера и затем проделывает обратную процедуру с результатами. Таким образом, процедуры-суррогаты изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций. MOM: Message Oriented Middleware (MOM) - промежуточное ПО, ориентированное на обработку сообщений. Согласно этой модели приложения обмениваются байтовыми строками - сообщениями, обращаясь к АPI-интерфейсу системы МОМ, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от всех уже рассмотренных модел - промежуточное ПО, ориентированное на обработку сообщений. Согласно этой модели приложения обмениваются байтовыми строками - сообщениями, обращаясь к АPI-интерфейсу системы МОМ, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. На сегодняшний день существуют два варианта объектного промежуточного ПО:разработка COM/DCOM компании Microsoft и стандартная архитектура брокеров объектных запросов CORBA. COM (англ. Component Object Model — объектная модель компонентов; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. . (Common Object Request Broker Architecture - Общая Архитектура Брокерных Объектных Запросов), поддерживаемая консорциумом OMG. |
|
Также можно унаследовать свой класс от MarshalByValueComponent, и реализовать интерфейс ISerializable. Передача ссылки на объект вместо копирования его состояния позволяет избежать описанных выше проблем. Работа на клиенте идет с объектной ссылкой, которая с помощью прокси-объекта отправляет запросы серверному компоненту, таким образом позволяя не переносить все данные о состоянии объекта, а также получать прямой доступ к ресурсам сервера. Стоит отметить, что при обращении к объектам, передаваемым по ссылке и находящимся в том же приложении, что и вызывающий объект, система вернет прямую ссылку. Это позволит работать без потери производительности. В .NET объекты, передаваемые по ссылке, должны наследоваться от класса MarshalByRefObject, например: public class Toy : MarshalByRefObject { public String ToyName; public int ToyPrice; } Наследование от MarshalByRefObject позволяет переложить всю функциональность передачи объекта по ссылке на имеющуюся реализацию. |
Каждый интерфейс в CORBA наследуется от CORBA::Object, конструктор которого выполняет некоторые общие действия, такие как регистрация объекта, генерация объектной ссылки, обработка серверного стаба (skeleton). В DCOM такие функции явно выполняются серверной программой или динамически средой "времени исполнения" DCOM. В DCOM транспортный протокол обязательно связан с RPC, в CORBA такого ограничения нет. Кроме того, необходимо отметить, что технология DCOM изначально ориентировалась на системы, построенные на базе операционных систем фирмы Microsoft, тогда как CORBA представляется архитектурой межплатформенного взаимодействия. Важная группа типов прозрачности связана с местоположением ресурсов. Прозрачность местоположения (location transparency) призвана скрыть от пользователя, где именно физически расположен в системе нужный ему ресурс. Важную роль в реализации прозрачности местоположения играет именование. Так, прозрачность местоположения может быть достигнута путем присвоения ресурсам только логических имен, то есть таких имен, в которых не содержится закодированных сведений о местоположении ресурса. О распределенных системах, в которых смена местоположения ресурсов не влияет на доступ к ним, говорят как об обеспечивающих прозрачность переноса (mig-ration transparency). Более серьезна ситуация, когда местоположение ресурсов может измениться в процессе их использования, причем пользователь или приложение ничего не заметят. В этом случае говорят, что система поддерживаетпрозрачность смены местоположения (relocation transparency). Примером могут служить мобильные пользователи, работающие с беспроводным переносным компьютером и не отключающиеся (даже временно) от сети при перемещении с места на место. Как мы увидим, репликация имеет важное значение в распределенных системах. Так, ресурсы могут быть реплицированы для их лучшей доступности или повышения их производительности путем помещения копии неподалеку от того места, из которого к ней осуществляется доступ. Прозрачность репликации (replication transparency) позволяет скрыть тот факт, что существует несколько копий ресурса. Для скрытия факта репликации от пользователей необходимо, чтобы все реплики имели одно и то же имя. Соответственно, система, которая поддерживает прозрачность репликации, должна поддерживать и прозрачность местоположения, поскольку иначе невозможно будет обращаться к репликам без указания их истинного местоположения. Мы часто упоминаем, что главная цель распределенных систем — обеспечить совместное использование ресурсов. Во многих случаях совместное использование ресурсов достигается посредством кооперации, например в случае коммуникаций. Однако существует множество примеров настоящего совместного использования ресурсов. Например, два независимых пользователя могут сохранять свои файлы на одном файловом сервере или работать с одной и той же таблицей в совместно используемой базе данных. Следует отметить, что в таких случаях ни один из пользователей не имеет никакого понятия о том, что тот же ресурс задействован другим пользователем. Это явление называется прозрачностью параллельного доступа (concurrency transparencyЛюбой компонент COM не обязательно должен находиться на том компьютере, на котором Вы работаете. В COM реализуется технология под именем прозрачность местонахождения. Во первых указать где находиться необходимый компонент можно использовав ключ реестра RemoteServerName. Если операционная система здесь найдет имя компьютера, то она попытается активизировать компонент на удаленном компьютере. Этот способ довольно удобен для запуска компонентов на удаленном компьютере. Вот шаблон нахождения этого ключа. |
Реализация заглушек: Некоторые распределенные системы поддерживают механизм вызова удаленных процедур (RPC). Клиент в одном узле запрашивает удаленную процедуру сервера, находящегося в другом узле. Вызов удаленной процедуры аналогичен вызову локальной процедуры. Процедура, необходимая клиенту, часто называется клиентской заглушкой (Client Stub). Она принимает запрос и произвольные параметры, упаковывает их в сообщение (данный процесс называется маршалингом) и отправляет сообщение серверу. Удаленная серверная заглушка (Server Stub) распаковывает сообщение (демаршалинг) и вызывает нужную процедуру, передавая ей параметры. Когда серверная процедура заканчивает обработку запроса, она возвращает результаты серверной заглушке, которая упаковывает их в ответное сообщение и отправляет клиентской заглушке. Клиентская заглушка извлекает результаты из сообщения и возвращает их клиенту в виде выходных параметров. Таким образом, роль клиентской и серверной заглушек сводится к тому, чтобы представить вызовы удаленных процедур так, как если бы они были локальными. Локально вызывается клиентская заглушка, которая упаковывает имя и параметры процедуры в сообщение, отправляемое по сети. Интерфейсный уровень удаленного узла получает сообщение и передает его серверной заглушке, которая распаковывает сообщение и вызывает указанную процедуру серверного объекта. После завершения процедуры серверная заглушка упаковывает ответ и посылает его по сети. Затем клиентская заглушка распаковывает сообщение и передает его клиентскому объекту. |
|
|
Множественное наследование и реализация интерфейсов Как правило, языки программирования разрешают наследовать интерфейс от нескольких интерфейсов-предков. Все методы, объявленные в интерфейсах-предках, становятся частью объявления интерфейса-потомка. В отличие от наследования классов, множественное наследование интерфейсов гораздо проще реализуется и не вызывает существенных затруднений. Тем не менее, одна коллизия при множественном наследовании интерфейсов и при реализации нескольких интерфейсов одним классом всё-таки возможна. Она возникает, когда в двух или более интерфейсах, наследуемых новым интерфейсом или реализуемых классом, имеются методы с одинаковыми сигнатурами. Разработчики языков программирования вынуждены выбирать для таких случаев те или иные способы разрешения противоречий. Вариантов здесь несколько: запрет на реализацию, явное указание конкретного и реализация базового интерфейса или класса. -Запрет. В одном классе просто запрещается реализовывать несколько интерфейсов, имеющих методы с одинаковыми сигнатурами. Если для какого-то класса требуется комбинация несовместимых интерфейсов, программист должен выбрать другой путь решения проблемы, например, выделить несколько классов, каждый из которых реализует один из необходимых интерфейсов, и использовать их экземпляры совместно. -Явное разрешение неоднозначности. В случае обнаружения компилятором коллизии от программиста требуется явно указать, метод какого из интерфейсов он реализует и вызывает. То есть одноимённые методы реализуются раздельно, а при вызове указывается, какой из них вызывается. При вызове одноимённых методов через переменную типа «интерфейс» неоднозначность не возникает, если использованный в качестве типа переменной интерфейс имеет только один метод с заданным именем. Вариантом этого решения является явное переименование для совпадающих по именам наследуемых или реализуемых методов, за счёт чего в пределах реализующего класса нет одноимённых методов, но при обращении через интерфейс всегда вызывается нужная реализация. -Общая реализация одноимённых методов. Если наследуется или реализуется несколько методов с одной и той же сигнатурой, то они объединяются в интерфейсе-наследнике, а в классе-реализаторе получают одну общую реализацию. Это хорошо подходит для случаев, когда одноимённые методы разных интерфейсов идентичны по предполагаемой функциональности, но может вызвать нежелательные эффекты, если поведение этих методов должно различаться. Распределённая система — система, для которой отношения местоположений элементов (или групп элементов) играют существенную роль с точки зрения функционирования системы, а, следовательно, и с точки зрения анализа и синтеза системы. Для распределённых систем характерно распределение функций, ресурсов между множеством элементов (узлов) и отсутствие единого управляющего центра, поэтому выход из строя одного из узлов не приводит к полной остановке всей системы. Типичной распределённой системой является Интернет. (пример: компьютерная сеть) Один из способов решения проблем - это поддержка стандартных программных интерфейсов. Они облегчают задачу переноса приложений на серверы различных типов, предоставляя потребителю некоторую независимость от производителей. В прошлом было достаточно поддержки стандартного языка программирования, например, COBOL или С. Сегодня же типичное приложение может использовать базы данных, коммуникации, представления и другие сервисы, и их интерфейсы не являются компонентами языка программирования. Условием успешного переноса приложения на другую платформу является поддержка соответствующих интерфейсов на этой другой (целевой) платформе. |
-Программа может проверить собственные метаданные или метаданные в других программах с помощью отражения. Дополнительные сведения см. в разделе Доступ к атрибутам через отражение (Руководство по программированию в C#). -Атрибуты, например MarshallAsare, широко используемые в сценариях COM-взаимодействия. Лучше объяснить использование атрибутов на примере. Допустим, у вас есть приложение, хранящее некоторые данные в реестре. Одна из проблем разработки связана с выбором места хранения информации о разделе реестра. В большинстве сред разработки она, как правило, хранится в файле ресурсов, в константах или даже жестко запрограммирована в вызовах API реестра. Однако мы снова имеем ситуацию, когда неотъемлемая часть класса хранится отдельно от определения остальной части класса. Атрибуты позволяют "прикреплять" эту информацию к членам класса, получая полностью самоописывающийся компонент. Вот пример, иллюстрирующий, как это может выглядеть, если предположить, что атрибут RegistryKey уже определен: class MyClass { [RegistryKey(HKEY_CURRENT_USER, "foo")] public int Foo; } Чтобы прикрепить определенный атрибут к типу или члену С#, нужно просто задать данные атрибута в скобках перед целевым типом или членом. В нашем примере мы прикрепили атрибут RegistryKey к полюMyClass.Foo. Как вы вскоре увидите, все, что нам надо сделать в период выполнения, — это запросить значение поля, связанное с разделом реестра и использовать его, чтобы сохранить дату в реестре. |
Сертификат подписывается закрытым ключом некоторой доверенной третьей стороной ( certificate authority, CA). Цифровая подпись заключается в вычислении образа сертификата, вычисленного криптографической хеш функцией MD5, и последующего шифрования образа закрытым ключом CA. Результат шифрования образа сертификата называется цифровой подписью (рис. 9.3). Таким образом, сертификат содержит: -реквизиты предъявляющей его организации или подразделения организации;-реквизиты подписавшей его доверенной третьей стороны;-сроки действия сертификата;-открытый ключ;-цифровую подпись. После получения сертификата другая сторона обмена информацией проверяет его, используя открытый ключ подписавшей его организации. Если результат дешифровки подписи сертификата совпадает с образом остальной части сертификата, то сертификат верен. Сертификат доверенной стороны подписывается им самим. Протокол Kerberos Протокол Kerberos позволяет осуществлять идентификацию клиента и симметричное шифрование трафика на основе временных сессионных ключей. В настоящее время его модификация применятся в сетях Microsoft Windows 2000 и более поздних. Протокол Kerberos основан на использовании третьей доверенной стороны, называемой центром распространения ключей ( key distribution center, KDC). При идентификации в домене Active Directory клиент программной компоненты получает так называемый билет на дарование билета ( ticket-granting ticket, TGT), который затем используется для обращения к применяющим протокол Kerberos сетевым службам. При обращении к программной компоненте клиент посылает запрос к KDC, получает от него билет на доступ к сервису ( service ticket ), содержащий реквизиты клиента для авторизации сервисом и сессионный ключ, зашифрованные основным ключом сервиса, а так же сессионный ключ, предназначенный для клиента. Билет на доступ к сервису используется затем клиентом при доступе к сервису. Передаваемый сервису токен состоит из информации из билета доступа к сервису, к которой добавляется уникальная клиентская информация ( authenticator ), включающая в себя в частности время посылки запроса. Данная информация шифруется полученным клиентом сессионным ключом. Сервис дешифрует своим основным ключом полученный от клиента билет на доступ к сервису, извлекает из него сессионный ключ и дешифрует им реквизиты пользователя. В случае успеха дешифровки клиент проходит аутентификацию. |
объектов. Другой положительный момент — упрощение самого процесса программирования. С другой стороны, наличие сборки мусора может вызывать у неопытного разработчика чувство ложной безопасности, базирующееся на представлении, что вопросам выделения и освобождения памяти вообще не надо уделять внимания, поскольку они решаются сборщиком мусора. создавать классы с детерминированным вызовом специального метода-«деструктора» (Dispose) при выходе из зоны видимости. Во многих случаях системы со сборкой мусора демонстрируют меньшую эффективность, как по скорости, так и по объёму используемой памяти (что неизбежно, так как сборщик мусора сам потребляет ресурсы и нуждается в некотором избытке свободной памяти для нормальной работы). Кроме того, в системах со сборкой мусора сложнее реализуются низкоуровневые алгоритмы, требующие прямого доступа к оперативной памяти компьютера, поскольку свободное использование указателей невозможно и прямой доступ к памяти требует наличия специальных интерфейсов, написанных на низкоуровневых языках. С другой стороны, в современных системах со сборкой мусора операция выделения памяти сведена к элементарному добавлению блока в конец кучи, причём куча время от времени уплотняется, уменьшая фрагментацию данных. Существенное удобство от сборки мусора возникает тогда, когда динамически созданные объекты живут длительное время, многократно дублируются, а ссылки на них передаются между различными участками программы. В таких программах в общем случае достаточно сложно безошибочно определить место, где объект перестал использоваться и его можно удалять. Поскольку именно такая ситуация складывается при широком использовании динамически изменяемых структур данных (списки, деревья, графы), сборка мусора является необходимой в широко использующих такие структуры функциональных и логических языках, типа Хаскелла, Лиспа или Пролога. Использование сборки мусора в традиционных императивных языках (основанных на структурной парадигме, возможно, дополненной объектными средствами) определяется желаемым соотношением между простотой и скоростью разработки программ и эффективностью её выполнения. детерминированное уничтожение В С++ деструкторы объектов кучи вызываются, когда пользователь явно удаляет объект. В CLR этим занимается сборщик мусора, так что об удалении объектов беспокоиться не нужно. С другой стороны, для объекта С++, расположенного в стеке, деструктор вызывается, как только управление покидает область определения этого объекта. Это называется детерминированным уничтожением, и оно чрезвычайно удобно при управлении ресурсами. Рассмотрим случай с объектом, хранящим системный дескриптор файла. Такой находящийся в стеке объект в С++ может использоваться для управления жизненным циклом дескриптора файла. Когда объект создается, его конструктор захватывает дескриптор файла, и как только объект выходит из своего контекста (области определения), вызывается деструктор, код которого закрывает дескриптор файла. Это избавляет клиентский код объекта от необходимости явного управления ресурсом. Это также предотвращает утечку ресурсов, поскольку даже если будет сгенерировано исключение в блоке кода, использующем объект, С++ гарантирует вызов деструкторов всех находящихся в стеке объектов — независимо от того, каким именно образом произошел выход из блока. |