В зависимости от конкретной области применения, информационные системы могут очень сильно различаться по своим функциям, архитектуре, реализации. Однако можно выделить по крайней мере два свойства, которые являются общими для всех информационных систем.
Во-первых, любая информационная система предназначена для сбора, хранения и обработки информации. Поэтому в основе информационной системы лежит среда хранения и доступа к данным. Среда должна обеспечивать уровень надежности хранения и эффективность доступа, соответствующие области применения информационной системы.
Во-вторых, информационные системы ориентируются на конечного пользователя, например, банковского клерка. Такие пользователи могут быть очень далеки от мира компьютеров. Для них терминал, персональный компьютер или рабочая станция представляют собой всего лишь орудие их собственной профессиональной деятельности. Поэтому информационная система обязана обладать простым, удобным, легко осваиваемым интерфейсом, который должен предоставить конечному пользователю все необходимые для его работы функции, но в то же время не дать ему возможность выполнять какие-либо лишние действия. Иногда этот интерфейс может быть графическим с меню, кнопками, подсказками и т.д. Сейчас очень популярны графические интерфейсы, и многие современные средства разработки информационных приложений прежде всего ориентированы на разработку графических интерфейсов. Наличие развитых интерфейсных средств является обязательным для любой современной информационной системы.
Тематика прикладных информационных систем исключительно широка. В этой части курса мы рассмотрим только некоторые вопросы, связанные с организацией, разработкой и использованием таких систем, причем не будем слишком углубляться в технические детали.
Сегодня трудно найти компанию, производящую компьютерную технику или программное обеспечение, которая не поставляла бы средства разработки информационных приложений, компоненты информационных систем или законченные готовые к использованию решения. Одним из немногих исключений из этого правила является компания InformixSoftware, которая (по крайней мере, пока) производит только базовые программные системы и средства разработки, но не предлагает собственных готовых приложений, оставляя их создание своим партнерам.
Вообще, в компьютерном мире понятие стороннего поставщика (third-partycompany) имеет очень большое значение, поскольку значительная часть прикладного программного обеспечения производится именно небольшими независимыми софтверными компаниями.
9.1.1. Информационные приложения, поставляемые крупными компаниями производителями вычислительной техники и СУБД (Oracle, Hewlett-Packard, IBM, Microsoft и т.д.)
Исключительно в качестве примера приведем очень краткую характеристику прикладных программных продуктов, производимых и распространяемых некоторыми ведущими компаниями.
Начнем с компании Oracle. Представители этой компании любят представлять набор производимых продуктов в виде перевернутой пирамиды с вершиной внизу и основанием наверху. Вершине пирамиды соответствует базовый комплект серверов баз данных, предлагаемых компанией. В середине пирамиды располагаются средства проектирования и разработки баз данных и информационных систем (в частности, Designer/Developer 2000). Наконец, основанию пирамиды соответствуют готовые компоненты информационных приложений и законченные решения. Такая картина правильно отражает соотношения объемов и числа продуктов. Конечно, серверы баз данных - это наиболее сложные и ответственные продукты. Но их число и объем кода не очень велики. Средства проектирования и разработки опираются на использование серверов; эти продукты менее сложны, но более объемны. Наконец, приложения создаются с использованием средств проектирования и разработки; приложений много, и суммарный объем кода очень велик.
Oracle предлагает приложения (естественно, основанные на использовании серверов баз данных Oracle) для использования в следующих предметных областях:
Другая картина представлена компанией HewlettPackard. Как один из ведущих производителей вычислительной техники, компания в основном зарабатывает деньги за счет продажи компьютеров. Но с другой стороны, для увеличения спроса желательно предлагать заказчикам готовые решения. Это и делает компания. В кооперации с компаниями-разработчиками программного обеспечения (в частности, с Oracle) разрабатываются законченные аппаратно-программные конфигурации, пригодные для использования в различных предметных областях.
В частности, имеются решения HP для применения в следующих сферах:
Компания IBM, являясь крупнейшей (и одной из старейших) в мире производителей компьютеров и программного обеспечения, предлагает компоненты информационных приложений и готовые решения для использования во всех сферах человеческой деятельности. Естественно, как и в случае HewlettPackard, эти решения опираются на аппаратные средства IBM (и базовое программное обеспечение этой же компании).
Совершенно необъятное число информационных приложений предлагает компания Microsoft. Следуя своей технологии компонентной организации программных продуктов, компания Microsoft предлагает компоненты для горизонтального рынка - набор полуфабрикатов, пригодных для построения бухгалтерских систем, систем документооборота, систем планирования ресурсов и т.д., а также готовые продукты для вертикального рынка - финансовые системы, здравоохранение, автоматизация работы гостиниц, издательские системы и т.д.
9.1.2. Приложения, предлагаемые третьими компаниями (пример: Catalyst компании SunMicrosystems)
Мы уже отмечали, что большинство прикладных программных продуктов производится небольшими самостоятельными софтверными компаниями. Такие компании в силу ограниченности своих ресурсов часто не могут обеспечить разработку и сопровождение продуктов на разных платформах и сосредотачиваются на поддержке платформ одного поставщика. Компании этого рода недаром называют "сторонними поставщиками", поскольку они ведут свою собственную политику, сами рекламируют и продают свою продукцию и не связаны со своими "старшими братьями" партнерскими отношениями. Тем не менее, основные поставщики также заинтересованы в том, чтобы их потенциальные заказчики знали о существовании продуктов третьих компаний, поскольку это является дополнительным доводом при принятии решения о покупке. Большинство крупных компаний собирает и распространяет информацию о доступности продуктов сторонних поставщиков.
Например, компания SunMicrosystems каждый год издает специальный каталог под названием "Catalyst", содержащий исключительно информацию о продуктах независимых фирм, работающих на платформах Sun. Catalyst обычно имеет объем более 1000 страниц. Прикладные продукты разбиты на предметно-ориентированные категории. По поводу каждого продукта приводятся его краткая характеристика и адрес и другая контактная информация производителя.
Понятное дело, что любую программу можно написать на любом языке программирования. Однако, когда речь идет об информационных приложениях, существенно возрастает сложность проектирования и программирования интерфейсов с конечным пользователем (как мы отмечали, эти интерфейсы должны быть предельно просты, понятны и удобны), а также требуется большая скорость получения хотя бы как-нибудь работающей версии программы (чтобы понять, устраивает ли это приложение хотя бы в первом приближении).
9.2.1. Что такое "быстрая разработка приложений" (rapidapplicationdevelopment)
Все равно, если Вы хотите получить правильно работающую, настроенную под Ваши потребности, грамотно написанную программу, обращайтесь к профессионалам. Но необходимо знать, какие средства разработки Вашими коллегами применяются. Возможны два подхода: RapidApplicationDevelopment - быстрая разработка приложения и традиционный способ программирования. Быстрая разработка - это, как правило, создание работающего прототипа приложения (прототипа в том смысле, что это все-таки не законченное приложение, а некоторый его прообраз). Этот прототип может быть полностью функционален. (Иногда не полностью; это зависит от сложности приложения.) Что Вам могут честно обещать - это полная отработка интерфейсов. Экранные формы, разного рода меню, подсказки делаются быстро и качественно. Можно почувствовать, как внешне будет выглядеть приложение.
Но это не значит, что внутренность прикладной программы будет достаточно эффективной и качественной. Как правило, за небольшим числом исключений (к ним, в частности, относится язык компании BorlandDelphi) языки быстрого прототипирования являются интерпретируемыми. Это не обязательно означает пошаговую пооператорную обработку программы. Иногда, как в случае языка Java, вся программа подвергается предварительной обработке, в результате которой образуется промежуточный машинно-независимый код, который в дальнейшем исполняется с помощью встроенного машинно-независимого интерпретатора. Но в любом случае интерпретатор остается интерпретатором; он не может так же эффективно выполнять программу как компьютер.
Почему же так часто используются языки быстрой разработки приложений? Основной ответ состоит в том, что они действительно быстро дают возможность получить работающий вариант программы со всеми ее внешними интерфейсами (применительно к системам, связанным с базами данных, такие языки часто называют 4GL, языками четвертого поколения).
9.2.2. Пригодны ли средства быстрой разработки только на стадии пилотного проекта?
Конечно же, нет. Можно найти массу простых информационных приложений, основное назначение которых состоит в том, чтобы формировать отчеты на основе заранее подготовленных запросов пользователей к базам данных. Общая эффективность подобных приложений главным образом определяется эффективностью используемой СУБД, и на нее мало влияет интерпретируемость выполнения клиентской части приложения.
Заметим, что большая часть современных языков и инструментальных средств быстрой разработки приложений (например, Delphi компании Borland, PowerBuilder компании Sybase и т.д.) имеют несколько собственных интерфейсов с распространенными серверами баз данных, либо могут работать с ними через драйверы ODBC. Поэтому с архитектурной точки зрения быстро разработанное приложение вполне может соответствовать модели "клиент-сервер". Если же в дополнение к средствам быстрой разработки применяются такие серверные средства как хранимые процедуры, ограничения целостности и триггеры, то часть логики приложения может быть перенесена на сервер баз данных (фактически, это позволяет сформировать третье звено общей цепочки - сервер приложений).
9.2.3. Тенденции к сближению языков быстрой разработки и языков программирования. Что это дает?
При использовании средств быстрой разработки приложений для создания сложных информационных систем с необходимостью существенных вычислений на стороне клиента обычно применяется комбинированный подход. Сначала создается пилотный проект, выполненный целиком на языке быстрой разработки, а затем наиболее ответственные части приложения переписываются на некотором традиционном языке программирования (как правило, на Си/Си++), компилируются и компонуются с остальной частью системы. В большинстве средств быстрой разработки такая возможность явно предусматривается и поддерживается. Ясно, что так работать можно. Но возникают некоторые сомнения.
По каким причинам для большинства языков быстрой разработки используется техника интерпретации? Кажется, что можно дать два основных ответа. Во-первых, в случае применения интерпретации упрощаются компиляторы. В частности, в компиляторе исчезает существенный по сложности компонент генерации машинных кодов. В результате средство быстрой разработки может быть реализовано быстрее. Быстрее можно получить и работоспособный вариант приложения. Во-вторых, применение техники интерпретации машинно-независимых промежуточных кодов снимает (или, по крайней мере, облегчает) проблему переноса на новую платформу как самого средства разработки, так и созданных на его основе информационных систем. Но на самом деле, оба приведенных довода являются чисто техническими.
Все мы знаем примеры высококачественных компиляторов традиционных языков программирования (например, того же семейства Си/Си++), которые легко переносятся, умеют генерировать машинный код для многих платформ и обеспечивают простоту переноса приложений. К тому же, эти компиляторы обеспечивают высокое качество генерируемого кода и соответственно высокую эффективность выполнения приложений.
В настоящее время имеется явная тенденция к переходу на новое поколение средств быстрой разработки, которые не утратят достоинства существующих систем, но будут выполняться в режиме компиляции. Одним из ярких примеров таких систем является BorlandDelphi, которая позволяет быстро производить высокоэффективные информационные приложения (ограни- чиваясь, правда, платформами Intel). В компьютерной прессе обсуждаются перспективы к пе- реходу на такую технологию для Powerbuilder и других средств быстрой разработки.
9.2.4. Особенности инструментальных средств, предназначенных для разработки Intranet-приложений
Об Intranet-приложениях уже достаточно много говорилось в этом курсе. Тем не менее, для полноты мы немного обсудим особенности инструментальных средств Intranet-приложений и в этом пункте.
Не будем обсуждать базовые механизмы организации Web-ориентированных Intranet-приложений и, в частности, средства их интеграции с другими серверами (включая, естественно, серверы баз данных). Коснемся только языка Java, наиболее популярного на сегодня инструмента Internet/Intranet, и сопоставим особенности реализации и использования Java с языками быстрой разработки, упоминавшимися в предыдущих пунктах этого раздела.
Краткой характеристикой языка Java может быть следующее: более безопасный по сравнению с Си++ объектно-ориентированный язык с постоянно развивающимися библиотеками классов. Компания SunMicrosystems разработала и ввела в обиход этот язык специально для операционной поддержки клиентов Всемирной Паутины. Полная машинная независимость языка Java дала возможность создать ряд интерпретаторов, которые сегодня существуют практически для всех платформ и в состоянии выполнять программы (Java-апплеты), передаваемые клиенту с Web-серверов. Хотя много раз начинались разговоры о реализации компиляторов Java в машинные коды, для "гуляющих" по Сети Java-апплетов более естественно применение интерпретации промежуточных кодов.
В начале этой части курса мы кратко рассмотрели основные требования, которым должна удовлетворять информационная система, и задачи, которые должны решаться такой системой. При этом мы подчеркивали, что строгость соблюдения требований и фиксированность набора решаемых задач во многом являются условными в зависимости от конкретных целей, для достижения которых разрабатывается прикладная информационная система. Соответственно, проектирование и разработка информационной системы может базироваться на разных архитектурных решениях.
В данном разделе приводится классификация возможных архитектур информационных систем. Мы начинаем с традиционных архитектурных решений, основанных на использовании выделенных серверов баз данных и, возможно, серверов приложений. Затем рассматриваются варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы (еще не вполне установившаяся) относится к приложениям оперативной аналитической обработки данных. Наконец, последняя выделяемая нами архитектура предназначена для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектно-ориентированного подхода.
Замечание по поводу терминологии. С терминологией в области информационных систем вообще, а русскоязычной терминологией в особенности, дела обстоят неважно. Область информационных систем очень быстро развивается. Практически каждый год возникают новые технологии и архитектурные решения, для которых в маркетинговых целях придумываются оригинальные, привлекающие внимание названия, далеко не всегда точно отражающие смысл технологии и/или архитектуры. На самом деле, все подходы к организации информационных систем, рассматриваемые в этом курсе базируются на общей архитектуре "клиент-сервер". Различие состоит только в том, что делают клиенты и серверы. Тем не менее, чтобы избежать путаницы, далее мы вынуждены применять русскоязычные эквиваленты соответствующих англоязычных терминов.
Следует заметить, что как и любая классификация, наша классификация архитектур информационных систем не является абсолютно жесткой. В архитектуре любой конкретной информационной системы часто можно найти влияния нескольких общих архитектурных решений. Тем не менее, при архитектурном проектировании системы кажется полезным иметь хотя бы частично ортогонализированный архитектурный базис.
9.3.1. Информационные системы, использующие серверы приложений
Под клиент-серверным приложением в узком смысле мы будем понимать информационную систему, основанную на использовании серверов баз данных. Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 9.1.
Рис. 9.1. Общее представление информационной системы в архитектуре "клиент-сервер"
(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)
Интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения.
Здесь необходимо сделать еще два замечания:
Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL.
Как видно, в клиент-серверной организации клиенты могут являться достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы был в состоянии удовлетворить потребности всех клиентов (рисунок 9.2).
Рис. 9.2. Тонкий клиент и толстый сервер в клиент-серверной архитектуре
С другой стороны, разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки локального кэша общей базы данных на стороне каждого клиента.
Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных (или, как иногда их называют в русскоязычной литературе, тиражированных) баз данных. Как и в общем случае, для поддержки локального кэша базы данных программное обеспечение рабочих станций должно содержать компонент управления базами данных - упрощенный вариант сервера баз данных, который, например, может не обеспечивать многопользовательский режим доступа. Отдельной проблемой является обеспечение согласованности (когерентности) кэшей и общей базы данных. Здесь возможны различные решения - от автоматической поддержки согласованности за счет средств базового программного обеспечения управления базами данных до полного перекладывания этой задачи на прикладной уровень. В любом случае, клиенты становятся более толстыми при том, что сервер тоньше не делается (рисунок 9.3).
Рис. 9.3. Потолстевший клиент и толстый сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов
Другой идеей, позволяющей сократить сетевой трафик между компонентам клиент-серверной организации, является выделение дополнительного сервера (сервера приложений), на который перекладывается часть прикладной обработки и в котором, в свою очередь, может поддерживаться локальный кэш базы данных. Тогда клиенты взаимодействуют напрямую только с сервером (или несколькими серверами) приложений (естественно, что при этом могут использоваться протоколы более высокого уровня, чем при взаимодействии с сервером баз данных, и интенсивность этих взаимодействий может быть снижена), а сервер приложений по мере необходимости обращается к серверу баз данных (рисунок 9.4).
Рис. 9.4. Информационная система в архитектуре "клиент-сервер" с выделенным сервером приложений
Информационные системы в трехзвенном (или многозвенном исполнении) могут создаваться на основе использования промежуточного программного обеспечения мониторов распределенных транзакций, например, Tuxedo компании BEASystems, Inc. или Encina компании TransarcCorp.
Громадным преимуществом клиент-серверной архитектуры любого рода является ее масштабируемость и вообще способность к развитию. При проектировании информационной системы, основанной на этой архитектуре, большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть минимальными (например, в качестве аппаратной основы сервера баз данных может использоваться одна из рабочих станций). После создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.
Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы. В идеале, которого конечно же не бывает, информационная система продолжает нормально функционировать даже после смены аппаратуры.
Назад | Содержание | Вперед