Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ПОКС.doc
Скачиваний:
13
Добавлен:
04.12.2018
Размер:
536.58 Кб
Скачать

29. Инструментальные средства создания серверных web приложений

Компания Epsylon Technologies занимается разработкой серверов приложений и инструментальных средств для создания многопользовательских сетевых приложений под общим именем Baikonur. До недавнего времени компания выпускала продукты предназначенные только для российских пользователей. На CeBIT'98 состоялась премьера первой версии "на экспорт" - Baikonur Internet/Intranet Suite 1.3.

BIIS включает в себя сервер приложений Baikonur Enterprise Web App Server 1.3 и инструментальные средства разработки серверных приложений в программных средах Borland Delphi и C ++ Builder.

Применение визуального проектирования при разработке Internet/intranet системы ведет к существенному сокращению времени и стоимости проекта, а использование сервера Baikonur в качестве основы сетевой информационной системы обеспечивает следующие преимущества: - функциональная расширяемость системы и совместимость с программным обеспечением других производителей; - минимальные требования к программному и аппаратному обеспечению рабочих мест сетевых пользователей (технология Lтонкогоі клиента); - безопасность передаваемых по сети данных - поддержка международных стандартов SSL 2.0/3.0; - высокая надежность; - отсутствие архитектурных ограничений на количество одновременно работающих с сервером пользователей; - визуальная сборка приложений при помощи HTML-компонент.

Кроме коммерческого варианта Baikonur Internet/Intranet Suite на CeBIT компания Epsylon Technologies представила и некоторые новые технологии, которые не входят пока в экспортный вариант продукта, но доступны в российском варианте под названием Baikonur SuperServer 1.5.

Как и ожидалось, большой интерес на выставке был проявлен к JAT-технологии. Это - know-how Epsylon Technologies, позволяющее вести визуальную компонентную разработку многопользовательских приложений серверного слоя в Delphi и C ++ Builder, а доступ к ним осуществлять при помощи Java-аплета чрезвычайно малого размера -всего 40 Кбайт. При этом для всех типов серверных приложений требуется только один аплет, выполняющий роль Java-терминала.

Также были представлены интересные разработки в области геоинформационных систем, применения фреймов в динамически генерируемых HTML-страницах и построения почтовых роботов.

В целом участие в CeBIT ' 98 и международную "премьеру" Baikonur можно уверенно оценить как успешные. На сегодняшний день подписано крупное соглашение с компанией BHV, контракты на дистрибуцию программного обеспечения серии Baikonur в Швеции и Бразилии, в состоянии предварительных переговоров находятся аналогичные соглашения с 12 европейскими компаниями (Франция, Нидерланды, Польша, Чехословакия, Венгрия, Турция, Италия, Испания и др.). Кроме того, возникли предварительные договоренности о нескольких внедрениях технологий Epsylon Technologies для интранет-сетей крупных европейских предприятий

30. Инструментальные средства создания клиентских web приложений

Типы инструментальных средств

Для выполнения различных функций в большинстве приложений понадобится та или иная комбинация инструментальных средств. Продавец какой-нибудь фирмы, возможно, убедил ваше руководство в том, что в последней версии продукта этой фирмы можно эффективно создать абсолютно все, но, как правило, вам будет нужна комбинация инструментальных средств для управления следующими компонентами:

Формы

Экранные формы для ввода, сопровождения и запрашивания данных.

Отчеты

Печатные и, возможно, экранные отчеты.

Пакетные процессы

Процессы, поддерживающие механизмы подачи данных и обработку больших объемов данных.

Нерегламентированные запросы

Поддержка нерегламентированных запросов.

Средство интеграции

Средство, собирающее различные компоненты в одно цельное приложение.

Хотя проектировщик, вероятно, будет участвовать в выборе инструментальных средств, окончательное решение обычно принимает не он. Во многих случаях на это решение влияют внешние факторы и предпочтения. У многих фирм имеется список "стратегических" продуктов, которые используются в каждой разработке, если только нет хорошего обоснования для применения других средств. Предлагая альтернативные варианты, следует делать больший акцент на ожидаемом повышении производительности и экономии средств, а не на эстетической стороне разных продуктов.

У одного из авторов еще живо в памяти воспоминание о том, как он пытался уговорить клиента-консультанта написать всего один модуль (из почти 750) на Рго*С, а не на PL/SQL. Руководитель проекта настаивал на том, что поскольку PL/SQL является корпоративным стандартом, то следует использовать этот язык. В соответствующем разделе отчета консультанта было написано:

Я согласен с вашими разработчиками, что на PL/SQL технически невозможно написать модуль, который удовлетворял бы поставленным требованиям к производительности. Кроме того, затраты на разработку варианта на PL/SQL примерно в десять раз больше, чем варианта на С.

Новый руководитель проекта больше года старался решить проблемы производительности средствами PL/SQL, пробуя вариант за вариантом, после чего наконец санкционировал написание этого модуля на Рго*С. Для создания и тестирования понадобилась неделя работы одного программиста, и проблемы производительности были решены. Если инструментальное средство не делает то, что вам нужно, поменяйте инструментальное средство.

Инструментальные средства для систем клиент/сервер

Существует ряд специфических вопросов, которые необходимо исследовать при оценке инструментальных средств для среды клиент/сервер. Взаимодействие между клиентом и сервером осуществляется одним из трех способов:

• прямое SQL-соединение через SQL*Net;

• SQL-соединение через ODBC-драйвер;

