6. Файл - серверные субд: назначение и описание

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

Модель поддерживается своей ОС (СОС). На каждом клиенте размещается копия ядра СУБД. НА ФС хранятся только данные в виде файлов. Когда какой-то клиент запускает приложение, в котором имеются команды обработки данных, запрос к данным формируется на файл-сервер. В ответ клиенту передается запрошенный файл данных. На клиенте осуществляется обработка данных с последующим возвратом в централизованное хранилище на ФС. Передача файла осуществляется с помощью сегментной передачи данных. Клиент получает сегмент, если он не находит в нем требуемую запись, он запрашивает следующий сегмент. Если обрабатывается последняя запись, то в итоге передастся весь файл.

Недостатки:

1. Передается не требуемый кусок, а все или почти все.

2. Защита возможна только на уровне файла.

Эта архитектура позволила применить те наработки, которые были сделаны в ИС.

В качестве расширения были введены операторы для обеспечения многопользовательского режима → введены команды транзакций и блокировок/разблокировок данных. Имеется возможность блокировки на уровне записи – блокировка записи или совокупности записей и проводить модификацию только на тех клиентах, где была сделана блокировка. Другие клиенты могут только читать. После клиент разблокирует.

Блокировка возможна на уровне файла или на уровне записей/полей записей.

Транзакция – совокупность операций как единое целое – они либо выполняются полностью, либо не выполняются совсем

13. Базовая технология com: понятие и создание объекта, интерфейсы объекта, библиотека классов com

