Обеспечение отказоустойчивости
В серьезной ИС вопросы отказоустойчивости выходят на первый план не только из-за требования работоспособности самой корпорации. Когда ИС становится лицом компании, обращенным к потенциальным клиентам и бизнес-партнерам, ее работоспособность становится залогом общего доверия к компании на рынке
Поэтому корпорация Sybase уделила вопросам обеспечения отказоустойчивости особое внимание
Основополагающим для обеспечения отказоустойчивости является понятие кластера Jaguar-серверов. При настройке сервера администратор имеет возможность организовать несколько серверов приложений в единый кластер. Для такого кластера доступны общая прогрузка и регистрация компонентов и обеспечение работоспособности системы даже в условиях выхода из строя нескольких машин. Jaguar-сервер предоставляет возможность автоматического восстановления работоспособности в случае сбоев (automatic failover), заменяя прозрачно для клиента отключившийся экземпляр компонента экземпляром компонента на другом компьютере. Такая возможность не является «родной» для всех программных модулей и требует определенной поддержки со стороны разработчика. В частности, для реализации автоматического восстановления работоспособности могут использоваться компоненты без сохранения состояния (stateless) или компоненты, поддерживающие возможность внешнего сохранения состояния (serialization).
Внутри кластера осуществляется контроль за работоспособностью каждой отдельной машины. В случае обнаружения неработоспособности компьютера он отключается от кластера и все клиентские запросы от него перенаправляются к работающим компьютерам. Администратор может управлять алгоритмом автоматической балансировки распределения нагрузки по машинам в кластере. Таким образом за счет использования кластерной архитектуры можно добиться не только построения высоконадежных систем (high availability), но и осуществлять постепенное наращивание компьютерных мощностей по мере увеличения числа работающих в кластере машин.
Архитектура построения серверного приложения
Как уже говорилось, сервер приложений представляет собой распределенную среду для функционирования компонент. Но из этого совсем не следует, что установленные на сервере компоненты не должны взаимодействовать друг с другом. Непосредственный обмен данными между компонентами невозможен, это противоречило бы концепции независимости и защиты экземпляров компонент на момент их выполнения в памяти компьютера. Но каждый создаваемый экземпляр компонента может аналогично клиентскому приложению обратиться к другому компоненту, используя его функциональность.
Помимо обычных компонентов, экземпляры которых создаются отдельно для каждого работающего клиента, существуют специальные разделяемые (shared) компоненты. Для таких компонентов в рамках компьютера существует только один запущенный экземпляр. Доступ к такому экземпляру со стороны нескольких приложений контролируется самим сервером, что гарантирует корректность вызовов компонента в многозадачном режиме. Такие разделяемые компоненты можно использовать для организации глобального контекста для нескольких независимо выполняемых компонентов.
Рис.6 Пример построения приложений на базе компонентов
Клиентское приложение запрашивает экземпляр компонента 1 для выполнения бизнес-транзакции. Компонент 1 при этом запрашивает для своих нужд экземпляр компонента 2, и сервер дополнительно создает его. Одновременно компоненты 1 и 2 обращаются к разделяемому компоненту 3, осуществляя обмен информацией между собой и с другими компонентами. Разделяемый компонент 3 осуществляет доступ к БД не самостоятельно, а через функции разделяемого компонента 4. Компонент 1 по мере необходимости вызывает и создает компонент 5, находящийся уже на другом сервере приложений. На другом сервере могут вызываться как обычные компоненты, так и разделяемые (компонент 6).
Передачу информации между независимо запущенными компонентами можно организовать и на уровне вызовов специального API Jaguar-сервера. В целом, набор установленных на сервере компонент образует целое приложение. Его запуск начинается с обращения клиентского ПО к серверу, что порождает затем целую цепочку взаимодействующих компонент. Такая структура позволяет использовать при проектировании ПО хорошо зарекомендовавший себя объектно-ориентированный подход, но уже без ограничений на используемые инструментальные средства и оперируя масштабами всей корпоративной системы, а не нескольких компьютеров.
Учитывая, что большинство аспектов взаимосвязи компонентов и клиентского ПО реализуется самим Jaguar-сервером, а не на уровне разработчика, процесс проектирования всей системы четко отделяется от конкретного кодирования программных модулей и ассоциируется уже не с конкретным кодом, а с администрированием сервера приложений. Отлаженное и работающее приложение, состоящее из нескольких компонент, можно затем устанавливать на «боевой» сервер целым контейнером (package) вместе с административными настройками.
Транзакции и базы данных
Появление понятия транзакции и создание серверов БД, обеспечивающих целостность информации в рамках одной транзакции, послужило в свое время важным стимулом для использования двухуровневой архитектуры. Теперь требование наличия единого транзакционного контекста является обязательным для любой бизнес-операции. В то же время, насущная необходимость объединения в одной ИС нескольких взаимодействующих серверов БД снова поднимает эту проблему. В трехуровневой модели организации системы основные тяготы по обеспечению целостности данных должен взять на себя сервер приложений.
Jaguar сервер поддерживает три модели работы с распределенными транзакциями. Первая, фиктивная, практически декларирует готовность самого разработчика обеспечить транзакционный контекст при модификации данных в БД. На практике эта «псевдомодель» используется в тех случаях, когда бизнес-логика позволяет обойтись без одновременной модификации информации сразу в нескольких БД. В этом случае от сервера приложений требуется только максимальное быстродействие без дополнительного контроля за границами действия проводимых транзакций.
Две другие модели предлагают реальное обеспечение единой транзакции при работе с несколькими БД в рамках работы с Microsoft или UNIX совместимыми средами. Одна модель обеспечивает работу с Microsoft DTC (distributed transaction coordinator), другая представляет из себя Sybase реализацию распределенных транзакций по OTS/XA протоколу. Выполнение общей транзакции может управляться компонентами сервера как с использованием предоставляемого API, так и с использованием стандартных средств, специфичных для конкретной среды разработки. Так, в случае применения компонент JavaBeans, поддерживается управление транзакциями в соответствии с моделью JavaBeans.
Средства администрирования Jaguar-сервера позволяют осуществлять тонкую настройку роли установленного компонента в проводимой транзакции. Компонент может поддерживать или не поддерживать работу с транзакциями. Использование компонента может требовать наличия уже начатой транзакции, или наоборот автоматически начинать транзакцию при первом вызове метода. В зависимости от настроек, сервер приложений управляет не только единым транзакционным контекстом, но и временем существования экземпляра объекта. Так, если компонент работает в рамках единой транзакции, его экземпляр не будет уничтожен, пока вся транзакция не будет успешно завершена или отменена из другого компонента.
Сервисная шина предприятия (ESB)
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.
Очередь сообщений может упростить взаимодействие приложений, но она не способна решить проблему разных форматов языков. Впрочем, была сделана попытка превратить очередь сообщений из простого канала связи в посредника, доставляющего сообщения и преобразующего их в нужные форматы/языки. ESB стал следующей ступенью в естественной эволюции простой очереди сообщений.
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
- Отслеживать и маршрутизировать обмен сообщениями между сервисами.
- Преобразовывать сообщения между общающимися сервисными компонентами.
- Управлять развёртыванием и версионированием сервисов.
- Управлять использованием избыточных сервисов.
- Предоставлять стандартные сервисы обработки событий, преобразования и сопоставления данных, сервисы очередей сообщений и событий, сервисы обеспечения безопасности или обработки исключений, сервисы преобразования протоколов и обеспечения необходимого качества связи.
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.
Достоинства
- Независимость набора технологий, развёртывания и масштабируемости сервисов.
- Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
- Оптимизированный обмен сообщениями.
- Стабильная спецификация обмена сообщениями.
- Изолированность контекстов домена (Domain contexts).
- Простота подключения и отключения сервисов.
- Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
- Единая точка для управления версионированием и преобразованием.
Недостатки
- Ниже скорость связи, особенно между уже совместимыми сервисами.
- Централизованная логика:
- Единая точка отказа, способная обрушить системы связи всей компании.
- Большая сложность конфигурирования и поддержки.
- Со временем можно прийти к хранению в ESB бизнес-правил.
- Шина так сложна, что для её управления вам потребуется целая команда.
- Высокая зависимость сервисов от ESB.
PowerDesigner — семейство продуктов для проектирования корпоративных ВД
PowerDesigner (бывшее название S-Designor) базовый продукт Sybase для проектирования корпоративных информационных. Различные модули PowerDesigner, интегрированные между собой и объединенные системой групповой разработки MetaWorks, позволяют создавать функциональные диаграммы потоков данных в нотации различных методологий, создавать концептуальные и физические информационные модели, производить создание информационных моделей на основе уже имеющихся баз данных (обратное проектирование), создавать приложения для ряда популярных средств разработки.
PowerDesigner WarehouseArchitect — специальный модуль для проектирования хранилищ данных, позволяющий проектировать многомерные информационные модели, модели типа «звезда» и поддерживающий генерацию баз данных как для Sybase IQ, так и для других СУБД. WarehouseArchitect поддерживает все уровни ХД с точки зрения моделирования данных, метаданных и импорта данных, а также содержит интерфейсы для подключения аналитических инструментов третьих фирм, которые являются неотъемлемой частью хранилищ данных.
Основные возможности WarehouseArchitect:
- Импорт из OLTP БД
- проектирование моделей ХД и ВД, поддерживающих информационные и аналитические системы с использованием пространственного моделирования, схем «звезда», «снежинка», разбиения и агрегации
- генерация и управление ХД и ВД (как оптимизированных традиционных РСУБД, так и многомерных систем)
- использование сценариев для автоматизации переноса данных из OLTP БД в ХД
- экспорт/импорт многомерной информации в/из механизмов OLAP и других проектировщиков запросов
- генерация отчетов о проделанной работе над проектированием системы.
Многомерное моделирование является методом, помогающим проектировщику баз данных строить информационные структуры, удовлетворяющие запросам, выдвигаемым конечными пользователями. Цель пространственного моделирования состоит в том, чтобы предоставить хранилищам данных и инструментам управления запросами корректное определение БД, которое само может быть представлено для предметно-ориентированного моделирования информации. Для этого, информация может быть переопределена и представлена конечным пользователям различными способами, с различных точек зрения. WarehouseArchitect позволяет при многомерном моделировании использовать графические объекты, которые могут удерживаться и управляться словарем PowerDesigner MetaWorks:
Этапы создания ХД с точки зрения бизнес-процессов
В общих чертах, процесс создания ХД состоит из следующих основных этапов — проектирования и загрузки данных. Проектировщики, тесно взаимодействуя с бизнес-аналитиками, очерчивают круг бизнес-понятий, процессов и объектов, принятых в конкретной организации, формализуют и описывают потоки данных. Проектируется структура хранилища, заполнение хранилища данными и начинается работа аналитиков.
В реальной жизни процессу создания хранилища данных зачастую предшествует разработка прототипа — небольшой системы, призванной продемонстрировать новые возможности, чтобы, попробовав систему в работе, сделать выводы о необходимости продолжения дальнейшей разработки.
Такая система, называемая далее витриной данных (ВД) — это небольшое хранилище, обеспечивающее потребности одного из подразделений компании, или одного из направлений бизнеса. ВД не требует, хотя и не исключает, наличие корпоративного ХД, охватывающей сразу все аспекты ее жизнедеятельности организации. Как правило, она доступна ограниченному кругу аналитиков, для работы которых она и создавалась. Стоимость разработки такой ВД намного ниже, чем корпоративного ХД, а результат ее внедрения может окупиться много быстрее. Параллельно с созданием ВД, может идти процесс проектирования корпоративного ХД.
Здесь важно подчеркнуть такое принципиальное отличие DSS на основе ХД от интегрированной системы управления предприятием, как наличие метаданных. Они хранятся в централизованно управляемом репозитарии, и содержат информацию о структуре данных ХД (или ВД); структурах данных, импортируемых из иных источников; о самих источниках; методах загрузки и агрегирования данных
Для успешного внедрения, ВД должны сразу создаваться в рамках единой корпоративной архитектуры, для решения задач, связанных с поддержанием целостности, обмена, преобразования и перемещения данных внутри всей корпоративной инфраструктуры. Можно выделить четыре ключевых требования к корпоративной архитектуре витрин данных:
- настраиваемая технология для быстрого внедрения
- поддержка больших объемов данных и хранение детализированных данных
- быстрое время отклика с возможностью его настройки
- корпоративная архитектура для ввода, преобразования и обновления данных
PowerDesigner — семейство продуктов для проектирования корпоративных ВД
PowerDesigner (бывшее название S-Designor) базовый продукт Sybase для проектирования
корпоративных информационных. Различные модули PowerDesigner, интегрированные
между собой и объединенные системой групповой разработки MetaWorks, позволяют
создавать функциональные диаграммы потоков данных в нотации различных методологий,
создавать концептуальные и физические информационные модели, производить создание
информационных моделей на основе уже имеющихся баз данных (обратное проектирование),
создавать приложения для ряда популярных средств разработки.
PowerDesigner WarehouseArchitect — специальный модуль для проектирования
хранилищ данных, позволяющий проектировать многомерные информационные модели,
модели типа «звезда» и поддерживающий генерацию баз данных как для
Sybase IQ, так и для других СУБД. WarehouseArchitect поддерживает все уровни
ХД с точки зрения моделирования данных, метаданных и импорта данных, а также
содержит интерфейсы для подключения аналитических инструментов третьих фирм,
которые являются неотъемлемой частью хранилищ данных.
Основные возможности WarehouseArchitect:
- Импорт из OLTP БД
- проектирование моделей ХД и ВД, поддерживающих информационные и аналитические
системы с использованием пространственного моделирования, схем «звезда», «снежинка»,
разбиения и агрегации - генерация и управление ХД и ВД (как оптимизированных традиционных РСУБД,
так и многомерных систем) - использование сценариев для автоматизации переноса данных из OLTP БД в
ХД - экспорт/импорт многомерной информации в/из механизмов OLAP и других проектировщиков
запросов - генерация отчетов о проделанной работе над проектированием системы.
Многомерное моделирование является методом, помогающим проектировщику баз
данных строить информационные структуры, удовлетворяющие запросам, выдвигаемым
конечными пользователями. Цель пространственного моделирования состоит в том,
чтобы предоставить хранилищам данных и инструментам управления запросами корректное
определение БД, которое само может быть представлено для предметно-ориентированного
моделирования информации. Для этого, информация может быть переопределена и
представлена конечным пользователям различными способами, с различных точек
зрения. WarehouseArchitect позволяет при многомерном моделировании использовать
графические объекты, которые могут удерживаться и управляться словарем PowerDesigner
MetaWorks:
Быстрое создание ХД для Windows NT
Не стоит думать, что ХД можно построить только на дорогостоящей Unix-платформе. Для упрощенного старта проекта Sybase разработала интегрированный пакет программ QuickStart DataMart for Windows NT, основанный на Sybase IQ 11.5. QuickStart DataMart содержит все программные компоненты, необходимые для построения законченных витрин данных, включая средства проектирования, трансформации и перемещения данных, БД, инструменты анализа и администрирования. Версия QuickStart DataMart для Windows NT включает PowerStage, упрощащий извлечение, очистку и трансформацию данных именно в среде Windows NT. По оценкам Sybase, с помощью него можно разработать ХД в течение всего трех месяцев.
Пакет QuickStart ReportMart for Windows NT, предназначен для построения витрин данных, содержащих данные работающих систем OLTP, для построения сложных аналитических запросов и отчетов. Он содержит Sybase IQ 11.5, а также Replication Agent и Replication Server.
Инструменты разработки трехуровневых систем — подход Sybase
Используя свой многолетний опыт в области выпуска инструментов построения корпоративных приложений, корпорация Sybase предлагает законченное решение для реализации систем в трехуровневых архитектурах. В качестве сервера приложений предлагается Enterprise Application Server (EAServer) — высокопроизводительная среда для исполнения компонентов, реализующих деловую логику информационной системы. Отличительной чертой EAServer является открытость — он поддерживает широкий перечень различных типов компонентов, таких как Java, C/C++, COM/ActiveX, PowerBuilder Non-Visual User Object (PB NVUO). Впечатляет набор операционных систем, поддерживаемых EAServer — это как все варианты 32-разрядных ОС семейства Windows, так и наиболее известные UNIX-платформы (Sun Solaris, Hewlett Packard HP-UX, IBM AIX, а также LINUX). Более подробную информацию о возможностях EAServer можно найти в статье .
В качестве средства разработки приложений для трехуровневой архитектуры предлагается PowerBuilder — инструмент, который без преувеличения можно назвать классикой систем, предназначенных для работы с SQL СУБД. Начиная с первых версий PowerBuilder был средством разработки клиент-серверных приложений, и средством достаточно успешным. Основой его успеха стала удачная технология работы с данными через механизм DataWindow, а также открытость и масштабируемость. Мало какой иной инструмент позволяет работать с таким широким спектром источников данных — от DBF-файлов до корпоративных БД масштаба Sybase SQL Server или Oracle.
Первые возможности для разработки трехуровневых приложений появились в PowerBuilder в середине 90-х годов. С течением времени эта функциональность развивалась и наращивалась, и текущая версия продукта — PowerBuilder 8.0 — предлагает широкие возможности для разработки многоуровневых информационных систем. Одна и та же деловая логика, реализованная средствами PowerBuilder и функционирующая в виде компонентов на EAServer, доступна для использования в любых типах архитектур — как клиент-серверных, так и распределенных, а также и в Интернет. Такие технологии как DataWindow и PowerScript могут использоваться как при разработке обычных Windows-программ, так и при создании бизнес-компонентов, предназначенных для работы в среде EAServer. Более того, предлагаются специальные методики переноса двухуровневых приложений, написанных в прежние годы на PowerBuilder, в трехуровневую архитектуру. Деловая логика таких приложений выносится из клиентских программ и реализуется в виде компонентов для EAServer. Эти компоненты развертываются на сервере приложений, и клиентские программы настраиваются для вызова их методов. За счет того, что в EAServer реализована полная функциональность PBVM (PowerBuilder Virtual Machine), достигается возможность исполнения написанного на PowerBuilder кода на сервере приложений без каких-либо ограничений. Ни один из других представленных на рынке серверов приложений не предлагает разработчикам на PowerBuilder такой возможности. Необходимо отметить, что связка PowerBuilder + EAServer является в настоящее время полнофункциональным и хорошо отлаженным решением, предлагаемым компанией Sybase для реализации многоуровневых информационных систем.
Организация безопасности сервера
Условно структура безопасности Jaguar-сервера делится на две части: аутентификация пользователя и обеспечение защищенного канала связи. Для этого активно задействуются возможности аутентификации операционной системы, на которой запущен сервер, и тунелирование коммуникационных протоколов внутри SSL протокола.
При присоединении клиентского ПО к серверу приложений происходит аутентификация по имени пользователя и паролю, или посредством предъявления электронной подписи SSL сертификата. Для проверки пароля пользователя могут быть использованы реестр пользователей самой операционной системы, внутренняя таблица пользователей Jaguar-сервера или подключаемый пользовательский компонент, специально предназначенный для аутентификации.
Использование SSL протокола для закрытия канала связи одновременно позволяет управлять как уровнем криптографической защиты данных, так и гарантировать распознавание пользователей по выданным им сертификатам с открытым ключом. Использование апробированных криптографических алгоритмов и протоколов гарантирует совместимость слоя безопасности с продуктами третих фирм и обеспечивает надежную защиту информации.
Администратору сервера приложений предоставляются широкие возможности по контролю уровня защиты, на котором осуществляется доступ к контейнеру сервера (package), к его компоненте, или, даже, к отдельному методу компоненты. Иерархическая структура задания атрибутов защиты позволяет разрабатывать полнофункциональные компоненты, контролируя доступ к части функциональности уже на этапе загрузки компонента на Jaguar-сервер средствами администрирования.
PowerStage — инструмент загрузки данных в ХД
В процессе загрузки данных в ХД решаются три взаимосвязанные задачи: сбор данных, их очистка, агрегирование. Сбор данных состоит в организации передачи данных из внешних источников в ХД. Очистка данных — это процесс модификации данных по ходу заполнения ХД, который состоит из следующих последовательных этапов:
- исключение дублирования данных,
- восстановление пропущенных данных,
- приведение данных к единому формату,
- удаление служебной и управляющей информации,
- проверка данных на целостность.
Компания Sybase предлагает свой продукт PowerStage (разработанный на базе ПО DataStage компании VMARK), упрощающий извлечение, очистку, трансформацию и агрегирование данных. Он специально оптимизирован для работы с Sybase IQ.
Dynamic OLAP — новая архитектура для DSS
Dynamic OLAP — это новая архитектура для DSS, предложенная Sybase Inc. Она
базируется на контроле со стороны конечного пользователя процессов построения
и разделения аналитических моделей в масштабируемой среде ХД. Dynamic OLAP
объединяет гибкость и простоту «табличного» похода с масштабируемостью
РСУБД. В отличие от традиционного подхода OLAP, требующего нескольких месяцев
для реализации, Dynamic OLAP обеспечивает построение сложных аналитических
систем в считанные дни. Для реализации Dynamic OLAP компания Sybase предлагает
PowerDimensions, пространственную среду бизнес- моделирования. Последняя содержит
развитые аналитические функции: финансового, статистического, логического анализа,
расчета временных рядов и прочие математические отношения, которые являются
неотъемлемыми атрибутами при построении аналитической модели.
PowerDimensions — это фактически аналитический подход, рожденный из катастрофического
сокращения времени, отпущенного на принятие решения. Единственно возможный
выход — дать аналитикам контроль над процессом моделирования. Сочетание такого
контроля со стороны аналитика с контролем информационного подразделения за
ХД, основанным на других технологических решениях Sybase, обеспечивает сохранение
целостности информации, но не за счет производительности конечного пользователя.
Сервер PowerDimensions может легко интегрируется в существующую инфраструктуру
и показывает в сочетании с Sybase IQ рекордную в отрасли производительность.
Таблица 1. Матрица технологий Sybase для создания ХД и ВД
Категория | Технология Sybase |
---|---|
Проектирование, разработка | PowerDesigner — интегрированный набор средств проектирования; |
Сбор данных | Семейство программных технологий Sybase EnterpriseCONNECT, в том числе Replication Server, Replication Agents, OmniCONNECT; |
Загрузка данных в хранилище
|
PowerStage — автоматизация выборки, очистки, трансформации данных из разнородных оперативных БД;Adaptive Server Enterprise — СУБД масштаба предприятия;Adaptive Server Anywhere — CУБД масштаба департамента |
Витрины данных |
Adaptive Server IQ — Оптимизированная СУБД для хранилищ и витрин данных; |
Анализ данных, построение модели бизнеса |
PowerDimensions — пространственная среда моделирования модели бизнеса; |
Администрирование, управление мета данными |
Warehouse Control Center, Carleton Passport, Informatica PowerMart, Intellidex MetaCenter, Prism Warehouse Manager и другие; |
Методология |
SAFE/DW, учебные курсы по технологиям хранилищ данных и витрин данных; |
См. Также
- Разработка программного обеспечения
- Компонентная разработка программного обеспечения
- Распределенные вычисления
- Переносимый объект
- Сервис ориентированная архитектура (SOA)
- Программные технологии на основе компонентов
- Freedesktop.org D-Bus — текущая открытая межъязыковая кроссплатформенная объектная модель
- GNOME Bonobo — устаревшая межъязыковая объектная модель GNOME
- KDE DCOP — устаревшая система межпроцессного взаимодействия и взаимодействия компонентов программного обеспечения KDE
- KDE — Структура компонентов KDE
- Компонентная объектная модель (COM) — Межъязыковая объектная модель только для Microsoft Windows
- DCOM (Distributed COM) — расширение, позволяющее COM работать в сетях
- Common Language Infrastructure — Текущая .NET межъязыковая кроссплатформенная объектная модель
- XPCOM (Cross Platform Component Object Model) — разработана Mozilla для приложений на основе на нем (например, Mozilla Application Suite, SeaMonkey 1.x)
- Системная объектная модель IBM SOM и DSOM — компонентные системы от IBM, используемые в OS / 2 и AIX
- Internet Communications Engine (ICE)
- Вызов удаленного метода Java (Java RMI)
- Платформа Java, Enterprise Edition (Java EE)
- JavaBean
- OpenAIR
- Удаленный вызов процедуры (RPC)
- Windows Communication Foundation (WCF)
- Software Communications Architecture (SCA) — компоненты для встроенных систем, кросс-языковые, кросс-транспорт, кроссплатформенность
- языковые привязки
- языковые привязки
- интерфейс внешней функции
- соглашение о вызовах
- интерфейс динамического вызова
- изменение имени
- интерфейс прикладного программирования — API
- Бинарный интерфейс приложения — ABI
- Сравнение виртуальных машин приложений
- SWIG генератор привязок автоматических интерфейсов с открытым исходным кодом со многих языков на многие языки
Заключение
Данная статья далека от претензий на исчерпывающее изложение возможностей и внутренней архитектуры Jaguar-сервера. Автор лишь попытался кратко обрисовать тот потенциал, который заложен в использовании сервера Jaguar для построения трехуровневой модели ИС. Мощные возможности продукта в данном случае одновременно сочетаются с легкостью первых шагов по переводу ИС на трехуровневую архитектуру. Решения, базирующиеся на поддержке большинства современных корпоративных стандартов и стандартов «де-факто», позволяют строить гарантированно совместимые и надежные системы.
По широте спектра поддерживаемых форматов и стандартов серверу Jaguar на рынке сейчас нет равных. Использованные решения и архитектура продукта позволяют руководителям проектов четко контролировать процесс развития и эксплуатации ИС. А разработчик за счет применения Jaguar-сервера получает возможность задействовать уже имеющийся у него профессиональный опыт в разрезе новых требований времени и рынка.
Решение назревших проблем на уже имеющейся базе, обеспечивающее экономию ресурсов предприятия, — вот то, что дает внедрение Jaguar-сервера, одновременно перемещая ИС предприятия в новую плоскость распределенных вычислений и электронного бизнеса. Поставляемые в комплекте с Jaguar сервером административные и сервисные программы, входящие в состав Enterprise Application Server, позволяют уверенно смотреть в завтрашний день, идя в ногу с современными требованиями рынка и индустрии.
Ссылки по теме
-
Подробней о продуктах компании Sybase
-
Приобрести продукты корпорации Sybase в электронном магазине ITShop.ru
-
Учебные курсы по продуктам корпорации Sybase
- Обратиться в «Интерфейс Ltd.» за дополнительной информацией/по вопросу приобретения