• направление удаленных вызовов процедур на серверы приложений, выдающие все запросы к базе данных.

На практике в настоящий момент времени широко распространены только первые два способа. Третий начинает выглядеть как вариант для Web-приложений и для развертывания архитектуры сетевых вычислений Oracle (NCA). Без сомнения, в Oracle есть люди, считающие, что это одно и то же и что каждый Oracle-узел, развертывающий Web-приложения, автоматически принимает NCA.

Некоторые продукты, например Powerbuilder фирмы Powersoft, позволяют выбрать любой из двух вариантов SQL-соединений, поэтому важно знать о различиях между ними. Во-первых, для использования ODBC необходим ODBC-драйвер, хотя необходимые драйверы довольно часто продаются в комплекте с инструментальными средствами. При использовании SQL*Net можно свободно писать SQL-код, включающий Oracle-расширения стандарта ANSI. Если же применяется ODBC-драйвер, он может попытаться разобрать этот SQL-код и отклонить SQL, не соответствующий стандарту ANSI.

Это ограничение приводит к появлению проблем, когда мы пытаемся проектировать экранную форму, позволяющую администратору приложения сопровождать пользователей, поскольку такие команды, как ALTER USER и DROP USER в стандарте ANSI отсутствуют. Это ограничение касается почти всех DCL- и DDL-операций в Oracle7. Документ The Oracle7 Server SQL Reference Manual содержит перечень Oracle-расширений стандартного SQL, а руководство для версии 7.2 — список более чем 60 команд SQL, поддерживаемых Oracle7, но не входящих в стандартный SQL. Для тех, кто не знаком с ограниченной областью применения стандарта (стандартов) на SQL, сообщаем, что этот список включает команду CREATE SYNONYM.

В большинстве ODBC-драйверов это ограничение ANSI можно обойти, установив опцию, называемую режимом ретрансляции (pass through mode). Этот режим заставляет драйвер передавать SQL прямо на сервер, не интерпретируя его. Это позволяет использовать SQL, не соответствующий стандарту ANSI, но лишает нас одного из главных преимуществ ODBC, которое заключается в следующем. Если режим ретрансляции не применяется, то приложение можно сделать независимым от базы данных. Это значит, что теоретически оно должно работать с Oracle7, Sybase, SQL Server, Informix и т.д. Если это важно — например, в случае, когда создается продукт, который планируется продавать на более широком рынке, чем рынок серверов Oracle7, — то следует в качестве стандарта разработки применять ODBC без режима ретрансляции. Однако в этом случае вам пригодится лишь очень малая часть нашей книги (не считая раздела о псевдокоде).

Иногда режим ретрансляции включают из-за того, что предполагают, будто наличие промежуточного ПО (ODBC-драйвера, интерпретирующего SQL) влечет очень высокие затраты и сильно замедляет работу приложения. Однако это зависит от конкретного ODBC-драйвера. Ведь ODBC — это просто стандарт, и на рынке есть множество драйверов. Некоторые из них обеспечивают высокую скорость работы вне зависимости от режима. Опять-таки, ценным подспорьем здесь могут быть оценка по результатам макетирования и эталонные тесты драйверов. Следует помнить одно: если ODBC-драйвер интерпретирует и переписывает SQL, он может удалить встроенные комментарии, в том числе и те, которые являются подсказками оптимизатору Oracle7. Это серьезно ограничит возможность воздействия на сервер при оптимизации производительности некоторых SQL-запросов.

В заключение скажем, что в первом стандарте на ODBC (ODBC 1) программа может вызывать хранимую процедуру или функцию базы данных и передавать ей параметры. Однако такая процедура не может возвращать значения в вызывающую программу. Это существенно ограничивало возможности проектирования интерфейса клиент/сервер, так как хранимые процедуры обычно играют здесь важную роль. В стандарте ODBC 2.0 это упущение исправлено.

Если рассматривается возможность использования Microsoft Visual Basic или Visual C++ в качестве внешней системы, существует альтернатива ODBC (или встроенному SQL) — Oracle Objects for OLE (OO4O). По стилю программирования этот продукт очень похож на ODBC, но написан специально для сервера Oracle7 и, следовательно, оптимизирован под Oracle.

Некоторые средства разработки для клиентов имеют встроенную СУБД. Это может быть полезно для разработки на базе ПК, поскольку в противном случае нам потребуется доступ к серверу Oracle7 (или к Personal Oracle7, если на ПК достаточно оперативной памяти). Вот некоторые примеры:

• Blaze в Oracle Power Objects версии 1.x;

• Oracle Lite в Oracle Power Objects версии 2.x;

• Jet в Microsoft Visual Basic;

• Interbase в Borland Delphi;

• Watcom SQL в Powersoft Powerbuilder.

Эти СУБД не обладают всеми функциональными возможностями Oracle7. В частности, они не поддерживают ограничения целостности и компоненты кода, такие как триггеры и хранимые процедуры. Эти ограничения диктуют уровень, до которого может успешно продолжаться разработка в автономной конфигурации, что делает Personal Oracle7 гораздо более приемлемым вариантом. Недавно Oracle представила продукт Oracle Lite, который способен работать в одном мегабайте оперативной памяти, но это, опять-таки, весьма ограниченная СУБД, нацеленная, скорее, на рынок встроенных систем, нежели на рынок приложений.

Рис. 19.1. Проблемы, возникающие при попытках диспетчера клиентской базы данных взять все под свой контроль

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