COM (англ. Component Object Model — объектная модель компонентов; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были реализованы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX, а также XPCOM.

Стандарт COM был разработан в 1993 году корпорацией Microsoft как основа для развития технологии OLE. Технология OLE 1.0 уже позволяла создавать т. н. «составные документы» (англ. compound documents): например, в пакете Microsoft Office эта технология позволяла включать диаграммы Microsoft Excel в документы Microsoft Word.

Путаница в названиях

В 1996 году Microsoft попыталась переименовать технологию OLE в ActiveX, но это удалось лишь частично. Например, технология OLE позволяла создавать так называемые элементы управления OLE (англ. OLE Controls, или OCX) — повторно используемые элементы пользовательского интерфейса, которые были построены на стандарте COM. Эти элементы управления OLE были переименованы в элементы управления ActiveX (англ. ActiveX controls), хотя расширение файлов «.ocx» за ними осталось. Затем Microsoft стала активно продвигать ActiveX в Интернет, включив поддержку элементов ActiveX в свой браузер Internet Explorer. В результате название OLE осталось только за технологией составных документов и локальных внедряемых объектов. А сетевые OLE-объекты стали называть по-новому — ActiveX.

Некоторая путаница между понятиями OLE и ActiveX сохраняется и до сих пор, но речь идёт об одних и тех же COM-технологиях. Причём, иногда даже путают понятия OLE и COM. Так, внедряемые OLE-объекты иногда называют COM-объектами, а OLE-контейнеры COM-контейнерами, и т. п.

Принципы работы COM

Основным понятием, которым оперирует стандарт COM, является COM-компонент. Программы, построенные на стандарте COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор (GUID) и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы — наборы абстрактных функций и свойств. Каждый COM-компонент должен, как минимум, поддерживать стандартный интерфейс «IUnknown», который предоставляет базовые средства для работы с компонентом. Интерфейс «IUnknown» включает в себя три метода: QueryInterface, AddRef, Release.

Windows API предоставляет базовые функции, позволяющие использовать COM-компоненты. Библиотеки MFC и, особенно, ATL/WTL предоставляют более гибкие и удобные средства для работы с COM. Библиотека ATL от Microsoft до сих пор остаётся самым популярным средством создания COM-компонентов. Но зачастую COM-разработка остаётся ещё довольно сложным делом, программистам приходится вручную выполнять многие рутинные задачи, связанные с COM (особенно это заметно в случае разработки на C++). Впоследствии (в технологиях COM+ и особенно .NET) Microsoft попыталась упростить задачу разработки COM-компонентов.

Технология часто критикуется за неоправданную сложность, конкретно:

необходимость использования двух языков программирования (.idl для описания интерфейсов и, обычно, C++ для написания реализаций). Необходимость возникает только при создании собственных интерфейсов, и не возникает в случае, если разработчик ограничил себя использованием готовых интерфейсов.

необходимость "прокладочного" кода (в его роли обычно выступает ATL) для того, чтобы создать COM-объект на базе Си++ класса. Хотя этот код и тривиален в использовании для опытного человека, он не очень прост для начинающих. Как и в предыдущем пункте, эта проблема возникает только при написании собственных классов и не возникает при одном лишь использовании стандартных чужих классов (для которых MS разработал библиотеку смарт-пойнтеров - comdef.h, _com_ptr_t<Interface>, эта библиотека делает использование COM-объектов тривиальным).

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

инфраструктура remoting (удаленного вызова методов) использует бинарный формат запросов и ответов, являясь расширением DCE RPC. Это приводит к возникновению огромной "поверхности уязвимости" с точки зрения безопасности, и не раз приводило к крупным эпидемиям вредоносного ПО (MSBlaster).

инфраструктура remoting использует по умолчанию (вслед за DCE RPC) динамически назначаемые номера TCP и UDP портов, что делает ее крайне сложной в настройке при наличии межсетевых экранов.

обработка ошибок. В COM принято использовать 32битные коды ошибки HRESULT, которые имеют значения вроде 0x80070123, и совершенно не читаемы человеком (хотя в последнее время все они тривиально ищутся поисковыми машинами Интернета).

Кроме того, runtime type information в COM, известная под названием type libraries, поддерживается только для т.н. Automation-compatible интерфейсов, имеющих огромные ограничения на типы параметров (массивы - только SAFEARRAY, строки - только BSTR, никаких произвольных структур, только числа, дата/время, массивы, строки и ссылки на другие Automation-compatible объекты).

Заметно, однако, что многие из этих недостатков являются платой за достоинство COM - независимость от языка программирования и исполняющей среды, и не существуют в «истинно объектных» языках, таких, как C# или же (прекращенная) реализация Java компании Microsoft. Эти языки предоставляют и полную runtime type information, и отсутствие необходимости регистрации, и возможность написания как интерфейсов, так и классов стандартным для языка образом, без «прокладок» вроде ATL. Так, в MS J++ любой класс Java тривиально публиковался внешнему миру как класс COM, достаточно было лишь регистрации. То же существует и в C#.

С противоположной стороны, «истинно объектные» языки либо вообще не способны стыковаться с компонентами из других объектных языков и требуют написания всей системы (и нижележащих подсистем и фреймворков) «сверху донизу» на одном языке в одной исполняющей среде (Java, Objective C), либо же налагают такое же требование хотя и не на язык, но на исполняющую среду (.NET, языки C#, C++ managed и VB.NET).

Более новые аналогичные технологии (например, в мире .NET) пытаются решить эти проблемы. Там обычно стек remoting полиморфен и кастомизируем, что дает возможность самостоятельно выбирать формат вопросов/ответов и транспортный протокол (по умолчанию используется уже не DCE RPC, а SOAP, в качестве формата данных - XML, а в качестве транспорта - HTTP, который не полагается на динамические номера портов).

Использование механизма позднего связывания может существенно снизить производительность по сравнению, например, с вызовом экспортируемой функции из динамической библиотеки. Однако этот механизм применяется только в скриптовых языках, и только в том случае, если язык не поддерживает объявление ссылок на объекты как ссылок на COM-интерфейсы из type libraries (в виде Dim obj As Excel.Workbook), а поддерживает только абстрактные COM-объекты (в виде Dim obj As Object). Кроме того, такой же подход применяется в Objective C и Cocoa.

http://www.developing.ru/com/com_disadvantages.html