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

Архитектурой АИС называется распределение функций по ее подсистемам и компонентам, точное определение границ этих подсистем и их взаимодействия, а также распределение хранения и исполнения этих подсистем и компонентов по различным ЭВМ, объединенных в локальную или глобальную вычислительную сеть.

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

2. Модель «клиент-сервер».

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

Рис. Модель «клиент — сервер»

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

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

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

Функционирующие в настоящий момент информационные системы налоговой службы базируются на вычислительных сетях с неоднородным техническим и системным программным обеспечением. Для интеграции таких информационных систем необходимы связующие технологии, позволяющие осуществлять взаимодействие между прикладными компонентами на различных платформах. Одна из таких связующих технологий основана на спецификациях ОМА (Object Management Architecture) — фактических международных стандартов для построения распределенных объектных систем в гетерогенных средах; стандарты разработаны консорциумом Object Management Group (OMG). Архитектура таких распределенных интероперабельных информационных систем базируется на концепции программного обеспечения промежуточного слоя (middleware), содержащего средства поддержки глобального пространства объектов (программных компонентов).

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

- архитектура брокера запросов объектов (CORBA — Common Object Request Broker Architecture) устанавливает базовые механизмы взаимодействия объектов в гетерогенной сети;

- сервисы объектов (Object services) являются основными системными службами, используемыми разработчиками для создания приложений;

- универсальные средства (Common Facilities) ориентированы на поддержку пользовательских приложений, таких, как электронная почта, средства печати и т. п.;

- объекты приложений (Application Objects) предназначены для решения конкретных прикладных задач.

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

Главными компонентами стандарта CORBA служат:

- обработчик объектных заявок (Object Request Broker — ORB);

- язык определения интерфейсов (Interface Definition Language — IDL), с помощью которого могут быть определены операции для обращения клиентов к серверным объектам;

- объектный адаптер (Object adapter), который предоставляет доступ к сервисам объектного обработчика и обеспечивает все низкоуровневые средства для связи объекта с его клиентами;

- репозиторий интерфейсов (Interface Repository), представляющий собой средство для хранения и обработки информации, необходимой для описания интерфейсов CORBA-объектов.

3. Структура интерфейса.

Интерфейсы объектов могут быть определены и помещены в репозиторий интерфейсов двумя способами: статически — описанием на языке определения интерфейсов IDL или динамически. Репозиторий интерфейсов представляет компоненты интерфейса как объекты и обеспечивает доступ к ним во время выполнения. •

При формировании заявки клиент может использовать интерфейс динамического вызова или генерируемую компилятором IDL локальную процедуру вызова.

Клиент может также непосредственно взаимодействовать с ORB. ORB ищет соответствующий код, пересылает параметры заявки и передает управление Реализации объекта (Object Implementation). Реализация объекта принимает заявку через сгенерированные компилятором IDL процедуры и при этом может обращаться к объектному адаптеру и ORB. Когда обработка заявки завершена, управление и выходные значения возвращаются клиенту.

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

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

Объектный адаптер являемся основным средством доступа к услугам ORB со стороны объектной реализации. Эти услуги обычно включают: генерацию и интерпретацию объектных ссылок, вызов методов, активизацию/деактивизацию, реализации объекта, регистрацию реализаций. Предполагается наличие нескольких широко доступных объектных адаптеров с интерфейсами, соответствующими определенным видам объектов.