Borland MIDAS - средство надежной и эффективной эксплуатации многозвенных информационных систем
Наталия Елманова, Центр Инфомационных Технологий
MIDAS (Multi-tier Distributed Application Services Suite) новый продукт компании Borland International, предназначенный для эксплуатации серверов приложений, расширяющий возможности, предоставляемые технологией Microsoft DCOM (Distributed Component Object Model). Этот продукт позволяет использовать при построении информационных систем трехзвенную архитектуру с "тонким" клиентом и, что более важно, обеспечить высокую производительность, надежность и защиту от сбоев при эксплуатации подобных систем.
Архитектура трехзвенной информационной системы, построенной с использованием MIDAS, представлена на рис.1.
Рис.1. Архитектура трехзвенной информационной системы с использованием MIDAS.
Рассмотрим, что представляют собой технологии, используемые в MIDAS.
Remote Data Broker позволяет создавать распределенные трехзвенные информационные системы, состоящие из серверной СУБД, среднего звена и "тонкого" клиента, при этом среднее звено может в общем случае состоять из нескольких серверов приложений и функционировать на нескольких компьютерах. Заметим, что "тонкий" клиент представляет собой приложение, не содержащее бизнес-правил, а лишь предоставляющее интерфейс пользователя, и по этой причине не требующее почти никаких дополнительных библиотек (кроме dbclient.dll размером 140 K), используемых обычными "толстыми" клиентами для доступа к данным (таких, как Borland Database Engine и клиентская часть серверных СУБД) и, соответственно, практически не нуждающееся в соответствующей настройке. Типичным примером такого клиентского приложения является исполняемая в Web-броузере форма ActiveX (созданная с помощью Delphi 3), содержащая интерфейсные элементы для отображения и редактирования данных, вся процедура инсталляции и настройки которого заключается в загрузке соответствующей Web-страницы из Internet или локальной сети.
Источником данных для "тонкого" клиента является сервер приложений, получающий от клиента запросы на выборку или изменение данных.
При получении такого запроса сервер приложений обращается к серверу баз данных, клиентом которого он является, со своим собственным запросом. Получив от сервера результат выполнения собственного запроса, сервер приложений передает данные клиенту.
Как только клиент получает набор данных от сервера приложений, этот набор может быть использован компонентом TClientDataset, который, наряду с компонентами TRemoteServer или TMidasConnection (появившимся в Delphi 3.01 и обладающим по сравнению TRemoteServer большей функциональностью, в частности, возможностью выбора способа доступа к серверу), а также поддерживающей их функционирование библиотекой dbclient.dll, составляет клиентскую часть Remote DataBroker.
Компонент TClientDataSet предназначен для хранения данных, полученных от сервера приложений, в кэше клиента, и, будучи потомком компонента TDataSet, обладает, подобно компонентам TTable и TQuery, как навигационными методами, так и методами, осуществляющими редактирование данных. Кроме того, этот компонент обладает методами SaveToFile и LoadFromFile, позволяющими сохранять данные из кэша в файле и восстанавливать их оттуда, реализуя так называемую "briefcase model" - модель обработки данных, основанную на том, что "тонкий" клиент осуществляет редактирование данных по большей части при отсутствии соединения с сервером, используя лишь кэш или локальные внешние устройства, и лишь иногда соединяется с сервером приложений для передачи ему измененных данных с целью дальнейшей обработки.
Отметим также, что Remote DataBroker предоставляет широкие возможности для решения характерных для многопользовательского доступа к данным проблем, связанных с попытками одновременного редактирования несколькими пользователями одних и тех же данных. Отметим, что в данном случае механизм блокировок, используемый в традиционной двухзвенной модели "клиент/сервер", может оказаться неэффективным или даже неприемлемым, так как промежуток времени между редактированием записи и сохранением ее в базе данных может быть весьма длительным.
Поэтому при попытке сохранения сервером приложений измененной записи в базе данных производится поиск изменяемой записи либо по ключевому полю, либо по всем полям в зависимости от значения свойства UpdateMode ответственного за этот процесс компонента TDBDataSet на сервере приложений и сравнение всех полей изменяемой записи с исходными значениями (т.е. теми, которые были в кэше клиента на момент получения этой записи с сервера до того, как пользователь изменил в кэше эту запись). Если какие-либо поля за время между получением оригинала записи клиентом и попыткой сохранить изменения были модифицированы другим пользователем, запись может быть передана обратно в клиентское приложение для дальнейшей обработки пользователем.
Отметим также, что удаленные модули данных (объекты Remote Data Module), входящие в состав серверной части Remote DataBroker и содержащие компоненты TDBDataSet, позволяют предоставить DCOM-интерфейс для соответствующих объектов, делая их управляемыми извне и превращая, таким образом, сервер приложений в DCOM-сервер. Осуществляется такая публикация объектов путем выбора опции экспорта из удаленного модуля данных из контекстного меню соответствующего компонента при разработке сервера приложений.
При использовании сервера приложений как DCOM-сервера требуется наличие в реестре компьютера, содержащего сервер приложений, соответствующего описания прав доступа к нему различных пользователей (или групп пользователей) сети, для чего требуется экспорт сведений о пользователях сети с первичного контроллера домена. При этом на тех компьютерах, где эксплуатируются клиентские приложения, требуется наличие в реестре описания сервера приложений с указанием, на каком конкретном компьютере сети этот сервер должен функционировать. Иными словами, при использовании технологии DCOM каждый клиент, нуждающийся в сервере приложений, может взаимодействовать только с одним конкретным компьютером, на котором имеется подобный сервер, сколько бы их ни было в сети. В этом случае информационная система не имеет никакой защиты от сбоев, связанных с перегрузкой сервера приложений или с его отказом по каким-либо иным причинам.
Использование Business ObjectBroker и OLEnterprise ( составной части MIDAS) позволяет решить подобную проблему (при этом несущественно, какое средство разработки использовалось для создания сервера приложений, лишь бы это был сервер OLE Automation).
Рис. 2. Состав OLEnterprise.
Business ObjectBroker осуществляет для "тонкого" клиента поиск нужного сервера приложений среди опубликованных (то есть доступных извне) частей реестров компьютеров сети (совокупность опубликованных частей реестров иногда называется глобальным реестром - global registry).
Приложение Object Factory, используемое сервером, является клиентом OLE Automation. Оно действует на сервере от имени удаленного клиента, "представляя" его путем воспроизведения его запросов. Со стороны клиента имеется соответствующий "представитель" удаленного сервера приложений - Object Agent, являющийся сервером OLE Automation. Получив запрос к удаленному серверу, Object Agent направляет его к Object Factory, используя механизм вызова удаленных процедур (RPC - Remote Procedure Call).
Рис.3. Object Explorer
Утилита Object Explorer (рис.3), входящая в состав OLEnterprise, позволяет просматривать локальный и глобальный реестры, а также осуществлять экспорт (публикацию) сведений об объектах из локального реестра в глобальный и импорт этих сведений из глобального реестра в локальный, осуществляя, таким образом, межреестровый обмен сведениями об удаленных серверах приложений в сети. Если в сети имеется несколько компьютеров, на которых установлен и зарегистрирован один и тот же сервер приложений, при запросе "тонкого" клиента Object Agent обратится к Business ObjectBroker за сведениями о местоположении сервера, а тот, в свою очередь, найдет для него в глобальном реестре один из этих компьютеров. После этого Object Agent обратится к Object Factory выбранного компьютера, инициируя создание экземпляра удаленного модуля данных на сервере приложений.
Каков принцип выбора одного сервера приложений из нескольких? В настоящее время сервер выбирается случайным образом среди компьютеров, доступных в сети.
В случае отказа одного из серверов для соединенных с ним клиентов, не получивших отклика от сервера, будет автоматически повторена процедура, описанная выше, и эти клиенты будут соединены с оставшимися серверами случайным образом без участия пользователя и незаметно для него. В настоящее время ведется разработка более эффективной технологии выбора сервера, использующей сведения о загрузке процессоров и сетевом трафике функционирующих в сети серверов, что позволит более равномерно распределять нагрузку между серверами.
Отметим также, что в глобальный реестр можно включать сведения об RPC-серверах, функционирующих не только в операционных системах Windows 95 и Windows NT, но и в других операционных системах.
Еще одной важной составляющей частью MIDAS является ConstraintBroker, предоставляющий возможность использовать бизнес-правила сервера баз данных "тонким" клиентом. Обычно при проектировании баз данных бизнес-правила и правила ссылочной целостности реализуются в виде объектов базы данных, таких как индексы, триггеры, хранимые процедуры. Такой подход к проектированию данных позволяет использовать эти объекты различными клиентскими приложениями без написания дополнительного кода.
В случае классической двухзвенной клиент-серверной информационной системы при изменении данных клиентское приложение пытается отправить измененную запись на сервер, а сервер, в свою очередь, пытается сохранить ее в базе данных, начав соответствующую транзакцию. Если запись не удовлетворяет условиям ссылочной целостности, определенным на сервере, производится откат транзакции, и сервер возвращает клиентскому приложению сообщение об ошибке, после чего пользователь должен будет скорректировать предназначенные для сохранения данные. Если подобные случаи происходят часто, это приводит к перегрузке сети и увеличению времени отклика сервера.
Чтобы уменьшить количество отправляемых на сервер некорректных записей, иногда часть бизнес-правил воспроизводят в клиентском приложении. В этом случае частичный контроль соответствия записи бизнес-правилам производится без обращения к серверу, но возможность отправки некорректной записи все же сохраняется, так как обычно код, содержащийся в хранимых процедурах и триггерах, в клиентских приложениях не воспроизводится.
Кроме того, при изменении бизнес- правил такое приложение требует внесения в него изменений, что влечет за собой трудозатраты, связанные с установкой и конфигурацией новой версии на рабочих станциях.
При использовании ConstrainBroker эта проблема решается по-другому. В этом случае RemoteDataBroker не только доставляет данные клиентскому приложению, но и обращается к словарю данных с целью получения ограничений сервера и передачи их клиенту. Соответственно при попытке передачи записи на сервер приложений анализ соответствия записи правилам сервера производится непосредственно в клиентском приложении без обращения к серверу баз данных и серверу приложений, что снижает загрузку серверов и сети. Отметим, что при изменении бизнес-правил следует внести соответствующие изменения в словарь данных, что можно сделать с помощью входящей в состав MIDAS утилиты SQL Explorer(рис.4), позволяющей вносить серверные ограничения, а также создавать и изменять таблицы, индексы, триггеры, хранимые процедуры, правила ссылочной целостности.
Рис.4. SQL Explorer
Таким образом, использование технологии MIDAS позволяет создавать многозвенные информационные системы с "тонким" клиентом, не нуждающимся в инсталляции и настройке, обеспечивая защиту от сбоев в работе серверов приложений, а также снижение загрузки серверов и сети за счет переноса бизнес-правил и серверных ограничений в клиентское приложение вместе с данными.
В заключение отметим, что разработка серверов приложений с помощью Delphi 3 может быть осуществлена с помощью trial-версии MIDAS, входящей в комплект поставки Delphi 3 Client/Server Suite и имеющей ограниченное число подключаемых клиентов и объектов, доступных Business ObjectBroker, а также ограничения на время работы ConstrainBroker. Однако эксплуатация серверов приложений требует обязательного наличия на компьютерах, содержащих серверы приложений, полной версии MIDAS (рис.5), не обладающей вышеперечисленными ограничениями.
Рис.5. Состав Borland MIDAS
Последнее обновление - 3 апреля 1998
Интеграция объектов
Некоторые мониторы транзакций могут эффективно работать с объектами. В этом отношении выделяется Microsoft Transaction Server (MTS). Продукт строго интегрирован с DCOM. По-существу, любой объект ActiveX может управляться и кэшироваться с помощью MTS. Это позволяет более просто осуществлять разделение объектов, поскольку существующие компоненты, построенные с помощью Visual Basic, или J++, могут быть легко приспособлены для управления сервером. MTS сохраняет "жизнеспособность" объектов для их повторного использования, устраняя потребность в постоянном создании объектов при запросе сервиса. По очевидным причинам MTS тесно привязан к , но надежность и низкая стоимость продукта делают его очень привлекательным. Компания Microsoft проделала отличную работу по интеграции Java и ActiveX - можно использовать все Java-объекты. Это облегчает интеграцию MTS в многоплатформенные среды.
В мире UNIX спецификация OMG Object Transaction Server (OTS) направлена на унификацию функций TP-мониторов при использовании брокеров объектных заявок. Это расширение протокола CORBA нашло отражение в спецификации Java Transaction Service компании JavaSoft. Коммерческий дебют этой спецификации состоялся в феврале с выпуском компанией Sybase продукта Jaguar Component Transaction Server.
Другим влиятельным стандартом, который необходимо учитывать при оценке TP-мониторов и серверов приложений, является Transation Architecture (XA), спецификация, разработанная компанией . XA определяет интерфейс между менеджером транзакций и используемыми им ресурсами, такими как системы баз данных и коммуникационные каналы. Большинство UNIX-ориентированных TP-мониторов и систем баз данных поддерживает этот стандарт. Поддержка на платформах Windows NT отстает, но MTS развивается в этом направлении.
Нужно также принимать во внимание коммуникационный протокол, используемый сервером приложений. Серверы, которые тесно привязаны к RPC (или DCOM в случае MTS), могут быть ограничены синхронной природой работы. Продукты, позволяющие использовать очереди сообщений, часто обладают большей гибкостью, особенно в случае ориентации на широкомасштабные сети. Например, в мониторе Encina может использоваться промежуточное программное обеспечение MQSeries компании IBM. Компания Microsoft намерена интегрировать MTS и Message Queuing Server в будущих версиях.
IPC и объекты
Протоколы и продукты этой категории облегчают межпроцессные взаимодействия (IPC - InterProcess Communications) и распределение объектов. Они выполняют роль клея, позволяющего соединить многозвенные приложения. В большинстве продуктов более высокого уровня, которые обсуждаются ниже, используется один или несколько таких протоколов. Ключевыми категориями являются следующие:
Вызовы удаленных процедур (RPC - Remote Procedure Call) и соответствующий Java-эквивалент, вызовы удаленных методов (RMI - Remote Method Invocation. Эти протоколы позволяют приложению вызывать функции и передавать параметры, минуя границы процессов и машин. Более распространены синхронные механизмы, т.е. каждая операция должны закончиться до начала следующей. Такие сервисы обеспечиваются операционной системой или языковой средой разработки. Обычно RPC базируются на инфрастуктуре распределенной вычислительной среды (DCE - Distributed Computing Environment). Системы передачи сообщений. В отличие от RPC такие системы, как правило, бывают асинхронными. Запросы сервисов ставятся в очередь и обрабатываются в соответствии с приоритетами и доступностью ресурсов. Возвращаемые ответы содержат информацию об успешном или неуспешном выполнении операции. Средства этой категории часто используются в приложениях, связанных с организацией потоков работ (workflow) и управлением процессами, а также в сильно распределенных приложениях с медленными и ненадежными соединениями. Распределенные объектные системы. Объектные системы обеспечивают средства размещения и взаимодействия объектов в распределенной среде. Объекты идентифицируются именами или сервисами, а также поддерживаемыми ими интерфейсами. Реализация объекта и платформа, на которой он выполняется, прозрачны для клиента.
В последней из перечисленных областей бушует война. При поверхостном взгляде видно сражение технологий Distributed COM и ActiveX компании Microsoft с технологиями CORBA и IIOP (Internet InterORB Protocol) консорциума и JavaBeans. При более глубоком рассмотрении эта битва отражает борьбу между открытостью, зрелостью и масштабируемостью и возрастающей силой . Итеропетабельность между этими стандартами достигается медленно.
Объекты - это реальная основа современных многозвенных приложений. Во всех обсуждаемых ниже продуктах более высокого уровня основным является управление объектами. Планирование стратегии предприятия в терминах объектов и компонентов позволит наилучшим образом применить эту быстро развивающуюся технологию.
MIDAS и создание серверов приложений: вопросы и ответы
Наталия Елманова, Центр Инфомационных Технологий
После выхода статьи от читателей и слушателей проводимых в Учебно-консалтинговом центре Interface Ltd. курсов, посвященных Delphi 3 и MIDAS, поступило большое количество вопросов, касающихся технических и организационных аспектов разработки и эксплуатации трехзвенных информационных систем с "тонким" клиентом. Данная статья посвящена особенностям и наиболее предпочтительным архитектурам построения подобных информационных систем в случае различных схем организации функционирования обслуживаемых ими предприятий, новым возможностям создания "тонких" клиентов, предоставляемым Delphi 3.01/3.02 и С++Builder 3.0, ответам на наиболее часто встречающиеся вопросы, а также наиболее распространенным ошибкам при создании серверов приложений и "тонких" клиентов.
Мониторы управления транзакциями
Интенсивное совместное использование ресурсов приводит к возникновению узкого места, затрудняющего выполнение работ. Многие ранние попытки использования архитектуры "клиент-сервер" в масштабах предприятия провалились в результате неадекватного управления ресурсом баз данных. Ранние эксперименты по использованию РСУБД для управления динамическим содержимым Web-страниц постигла та же судьба и по тем же причинам. Во многих случаях проблема не была связана с реальной обработкой операторов SQL. Неприятности возникали по причине отсутствия должного управления соединениями с базами данных и применения неэффективных методов хэширования.
Начиная с CICS (Customer Information Control System) компании , созданной в начале 1970-х, был разработан ряд систем для управления ресурсом баз данных и транзакциями. Успех этих продуктов демонстрируется тем, что лучшие 20 результатов, полученных на тестовом наборе (измеренных в числе транзакций в минуту 2 февраля 1998 г.), получены с примением технологии промежуточного программного обеспечения баз данных. При отборе на основе параметра цена/производительность в 18 из лучших 20 результатов использовались .
TP-мониторы получили развитие по следующим причинам:
Во многих организациях используется более чем одна система баз данных, и требуется возможность выполнять транзакции, пересекающие границы этих систем. Многие системы баз данных требуют наличия отдельного процесса операционной системы для каждого подключенного пользователя. Для приложений с сотнями пользователей не хватает мощности даже самых крупных компьютеров. Установление соединения с базой данных часто происходит медленно. Если много пользователей часто подключается и отключается, производительность системы серьезно деградирует.
Эти проблемы решаются в TP-мониторах следующим образом:
Обеспечивается одновременная связь с набором различных систем баз данных. Поддерживается двухфазный протокол фиксации, гарантирующий завершение транзакций над несколькими базами данных. Пользовательские запросы обрабатываются с использованием легковесных нитей (threads) операционной системы, а не полновесных процессов.
Это позволяет TP-мониторам использовать возможности SMP-систем (SMP - Symmetric MultiProcessor), таких как Sun Enterprise, Digital Alpha и Compaq Proliant. Поддерживается постоянный пул подключений к базам данных, и эти подключения разделяются между пользователями. В большинстве приложений каждый пользователь реально обращается к базе данных только часть общего времени. Часто сотни "одновременно работающих" пользователей могут быть эффективно обслужены за счет наличия одной трети или даже одной десятой от числа подключений к базе данных, требуемых для прямого доступа. Долговременное сохранение разделяемых подключений к базе данных существенно уменьшает трафик подключений. Обеспечивается балансировка нагрузки путем планирования использования разделяемых ресурсов и направления запросов к наименее загруженным серверам. Мониторы могут также обнаруживать и обрабатывать ситуации, когда сервер или другой ресурс выходит из строя и нуждается в перезапуске. Запросы обрабатываются асинхронно с распределением нескольких запросов к одному и тому же серверу между разными подключениями к базе данных (так называемый "конвейерный" параллелизм). Запросы заспределяются между несколькими серверами баз данных (так называемый "развернутый" параллелизм). Для координации операций разделенных и распределенных приложений поддерживается одноранговая связь с другими мониторами обработки транзакций.
Появление TP-мониторов породило ряд интересных вопросов по поводу лицензирования продуктов управления базами данных. Большинство поставщиков, включая , и , лицензирует свои продукты на основе числа подключений. Чем больше допускается одновременных подключений к базе данных, тем больше нужно платить. Но при использовании TP-монитора много пользователей может совместно использовать небольшое число подключений. Значит ли это, что можно купить лицензию на РСУБД по дешевке? Вероятно, нет, поскольку теперь основные поставщики принимают это во внимание и требуют платы на основе числа реальных пользовательских подключений, независимо от того, используется ли промежуточное программное обеспечение.
Это противоречие особенно неприятно для Web-приложений, с которыми часто работают миллионы пользователей. Во многих случаях взаимодействие этих пользователей с базой данных очень ограничено. Например, Web-сайт, в котором база данных используется только для регистрации пользователей, может нуждаться в пуле из десяти подключений для обслуживания всех возможных пользователей. Однако поставщик РСУБД скорее всего потребует приобретения лицензии для поддержки неограниченного числа пользователей. Для UNIX-систем стоимость таких лицензий может доходить до сотен тысяч долларов. Такая ценовая политика стимулирует перенос Web-приложений на Windows NT, и в ближайшие месяцы и годы это будет сильно влиять на выбор платформы поставщиками РСУБД.
На арене открытых систем в категории TP-мониторов лидирует Tuxedo компании . Вышедший из компании Novell в феврале 1996 г., этот надежный и зрелый продукт использовался примерно в 80% упоминавшихся выше результатах TPC-C. В 1997 г. продукт стал победителем конкурса журнала DBMS Readers' Choice на лучший монитор транзакций. Среди других продуктов этой категории следующие:
Encina компании (победитель конкурса DBMS 1996 г.) Продукты семейства Transaction Server компании IBM (включая CICS и Encina) ACMSxp компании Top End компании (распространяемый компаний ) Trnasaction Server компании Microsoft.
Некоторые другие вопросы
Посмотрел Вашу статью: . Очень понравилось. Не могли бы Вы уточнить, как вручную отредактировать реестр (какие ключи добавить или отредактировать), чтобы OLE-объект воспринимался не как локальный, а как удаленный? К сожалению, из статьи я этого не смог понять.
С уважением Алексей Гудков,
ОАО ИК "РИФ"
В принципе это делается с помощью утилиты DCOMCNFG (в Windows NT 4 она есть, а для Windows 95 можно найти и эту утилиту, и сам клиент DCOM на Web-сервере Microsoft). Но если осуществлять соединение клиента и сервера с помощью DCOM, сервер при этом не сможет работать под управлением Windows 95. Кроме того, требуется на странице Access Control раздела Network в Control Panel выбрать опцию User Level Access Control, что отличается от установок, принятых по умолчанию, а также экспортировать с первичного контроллера домена сведения о пользователях, а затем описать, кому из них Вы разрешаете этот сервер запускать. Естественно, в сети при этом обязательно должен быть первичный контроллер домена.
С помощью OLEnterprise (в частности, Object Explorer) все это сделать проще, так как в этом случае наличие первичного контроллера домена не обязательно, экспорт имен тоже не требуется, и сервер может работать под управлением Windows 95. Чтобы сервер воспринимался как удаленный, в раздел компьютера-сервера HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{<CLSID Вашего сервера>} добавляется подраздел OLEnterpriseExport, а в раздел компьютера-клиента HKEY_CLASSES_ROOT\CLSID\{<CLSID Вашего сервера> } добавляется раздел Dap\DCEClient\<имя выполняемого файла>.<имя OLE-сервера> c набором параметров, представленных на рис. 6.
Рис.6 Раздел Dap\DCEClient\ реестра клиента при импорте объекта
Уважаемая Наталия Елманова!
Прочитав Вашу статью, я попробовал создать приложение-сервер, и у меня возник вопрос - как установить связь master-detail в удаленном модуле данных без компонентов DataSource?
Буду очень вам признателен за ответ.
С уважением Денис Бокатый
Можно создать модифицируемый SQL-запрос к обеим таблицам, содержащий предложение WHERE, и поместить его в удаленный модуль данных вместо компонентов TTable. Кроме того, можно поместить компонент TDataSource, используемый для связи таблиц, в обычный модуль данных или на форму. Иногда также можно связь master/detail установить не на сервере приложений, а в клиенте (при небольших объемах таблиц это может быть даже выгоднее с точки зрения производительности). Отметим, что наиболее общепринятый способ установки такой связи подразумевает описание ее в словаре данных сервера приложений с помощью SQL Explorer (ConstraintBroker Manager), входящего в состав MIDAS, с целью передачи сведений о ней клиентскому приложению.
Здравствуйте, Наталия!
Большое спасибо Вам за внимание, которое Вы нам уделили. Ваши советы нам помогли.
...
Думаю, что было бы хорошо "обозреть" имеющиеся у пользователей Delphi средства для создания приложений для Internet, работающих с базами данных. По моему разумению, можно выделить три группы средств:
"Родные" средства Delphi с палитры компонентов Internet - позволяют работать с любым www-сервером под управлением Windows NT или Windows 95, но требуют знания HTML и неудобны при отладке приложений (может быт, ь в этом я и не прав, так как сам этот способ не реализовывал).
Разработка с использованием библиотек Baikonur от Epsylon Technologies - они замечательны, удобны в разработке и отладке, не требуют (не затрагивая сложных случаев) знания HTML , но необходима установка сервера Baikonur, что возможно, чаще всего, в корпоративной сети, а провайдеры неохотно идут на установку широко не известного (к сожалению) продукта.
Разработка с использованием ActiveForm и многозвеннных приложений - это очень удобно в разработке, отладке и сопровождении, не требуется (не затрагивая сложных случаев) знание HTML, но при работе в "медленном" Internet не каждый пользователь дождется окончания загрузки ActiveX. Думаю, что более подробный анализ этих средств поможет сориентироваться многим разработчикам на Delphi - ведь переход к переносу приложений в Internet, пожалуй, неизбежен.
С уважением, Михаил Шунин
начальник отдела программирования КИВЦ ОАО "Аэрофлот"
,
Разработка web-приложений, связанных с динамической генерацией HTML-страниц - это действительно интересная и важная тема, которой, по-видимому, будет посвящена одна из ближайших статей, посвященных продуктам Borland.
Что касается сервера Baikonur от Epsylon Technologies - это действительно интересный продукт, наглядно демонстрирующий, какие возможности предоставляют разработчикам технологии Borland, использованные при его создании. Нельзя не отметить, что этот продукт является, по существу, сервером приложений, предоставляющим возможность их визуально создавать. Своей технологической направленностью этот продукт заметно выделяется среди отечественных программных продуктов, ориентированных в основном на национальную российскую специфику (не секрет, что это главным образом бухгалтерские, финансовые и офисные приложения, юридические базы данных, игры, мультимедиа-энциклопедии, OCR, различные программы лингвистического назначения - достаточно посетить очередной SofTool, чтобы в этом убедиться). Остается только пожелать удачи компании Epsylon Technologies, разработавшей этот интересный продукт и надеяться на то, что авторы Baikonur смогут написать о нем и использованных при его создании технологиях более подробно.
Что касается использования ActiveForm и многозвенных приложений - я надеюсь, что настоящая статья в определенной степени выполняет это пожелание.
Несколько слов для пользователей C++Builder.
Все изложенное в данной статье (и в других статьях, посвященных серверам приложений и MIDAS) в равной степени (с точностью до написания кода, которого, по существу, не так уж и много) относится и к С++Builder 3.0. В новую версию C++Builder включена поддержка MIDAS на уровне компонентов (имеются компоненты TClientDataSet, TRemoteServer, TMidasConnection, TProvider), эксперты для создания удаленных модулей данных и ActiveX, и имеется MIDAS Development Kit для создания серверов приложений. Отличие от Delphi заключается в том, что для создания ActiveX используется библиотека Active Template Library (ATL), тогда как Delphi использует собственные средства создания ActiveX. Одновременная разработка сервера приложений и клиента в C++Builder осуществляется даже более просто, чем в Delphi, благодаря новым средствам управления проектами, позволяющим загрузить в среду разработки несколько проектов одновременно. Отметим также, что с помощью C++Builder Enterprise возможна разработка "тонких" клиентов для Borland Entera. Таким образом, C++Builder, наряду с Delphi 3, теперь является инструментом, позволяющим создавать серверы приложений и "тонкие" клиентские приложения, в том числе в виде выполняемых в web-броузере элементов ActiveX.
В заключение хотелось бы поблагодарить авторов многочисленных (как процитированных, так и многих других) писем, пришедших после публикации статьи о серверах приложений, свидетельствующих о том, что данная тема представляет определенный интерес для читателей.
Об удаленном клиенте с использованием DCOM
Об удаленном клиенте с использованием DCOM
В принципе можно использовать не OLEnterprise, а непосредственно технологию DCOM (Distributed Component Object Model) корпорации Microsoft. Не вдаваясь в теоретические подробности использования DCOM, отметим, что использование этой технологии для запуска серверов приложений возможно лишь при условии наличия первичного контроллера домена в сети и выбранной на рабочих станциях установки User Level Access Control на странице Access Control раздела Network панели управления Windows (это необходимо для переноса с контроллера домена списка пользователей для разрешения им доступа к серверу приложений). Помимо этого, сервер приложений может быть доступен для клиентских приложений, если только он выполняется под управлением Windows NT, но не Windows 95.
Отметим также, что сведения о сервере приложений должны быть в реестре клиента (этого можно добиться, например, путем запуска сервера приложений непосредственно на рабочей станции с ключом /regserver, если, конечно, ресурсы рабочей станции позволяют это сделать). После этого следует внести изменения в реестр так, чтобы зарегистрированный таким образом OLE-объект воспринимался не как локальный, а как удаленный объект. Это можно сделать как отредактировав реестр вручную, так и с помощью утилиты конфигурации DCOM, указав явно, на каком компьютере запускается сервер приложений (запустив эту утилиту на рабочей станции, содержащей клиентское приложение), и кто из пользователей имеет право его запускать (на компьютере, содержащем сервер приложений).
Примеры сервера и клиента, описанные в начале статьи, были выполнены и с использованием DCOM (без OLEnterprise). Характеристики использованных ПК для этого примера представлены в табл.2.
Таблица 2. Технические характеристики использованных ПК и ПО при соединении клиента и сервера приложений с помощью DCOM
| Сервер БД | Windows NT Server 4.0 + Oracle Workgroup Server 7.2 (Trial 90-day version) for Windows NT | Pentium-133/32 MB RAM |
| Сервер приложений | Windows Nt Server 4.0 | Pentium-133/32 MB RAM (это тот же самый ПК, на котором запущен сервер БД) |
| Клиенты 1,2,3 | Windows 95 | Pentium-120/16 MB RAM |
| |
Подготовка данных для сервера приложений
Подготовка данных для сервера приложений
Для создания сервера приложений нам потребуются какая-либо серверная СУБД, клиентом которой будет данный сервер приложений, и тестовые таблицы, которые будут перенесены на сервер баз данных. В рассмотренных в настоящей работе примерах используются Personal Oracle for Windows 95 и Oracle Workgroup Server 7.2 for Windows NT (90-дневные trial-версии), но не возбраняется использовать в качестве источника данных любую серверную СУБД (и, вообще говоря, даже набор таблиц dBase или Paradox).
Создадим нового пользователя Oracle с правами CONNECT и RESOURCE и от его имени перенесем c помощью утилиты Data Migration Wizard таблицы CLIENTS.DBF и HOLDINGS.DBF из базы данных DBDEMOS, входящей в комплект поставки Delphi 3, в базу данных Personal Oracle for Windows 95 или Oracle Workgroup Server 7.2 for Windows NT. После этого можно приступить к созданию простейшего сервера приложений, являющегося, с одной стороны, клиентом серверной СУБД, и, с другой стороны, сервером конечного пользовательского приложения, которое становится при этом так называемым "тонким" клиентом.
| |
Поставка серверов приложений
Если с поставкой "тонких" клиентов все более или менее ясно, то поставка серверов приложений и связанные с ней проблемы вызвали самый большой наплыв вопросов.
Нередко разработчики, создавшие сервер приложений и успешно протестировавшие его на компьютере, на котором производилась разработка, сталкиваются с трудностями при переносе этого сервера приложений на другой компьютер - он отказывается там выполняться либо работает некорректно. Вопросы по этому поводу обычно содержат описание проблемы и формулируются примерно следующим образом: "Что должно быть установлено на компьютере, на котором эксплуатируется сервер приложений?". Например, Георгий Буриков и Михаил Шунин из ВЦ ОАО "Аэрофлот-Российские Международные авиалинии" спрашивают в своем письме:
Мы пытаемся установить удаленное соединение с базой данных, используя компонент TMidasConnection. На серверной части (WindowsNT) работает серверное приложение - TProvider, TQuery и TDataBase в RemoteDataModule и главная форма, показывающая счетчик клиентов (аналог примера из DEMOS\ACTIVEFM\EMPEDIT\Server.dpr из поставки Delphi 3.01).
В директории с приложением-сервером находится программа scktsrvr.exe (она запускается как приложение ) и dbclient.dll. Приложение-сервер запущено.
Клиентское приложение содержит DataModule c ClientDataSet, Query и MidasConnection и главную форму с DBGrid, настроенным на Query. Свойства MidasConnection выставлены следующим образом:
ComputerName - IP-адрес сервера,
ConnectType - stSockets
ServerGuid - {56791B61-7625-11D1-A3B8-00C0DF817EF4} - (взято из текста
приложения сервера)
ServerPort - 211
UserBroker - False
При установке свойства Connected компонента MidasConnection равным true счетчик клиентов в приложении-сервере увеличивается на 1 и при сбросе Connected в false уменьшается. Т.е. вроде бы приложение-сервер "чувствует" подключение приложения-клиента. Однако при установке ClentDataSet.Active равным true возникает ошибка - "Ошибка при загрузке библиотеки" без дополнительных пояснений.
О какой библиотеке идет речь?
С уважением, Михаил Шунин, Георгий Буриков
ВЦ ОАО "Аэрофлот-Российские Международные авиалинии"
Речь идет об одной из библиотек, которые входят в состав MIDAS и должны находиться на сервере приложений. Это библиотеки IDPROV32.DLL (она должна быть в том же каталоге, что и BDE), DBCLIENT.DLL и STDVCL32.DLL (эти библиотеки должны быть в каталоге Windows\System и должны быть зарегистрированы в реестре).
В целом же на этот и другие подобные вопросы можно ответить следующее. На компьютере, где выполняется сервер приложений, должен быть установлен MIDAS. В его состав входит BDE, SQL Explorer (ConstraintBroker Manager), вышеупомянутые библиотеки, а также OLEnterprise. В состав Delphi 3 Client/Server Suite входит только MIDAS Development Kit, включающий лицензию разработчика и ограниченную версию MIDAS, позволяющую создавать серверы приложений, тестировать их, но не позволяющую заниматься их поставкой. Для поставки и промышленной эксплуатации серверов приложений, созданных с помощью Delphi 3, требуется полная версия MIDAS, предоставляющая, наряду с необходимыми библиотеками и утилитами, право эксплуатации любого количества серверов приложений на том компьютере, где она установлена. Естественно, комплектов MIDAS нужно столько, сколько в сети имеется компьютеров с поддерживаемыми MIDAS серверами приложений. Эксплуатация серверов приложений без наличия полной версии MIDAS на компьютере, где они установлены, является нарушением лицензионного соглашения Delphi.
Поставка "тонких" клиентов
Как уже неоднократно отмечалось, поставка "тонких" клиентских приложений представляет собой намного более простой процесс, чем поставка "толстых" клиентов. Для функционирования такого клиента требуется, помимо исполняемого файла, наличие библиотеки dbclient.dll (ее можно найти в каталоге Windows\System на компьютере разработчика и скопировать либо в аналогичный каталог компьютера пользователя, либо в каталог, содержащий исполняемый файл клиентского приложения). Если речь идет о создании стандартного дистрибутива с помощью InstallShield Express или иного аналогичного средства, следует отказаться от включения BDE и SQL Links в его состав, а включить лишь файлы, необходимые для функционирования клиентского приложения, и библиотеку dbclient.dll.
Если клиентское приложение выполнено в виде иcполняемого в броузере ActiveX, следует выбрать dbclient.dll в закладке Deploy Additional Files диалоговой панели Web Deployment Options. При распространении ActiveX через Internet рекомендуется выбрать также опцию "Use CAB file compression" для уменьшения времени передачи его по сети.
Простые Web-серверы уже не так уж и просты
Первичной задачей Web-серверов была поддержка Web-сайтов. Однако теперь они играют более серьезную роль в информационных корпоративных системах. Web-технология оказывает сильное влияние на новое поколение серверов приложений. В них используются такие Web-протоколы как и , а Web-браузеры применяются для организации первичной среды клиентов.
Определение платформы Web-сервера существенно изменилось за последние 18 месяцев. Это связано с быстрым развитием Web-технологии как основы информационных и коммерческих платформ. Анализ инвестиций в intranets показывает, что удалось сэкономить многие миллионы долларов, особенно в областях продаж и поддержки заказчиков. Многие бизнесмены ожидают, что Web-коммерция позволит существенно увеличить общий объем продаж. Например, президент компании Джон Чамберс (John Chambers) утверждает, что применение Internet-коммерции и intranet-систем позволяет его компании каждый год экономить более 250 миллионов долларов. Через Web осуществляется около 40% продаж с ожидаемым объемом в 1998 г. в 3 миллиарда долларов. Компания организовала совместное предприятие с компанией с целью переноса корпоративных приложений в среду Web.
Технически развитие Web-технологии облегчается наличием стандартов, таких как , SSL и Java. Эти стандарты воплощаются в Web-сервере, который служит центральной точкой для интеграции новых инструментальных средств и технологий. В приводимая ниже таблица иллюстрирует развитие функциональных возможностей Web.
| Common Gateway Interface (CGI) | Запросы целиком обрабатываются в отдельных процессах сервера; медленное и трудное программирование; отсутствует встроенная поддержка баз данных |
| Скриптовые среды первого поколения: Netscape LiveWire; Microsoft Active Server Pages (ASP); Apache with Java Servlets; GoldFusion; WebObjects | Интеграция с HTML позволяет динамически расширять Web-страницы; разработка убыстряется благодаря возможности создания скриптов высокого уровня на JavaScript, VB Script и Java; имеются некоторые проблемы с эффективностью выполнения скриптов; обеспечивается некоторая поддержка объектов и баз данных; очень ограниченная безопасность. |
| Прикладные среды второго поколения: LiveWire plus LiveConnect and Borland/Visigenic ORB; ASP plus ADO and MTS; Apache with CORBA and JavaBeans; SilverStream 1.0; Progress Software WebSpeed | Более развитая поддержка объектов; интеграция Java и CORBA; поддержка пулов подключений к базам данных; улучшенная производительность за счет кэширования и прекомпиляции; улучшенная безопасность за счет использования 40-битового SSL. |
| Корпоративные и коммерческие среды третьего поколения: Netscape with Kiva Application Server and Actra commerce servers; Microsoft Site Server 3.0 with Active User Object; MTS 2.0 and Merchant Server; Open Market LiveCommerce and Transact | Усложненное пулирование ресурсов баз данных и кэширование объектов; интеграция с серверами знаний; расширения в сторону более вертикальных прикладных областей, таких как регистрация и профилирование пользователей; развитые функции категорий пользователь-бизнес и бизнес-бизнес; интеграция с платежными системами; более развитая безопасность с использование 64-битового SSL и цифровых сертификатов |
Прозрачность баз данных
Если приходится иметь дело с несколькими системами баз данных, то наиболее существенным является общий интерфейс доступа к данным (API - Application Programming Interface). Наличие такого API позволяет использовать стандартные инструментальные средства и существенно упрощает процесс разработки приложения. К наиболее популярным интерфейсам относятся ODBC, OLE DB и ActiveX Data Object (ADO) компании . Среди разработчиков, использующих язык Java, в качестве общего интерфейса доступа к базам данных принят JDBC. В мире Си++ многих привлекает DBTools++ компании RogueWave Software (www.roguewave.com).
Различные архитектуры построения трехзвенных информационных систем
Нередко у потенциальных пользователей MIDAS возникают вопросы о способах построения многозвенных информационных систем, наиболее удовлетворяющих нуждам именно их предприятия, в том числе вопросы о том, сколько нужно иметь серверов приложений, как конфигурировать клиентские рабочие станции, каковы возможности осуществления и изменения конфигурации рабочих станций удаленно, например, через Internet или с помощью модемной связи.
Многозвенные информационные системы можно построить разными способами, и выбор той или иной архитектуры существенно зависит от числа пользователей такой ИС, степени территориальной разбросанности предприятия, потребности в централизованном хранении и обработке данных, частоты обновления версий используемых автоматизированных рабочих мест и структуры используемой базы данных.
Первый часто встречающийся случай - крупное или среднее предприятие, расположенное компактно и имеющее общую локальную сеть. В этом случае нередко корпоративные данные хранятся в общей для всех серверной СУБД. Переход к трехзвенной архитектуре в этом случае производится главным образом с целью снижения издержек, связанных с конфигурацией рабочих станций (установка и настройка клиентской части серверной СУБД, настройка BDE, обновление версий автоматизированных рабочих мест) и поддержкой их в рабочем состоянии, и, во вторую очередь - с целью снижения сетевого трафика и повышения надежности эксплуатации системы в целом. В этом случае наиболее приемлемым представляется наличие в сети нескольких компьютеров, на которых установлены MIDAS и OLEnterprise и эксплуатируются одни и те же серверы приложений, при этом сведения о них экспортированы в глобальный реестр (например, с помощью утилиты Object Explorer). На рабочих станциях в этом случае устанавливается Run-time - версия OLEnterprise, и все описания серверов приложений импортируются в локальные реестры. При такой конфигурации рабочие станции подключаются к серверам приложений случайным образом и в случае отказа одного из серверов эти подключения окажутся равномерно распределенными по другим серверам.
В случае очень большого числа пользователей и высокой интенсивности транзакций можно рекомендовать как альтернативу "самодельным" серверам приложений серверы приложений Borland Entera, которые, в отличие от серверов, созданных с помощью Delphi, могут управляться не только помощью Windows 95 и Windows NT, но и с помощью других операционных систем (в частности, различных версий Unix). В этом случае вместо Delphi Client/Server Suite следует использовать Delphi Enterprise, что позволит создать "тонких" клиентов для использования Entera в качестве сервера приложений.
Второй случай, характерный, в частности, для многих предприятий нефтяной и газовой промышленности, крупных торговых объединений, а также различных межрайонных и межрегиональных служб, от налоговых инспекций до авиационных касс - предприятие, имеющее несколько территориально разбросанных подразделений (возможно, даже в разных городах), не связанных локальной сетью между собой. Нередко такие предприятия имеют несколько локальных информационных систем и набор связанных с этим проблем, таких, как поддержка актуальности данных во всех этих информационных системах, репликация данных, объединение данных из нескольких информационных систем для их совместного анализа и составления итоговых сводок и отчетов. Переход к трехзвенной архитектуре в случае таких предприятий осуществляется с целью устранения этих проблем и организации централизованного хранения и обработки данных (а нередко также с целью снижения тех же затрат на конфигурацию рабочих станций, что и в предыдущем случае). Обычно в этом случае наиболее приемлемым представляется установка сервера баз данных и сервера приложений в центральном офисе (не обязательно на одном и том же компьютере), при этом последний должен быть оснащен MIDAS и быть доступным через Internet. Рабочие станции филиалов должны быть оснащены Internet Explorer 3.0 и выше, при этом и разработчики, и пользователи рабочих станций удаленных филиалов должны иметь доступ не только к компьютеру, содержащему сервер приложений, но и к какому-либо web-серверу (его местоположение не играет существенной роли, так как первые лишь отправляют туда новые версии "тонких" клиентских приложений, а вторые их сгружают на свои рабочие станции).
В этом случае никаких особых требований к рабочим станциям, помимо наличия Internet Explorer 3.0, а также доступа в Internet, нет. В этом случае, естественно, также возможно использование Borland Entera и Delphi Enterprise вместо MIDAS и Delphi Client/Server Suite.
В случае невозможности доступа через Internet возможны иные варианты, такие, как использование выделенной линии, модемная связь и др. Реализация связи не так принципиальна - лишь бы при этом была возможность использования протокола TCP/IP. Естественно, при частых сбоях и разрывах соединения рекомендуется активно использовать кэширование данных на рабочих станциях, сохранять содержимое кэша в файлах и загружать их оттуда, благо у компонента TClientDataSet есть методы SaveToFile и LoadFromFile.
Возможны различные комбинации этих вариантов, например, доступ по протоколу TCP/IP и наличие нескольких однотипных серверов приложений. Дать рекомендации на все случаи жизни, естественно, невозможно, но имеющиеся благодаря средствам разработки Borland технические возможности предоставляют разработчикам и руководителям отделов автоматизации достаточно большой простор для фантазии при организации информационных систем предприятий, и достаточный выбор вариантов их построения.
Серверы приложений
Являясь эффективными средствами для построения масштабных приложений категории OLTP (OnLine Transaction Processing), TP-мониторы обычно не обеспечивают следующие возможности:
Хранение логики приложений и управление ею Размещение и создание экземпляров объектов Кэширование объектов и отслеживание их времени жизни
Разработка многозвенных приложений целиком связана с их разделением, которое состоит в делении работы между клиентом и одним или несколькими специализированными серверами. Серверы приложений облегчают разделение, допуская перенос компонентов приложения на архитектурный уровень и физическую платформу, на которых они могут работать наиболее эффективно.
Сервер приложений поддерживает определение логики приложений. Для этих целей некоторые серверы обеспечивают собственные средства разработки и языки. Другие полагаются на объектные стандарты, такие как CORBA, COM или JavaBeans. Почти во всех случаях требуется инкапсуляция логики приложения в одном или нескольких объектах. Возможности этих объектов доступны через их методы, которые могут быть вызваны напрямую из кода приложения или из других объектов.
Гибкость современных РСУБД делает соблазнительным поместить существенную часть логики приложения прямо в базу данных в виде хранимых процедур. Если не принимать во внимание ссылочные и другие ограничения целостности, это, вообще говоря, плохая идея. Для большинства приложений пропускная способность сервера баз данных является наиболее ценным ресурсом. Если сервер выполняет специфичную для приложения задачу для одного пользователя, пожирающего этот ресурс, то он не в состоянии обслуживать потребности всех других пользователей. Лучше разделить эту работу таким образом, чтобы аппаратные ресурсы могли быть сосредоточены на выполнении наиболее требуемых действий.
До последнего времени большинство серверов приложений было тесно связано с платформами разработки корпоративных приложений. Хорошим примером являются продукты компании . Линия продуктов этой компании включает средства разработки GUI (Graphical User Interface), компоненты связи с базами данных и средства распространения. Все они выстроены вокруг надежного сервера приложений. Проектировщик создает приложение так, как если бы оно должно было выполняться на одной машине, а затем использует средства разделения, чтобы поделить работу между клиентом и серверами приложений. В продуктах семейства Vision компании также используется эта модель.
До конца 1995 г. этот класс корпоративных инструментальных средств переднего края составлял достаточно хорошо понимаемую и устоявшуюся категорию. И тогда пришло время Web.
Создание локального клиентского приложения
Создание локального клиентского приложения (на том же ПК, что и сервер)
Закрыв проект созданного только что сервера, можно приступить к созданию клиентского приложения. Создадим главную форму приложения и обычный модуль данных, который должен быть видим из главной формы (этого можно достичь путем выбора опции: File/Use unit...). В модуль данных поместим один компонент TRemoteServer, два связанных с ним компонента TClientDataSet и два связанных с ними компонента TDataSource.
Рис.6. Модуль данных клиентского приложения
Попробуем установить свойство ServerName компонента RemoteServer1 (выбрав его из выпадающего списка или введя вручную). После этого, если в реестре есть соответствующая запись, автоматически будет установлено значение свойства ServerGUID. При этом сервер приложений, созданный ранее, должен автоматически запуститься, о чем будет свидетельствовать появившаяся на экране его главная форма.
После этого можно установить нужные значения свойств ProviderName компонентов TClientDataSet, выбрав их из выпадающего списка (так как сервер приложений выбран, все его доступные через интерфейс свойства становятся видны в среде разработки). После этого можно установить связь master/detail между таблицами по общему полю ACCT_NBR.
Далее нужно установить значения свойства Active компонентов TClientDataSet равными True и связать интерфейсные элементы главной формы приложения с соответствующими полями таблиц, доступных через запущенный сервер приложений.
Рис.7. Главная форма клиентского приложения
Теперь можно скомпилировать и запустить приложение. Отметим, что при запуске приложения из среды разработки с сервером приложений соединены два клиента - среда разработки и скомпилированное клиентское приложение. При желании можно с помощью утилиты SQL Monitor проследить, какие именно запросы созданный нами сервер приложений направляет серверу баз данных.
Данный пример был выполнен на ПК Pentium-120/32 МБ c ОС Windows 95 с использованием. Personal Oracle 7.2 for Windows 95 (90-дневная trial-версия)и Delphi 3.0. При этом во время отладки приложения был постоянно загружен MicrosoftWord 7.0.
| |
Создание сервера приложений
Создание сервера приложений
Создание сервера приложений начнем с создания обычной формы (можно небольшого размера, так как основное ее назначение - быть индикатором запущенного сервера приложений) со значением свойства FormStyle равным fsStayOnTop (рис.1). Вообще говоря, появление на экране главной формы в общем случае не является обязательным. Далее создадим обычный модуль данных, содержащий компонент TDataBase, указывающий на серверную СУБД. Для простоты установим свойство LoginPrompt этого компонента равным False, а в свойстве Params укажем имя пользователя, от имени которого будет запущен сервер приложений, и его пароль:
Username=user1 Password = user1
Рис.1. Главная форма и модуль данных сервера приложений
Далее из репозитария объектов (доступ к которому осуществляется выбором пункта меню File/New:) со страницы New следует выбрать объект Remote Data Module (рис.2).
Рис.2. Выбор удаленного модуля данных из репозитария объектов
Remote Data Module имеет принципиальное отличие от обычного DataModule, заключающееся в том, что объекты, помещенные в него, могут иметь COM-интерфейс.
Создание Remote Data Module начинается с запуска эксперта Remote Dataset Wizard, в котором определяется, в частности, имя класса, под которым данный сервер приложений (он же OLE-сервер) будет зарегистрирован в реестре (рис.3):
Рис.3. Выбор имени класса
Далее в созданный удаленный модуль данных поместим два компонента TTable, связанных с компонентом Database1 и указывающих на только что созданные таблицы CLIENTS и HOLDINGS, а также два компонента TProvider. Установим значения свойств DataSet компонентов TProvider равными именам соответствующих компонентов TTable. Установим связь master/detail между таблицами по полю ACCT_NBR. Откроем таблицы (рис. 4)
Рис.4. Содержимое удаленного модуля данных
Далее из контекстного меню компонентов TTable и TProvider нужно выбрать опции
Export MyProv1 from data module Export MyProv2 from data module Export Table1 from data module Export Table2 from data module
Последние две опции являются, вообще говоря, необязательными, так как компоненты TProvider обеспечивают другим приложениям, функционирующим в сети, доступ к данным, содержащимся в компонентах TTable и Tquery.
Если теперь исследовать полученную библиотеку типов (Type library), можно обнаружить, что COM-объект, который будет создаваться при запуске данного приложения, обладает интерфейсом, осуществляющим доступ извне к компонентам MyProv1, MyProv2, Table1 и Table2. (рис. 5).
Рис.5. Библиотека типов созданного проекта
Далее следует сохранить проект и скомпилировать приложение.
Рекомендуется убедиться, что оно зарегистрировано в реестре под выбранным ранее именем. Если тем не менее по каким-либо причинам этого не произошло, следует запустить наше приложение-сервер с параметром /regserver. После этого проект следует закрыть.
| |
Создание сервера приложений и
Созданные с помощью Delphi 3.0 клиент и сервер приложений могли взаимодействовать посредством OLEnterprise либо DCOM. В версии Delphi 3.01появилась также возможность организовать связь клиента и сервера непосредственно с помощью протокола TCP/IP. Для этого в палитре компонентов последних версий Delphi (3.01 и 3.02) имеется компонент TMidasConnection, обладающий большей функциональностью по сравнению с TRemoteServer из Delphi 3.0. Этот компонент позволяет выбрать тип соединения с сервером приложений (DCOM, OLEnterprise, непосредственное использование протокола TCP/IP). При его использовании процесс создания сервера приложений и клиента заметно упрощается, так как в случае доступа по протоколу TCP/IP в общем случае нет необходимости иметь в реестре компьютера, на котором установлен "тонкий" клиент, какие-либо сведения о сервере приложений. Рассмотрим простейший пример создания такой системы.
Начнем с создания сервера приложений. Создадим главную форму приложения, основное назначение которой - служить индикатором запущенного сервера. С этой целью можно разместить ее где-нибудь в углу экрана, а свойство FormStyle установить равным fsStayOnTop, чтобы не потерять это окно среди других открытых окон. Далее следует создать удаленный модуль данных, выбрав пиктограмму Remote DataModule из репозитария объектов, поместить в него компонент TTable или TQuery, установив необходимые значения свойств DatabaseName и TableName. Свойство Active также следует установить равным True (или установить его динамически при создании модуля данных). В противном случае компонент не будет содержать никаких данных, и тем более предоставлять их клиентскому приложению (рис.1).
Рис.1. Форма и удаленный модуль данных сервера приложений
Затем нужно обязательно экспортировать этот компонент из модуля данных (либо связать его с компонентом TProvider и экспортировать последний). Если этого не сделать, клиентское приложение не будет иметь доступа к этому объекту (эта ошибка является довольно типичной).
Основное назначение удаленного модуля данных заключается именно в предоставлении содержащимся в нем компонентам доступа к данным возможности быть видимыми и управляемыми извне, то есть из других приложений (и в общем случае - с других компьютеров, в том числе доступных не только посредством локальной сети, но и посредством Internet). Проконтролировать наличие в удаленном модуле данных объектов, видимых извне, можно, просмотрев соответствующую библиотеку типов (рис.2).
Рис.2. Библиотека типов, связанная с удаленным модулем данных
Если для доступа к данным необходим компонент TDatabase, его обычно размещают на главной форме приложения, либо в обычном модуле данных. Почему при использовании компонента TDatabase его обычно не помещают в удаленный модуль данных? Если этот компонент разместить в удаленном модуле данных, то могут возникнуть проблемы, связанные с тем, то при нескольких подключениях могут быть конфликты между несколькими его экземплярами - ведь каждое новое подключение создает свой экземпляр удаленного модуля данных. Поэтому следует позаботиться о разных именах пользовательских сессий во избежание таких конфликтов, либо, если это позволяют соображения безопасности, использовать для всех подключений общий компонент TDatabase.
Затем, если есть желание проконтролировать число соединившихся с сервером клиентов, можно создать обработчики событий OnCreate и OnDestroy удаленного модуля данных, в которых значение какой-либо целой переменной соответственно увеличивается или уменьшается на единицу и при необходимости отображается в каком-либо интерфейсном элементе главной формы сервера приложений.
После этого сервер приложений можно скомпилировать и запустить на выполнение. Это нужно для того, чтобы зарегистрировать его как OLE-сервер в реестре Windows. По поводу регистрации сервера также следует сделать одно замечание. Автору пришлось наблюдать случай, когда системный администратор сумел настроить операционные системы на компьютерах разработчиков отдела автоматизации одного из московских предприятий таким образом, что у них не было никакой возможности менять что-либо в своих реестрах.
При этом, естественно, и серверы приложений также в реестрах не регистрировались. Если при создании сервера приложений он не регистрируется в реестре, возможно, этот случай подобен описанному. А может быть, просто по ошибке вместо удаленного создан обычный модуль данных...
Если обобщить данный случай, то, образно говоря, серверы приложений такого класса обязаны содержать либо генерировать некий набор SQL-запросов для изменений в базе данных и посылать их на сервер баз данных по команде клиентского приложения. Наш сервер приложений использует для генерации запросов библиотеку Borland Database Engine. Другие серверы приложений, такие, например, как Borland Entera, используют иные механизмы генерации запросов, обусловленные в известной степени той платформой, на которой этот сервер приложений функционирует. В любом случае именно набор SQL-запросов является самой главной составляющей функциональности такого сервера приложений. Что же касается пользовательского интерфейса сервера приложений (форма со счетчиком подключений или что-то в этом роде), он совершенно необязателен. В конце концов, сервер приложений может не иметь главной формы или не показывать ее, или может быть запущен в виде сервиса. Если же говорить опять об общем случае (когда речь идет не только о серверах приложений, созданных с помощью Delphi, но и о других подобных серверах приложений, в том числе для других платформ), то ведь не все платформы обладают графическим пользовательским интерфейсом, и, следовательно, создание такого объекта, как форма, возможно не на всех платформах. Не стоит обольщаться - самые дорогие серверы приложений нередко просто запускаются из командной строки и не обладают интерфейсом в привычном для пользователей Windows понимании.
В известном смысле сервер приложений и "тонкий" клиент представляют собой разделенное на две части классическое клиентское приложение, называемое в совокупности с клиентом серверной СУБД и библиотеками доступа к данным, такими как BDE, "толстым" клиентом.
Первая часть ( созданный нами сервер приложений) содержит компоненты доступа к данным (и требует наличия BDE и клиента серверной СУБД), а вторая (клиент) должна содержать пользовательский интерфейс (и не требовать наличия BDE и клиентской части серверной СУБД).
Прежде чем приступить к созданию "тонкого" клиента, запустим Borland MIDAS Socket Server scktsrvr.exe (его можно найти в каталоге Delphi 3.0\Bin), предоставляющий доступ извне к имеющимся на данном компьютере серверам приложений, созданных с помощью Delphi 3, по протоколу TCP/IP. Отметим, что в этом случае любой из имеющихся серверов приложений может быть запущен с любого компьютера, имеющего доступ к Вашему компьютеру с помощью данного протокола, поэтому при использовании подобных систем следует рассматривать различные вопросы, связанные с безопасностью их эксплуатации.
Рис.3. Borland MIDAS Socket Server
Теперь, наконец, можно создать клиентское приложение. Для этого создадим обычную форму (или выберем со страницы ActiveX репозитария объектов пиктограмму ActiveForm для создания клиентского компонента ActiveX). На форму поместим компонент TMidasConnection и установим его свойство ComputerName равным IP-адресу компьютера, на котором должен выполняться сервер приложений. Если этот компьютер в данный момент доступен в сети, можно выбрать его имя из списка, появляющегося при щелчке напротив имени этого свойства. Но нужно понимать, что в общем случае, особенно если клиентское приложение предназначено для доступа к серверу через Internet, указание именно IP-адреса является более предпочтительным. Далее следует установить значение свойства ServerName в следующем формате: <имя исполняемого файла>.<имя OLE-сервера>, например MyAppSrv.MyRemDataMod1. Свойство ServerGUID можно не устанавливать. Если сервер приложений не зарегистрирован на компьютере, где разрабатывается клиент, значение этого свойства должно остаться пустым, и это не помешает совместной работе сервера и клиента - ведь в общем случае при распространении клиентского приложения или ActiveX через Internet в реестре компьютера, где оно будет выполняться, нет и не может быть сведений о сервере приложений.
Свойство Connected можно установить равным True (или произвести установку этого свойства равным True на этапе выполнения в момент создания формы клиентского приложения). После этого должен запуститься сервер приложений (в том числе удаленный).
Далее следует поместить на форму компонент TClientDataSet, выбрать имя компонента TMidasConnection в качестве значения свойства RemoteServer и выбрать значение свойства Provider из выпадающего списка объектов, экспортированных из удаленного модуля данных сервера приложений. Теперь можно установить свойство Active равным true. Далее следует поместить на форму компонент TDataSource и связать его с компонентом TClientDataSet.
После этого можно заняться пользовательским интерфейсом, поместив на форму необходимые компоненты отображения данных (рис.4). Следует также в качестве обработчика какого-нибудь события вызвать метод ApplyUpdates компонента TClientDataSet, иначе изменения будут накапливаться в кэше и не будут сохраняться в базе данных.
Рис. 4. Активная форма на этапе проектирования.
Далее можно запустить и протестировать клиентское приложение, а если он выполнено в виде ActiveX - осуществить его поставку на Web-сервер вместе с библиотекой dbclient.dll и протестировать, обратившись к сгенерированной HTML-странице (рис.5).
Рис.5. Тестирование "тонкого" клиентского приложения
Отметим также, что можно обратиться к созданной HTML-странице с другого компьютера локальной сети.
Следует обратить внимание на то, что web-сервер вовсе не обязан находиться на том же самом компьютере, что и сервер приложений. Назначение web-сервера в такой информационной системе весьма утилитарно - он представляет собой лишь хранилище, откуда можно сгрузить ActiveX, и ничего более. Если говорить о передаче ActiveX через Internet и доступе к серверу приложений через Internet, то в принципе возможна ситуация, когда сервер приложений, Web-сервер и пользователь находятся в трех разных городах, пользователь обращается к своему провайдеру в своем городе, а как именно он получает ActiveX и обращается к серверу приложений, его как пользователя Internet интересовать не должно.
Нередко при создании таких ActiveX задаются вопросы типа: "А если приложение должно содержать несколько форм, как мне поступить?". Ответ достаточно прост: в этом случае возможна генерация дополнительных форм динамически при наступлении какого-либо события (например, нажатия на кнопку). Нужно только не забыть уничтожить созданную форму, когда она станет не нужна. Следует также помнить, что библиотека OCX, содержащая ActiveX, содержащий, в свою очередь, несколько форм, будет иметь больший размер, чем в случае ActiveX c одной формой.
Довольно часто встречаются вопросы, связанные с тем, что ActiveX не отображается в броузере. Вот одно из таких писем:
Здравствуйте, Наталия Елманова!
Прочел вашу статью на Web-сайте www.interface.ru. Пробую создать сервер приложений с использованием ActiveForm. После создания и переноса CAB-файла и Web-страницы на Web-сервер страничка открывается, но на месте предполагаемой аппликации только квадратик. Разъясните, в чем может быть проблема.
С уважением Слава.
Причин такого поведения может быть несколько. Первая причина связана с тем, что далеко не все броузеры поддерживают отображение ActiveX с помощью тега <OBJECT>. Для отображения ActiveX следует использовать только MS Internet Explorer версии 3.0 и выше. Вторая причина может быть связана с настройкой уровня безопасности броузера. В случае максимального уровня безопасности (значение, принятое по умолчанию) никакой исполняемый код (в том числе и ActiveX) в броузере не выполняется, а некоторые версии Internet Explorer не только не сгружают ActiveX и тем более не выполняют его, но при этом еще и ничего не сообщают пользователю. Есть еще и третья причина - настройки операционной системы компьютера пользователя таковы, что пользователю запрещено изменять реестр, и в этом случае ActiveX в нем, естественно, не зарегистрируется.
Светлые и темные стороны
Во всех этих продуктах очевидным победителем является Java. Везде обеспечивается совместимость с Java на некотором уровне. Многие продукты, такие как Dynamo и Novera EPIC, базируются на Java с самого начала. Как уже отмечалось, даже Microsoft обеспечивает хорошую поддержку Java. Java является лучшим языком разработки многоплатформенных приложений, дающим возможность повторного использования и эффективного выполнения компонентов в клиентских и серверных звеньях приложения. Реализации Java быстро приобретают зрелость, а ранние проблемы эффективности решаются за счет улучшенных сред выполнения Java-программ и более быстрых процессоров.
Beans по отношению к Java играют ту же роль, что ActiveX по отношению к COM. Beans обеспечивают компонентную модель, включая обработку событий. До недавнего времени JavaBeans наиболее активно использовались для упаковки визуальных компонентов клиентских приложений. Новым шагом на пути становления Java корпоративным стандартом явился выпуск компанией продукта Enterprise JavaBeans (EJB). Это расширение сосредоточено на специализированных невизуальных Beans для сервера. Среда выполнения EJB обеспечивает поддержку пула нитей и неявное управление транзакциями. Многие поставщики TP-мониторов и серверов приложений собираются поддерживать эту компонентную модель. Некоторые из них будут иметь готовые продукты к моменту завершения выработки спецификации EJB.
Каковы отрицательные аспекты использования Web в качестве звена архитектуры корпоративного приложения? Вот некоторые из них:
идеально подходит для приложений "клиент-сервер". Это протокол без запоминания состояния, поэтому не требуется постоянное подключение к серверу. С другой стороны, информация о состоянии должна включаться в каждый запрос, что вызывает падение эффективности. Бешеные темпы разработки приводят к появлению ненадежных выпусков продуктов с сомнительным качеством. Надежность и эффективность выполнения и Java в Web-браузерах все еще недостаточны. Это побуждает поставщиков Web-серверов приложений, таких как SilverStream, предлагать специальные клиенские среды выполнения приложений. Это решение разумно, но противоречит одному из основных обещаний Web-технологии - не заставлять инсталировать специальное программное обеспечение на стороне клиента. (DHTML) и библиотеки Java-классов для разработки пользовательских интерфейсов еще не стандартизованы. Если для приложения требуются развитые интерфейсные средства, придется ограничиться использованием некоторой конкретной версии браузера. Внутри Web-браузера загруженный Java-код без разрешения пользователя не может писать на диски и производить другие потенциально разрушительные действия.
The Middleware Muddle
, May 1998
, the principal of WebMine, a Boston-based consulting practice focused on information and technology solutions for Internet business
В настоящее время термин "промежуточное программное обеспечение" ("middleware") относится к любому программному компоненту, который располагается между пользовательскими приложениями на персональных компьютерах и РСУБД или унаследованной системой, непосредственно управляющими необходимыми данными. Этот термин, подобно многим другим, применяется настолько широко, что теряет смысл. Для наведения какого-нибудь порядка в статье предлагается несколько более точных категорий, хотя конкретные продукты могут одновременно относиться к нескольким категориям.
Удаленный клиент с использованием ActiveForm
Удаленный клиент с использованием ActiveForm
Как было сказано выше, наличие "тонкого" клиента не только снижает требования к ресурсам рабочей станции, но и упрощает конфигурацию программного обеспечения для них (для работы такого клиента требуется лишь файл dbclient.dll размером 156 Кб из комплекта поставки Delphi 3.0 Client/Server Suite). Следствием этого является возможность осуществлять поставку таких приложений не путем создания обычного дистрибутива, а через intranet (или Internet, если говорить об информационной системе предприятия с удаленными филиалами), используя Web-сервер в качестве источника очередной версии приложения и Web-броузер в качестве средства его установки. При этом существует возможность выполнения такого приложения (если оформить его не как исполняемый файл, а как компонент ActiveX) непосредственно в броузере, используя тег <OBJECT>, поддерживаемый MS Internet Explorer 3.0 и 4.0.
Для распространения такого "тонкого" клиента следует иметь в сети какой-нибудь Web-сервер (например, Personal Web Server для Windows 95 или Internet Information Server для Windows NT).
Для создания "тонкого" клиента в виде ActiveX следует в репозитарии объектов Delphi выбрать страницу ActiveX и пикторамму ActiveForm.
Рис.9. Выбор ActiveForm из репозитория объектов
Рис.10. Создание нового компонента ActiveX для показа в броузере
После этого автоматически будет предложено создать ActiveX Library (файл с расширением OCX). Помимо главной формы приложения, на которой располагаются интерфейсные элементы (подобные, например, тем, что были использованы в предыдущем примере), следует создать модуль данных с необходимыми компонентами для доступа к данным..
Рис.11. "Тонкий" клиент, реализованный как ActiveForm
Отметим, что обработчик события для кнопки "О программе" отличается от стандартного: в модуле, свзанном с ActiveForm, имеется набор сгенерированных автоматически процедур и функций (можно найти их в исходном тексте соответствующего модуля), одну из которых мы и использовали.
Если же выбран средний или минимальный уровень безопасности броузера, полученный по сети компонент будет зарегистрирован в реестре Windows (в этом можно убедиться, попытавшись найти имя формы в редакторе реестра), а соответствующий файл OCX хранится в каталоге для кэширования сгружаемых компонентов
Рис.13. Сведения о зарегистрированной библиотеке OCX в редакторе реестра
После открытия форма будет видна в броузере (рис.14). Можно убедиться, что все ее интерфейсные элементы работают так же, как и интерфейсные элементы в обычном приложении.
Рис.14. Web-страница с элементом ActiveX - "тонким" клиентом
Технические характеристики ПК, использованных для данного примера, приведены в табл. 3 (локальный вариант) и табл.4 (сетевой вариант). Таблица 3. Технические характеристики использованных ПК и ПО (локальный вариант трехзвенной системы с ActiveForm в качестве "тонкого" клиента)
| Сервер БД | Personal Oracle for Windows 95 (90-дневная trial-версия) | Pentium-120/32 MB RAM |
| Сервер приложений | Сервер приложений, созданный перед этим в первом примере | Pentium-120/32 MB RAM (это тот же самый ПК, на котором запущен сервер БД) |
| Web-сервер | Microsoft Personal Web Server for Windows 95 | - ''- |
| Web-броузер | Microsoft Internet Explorer 3.01 for Windows 95 | -''- |
| Сервер БД | Windows NT Server 4.0 + Oracle Workgroup Server 7.2 for Windows NT (90-дневная trial-версия) | Pentium-133/32 MB RAM |
| Сервер приложений | Windows NT Server 4.0 | Pentium-133/32 MB RAM (это тот же самый ПК, на котором запущен сервер БД) |
| Клиенты | Windows 95 | Pentium-120/16 MB RAM |
Если при создании сервера выбрана опция Single Instanse, каждый клиент на сервере может запустить свой процесс. Если же при создании сервера была выбрана опция Multiple Instanse, то каждый клиент может в рамках единого процесса создавать свой поток (то есть создавать свой экземпляр удаленного модуля данных). В этом случае рекомендуется использовать при создании сервера компонент TSession со значением AutoSessionName, равным True, так, чтобы потоки, созданные разными клиентами, не использовали одну и ту же сессию и не мешали друг другу при сбоях. В заключение хотелось бы отметить некоторые особенности Delphi 3.01, связанные с реализацией многозвенных приложений. В палитре компонентов этой версии продукта имеется новый компонент TMidasConnection, который может быть использован вместо TRemoteServer. Если TRemoteServer предназначен главным образом для доступа к серверам приложений посредством DCOM, TMidasConnection обладает свойством ConnectType, позволяющим определить, каким образом осуществляется соединение - посредством DCOM, сокетов TCP/IP или OLEnterprise. Еще одной приятной особенностью новой версии является автоматическая установка параметров HTML-тега <OBJECT> так, чтобы размер изображения ActiveX в броузере соответствовал размерам формы (в прежней версии требовалась ручная правка генерируемой Web-страницы). Автор выражает признательность Сергею Орлику за некоторые полезные идеи, в частности, идею использования ActiveForm для создания "тонкого" клиента, а также Андрею Брындину (АзовИмпекс) за идею создания многопоточного сервера. Последнее обновление - 3 апреля 1998
|
Удаленный клиент с использованием OLEnterprise
Удаленный клиент с использованием OLEnterprise.
В рассмотренном выше примере сервер баз данных, сервер приложений и приложение-клиент выполнялись на одном том же компьютере. Более интересным для практического применения представляется случай использования для этой цели разных компьютеров, связанных, например, локальной сетью. В этом случае возникает проблема обмена данными между реестрами сервера приложений и клиента, которая может быть решена различными способами. Одним из таких способов является использование OLEnterprise - составной части MIDAS.
Для использования OLEnterprise следует установить его полную версию (содержащую фабрику классов - Class Factory) на компьютер, на котором будет запущен сервер приложений, и Run-time-версию на компьютер, содержащий приложение-клиент.
На компьютере, содержащем полную версию OLEnterprise, следует запустить приложение Business Object Broker, обеспечивающее соединение клиента с сервером и равномерное распределение нагрузки между серверами приложений, если их несколько. Далее следует запустить приложение Object Factory. Затем следует запустить Object Explorer утилиту, предназначенную для межреестрового обмена сведениями о серверах приложений между компьютерами в сети. Далее следует найти созданный ранее сервер приложений среди полученного из реестра данного компьютера списка OLE-серверов и экспортировать его (иногда это называется публикацией объекта), выбрав в меню пункт Object/Export (рис.8). После этого OLE-сервер можно будет "увидеть" с удаленных компьютеров в сети как доступный для них объект.
Рис.8. Публикация объекта с помощью Object Explorer
На рабочей станции, где будет запущено приложение-клиент, следует запустить Object Explorer и соединиться с реестром компьютера, содержащего сервер приложений (Registry/Connect:). Все экспортированные объекты после этого будут видны в списке OLE-серверов удаленного реестра. Далее следует импортировать выбранный сервер приложений (Object/Import), отметив, что приложение будет выполняться на том компьютере, где оно содержится.
После этого можно убедиться, что данный OLE-сервер содержится в реестре рабочей станции (например, запустив входящий в состав операционной системы редактор реестра). Теперь можно слегка изменить клиентское приложение, выбрав значение свойства ComputerName компонента TRemoteServer из списка доступных в локальной сети компьютеров. При попытке установить свойство Connected этого компонента равным True сервер приложений будет найден в реестре и запущен на удаленном ПК. Отметим, что если пользователь редактирует данные в клиентском приложении, они не переносятся непосредственно на сервер баз данных, а вместо этого кэшируются. Для инициации процесса реального сохранения в базе данных используется метод ApplyUpdates компонента TClientDataSet. В качестве параметра этот метод использует целое число, равное максимально допустимому числу ошибок сервера, после которого следует прекратить попытки физического сохранения данных (значение -1 означает, что следует пытаться сохранить все данные независимо от числа ошибок). Почему предусмотрена возможность ошибок сервера? Ответ очевиден - клиентское приложение может ничего не знать о правилах ссылочной целостности и иных ограничениях, содержащихся на сервере баз данных, и только попытка физического сохранения изменений в базе данных может выявить их нарушения (вспомним, что на клиентской рабочей станции может даже не быть библиотеки BDE). Отметим также, что установить связи между таблицами можно как на сервере приложений, так и в клиентском приложении, и разработчик может выбрать, что удобнее с точки зрения эффективности работы и функциональности. Данный пример был выполнен в одном из классов Учебного центра Interface Ltd. Особо хотелось бы обратить внимание на довольно скромные требования к ресурсам как компьютера, содержащего сервер приложений, так и рабочих станций, на которых выполнялись клиентские приложения (табл.1) Таблица 1. Технические характеристики использованных ПК и ПО при соединении клиента и сервера приложений с помощью OLEnterprise
| Сервер БД | Windows NT Server 4.0 + Oracle Workgroup Server 7.2 (Trial 90-day version) for Windows NT | Pentium-133/32 MB RAM |
| Сервер приложений | Windows 95 | 486 DX2-66/16 MB RAM |
| Клиент 1 | Windows NT Server 4.0 | Pentium-133/32 MB RAM (тот же самый ПК, на котором запущен сервер БД) |
| Клиенты 2,3,4 | Windows 95 | 486 DX2-66/16 MB RAM |
в мире компьютерной индустрии возрастает
Уважаемые читатели!
С каждым годом в мире компьютерной индустрии возрастает значимость программного обеспечения категории middleware (на русском языке принято использовать не очень удачный эквивалент "промежуточное программное обеспечение"). Существует множество продуктов этой категории, производимых крупными, средними и даже мелкими софтверными компаниями. Перспективность направления middleware демонстрирует, например, тот факт, что всемирно известная компания Borland сменила свое название на Inprice (, ) и объявила, что стратегией компании является обеспечение широкого диапазона средств middleware. По всей видимости, основное влияние на распространение продуктов промежуточного программного обеспечения оказывает переход к использованию многозвенных архитектур при организации информационных систем и повсеместная тенденция к интеграции с технологией Internet. В статье, обзор которой предлагается вашему вниманию, делается попытка провести некоторую классификацию технологий и продуктов, относящихся к middleware. Несмотря на некоторый перекос в сторону Web (что, естественно, отражает личные привязанности автора), на мой взгляд, статья помогает упорядочить свои представления и познакомиться с новейшими тенденциями. Если вам интересна эта тематика, рекомендую познакомиться с Web-сайтами упоминаемых в статье компаний. Многие из этих сайтов содержат очень интересную информацию.
С уважением,
Выбор оружия
Ключом к успеху сегодняшних корпоративных приложений является гибкое использование ресурсов. Ориентация на компонентные приложения позволяет использовать новейшую технологию серверов приложений. Более не требуется изобретать собственные транспортные механизмы, коммуникационные протоколы и средства связи с базами данных.
Для большинства ресурсоемких приложений выделенные мониторы транзакций обеспечивают наивысшую эффективность. Для приложений с более сложными правилами и логикой отличной основой являются серверы приложений общего назначения. В любом случае большая часть новой технологии связана со стандартами Web. Разработка в среде Java открывает широкий выбор возможностей для разделения и распространения приложений. В мире имеется широкий набор продуктов, основанных на CORBA и Java. Для доминирует Microsoft MTS. Выбор поставщика, продукты которого строго соответствуют стандартам и открытой архитектуре, является лучшей гарантией в наше время быстрых перемен.
Зачем нужны многозвенные информационные системы
Зачем нужны многозвенные информационные системы
Информационные системы, созданные на основе классической архитектуры клиент/сервер, называемые двухзвенными системами или системами с "толстым" клиентом, состоят из сервера баз данных, содержащего сгенерированные тем или иным способом таблицы, индексы, триггеры и другие объекты, реализующие бизнес-правила данной информационной системы, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных согласно содержащимся в них алгоритмам. Если говорить о клиентских приложениях, созданных с помощью Delphi, для доступа к источникам данных они используют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД. Эти вызовы осуществляются обычно посредством использования библиотеки Borland Database Engine (BDE), хотя в целом это не является обязательным (например, некоторые пользователи Oracle непосредственно вызывают функции Oracle Call Interface из Delphi-приложений). Соответственно подобное клиентское приложение требует наличия на компьютере конечного пользователя клиентской части используемой серверной СУБД (и наличия лицензии на ее использование) и присутствия в оперативной памяти набора динамически загружаемых библиотек как из клиентской части, так и из BDE (либо иной заменяющей ее библиотеки), таких, как драйверы баз данных, библиотеки, содержащие функции API клиентских частей, и др. Это усложняет технические требования, предъявляемые к аппаратной части клиентской рабочей станции, и в конечном итоге приводит к удорожанию всей системы в целом.
Другим фактором, приводящим к удорожанию эксплуатации информационной системы, является необходимость инсталляции и конфигурации BDE и клиентской части серверной СУБД, что нередко является весьма трудоемким процессом, особенно при большом количестве и неоднородном парке рабочих станций.
Выходом из этой ситуации является создание систем с так называемым "тонким" клиентом, в частности, с клиентом, не содержащим в своем составе BDE и клиентскую часть серверной СУБД.
В этом случае функциональность, связанная с доступом к данным (а нередко и какая-либо иная функциональность), возлагается на другое приложение, называемое обычно сервером приложений, и являющееся клиентом серверной СУБД. В свою очередь, клиентские приложения обращаются не непосредственно к серверной СУБД посредством вызова функций клиентских API, а к серверу приложений, являющемуся для них источником данных, при этом собственно клиентская часть серверной СУБД и библиотеки типа BDE на рабочей станции, где используется такое клиентское приложение, присутствовать не обязаны. Вместо них используется одна-единственная динамически загружаемая библиотека dbclient.dll размером 154 Кб. Таким образом, созданная информационная система становится трехзвенной, а сервер приложений является средним звеном в цепи "тонкий клиент сервер приложений - сервер баз данных" и, соответственно, относится к классу продуктов middleware. Как может быть практически реализована данная технология? С одной стороны, с помощью набора компонентов и классов Delphi 3, обеспечивающих создание серверов приложений и клиентских частей, а, с другой стороны, с помощью MIDAS, позволяющего осуществлять запуск удаленных серверов приложений, осуществлять межреестровый обмен сведениями об OLE-серверах и оптимизировать нагрузку в случае использования нескольких серверов приложений. В данной статье будет рассмотрен простейший практический пример реализации подобной трехзвенной системы.
|
Pictures
