Однако, используя административные утилиты оказывается возможным применять Microsoft Exchange Server для передачи сообщений и от других серверных продуктов, в том числе и от Microsoft Windows NT Server. Например, сконфигурировав Performance Monitor как сервис операционной системы (это возможно сделать, пользуясь средствами Windows NT Resource Kit), и указав в качестве действий отправку сообщения через Microsoft Exchange Server, оказывается возможным оперативно извещать администратора системы о различных событиях в сети (вплоть до отправки текстов ему на пейджер).
Средства интеграции настольных приложений семейства Microsoft Office с серверными продуктами Microsoft BackOffice
Windows Open Services Architecture (WOSA) предоставляет набор открытых стандартов взаимодействия компонент прикладных систем на серверных и клиентских сторонах. Важнейшими из этих стандартов являются OLE (Object Linking and Embedding), ODBC (Open DataBase Connectivity) и MAPI (Messging Application Program Interface). Именно в рамках предоставляемых этими стандартами API и становится возможна интеграция настольных приложений семейства Microsoft Office с серверными продуктами Microsoft BackOffice.
Наиболее развитым и сложным стандартом открытой архитектуры является OLE, многие компоненты которого в последнее время стало принято называть ActiveX. Выросший из простых средств интеграции различных типов документов (например, вставки в текст Microsoft Word таблиц Microsoft Excel), стандарт OLE 2 включил в себя как организацию клиент-серверного взаимодействия (OLE-Server), так и управления встроенными элементами (OLE-controls, ActiveX). Сетевая компонентная модель COM (Component Object Model) также строится на основе OLE. Именно OLE позволяет, например, работать из Microsoft Excel с Microsoft Word или Microsoft Exchange, или использовать работающую на Microsoft Windows NT Server программу, написанную на Microsoft Visual Basic для обработки запросов Microsoft Internet Information Server.
Стандарт ODBC позволяет получать унифицированным образом доступ к различным базам данных как из клиентских, так и из серверных приложений. Например, функция Mail Merge в Microsoft Word может использовать ODBC для доступа к базе адресов, хранящейся на Microsoft SQL Server. С другой стороны, те же средства позволяют опубликовать эту базу данных на Internet или Intranet с помощью запросов Microsoft Internet Information Server.
Наконец, MAPI позволяет как клиентским, так и серверным приложениям обмениваться сообщениями. Именно он применяется для отправки документов (в том числе и по маршруту) из приложений семейства Microsoft Office. Он же применяется в SQL Mail в рамках серверного приложения.
Особенностью ODBC, MAPI и других стандартов WOSA является выделение двух типов программных интерфейсов - API (Application Program Interface) и SPI (Service Provider Interface). Если первый из этих интерфейсов определяет набор операций, используемых прикладной программой для работы с необходимым ей сервисом, то второй - набор операций, поддерживаемый конкретным сервером, реализующим этот сервис. Таким образом, стандарты открытой архитектуры высупают в роли шлюзов между клиентским приложением и стандартным сервером. Это дает возможность унифицированно работать с различными серверами, например, получать из одной и той же программы доступ к данным на Microsoft SQL Server, Oracle или DB2, либо посылать сообщения, используя как Microsoft Mail, так и Microsoft Exchange Server.
Интеграция с базами данных
ПО интеграции технологии Internet с существующими хранилищами данных позволяет администраторам Web узлов решить две фундаментальные проблемы: как опубликовать на Web-странице "снимок" данных, хранящихся в базе и как дать пользователям возможность выполнять запросы и модифицировать данные в базе с использованием программы просмотра вместо специализированного клиентского приложения.
Для решения этих проблем Microsoft создала шесть инструментов, обеспечивающих интеграцию баз данных со средствами просмотра Web-страниц:
В этом списке первые три компонента предназначены для создания Web-страниц, остальные три расширяют серверное ПО поддержки Internet, позволяя ему выступать в качестве платформы для создания приложений архитектуры клиент-сервер.
Публикация статических "снимков" информации, содержащейся в базе данных
Ключевые аспекты данного варианта распространения в Internet/Intranet информации из базы данных:
Для преобразования результатов запроса на MS SQL Server в HTML-страницы Microsoft предлагает SQL Server Web Assistant. Этот компонент создает страницы, которые могут быть опубликованы любым Web-сервером и просмотрены любым Web клиентом.
Visual Basic 5.0 и способы доступа к данным
Существует множество возможных решений проблемы взаимодействия с данными. Зачастую разработчики считают, что весьма затруднительно создавать коммерческие приложения, ориентируясь на перспективные технологии, которые в текущий момент еще не удовлетворяют насущным требованиям. Это действительно так, поэтому в данной статье даны некоторые рекомендации, которые помогут разработчикам оценить ситуацию с использованием тех или иных способов доступа к данным.
Я рекомендую Visual Basic в качестве основного инструмента в силу его наилучшей взаимосвязи с наиболее перспективными технологиями. В настоящий момент для работы с данными, хранящимися в реляционных серверных базах, применяется механизм Remote Data Access Objects (RDO) версии 2.0, в то время для настольных реляционных баз широко применяется механизм Data Access Objects (DAO/Jet). Оба интерфейса глубоко интегрированы в Visual Basic и являются его ключевой частью.
Производительность RDO 2.0 существенно возросла по сравнению с его первой версией, однако имейте в виду, что RDO входит только в Enterprise-редакции любого из средств разработки, входящих в состав Visual Studio.
Active Data Objects (ADO), разрабатываемые в течение последних полутора лет, соединили в себе наилучшие свойства DAO и RDO и призваны со временем их заменить. Если сегодня вы используете RDO, то не составит большого труда перепроектировать ваше приложение под ADO, так как их архитектура довольно похожа. Существующий в настоящий момент интерфейс ADO 1.5 не включен в состав Visual Basic 5.0, хотя на Visual Basic легко можно писать программы, использующие ADO. В последующих выпусках Visual Basic данный интерфейс станет его составной частью.
Вопрос, который волнует каждого разработчика: следует ли применять ADO уже сегодня? Обеспечит ли это те возможностями, которыми обладают сейчас RDO 2.0 или DAO 3.5. Ответ - да. Microsoft рекомендует разработчикам мигрировать на ADO, поскольку это стратегический интерфейс. В течение ближайших полутора лет ADO призван стать единым интерфейсом общения с источниками данных вне зависимости от их природы. Тем не менее, Microsoft гарантирует, что существующие интерфейсы взаимодействия с данными будут поддерживаться (по крайней мере, в ближайших версиях).
На протяжении последних нескольких лет программисты, использующие Visual Basic, создали множество разнообразных программ, компонент и сложных коммерческих решений. Свыше 80% этих разработок работают с различными данными - от текстовых файлов до серверных баз данных и распределенных данных на мэйнфреймах. Был создан ряд программ, использующих механизм VBSQL. Для того, чтобы удовлетворить запросы разработчиков, использующих Visual Basic и Access, корпорация Microsoft разработала два механизма - Microsoft Jet Database Engine (кратко - Jet) и Data Access Objects (DAO), чтобы дать возможность легко взаимодействовать с этими базами данных.
Visual Basic 5.0, кроме того, включает в свой состав абсолютно новый редактор запросов (Query Connection designer) для автоматизации создания сложных вызовов во время разработки приложения. Он позволяет в несколько раз уменьшить время, приходящееся на простое написание вызывающего кода и, в то же время, использует все возможности интерфейсов, предоставляемые в распоряжения разработчика.
В общей сложности разработчики, которые используют Visual Basic 5.0 в качестве инструмента, могут при разработке приложений использовать один из девяти способов взаимодействия с данными при создании клиентских или серверных компонент приложений. Каждый из них способен удовлетворить конкретные потребности клиента.
Что ожидает нас в ближайшем будущем?
Совершенно очевидно, что проектировщики и разработчики решений вовсе не горят желанием остановиться на полпути, обнаружив, что очередная новая технология Microsoft решает их проблемы с меньшими трудозатратами и возросшей функциональностью и производительностью приложений. Именно поэтому и именно сейчас необходимо отдавать себе отчет, что в ближайшем будущем механизм ADO будет призван сыграть ключевую роль в обработке разнообразных данных. Поэтому, приступая к долгосрочному планированию, имейте это в виду. В настоящий момент ADO только создается, хотя уже сейчас очевидно, что он унаследует всю мощь RDO 2.0. А появления полноценной версии следует ожидать в течение нескольких ближайших кварталов.
Таким образом, если вы заняты проектированием новой системы, проанализируйте текущую версию ADO на предмет его пригодности, и если это возможно - работайте с ним. Если же нет - в вашем распоряжении RDO для любых реляционных источников данных или DAO для ISAM типов данных.
Использованные источники
1. Браун С. “Мозаика” и “Всемирная паутина” для доступа к Internet: Пер. c англ. - М.: Мир: Малип: СК Пресс, 1996. - 167c.
2. Гайкович В., Першин А. Микрософт: решения 98. - М.: "Единая Европа", 1998. - 264 c.
3. Гилстер П. Новый навигатор Internet: Пер с англ. -Киев: Диалектика, 1996. - 495 c.
4. www.microsoft.com