Выбор методов решения
Разрабатываемая система основана на архитектуре клиент-сервер. Архитектура клиент-сервер - одна из наиболее используемых концепций при создании информационных систем. В этой архитектуре предвидены следующие компоненты:
1. серверная часть (хранение и обработка информации);
2. клиентская часть (рабочий инструмент пользователя);
3. сеть, которая обеспечивает взаимодействие (обмен информацией) между клиентом и сервером.
В общем случае, чтобы прикладная программа, выполняющаяся на рабочей станции, могла запросить услугу у некоторого сервера, как минимум требуется некоторый интерфейсный программный слой, поддерживающий такого рода взаимодействие. Из этого, собственно, и вытекают основные принципы системной архитектуры клиент-сервер.
Система разбивается на две части, которые могут выполняться в разных узлах сети, клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто надсетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. Заметим, что в развитых системах сетевое обращение к серверной части может и не понадобиться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его следующий запрос.
Общим решением проблемы мобильности систем, основанных на Архитектуре "клиент-сервер" является опора на программные пакеты, Реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call).
RPC - технология, позволяющая компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Существуют множество технологий, обеспечивающих RPC: Sun RPC (RFC 1831), .Net Remoting, XML RPC, Java RMI, Routix.RPC
Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова удалённых процедур являются:
- асимметричность, то есть одна из взаимодействующих сторон является инициатором;
- синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:
- так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация;
- в отличие от локального вызова удаленный вызов процедур обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах;
- выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса - по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут "осиротевшими", а при аварийном завершении удаленных процедур станут "обездоленными родителями" вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур;
- существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
При использовании средств RPC обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.
При вызове удаленной процедуры программы RPC производят преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразование в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.
Термин "сервер баз данных" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных.
Хотя обычно одна база данных целиком хранится в одном узле сети и поддерживается одним сервером, серверы баз данных представляют собой простое и дешевое приближение к распределенным базам данных, поскольку общая база данных доступна для всех пользователей локальной сети.
Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз Данных SQL. Этот язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах.
Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество - стандартность интерфейса. В пределе, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел.
Недостаток тоже довольно очевиден - при таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД.
Протоколы удаленного вызова процедур особенно важны в системах управления базами данных, основанных на архитектуре "клиент-сервер". Во-вторых, использование механизма удаленных процедур позволяет действительно распределять функции между клиентской и серверной частями системы, поскольку в тексте программы удаленный вызов процедуры ничем не отличается от удаленного вызова, и, следовательно, теоретически любой компонент системы может располагаться и на стороне сервера, и на стороне клиента.
Во-вторых, механизм удаленного вызова скрывает различия между взаимодействующими компьютерами. Физически неоднородная локальная сеть компьютеров приводится к логически однородной сети взаимодействующих программных компонентов. В результате пользователи не обязаны серьезно заботиться о разовой закупке совместимых серверов и рабочих станций.
В типичном случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к северу с использованием языка SQL.
Требования к аппаратуре и программному обеспечению клиентских и
серверных компьютеров различаются в зависимости от вида использования
системы. Если разделение между клиентом и сервером достаточно жесткое (как в
большинстве современных СУБД), то пользователям, работающим на рабочих
станциях или персональных компьютерах, абсолютно все равно, какая аппаратура
и операционная система работают на сервере, лишь бы он справлялся с
возникающим потоком запросов.
Еще одним методом решения создаваемой системы является среда .Net. Для
программирования приложения проектируемой системы будет применен язык
программирования С#.
С# является "компонентно-ориентированным" языком в том смысле, что все
объекты оформляются в виде компонентов и все происходящее так или иначе
связано с компонентами.
Такие концепции компонентов, как свойства, методы и события, имеют
первостепенное значение для языка и базовой среды времени выполнения. С
компонентами может быть связана декларативная информация (атрибуты),
которая передает сведения о компонентах другим частям системы на стадии
конструирования или выполнения.
В создании компонентов на помощь С# приходят .NET Runtime и Frameworks. В результате возникает унифицированная система типов, в которой все данные интерпретируются как объекты без понижения быстродействия, характерного для чистых объектно-ориентированных систем.
Программирование на С# отличается простотой, надежностью и логичностью. Имеет развитый механизм обработки ошибок. Исключения обрабатываются практически на любом Уровне. С# безопасен по отношению к типам. Он защищен от использования неинициализированных переменных, небезопасных преобразований типов и других распространенных ошибок программирования.
С# обладает всеми преимуществами унифицированной среды, но при этом предоставляет доступ и к менее "почтенным" возможностям (например, уазателям), когда этого требует конкретная ситуация.
С# бережет усилия, затраченные на разработку готового программного кода. (Существующие объекты СОМ могут использоваться так, словно они являются объектами .NET. Среда .NET Common Language Runtime действует таким образом, что во время выполнения программы существующий СОМ-код воспринимает объекты как объекты СОМ. Из программного кода С# можно обращаться к коду С, находящемуся в файлах DLL.
С# построен на базе наследия C++. Этот язык быстро изучается, повышает эффективность труда программиста.
Наконец, С# широко использует возможности среды .NET Common Language Runtime, обеспечивающей обширную библиотечную поддержку для решения общих и специализированных задач программирования. .NET Runtime, Frameworks и языки объединяются в среде Visual Studio, предоставляющей все необходимые средства в распоряжение программиста .NET.