MIDAS 3: новые возможности
Создание серверов доступа к данным: что нового
Создание MIDAS-клиентов: что нового
Создание MIDAS-клиентов, представляющих собой CGI/ISAPI-приложения. Использование XML
Изменения в поставке серверов и клиентов
Технология MIDAS предназначена для организации распределенной обработки данных на основе COM и автоматизации. Впервые появившаяся вместе с Delphi 3 и получившая свое дальнейшее развитие в последующих версиях, она в последние два года приобрела большую популярность.
Настоящая статья посвящена нововведениям и изменениям, произошедшим в этой технологии с появлением MIDAS 3 — составной части Delphi 5 Enterprise.
Коротко о MIDAS
Читатели, уже знакомые с данной технологией, могут пропустить эту вводную часть.
MIDAS (Multi-tier Application Server Suite) представляет собой технологию создания распределенных систем, состоящих из сервера баз данных, сервера доступа к данным (который, в свою очередь, является клиентом сервера баз данных) и так называемого тонкого клиентского приложения, являющегося, соответственно, клиентом сервера доступа к данным (рис. 1).
Фактически два последних звена делят между собой функциональность, характерную для клиентского приложения, используемого в «классических» двухзвенных клиент-серверных системах. «Тонкий» клиент обычно является приложением, с которым работает конечный пользователь, и поэтому предназначен главным образом для предоставления пользовательского интерфейса (то есть тех форм и интерфейсных элементов, с помощью которых пользователь редактирует данные). Естественно, подобное приложение должно «знать», на каком компьютере локальной или глобальной сети находится сервер доступа к данным, каково имя (или иной идентификатор) предоставляемого им сервиса и с помощью каких средств (имеются в виду сервисы операционной системы, сетевые протоколы и т.д.) с ним можно этими данными обмениваться. Это и есть те немногочисленные параметры, которые требуют настройки.
Что касается сервера доступа к данным, то обычно он недоступен конечным пользователям, и поэтому хотя у него может быть пользовательский интерфейс в традиционном понимании (формы, кнопки, поля для ввода данных), но не обязательно. Иными словами, сервер доступа к данным может представлять собой как обычное Windows-приложение с формами, так и приложение без форм, а также консольное приложение либо сервис операционной системы, пишущий сообщения для администратора системы в log-файл. Его задача — обмениваться данными с «тонким» клиентом и обращаться к серверу баз данных с собственными запросами (обычно инициированными этим обменом). Поэтому сервер доступа к данным должен, с одной стороны, предоставлять клиентам интерфейсы, позволяющие получать от него данные, а с другой стороны, быть полноценным клиентом сервера баз данных, то есть содержащий его компьютер должен иметь как минимум установленную клиентскую часть серверной СУБД. Нередко такой компьютер имеет и другие библиотеки доступа к данным, например, в прежних двух версиях MIDAS обязательной составляющей его частью была библиотека Borland Database Engine. В текущей версии MIDAS могут быть использованы и другие библиотеки, например библиотеки ADO (или исключительно те библиотеки, что содержат клиентский API и поставляются с сервером баз данных).
MIDAS-сервер доступа к данным может быть или COM-, или CORBA-сервером. И COM и CORBA имеют ограниченный набор передаваемых от клиента к серверу и обратно типов данных, который они поддерживают. Если не вдаваться в детали, обе технологии позволяют упаковывать в «пакеты» и передавать числа, строки, а также базирующиеся на них другие типы данных (варианты, CORBA Any и т.д.). В любом случае передача таких сложных типов, как набор данных (то есть результат SQL-запроса или часть таблицы базы данных) с непредсказуемым набором столбцов и числом строк, этими технологиями не предусмотрена. Поэтому с технологической точки зрения MIDAS есть реализованная в ряде компонентов VCL надстройка над COM или CORBA, осуществляющая превращение набора данных в тип, допустимый для COM или CORBA, передачу таких данных обычным для COM или CORBA способом и обратное восстановление набора данных на стороне, эти данные получающей. Лицензионная точка зрения на MIDAS в случае MIDAS 2 практически совпадает с технологической: оплате подлежит возможность передавать наборы данных с одного компьютера на другой; существенная разница заключается лишь в том, что в пределах одного компьютера данные можно передавать, не покупая лицензий. Отметим, однако, что в случае MIDAS 1 (версия, входившая в качестве MIDAS Development Kit в Delphi 3) лицензированию подлежал многопользовательский доступ к BDE.
Что касается иных лицензий, то использование собственно COM как технологии лицензированию не подлежит (иными словами, за применение COM уже было заплачено при приобретении Windows), а вот за использование CORBA как технологии полагается платить, приобретя одну из ее реализаций (например, VisiBroker), в соответствии с правилами ее лицензирования.
Справедливости ради надо отметить, что никто не запрещает создавать собственную реализацию преобразования набора данных в тип, воспринимаемый COM или CORBA, и аналогичного обратного преобразования. Пример подобной реализации для COM был приведен Чарльзом Калвертом в его книге «C++Builder Unleashed» (SAMS Publishing, 1997; русский перевод был выпущен в том же году издательством «ДиаСофт» под названием «C++Builder: энциклопедия пользователя»). Но, уверяю вас, он отнюдь не вдохновляет на «подвиги» — просто в то время MIDAS как продукт еще не существовал…
Вспомнив, что представляет собой MIDAS и как он лицензируется, вернемся наконец к обсуждению новых возможностей MIDAS 3 (а также новых интерфейсов, компонентов, свойств и событий, их реализующих).
Создание серверов доступа к данным: что нового
Следует сразу же отметить, что изменения в MIDAS привели к тому, что ранее созданные MIDAS-серверы и клиенты могут потребовать небольшой модернизации вследствие того, что некоторые интерфейсы, компоненты и библиотеки были выведены из употребления. Например, вместо интерфейса IProvider используется интерфейс IAppServer, вместо dbclient.dll — midas.dll; компонент TProvider также больше не используется. Впрочем, в документации Delphi 5 подробно описано, как следует модернизировать ранее созданные приложения, — в действительности это не очень сложный процесс.
Поддержка объектов, не хранящих состояния
Первое, на что следует обратить внимание в MIDAS 3, — это отсутствие интерфейса IProvider, который обычно экспортировался из удаленного модуля данных и с помощью которого клиент мог обращаться к содержащимся в удаленном модуле данных компонентам TDBDataSet. Наличие такого интерфейса при всей его привлекательности имело один серьезный недостаток: его применение приводило к тому, что модуль данных оказывался COM-объектом, хранящим состояние (stateful object). Это означало, что подобный объект, будучи создан в памяти сервера, должен содержать данные, связанные с конкретным обслуживаемым им клиентом (например, содержимое открытых таблиц, положение указателя текущей записи, сведения о том, сколько записей из набора данных было отправлено клиенту, и т.д.), даже если в данный момент клиент к серверу не обращается. А из этого следует, что такой сервер требует немалого количества ресурсов, часть из которых расходуется впустую.
В прежней версии MIDAS можно было описать удаленный модуль данных, указав, что он может создаваться в режиме Multiple Instance или Single Instance. В первом случае внутри одного процесса можно было создавать сколько угодно таких объектов, но обслуживались они по очереди, так как данное приложение было однопоточным. Поэтому производительность сервера была невысока. Во втором случае каждый клиент инициировал запуск на сервере отдельного процесса, что требовало большего количества ресурсов. Кроме того, в удаленных модулях данных MIDAS 1 и MIDAS 2 можно было использовать только компоненты — потомки TBDEDataset, а BDE поддерживает не более 48 процессов.
Альтернативой объектам, хранящим состояние, являются так называемые stateless objects — объекты, не хранящие состояния. После обмена данными с одним клиентом такой объект может быть использован другими клиентами, что позволяет «обобществлять» объекты, либо создавая соответствующий код, либо применяя средства, обеспечивающие такое коллективное использование объектов (object pooling), например Microsoft Transaction Server. В результате обычно требуется существенно меньше подобных объектов, чем в предыдущих двух случаях. Иными словами, поддержка возможности «обобществления» серверных объектов решает многие проблемы, связанные с производительностью и ресурсами сервера.
В MIDAS 3 альтернативой использования интерфейса IProvider является использование нового интерфейса IAppServer. Несмотря на то что он имеет много общего с вышедшим из употребления интерфейсом IProvider, он в силу особенностей своей реализации позволяет создавать модули данных, не хранящие состояния, — эта информация может теперь храниться в клиентском приложении. Если требуется сделать такой модуль данных обобществляемым, то можно вызвать его метод RegisterPooled.
Справедливости ради надо заметить, что удаленные модули данных, не хранящие состояния, можно было создавать и в предыдущих версиях MIDAS, однако при этом не использовался экспорт интерфейса IProvider — вместо этого создавались методы для передачи данных, изменения данных и т.д., что приводило к необходимости написания немалого количества кода.
Поддержка всех потомков TDBDataSet
В MIDAS 3 из употребления выведен и компонент TProvider. Для совместимости с ранее созданными серверами он оставлен в VCL, но отсутствует в палитре компонентов. Причиной выведения этого компонента из употребления стало введение нового интерфейса IProviderSupport, который предоставляет все методы, необходимые для доступа к потомкам TDBDataSet из клиентского приложения, и реализован в TDBDataSet и его потомках.
Вместо TProvider теперь используется компонент TDataSetProvider, свойство Exported которого можно теперь устанавливать равным True, что позволяет с помощью интерфейса IAppServer получить доступ к набору данных, с которым связан этот компонент.
Компонент TDataSetProvider в новой версии MIDAS (в отличие от прежней версии) может предоставлять доступ к любым потомкам TDBDataSet (вследствие поддержки ими интерфейса IProviderSupport). Это, в свою очередь, позволяет использовать в удаленном модуле данных любые компоненты доступа к данным, являющиеся наследниками данного класса (например, компоненты со страниц ADO и Interbase), и тем самым исключить обязательность использования BDE при создании MIDAS-серверов.
Новые свойства TDataSetProvider
В MIDAS 3 список вложенных свойств Options компонента TDataSetProvider существенно расширен по сравнению с предыдущей версией. Рассмотрим некоторые наиболее интересные из них. Нередко MIDAS-серверы помимо доступа к данным обладают и другими возможностями, позволяющими реализовывать те или иные бизнес-правила или просто выполнять какие-то действия (в том числе и изменять данные). Изменение данных мог осуществлять и сервер баз данных (например, при использовании автоматической генерации первичных ключей, выполнении триггеров и хранимых процедур и т.д.). В прежних версиях MIDAS об изменении данных клиент мог узнать, только перечитав с сервера все содержимое соответствующего компонента TClientDataset. В MIDAS 3 можно установить значение свойства Options компонента TDatasetProvider равным poPropagateChanges, и все изменения, происходящие на сервере, будут автоматически передаваться клиентам в их компоненты TClientDataset.
Помимо этого у данного компонента имеются свойства Options.poDisableEdits, Options.poDisableInserts, Options.poDisableDeletes, с помощью которых можно запретить вносить соответствующие изменения в компоненте TClientDataset, что, в свою очередь, позволяет централизовать на сервере доступа к данным правила редактирования данных.
Кроме того, TDataSetProvider может сохранять изменения непосредственно на сервере баз данных (а не только в наборе данных). Свойство Options.poAllowCommandText просто позволяет получить от клиента SQL-запрос в виде текста и выполнять его — соответствующий метод уже реализован в этом компоненте (в прежних версиях подобный метод приходилось создавать вручную).
Таким образом, компонент TDataSetProvider обладает теперь помимо набора характерных для данного компонента функций всеми возможностями прежнего компонента TProvider, в результате чего последний оставлен в VCL только для совместимости и отсутствует в палитре компонентов.
Как создать сервер доступа к данным с помощью MIDAS 3
Чтобы проиллюстрировать некоторые из новых возможностей, создадим простейший сервер доступа к данным с помощью MIDAS 3. Для этого нам потребуется какая-нибудь СУБД (в данном примере используется база данных DBDEMOS из комплекта поставки Delphi 5). Создадим новый проект, уменьшим размер его главной формы, поместим ее где-нибудь в углу экрана и установим свойство FormStyle равным fsStayOnTop, чтобы не потерять ее среди других открытых окон.
Затем создадим удаленный модуль данных, выбрав пиктограмму Remote Data Module со страницы Multitier репозитария объектов. В результате на экране появится редактор модулей данных, на который можно поместить два компонента TTable. Компоненты Table1 и Table2 свяжем с таблицами clients.dbf и holdings.dbf из базы данных DBDEMOS. Можно также создать для них некоторое количество компонентов TFields.
Все вышеописанное производится точно так же, как и в предыдущей версии MIDAS.
Теперь поместим в удаленный модуль данных один компонент TDataSetProvider (в прежней версии нужно было использовать компонент TProvider или экспортировать таблицы в интерфейс сервера).
Новый редактор модулей данных, безусловно, представляет собой одно из наиболее приятных средств визуализации разработки приложений. Если переключиться на его страницу Data Diagram, то методом drag-and-drop можно перетащить на нее компоненты из древовидного списка в левой части редактора модулей данных. В результате получим изображение, напоминающее диаграмму «сущность-связь», обычно изображаемую при проектировании данных с помощью CASE-средств. Выбрав на панели инструментов в левой части этой страницы пиктограмму Master-Detail, соединим две таблицы (так же, как это делается в CASE-средствах), и на экране появится стандартный диалог для выбора связанных полей таблиц (рис. 2).
Выбрав общее для двух таблиц поле (в данном случае ACCT_NBR), можем убедиться, что на странице Components и в списке компонентов появился компонент TDataSource и все свойства компонентов, реализующие связь, установлены корректно. Отметим, однако, что, хотя возможность такого визуального связывания таблиц является весьма удобным качеством, она является не особенностью MIDAS, а свойством самой среды разработки (рис. 3).
Выбрав на той же инструментальной панели пиктограмму Property, свяжем компонент TDataSetProvider1 c компонентом Table1 и установим его свойство Exported равным True (в прежней версии следовало выбирать из контекстного меню опцию экспорта компонента TProvider или потомка TBDEDataSet).
Теперь можно сохранить проект, скомпилировать его и запустить приложение, которое, будучи COM-сервером, зарегистрируется в реестре.
Как видим, процесс создания сервера доступа к данным остался таким же простым, как и в предыдущей версии, практически не претерпев никаких изменений.
Создание MIDAS-клиентов: что нового
Прежде чем создать клиентское приложение, рассмотрим, что нового предлагается для этого в MIDAS 3. Заметим сразу же, что процесс создания простейшего MIDAS-клиента в виде Windows-приложения или элемента управления ActiveX абсолютно не претерпел изменений (за исключением того, что трансформировался набор доступных компонентов, осуществляющих соединение), поэтому данный процесс здесь детально не описывается. Что же касается нестандартных типов клиентских приложений — об этом мы расскажем чуть позже.
Изменения в TSocketConnection
Компонент TSocketConnection приобрел новое свойство SupportsCallbacks. Если установить это свойство равным False, можно не заботиться об установке WinSock 2— когда клиент выполняется под управлением Windows 95.
Еще одно свойство связано с расширенными возможностями обеспечения безопасности. В принципе компонент TSocketConnection позволяет удаленно запускать любые серверы автоматизации, если на содержащем их компьютере запущено приложение Borland Socket Server. Теперь же можно добавлять в реестр сведения о том, разрешен ли удаленный запуск данного сервера с помощью данного протокола (что производится путем внесения изменений в метод UpdateRegistry удаленного модуля данных, генерируемый при его разработке, с помощью функций EnableSocketTransport и DisableSocketTransport), а при запуске Borland Socket Server включить в его меню опцию Registered Objects Only.
Поддержка протокола HTTP. Компонент TWebConnection
Помимо поддерживаемых ранее средств доступа к серверам, базирующихся на DCOM, CORBA и применении сокетов, Delphi 5 предоставляет возможность использовать протокол HTTP (для этой цели предназначен новый компонент TWebConnection — наследник TSocketConnection). Это означает, что при соединении с сервером можно использовать брандмауэры и SSL (Secure Sockets Layer — протокол, гарантирующий безопасную передачу данных по сети, комбинирующий криптографическую систему с открытым ключом и блочное шифрование данных), а также применять организацию пула ресурсов (resource pooling).
Использование протокола HTTP в качестве способа передачи данных в MIDAS обладает еще одним весьма существенным преимуществом при использовании кластеризации серверов, возможной в некоторых будущих версиях Windows NT. Это позволит обеспечить баланс загрузки серверов доступа к данным и устойчивость к сбоям исключительно средствами операционной системы — не нуждаясь в приобретении специальных средств, обеспечивающих подобную возможность.
Отметим, что в комплект поставки Delphi входит специальная ISAPI-библиотека httpsrvr.dll, предназначенная для превращения данных, передаваемых по протоколу HTTP, в данные, передаваемые с помощью MIDAS, и наоборот. Ее следует помещать в каталог, который предназначен для хранения исполняемых файлов Web-сервера.
При использовании этого компонента, так же как и при использовании TSocketConnection, можно указать в реестре Windows, доступен ли конкретный сервер автоматизации для удаленного доступа с помощью протокола HTTP. Это производится с помощью функций EnableWebTransport и DisableWebTransport.
О других компонентах, предназначенных для осуществления соединения с сервером
В палитре компонентов теперь отсутствуют компоненты TOLEnterpriseConnection, TMidasConnection, TRemoteServer. Они оставлены в VCL для совместимости с ранее созданными приложениями. Вместо них рекомендуется использовать компоненты TDCOMConnection, TSocketConnection или TWebConnection в зависимости от того, какой способ доступа к серверу применяется в клиентском приложении.
Изменения в TClientDataSet
Как было сказано выше, запретить выполнение тех или иных операций редактирования в компоненте TClientDataSet наиболее удобно в серверном приложении — посредством использования соответствующих свойств компонента TDatasetProvider.
Как мы говорили ранее, в MIDAS 3 можно заставить сервер доступа к данным выполнить SQL-запрос (в том числе запрос, не возвращающий набор данных). Для этой цели помимо установки соответствующих свойств компонента TDatasetProvider следует просто поместить текст запроса в свойство CommandText компонента TClientDataset и выполнить метод Execute. Параметры запроса можно передать, воспользовавшись свойством Params.
При выполнении хранимых процедур их выходные параметры теперь передаются в клиентское приложение автоматически, поэтому принудительный вызов метода FetchParams больше не требуется. Метод SendParams компонента TClientDataSet здесь также отсутствует.
Помимо этого список событий компонента TClientDataSet пополнился новыми событиями вида BeforeXXX и AfterXXX (BeforeApplyUpdates, AfterApplyUpdates, BeforeGetRecords, AfterGetRecords и др.). Эти события предоставляют возможность более гибко управлять данными, передаваемыми на сервер, а также обеспечивают хранение сведений о состоянии данных, связанных с конкретным клиентом, в самом клиентском приложении, позволяя тем самым снять необходимость их хранения в удаленном модуле данных (полезность подобного подхода уже обсуждалась выше).
Свойства HasProvider и Provider переименованы в HasAppServer и AppServer соответственно.
Создание MIDAS-клиентов, представляющих собой CGI/ISAPI-приложения. Использование XML
Говоря о MIDAS, нельзя не упомянуть поддержку MIDAS-клиентов в виде Web-приложений (ISAPI dll или CGI-скриптов). Конечное пользовательское приложение в этом случае представляет собой Web-браузер. В этом случае информационная система по существу становится четырехзвенной (рис. 4).
По сравнению с традиционными Web-приложениями для работы с данными, представляющими собой полноценное клиентское приложение для работы с сервером баз данных, использование «тонких» MIDAS-клиентов имеет существенное преимущество. Дело в том, что Web-приложения нередко обслуживают непредсказуемое число клиентов одновременно, поэтому вопрос уменьшения количества потребляемых ресурсов (а их расходуют и клиентские библиотеки, и BDE, и ADO, и иные средства доступа к данным) в этом случае стоит более остро, чем при использовании обычных Windows-клиентов в локальной сети.
Справедливости ради следует отметить, что приложения подобного вида можно было создавать и в прежних версиях MIDAS, но добиться того, чтобы с точки зрения функциональности они были аналогичны Windows-клиентам, было весьма непросто. В MIDAS 3 процесс создания таких клиентов заметно упрощен.
Компоненты InternetExpress
Поддержка MIDAS-клиентов в виде Web-приложений (Web MIDAS clients) реализована посредством компонентов InternetExpress, содержащих компоненты TXMLBroker и TMIDASPageProducer. Подобные приложения генерируют вместо вариантных массивов XML-код (XML расшифровывается как Extensible Markup Language), который интерпретируется несколькими библиотеками JavaScript (поставляемыми вместе с Web-приложением и включенными для этой цели в комплект поставки Delphi 5). Конечное пользовательское приложение в этом случае представляет собой Web-браузер, поддерживающий JavaScript.
Компонент TXMLBroker предназначен для получения данных с сервера доступа к данным с помощью интерфейса IAppServer и обработки HTTP-данных, получаемых от Web-браузеров, для передачи их серверу доступа к данным. Иными словами, данные, поставляемые компонентом TDataSetProvider, он представляет в виде XML-кода. Он автоматически получает все входящие HTTP-данные, поэтому создание объектов TWebAction для этой цели не требуется. Эта особенность данного компонента используется при передаче серверу доступа к данным результатов их редактирования в браузере.
Назначение компонента TMidasPageProducer — генерировать HTML-содержимое для представления в браузере, используя XML-код, полученный с помощью компонента TXMLBroker.
Как создать четырехзвенную информационную систему
Чтобы создать клиентское приложение в виде CGI-скрипта или ISAPI dll, нужно создать обычное Web-приложение, выбрав соответствующую пиктограмму на странице New репозитария объектов Delphi 5. Затем следует поместить в полученный модуль данных (объект TWebModule) компонент для установки соединения с сервером (например, TDCOMConnection, TSocketConnection и др.). Потом нужно установить его свойство ServerName равным строке вида <имя приложения>.<имя COM-объекта>. После этого нужно поместить в модуль данных компонент TXMLBroker и установить его свойство RemoteServer равным имени компонента для установки соединения с сервером (можно сделать это в редакторе модулей данных, выбрав кнопку Property на инструментальной панели страницы Data Diagram).
Теперь поместим в модуль данных компонент TMidasPageProducer. Далее следует установить значение свойства IncludePathURL этого компонента. Он должен указывать на доступный в Internet URL, где будущее Web-приложение сможет найти библиотеки JavaScript и HTML-файлы, которые будут использованы для генерации HTML-документов. Эти файлы следует скопировать из каталога Delphi5\Source\Webmidas в соответствующий каталог в Сети.
Следует обратить внимание на то, что каталог Inetpub\Scripts, являющийся по умолчанию каталогом для хранения исполняемых файлов, используемых Microsoft Internet Information Server, и, следовательно, потенциальным местоположением нашего будущего Web-приложения, — не самое лучшее место для размещения этих файлов. Дело в том, что при использовании установок по умолчанию файлы из этого каталога можно выполнять, но они не доступны для чтения ни внешним пользователям, ни самому Web-приложению. Поэтому следует либо изменить установки по умолчанию для этого каталога, разрешив чтение содержащихся в нем файлов, либо, что представляется более оправданным с точки зрения безопасности, выбрать для них другое местоположение.
Теперь можно из контекстного меню компонента TMidasPageProducer выбрать опцию Web Page Editor. На экране появится весьма удобный редактор свойств этого компонента, позволяющий увидеть, из каких объектов состоит и как будет выглядеть окончательный пользовательский интерфейс.
Теперь можно сформировать список интерфейсных элементов, выбирая опцию New из контекстного меню MidasPageProducer1 (или иных интерфейсных элементов, которые могут в результате этого появиться) в левой верхней части редактора свойств (рис. 5).
У получившихся интерфейсных элементов можно менять свойства, пользуясь инспектором объектов. Например, для отображения созданной на сервере связи Master-Detail нужно установить значение свойства XMLDataSetField компонента DataGrid2 равным Table2. Можно также изменить надписи на кнопках, цвета в объектах DataGrid и т.д. В результате получим примерно то, что изображено на рис. 6.
Наконец, мы можем создать компонент TWebActionItem и установить его свойство Producer равным MidasPageProducer1, а свойство Default равным True. Теперь наше Web-приложение можно скомпилировать, поместить в каталог, предназначенный для хранения исполняемых файлов Web-сервера, и попробовать обратиться к нему с помощью браузера (рис. 7).
Отметим, что компонент TXMLBroker обладает свойством ReconcileProducer, позволяющим указать компонент — потомок TPageProducer в качестве источника того HTML- или XML-кода, который следует выводить пользователю в браузер при возникновении коллизий, связанных с тем, что обновляемая запись за время редактирования была изменена другим пользователем. В комплекте поставки Delphi 5 в каталоге Demos\MIDAS\InternetExpress\InetXCustom имеется пример класса TReconcilePageProducer, который несложно превратить в компонент, добавив процедуру регистрации вида
procedure Register; begin RegisterComponents(‘InternetExpress’,[TReconcilePageProducer]); end;
Этот компонент можно установить в палитру компонентов и использовать в приложении, исправив некоторые значения его свойств (можно, кроме того, создать для этих целей свой собственный компонент либо изменить свойства одного из имеющихся в палитре «штатных» наследников TPageProducer). Пример использования этого компонента в приложении (Web-страница, соответствующая ReconcileErrorDialog обычного Windows-приложения) представлен на рис. 8.
Отметим, что компоненты InternetExpress можно также применять и при создании Web-приложений, являющихся клиентами серверов баз данных, так как компонент TDataSetProvider можно использовать и в таком приложении.
Изменения в поставке серверов и клиентов
Поставка серверов и клиентов претерпела несущественные изменения по сравнению с предыдущей версией MIDAS.
Во-первых, поскольку интерфейс IProvider больше не применяется, нет необходимости включать в комплект поставки сервера библиотеку STDVCL50.DLL (или STDVCL30.DLL, STDVCL40.DLL и др.).
Во-вторых, вместо поставляемой с клиентским и серверным приложениями библиотеки DBCLIENT.DLL теперь используется библиотека MIDAS.DLL. Хотя эта библиотека регистрируется как COM-сервер и содержит COM-объекты, взаимодействие с ней происходит без использования COM, что исключает диагностические сообщения о том, что не была вызвана функция CoInitialize.
При поставке WebMIDAS-клиентов следует, как было сказано выше, позаботиться не только о MIDAS.DLL, но и о библиотеках JavaScript, необходимых для выполнения Web-приложения, а также о том, доступны ли они для чтения этому приложению.
И, наконец (об этом уже говорилось ранее), включать библиотеку BDE в комплект поставки MIDAS-сервера следует теперь только в том случае, если он использует компоненты доступа к данным, являющиеся наследниками TBDEDataSet. Однако при использовании других компонентов доступа к данным следует позаботиться о включении иных необходимых для них библиотек (например, Microsoft Data Access Components и др.).
В заключение хотелось бы отметить, что в целом с появлением Delphi 5 и MIDAS 3 разработчики распределенных систем приобрели много новых возможностей, связанных с использованием протоколов передачи данных и средств безопасности, с повышением производительности и со снижением ресурсоемкости серверных приложений, а также с созданием Web-приложений, использующих преимущества как MIDAS, так и XML. Это позволяет создавать информационные системы, отвечающие самым современным требованиям (и самым причудливым запросам наиболее капризных заказчиков).
КомпьютерПресс 1'2000