- История спецификаций, организация семейства
- Общая структура систем, следующих архитектуре WOSA
- Некоторые спецификации семейства WOSA
В статье рассматривается семейство спецификаций WOSA (Windows Open Services Architecture), существенно облегчающих создание приложений в рамках операционных систем Windows и способствующих их мобильности. Особое внимание уделяется спецификациям ODBC (Open DataBase Gonnectivity), MAPI (Messaging Application Programming Interface) и расширению WOSA для финансовых сервисов WOSA/XFS.
Особенности открытой архитектуры клиентских частей приложений
Российский компьютерный бизнес предпочитает искать там, где светлее. На практике это означает, что наиболее широк выбор стандартизованных аппаратных и программных компонентов. В частности, для программных систем, реализуемых в идеологии клиент/сервер, не составляет большого труда найти несколько (иногда с десяток) серверных компонентов (реляционных СУБД, почтовых серверов и т.п.) разных поставщиков. И среди продавцов, и среди покупателей только и слышно разговоров: "Oracle или Informix? Что такое Sybase?". Странно, что темой обсуждения еще не стали электрические параметры банковских сетей. Действительно, что предпочесть - 50 или 60 Гц?
В этих условиях нужды клиентов, ради которых в принципе и создаются приложения, оказываются вне поля зрения. Между тем, клиентские проблемы представляются по крайней мере не менее важными и трудными, чем серверные. Одна из проблем, специфичных именно для клиентских частей - их двойная открытость. С одной стороны, клиентские компоненты должны быть открыты по вертикали, чтобы обеспечивалась совместимость с серверными компонентами. В современных открытых архитектурах обеспечивается прежде всего именно вертикальная открытость. Так, в семействе операционных систем Windows за вертикальную открытость отвечают спецификации WOSA.
С другой стороны, клиентские компоненты должны быть открыты по горизонтали, чтобы гарантировать интероперабельность с другими клиентскими приложениями. При наличии горизонтальной открытости законченное клиентское приложение может строиться из стандартных компонентов (текстовых процессоров, систем электронных бланков, почтовых приложений и т.п.) с добавлением специфических компонентов, например, банковских. В операционных системах Windows горизонтальную открытость обеспечивают спецификации OLE.
Тема данной статьи довольно традиционна - вертикальная открытость клиентских приложений в Windows. Естественно, речь пойдет о семействе спецификаций WOSA. Автор надеется, что изумительно красивые идеи, связанные с горизонтальной открытостью, уже в ближайшем будущем найдут отражение на страницах "Открытых систем".
Семейство спецификаций WOSA
История спецификаций, организация семейства
В Windows поддерживается семейство стандартов, облегчающих написание и обеспечивающих вертикальную открытость приложений. Общее название этих стандартов - WOSA (Windows Open Services Architecture - открытая архитектура сервисов системы Windows). Семейство подразделяется на три категории:
В группу стандартов общего назначения входят:
- Open Database Connectivity (ODBC) - обеспечивает единообразный доступ к системам управления базами данных разных производителей (упомянем прежде всего Oracle, Informix и Sybase). Возможность смены СУБД или аппаратно-программной платформы, на которой СУБД функционирует, позволяет ценой относительно небольших затрат увеличить мощность прикладной системы, защищает вложения в прикладное программное обеспечение, позволяет оптимальным образом конфигурировать аппаратуру и программные продукты различных поставщиков.
- Messaging Application Programming Interface (MAPI) - позволяет относительно несложно встраивать в приложения почтовые возможности и делает доступными для подобных приложений почтовые системы от разных производителей, реализованные на разных платформах. Так, система Microsoft Mail содержит шлюзы для сопряжения по существу со всеми популярными почтовыми стандартами, а продукт Messenger фирмы Wollongong, также поддерживающий MAPI, обеспечивает доступ к почтовым услугам UNIX-компьютеров;
- Telephony Application Programming Interface (TAPI) - обеспечивает единообразный доступ к телефонным сетям независимо от их типа. Наличие подобного стандарта важно в первую очередь для реализации прикладных систем, обслуживающих удаленных и мобильных пользователей, в качестве которых могут выступать отделения банков или клиенты;
- LSAPI - интерфейс для проведения лицензионной политики.
В группу коммуникационных стандартов входят следующие элементы:
- Windows SNA API - обеспечивает единообразный доступ к мейнфреймам и сетям фирмы IBM за счет поддержки интерфейса IBM SNA API;
- Windows Sockets - позволяет Windows-приложениям получать доступ к сетевым сервисам независимо от используемого протокола (TCP/IP, IPX/SPX, Apple Talk и т.п.). Сокеты системы Windows в большой степени совместимы по исходным текстам с аналогичным средством ОС UNIX, что не только обеспечивает совместную работу сетевых компонентов на разных платформах, но и существенно облегчает миграцию сетевых приложений между платформами;
- Microsoft Remote Procedure Call (RPC) - обеспечивает удаленный вызов процедур. Это является основой современной реализации сетевых услуг. Механизм удаленного вызова процедур, предлагаемый в рамках Windows, совместим с аналогичной возможностью, реализованной консорциумом OSF для распределенной вычислительной среды (DCE) под ОС UNIX. На сегодняшний день в группу стандартов для финансовых приложений и сервисов входят два элемента
- Расширение WOSA для оперативных рыночных данных (WOSA/ XRT) - обеспечивает единый способ получения оперативных рыночных данных (цены, объемы продаж и т.п.) и единый формат этих данных. Спецификации WOSA/XRT разрабатываются сотрудниками Microsoft совместно с представителями консорциума Open Market Data Council;
- Расширение WOSA для финансовых сервисов (WOSA/XFS) - обеспечивает единообразный доступ к услугам, типичным для банковских приложений. Разработкой расширения WOSA/ XFS занимается консорциум Banking Systems Vendor Council, куда, помимо Microsoft, входят такие крупные компании, как DEC, NCR, Olivetti, Siemens Nixdorf, Unisys и другие. Стратегия WOSA/XFS базируется на использовании семейства операционных систем Windows, существующих компонентов семейства стандартов WOSA и, в частности, ODBC и MAPI. На первом этапе стандартизуется доступ к банковскому оборудованию. Ближайшие цели - стандарты на управление транзакциями, формат и способы пересылки финансовых сообщений, управление сетью, средства обеспечения безопасности и надежной работы и ряд других. Несомненно, разработчикам отечественных банковских систем необходимо считаться с наличием WOSA/ XFS.
Общая структура систем, следующих архитектуре WOSA
Каждый из стандартов семейства WOSA описывает архитектуру, включающую в себя следующие основные компоненты:
Схематически типичную WOSA-архитектуру можно представлять себе так:
Разделение уровней прикладного и серверного интерфейсов делает каждый из этих компонентов относительно независимым и позволяет, например, менять сервер (почтовый или базы данных) без изменения приложения. А это, как известно, - ключевой момент открытой архитектуры. Кроме того, у приложения появляется возможость выбирать синхронный или асинхронный режим работы с сервером. Наконец, приложение может вообще не знать, какой сервер его обслуживает, поручив менеджеру заботы о направлении своих вызовов.
Важно отметить, что каждый компонент архитектуры WOSA - это не только стандарт, но еще и инструментарий для разработки соответствующих приложений и сервисов (менеджер, библиотеки, включаемые файлы), что является существенным подспорьем для разработчиков обоих видов программного обеспечения.
Некоторые спецификации семейства WOSA
Спецификации ODBC (интерфейс для доступа к базам данных)
Интерфейс ODBC (Open Data Base Connectivity - несколько (фри)вольно это можно перевести как "открытая связь с базами данных") служит для доступа к базам данных, поддерживаемым различными СУБД, посредством языка SQL.
Интерфейс ODBC в максимальной степени обеспечивает взаимную совместимость серверных и клиентских частей доступа к данным. В частности, приложение может общаться с несколькими СУБД, а готовая система, реализованная в рамках ODBC, может состыковываться с конкретной СУБД уже после поставки, на рабочем месте клиента.
Чтобы практически реализовать унифицированный доступ к разным СУБД посредством разных сетевых протоколов, в ОрВС введено понятие драйвера, представляющего собой динамически загружаемую библиотеку (DLL) в терминологии Windows. Каждой паре СУБД/протокол соответствует свой драйвер (библиотека). Драйверы можно динамически загружать (и выгружать), тем самым во время выполнения настраиваясь на конкретное окружение.
Важно отметить, что сама по себе никакая СУБД не способна решить всех пользовательских проблем. Необходимы специализированные инструменты (электронные бланки, программы статистического анализа, системы поддержки принятия решений и т.п.). Следовательно, требуется отделять уровень обмена данными с СУБД от уровня обработки и интерпретации этих данных. Интерфейс ODBC как раз и играет роль концептуального водораздела.
Интерфейс SQL определяет следующие компоненты:
Помимо стандартных, интерфейс ODBC предоставляет набор дополнительных функций для.использования специфических возможностей СУБД или группы СУБД, например, роллируемых курсоров или асинхронных операций. В результате автор приложения может выбирать между мобильностью и оптимальностью работы с конкретной СУБД. В любом случае, однако, для выполнения SQL-инструкции достаточно передать ее в текстовом виде в качестве аргумента функции.
В соответствии с общей концепцией WOSA, ODBC-архитектура включает в себя четыре компонента:
Приложение. Обрабатывает данные, вызывает ODBC-функции для выполнения SQL-инструкций, получает результаты.
Менеджер драйверов. Загружает драйверы по запросу приложений.
Драйверы. Обрабатывают вызовы ODBC-функций, передают SQL-инструкции конкретным СУБД и возвращают результаты приложениям. При необходимости модифицируют SQL-инструкции и результаты, если того требует специфика СУБД.
Источники данных. Включают в себя не только СУБД, но и операционную и сетевую платформы.
Приложение, использующее интерфейс ODBC, выполняет следующие действия:
Менеджер драйверов поставляется корпорацией Microsoft в виде DLL-библиотеки. Помимо основной функции загрузки драйверов, он выполняет следующие действия:
Драйвер - это DLL-библиотека, реализующая вызовы ODBC-функций и взаимодействующая с источником данных. Драйвер загружается в память как результат вызова функции семейства SQLConnect. Драйвер выполняет следующие действия:
Очевидно, что подход, принятый в ODBC, требует динамического варианта SQL. Вообще говоря, это ведет к снижению эффективности, так как, в отличие от статического случая, когда SQL-текст известен заранее, СУБД не может наметить план выполнения динамически передаваемых инструкций. В качестве компромиссного средства предлагается вызов для подготовки SQL-инструкции, локально сводящий дело к статическому случаю. Подобная возможность полезна для многократно выполняемых инструкций. Возможности различных СУБД, а, следовательно, и драйверов, могут существенно различаться. Чтобы реальное, сложное приложение могло быть действительно независимым от источника данных, требуются средства для динамического выяснения возможностей конкретного драйвера. Например, если приложение хочет запретить редактирование столбцов отношения, к которым у пользователя нет соответствующего доступа, оно должно сначала выяснить, поддерживает ли СУБД права доступа с точностью до столбцов. Интерфейс ODBC обеспечивает возможность ведения переговоров между приложением и драйвером. В принципе эти переговоры могут касаться двух предметов - полноты реализации функций ODBC и поддерживаемых SQL-инструкций. В заключение раздела приведем пример С-программы, использующей ODBC-вызовы.
#include#include int example (UCHAR *server, UCHAR *uid, UCHAR *pwd) { HENV henv; HDBC hdbc; HSTMT hstmt; SDWORD id; UCHAR name[MAX_НАМЕ_LEN + 1]; UCHAR create[MAX_STMT_LEN]; UCHAR insert[MAX_STMT_LEN]; UCHAR select[MAX_STMT_LEN]; SDWORD namelen; RETCODE rc; /*Подключиться к серверу */ SQLAllocEnv(&henv); SQLAllocConnect(henv, &hdbc); rc = SQLConnect(hdbc, server, SQL_NTS, uid, SQL_NTS, pwd, SQL_NTS); if (rc != SQL SUCCESS && rc != SQL SUCCESS WITH INFO) return(print err(hdbc, SQL NULL HSTMT)); SQLAllocStmt(hdbc, &hstmt); /* Выполнить SQL-инструкцию "/ lstrcpy(create, "CREATE TABLE NAMEID(ID INTEGER, NAME ARCHAR(50))"); rc = SQLExecDirect(hstmt, create, SQL_NTS); if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) return(print err(hdbc, hstmt)); /* Подтвердить завершение транзакции */ SQLTransact(hdbc, SQL_COMMIT); /* Выполнить вставку в таблицу */ lstrcpy(insert, "INSERT INTO NAMEID VALUES (?, ?)"); if (SQLPrepare(hstmt, insert, SQL NTS) != SQL_SUCCESS) return(print err(hdbc, hstmt)); SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_С_SLONG, SQL_INTEGER, 0, 0, &id, 0, NULL); SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_С_CHAR, SQL_VARCHAR, MAX_NAME_LEN, 0, name, 0, NULL); id=500; lstrcpy(name, "Babbage"); if (SQLExecute(hstmt) != SQL_SUCCESS) return(print err(hdbc, hstmt)); SQLTransact(hdbc, SQL COMMIT); /* Выполнить выборку данных */ lstrcpy(select, "SELECT ID, NAME FROM NAMEID"); if (SQLExecDirect(hstmt, select, SQL NTS) != SQL_SUCCESS) return(print err(hdbc, hstmt)); SQLBindCol(hstmt, 1, SQL_С_SLONG, &id, 0, NULL); SQLBindCol(hstmt, 2, SQL_С_CHAR, name, (SDWORD)sizeof(name), &namelen); SQLFetch(hstmt); SQLTransact(hdbc, SQL_COMMIT); SQLFreeStmt(hstmt, SQL_DROP); /* Отключиться от источника данных и освободить ресурсы */ SQLDisconnect(hdbc); SQLFreeConnect(hdbc); SQLFreeEnv(henv); return(0); }
Специфииации MAPI (интерфейс для почтовых приложений)
Messaging Application Programming Interface (MAPI) - это набор интерфейсов, относящихся как к почтовым приложениям (точнее, к почтовым компонентам приложений, мы будем называть их также почтовыми клиентами) так и к серверным частям почтовых систем (называемым далее почтовыми серверами, хотя точнее их было бы назвать источниками почтовых услуг).
Интерфейс MAPI позволяет относительно просто создавать чисто почтовые системы и, в то же время, встраивать почтовые возможности в более универсальные приложения, такие, например, как система контроля за ходом проектов или специализированное рабочее место банковского служащего.
Почтовые системы под Windows функционируют в среде Microsoft Windows Messaging System (WMS). Это окружение предоставляет клиентские приложения (такие как MS Mail), менеджер в смысле WOSA, включающий в себя спулер сообщений, и, наконец, сетевые услуги и почтовые серверные компоненты. Почтовые серверы и шлюзы от Microsoft обеспечивают сопряжение по существу со всеми употребительными видами почты, от Novell MHS до Х.400.
Клиентская часть функций MAPI дает возможность создавать письма, задавать адресатов, управлять прохождением сообщений и сохранять их для последующей обработки.
Серверная часть содержит следующие компоненты:
- хранилище сообщений - служит для хранения и выборки сообщений. Каждое хранилище - это иерархия папок, в которых могут находиться другие папки или сообщения;
- сервер адресных книг - предоставляет информацию об адресатах, обрабатывает списки рассылки;
- транспортный сервер - обеспечивает пересылку сообщений между клиентами;
- спулер сообщений обрабатывает очередь исходящих писем, направляя их подходящим транспортным серверам, и, кроме того, сохраняет входящую корреспонденция в соответствующих папках.
Клиентская часть интерфейса MAPI поддерживает так называемые общие почтовые вызовы (Common Mail Calls, СМС), предложенные группой поставщиков программного обеспечения, простой MAPI и расширенный MAPI.
СМС и простой MAPI - интерфейсы одного порядка сложности. Так, в простой MAPI входят три структуры и двенадцать функций. Если нужно добавить базовые почтовые возможности к какому-либо приложению, лучше всего использовать эти несложные интерфейсы.
Расширенный MAPI - явление другого порядка. Во-первых, расширенный MAPI следует объектно-ориентированному подходу, то есть предполагает использование более современной, чем СМС и простой MAPI, технологии программирования. Во-вторых, расширенный MAPI предоставляет более полный контроль над почтовыми средствами, что может быть существенно для сложных почтовых приложений.
Кратко остановимся на возможностях, предоставляемых СМС-интерфейсом. Все содержательные действия выполняются в рамках почтовых сессий. (Это верно и для других MAPI-интерфейсов.) Чтобы начать почтовую сессию, следует воспользоваться функцией cmc logon, для завершения сессии служит функция cmc logoff. В рамках сессии доступны три основных вида действий:
Отправка писем. Для этого служат функция cmc send или ее упрощенная разновидность cmc send document.
Чтение (выборка) писем. Сначала нужно получить сводную информацию о содержимом почтового ящика, воспользовавшись функцией cmc list. Затем можно читать отдельные письма (cmc read) или выполнять над ними иные действия (cmc act on).
Получение информации из адресной книги. Для этого служит функция cmc look up, основное назначение которой - обеспечить приложению переход от дружественного имени к формальному почтовому адресу.
Основными структурами, с которыми оперируют СМС-функции, являются СМС message (хранит информацию о сообщении), СМС recipient (содержит сведения об отправителе/получателе) и СМС attachment (хранит информацию о файлах, присоединенных к сообщению).
Функции группы СМС доступны не только из языков класса С/С++, но и из макроязыков, таких как Visual Basic for Applications. Это важно для быстрого встраивания в приложения несложных почтовых возможностей.
Организация простого MAPI-интерфейса близка к СМС. Информация хранится в трех структурах - MapiMessage, MapiRecipDesc и MapiFileDesc. Кратко охарактеризуем 12 функций, входящих в набор простого MAPI
- MAPIAddress - служит для задания или модификации списка адресатов;
- MAPIDeleteMail - удаляет сообщение;
- MAPIDetails - позволяет просмотреть и/или изменить информацию об адресате, хранящуюся в адресной книге;
- MAPIFindNext - позволяет по очереди получать сообщения определенного типа;
- MAPIFreeBuffer - служебная функция освобождея памяти;
- MAPILogoff - завершение почтовой сессии;
- MAPILogon - начало почтовой сессии;
- MAPIReadMail - чтение письма;
- MAPIResolveName - переход от дружественного имени к элементу адресной книги. При возникновении неоднозначности у пользователя запрашивается дополнительная информация;
- MAPISaveMail - сохраняет сообщение;
- MAPISendDocuments - отправка письма стандартным образом в рамках диалога с пользователем;
- MAPISendMail - отправка почтового сообщения.
Перейдем к рассмотрению расширенного MAPI. Расширенный MAPI позволяет:
Расширенный MAPI следует идеологии объектно-ориентированного программирования. Чтобы описать структуру расширенного MAPI, нужно перечислить классы объектов, которые расширенный MAPI предоставляет, и охарактеризовать методы, поддерживаемые этими классами.
Расширенный MAPI предоставляет следующие классы объектов (интерфейсы):
- IMapiSession - отвечает за организацию пользовательских почтовых сессий. В некотором смысле это корневой объект иерархии, поскольку именно он предоставляет методы для получения интерфейсов с хранилищами сообщений и адресными книгами. Другие методы позволяют опрашивать и/или изменять параметры сессии, такие как подразумеваемое хранилище или код последней ошибки. Отметим, что ссылку на объект класса IMapiSession нужно получать с помощью функции MAPILogon, не являющейся методом какого-либо класса.
- IMAPITable - обеспечивает работу с табличными структурами, такими как оглавление папки или набор адресатов конкретного сообщения. Предоставляются методы для перемещения по таблице, для сортировки ее строк и для их фильтрации (чтобы отобрать нужные элементы). Многие классы семейства MAPI наследуют этот интерфейс.
- IMAPIProp - позволяет работать со свойствами, то есть с данными, хранящимися в объектах. Посредством методов интерфейса IMAPIProp осуществляется доступ к данным всех MAPI-объектов, кроме табличных, то есть IMAPIProp - один из самых "наследуемых" интерфейсов. Среди методов данного класса - GetProps/SetProps (выборка/установка значений свойств), GetLastError (получение кода последней ошибки, случившейся при работе с объектом), GetPropList (получение списка всех свойств объекта), OpenProperty (открытие свойства, обычно с "большим", не умещающимся в памяти значением, доступ к которому будет осуществляться посредством методов интерфейса IStream), SaveChanges (сохранение изменений, произведенных в объекте).
- IMsgStore - отвечает за хранение сообщений. Предоставляет такие методы, как GetReceiveFolder и SetReceiveFolder (получение/установка папки для сообщений определенного типа), OpenEntry (открыть папку или сообщение) и т.п. OpenEntry
- пример метода, унаследованного у класса IMAPIProp.
- IMessage - отвечает за работу с сообщениями. Среди методов этого интерфейса - GetAttachmentTable (получение таблицы присоединенных файлов), CreateAttach/ DeleteAttach (создание/удаление присоединенного файла), OpenAttach (открыть присоединенный файл), GetRecipientTable (получение таблицы адресатов сообщения), ModifyRecipients (изменение адресатов сообщения) и, естественно, SubmitMessage (отправить письмо).
- IAttach - служит для работы с присоединенными файлами. Точнее, присоединять можно не только файлы, но и сообщения, а также объекты более сложной природы. Анализируя свойства присоединенного объекта, почтовые приложение должно выбрать правильные методы для работы с ним. Сам MAPI-интерфейс предлагает только один метод - SaveChanges (сохранение изменений).
- IAddrBook - отвечает за задание адресатов сообщения. Предоставляет такие методы, как Address (проведение стандартного диалога с отправителем на предмет задания или изменения списка адресатов), Details (предоставляет бланк для просмотра и/или изменения в диалоговом режиме детальной информации об адресате), ResolveName (возвращает таблицу адресатов, выбранных по неполной информации) и т.п.
- IABDistList - служит для обработки списков рассылки. Правда, вся обработка выполняется посредством единственного предоставляемого метода, GetContents Table (раскрыть список рассылки).
Предоставляются и некоторые другие классы объектов, на которых мы, однако, останавливаться не будем. Ограничимся схемой классов, входящих в иерархию MAPI.
На наш взгляд, приведенной информации достаточно, чтобы составить представление о MAPI как о высокоуровневом инструменте для создания почтовых приложений.
Разработка собственных почтовых серверов (например, защищенного сервера банковской почты) - задача существенно более сложная, хотя и решаемая средствами MAPI. Существенным подспорьем является разделение почтового сервиса на три компонента. Можно предположить, что чаще всего будет разрабатываться собственный транспорт (например, для пересылки сообщений по телеграфу), а сервис хранения и адресных книг может оставаться стандартным.
Отметим в заключение, что частью пакета Microsoft Office Developer's Kit является среда (FFAPI) для разработки собственных шлюзов в рамках почтовой системы MS Mail или собственных почтовых приложений. Таким образом, почта в Windows представляет собой по-настоящему открытую систему, допускающую как расширение, так и стыковку с почтовыми продуктами независимых производителей.
Спецификации WOSA/XFS (сервисы для финансовых приложений)
18 мая 1992 года было объявлено о создании совета поставщиков банковских систем (Banking Systems Vendor Council). В него вошли представители десяти фирм: Andersen Consulting Digital Equipment Corporation, EDS Corporation, ICL Plc, Microsoft Corporation, NCR, an AT&T Company, Ing С. Olivetti й С. S.p.A., Siemens Nixdorf Informationssysteme AG, Tandem Computers, Unisys Corporation.
Целью совета стала выработка такого подхода к компьютеризации финансовых учреждений, который позволил бы получать полные, непротиворечивые решения с учетом следующих требований:
- снижение расходов на разработку и сопровождение программного обеспечения путем повышения эффективности деятельности разработчиков, уменьшения затрат на их переподготовку, использования в максимальной степени существующих приложений;
- повышение своевременности новых приложений путем облегчения их разработки и более быстрого внедрения;
- повышение гибкости систем за счет возможности модульного построения, широкого выбора аппаратного и программного обеспечения от максимального числа поставщиков, поэтапного наращивания с сохранением первоначальных вложений;
- определение архитектуры, допускающей масштабирование решений в широком классе аппаратных платформ; стимулирование разработки большего числа высококачественных приложений путем всеобщего распространения стандартных интерфейсов и платформ;
- снижение затрат на переподготовку пользователей.
При достижении своих целей совет решил руководствоваться следующими стратегическими соображениями:
Использование семейства операционных систем Windows как основной платформы построения приложений в идеологии клиент/сервер.
Использование семейства стандартов WOSA для интеграции компонентов комплексных систем автоматизации финансовых предприятий. В частности, это означает максимальное использование существующих WOSA-спецификаций.
Дополнение архитектуры WOSA расширением для финансовых сервисов, чтобы удовлетворить специфические требования на доступ к услугам и устройствам.
Стабильность предлагаемых интерфейсов при последующем развитии финансового расширения.
Новый элемент семейства спецификаций WOSA получил название WOSA/XFS (Extensions for Financial Services). Первая версия финансовых расширений была подготовлена к маю 1993 года.
Совет решил в первую очередь сосредоточить свое внимание на унификации доступа к финансовой периферии (разного рода принтеры, устройства чтения/записи магнитных карт и т.п.), а уже затем приняться за такие темы, как:
Предполагается, что использование операционной платформы Windows, архитектуры WOSA и, в частности, финансовых расширений, принесет следующие выгоды:
- доступ к финансовым сервисам через стандартные для Windows пользовательские и программные интерфейсы позволит сэкономить на переподготовке пользователей и разработчиков.
- будет доступно все увеличивающееся число Windows-приложений и средств разработки;
- продукты от разных поставщиков станут взаимозаменяемыми, поскольку будут поддерживать общий интерфейс;
- приложения с минимальными изменениями или совсем без таковых смогут выполняться на всем спектре операционных систем Windows и на широком классе аппаратных платформ;
- приложения будут модульными, их будет относительно просто пополнять новыми компонентами (системы поддержки принятия решений, межбанковская связь и т.п.), приспосабливаясь тем самым к изменяющимся рыночным реалиям.
Расширения WOSA/XFS следуют общей архитектуре WOSA, поэтому основными описываемыми компонентами являются прикладной интерфейс (API), серверный интерфейс (SPI) и менеджер, связывающий приложения с серверами. Соответственно, WOSA/XFS - это не только спецификации, но и среда разработки приложений и серверов.
Как уже отмечалось, совет поставщиков банковских систем в первую очередь взялся за унификацию доступа к финансовой периферии, поскольку данный класс оборудования отличается большим разнообразием и относительной сложностью. В банковских устройствах много специфического, а почти каждый поставщик предлагает свой собственный интерфейс. Стандартизация в этой области сулит быстрый и немалый выигрыш в эффективности и гибкости новых разработок.
Основные функции серверов применительно к управлению финансовой периферией состоят в следующем:
Функции прикладного уровня разбиваются на следующие подмножества:
В спецификациях делается попытка в максимально возможной степени унифицировать структуру специфических команд и их операндов.
Проиллюстрируем типичную последовательность действий приложения на примере печати формы:
Далее в цикле выполняются следующие действия:
В первой версии спецификаций WOSA/XFS описано взаимодействие со следующими классами устройств:
В ближайшем будущем предполагается описать доступ к следующим устройствам:
Работа над спецификациями WOSA/XFS по существу только начинается. Следующие цели, которые наметил для себя совет поставщиков банковских систем, представляются не менее значимыми, чем доступ к финансовой периферии. Вероятно, в плане управления транзакциями будут взяты за основу рекомендации консорциума Х/Open. На сегодняшний день фактическим стандартом в этой области является система TUXEDO, клиентская часть которой реализована в том числе и под Windows.
Задачу управления финансовой сетью предполагается разбить на следующие подзадачи:
Не менее важно для финансовых приложений и обеспечение компьютерной безопасности. Предполагается, что в последующих версиях спецификаций будут затронуты такие темы, как:
Как и в других областях, предполагается в максимальной степени использовать существующие наработки (RSA, DES, Kerberos).
Можно надеяться, что совету поставщиков банковских систем удастся достичь поставленных целей.
