Для интеграции в реальном времени существующий пакетный метод нужно заменить на процессы, которые непрерывно отслеживают состояние исходных систем, фиксируют и преобразуют изменения в данных по мере их возникновения, а затем загружают эти изменения в Хранилище; и чем режим их работы ближе к реальному времени, тем лучше.
В последнее время новые технологии, такие как передача сообщений (messaging) и интеграция корпоративных приложений (EAI), обеспечили лучшие возможности построения активных Хранилищ данных и более качественную интегрированную аналитику.
XML и обмен сообщениями
В конце 90-х компании рассматривали XML как универсальное средство для передачи своевременных транзакционных данных в Хранилище. Идея состояла в том, чтобы по мере возникновения транзакций обеспечивать постоянные синхронные обновления систем поддержки принятия решений. Но, хотя эта концепция и казалась простой, у нее есть ряд скрытых особенностей. Во-первых, для каждой операции транзакционная система должна генерировать документ в фиксированном формате, а это может оказаться затратным по времени. Во-вторых, документы часто становятся большими по объему за счет тэгов и метаданных. Например, транзакции на основе протокола XMPP (extensible messaging and presence protocol — расширяемого протокола сообщений и присутствия) содержат для каждой точки данных открывающие и закрывающие тэги.
|
|
То есть сама запись содержит только 8 символов, а передаваемый документ — 55 символов. Еще больший объем возникает в результате описания типов, заголовков и т.п. В результате XML-протоколы не могут широко использоваться в очень крупных Хранилищах, куда поступают миллионы транзакций в день. Однако XML очень удобен при передаче коротких сообщений, а также и в web-приложениях для передачи транзакций в СУБД.
Отдельные поставщики выбрали иной подход к обмену сообщениями и создали стандарты интерфейсов, такие как электронный обмен данными (electronic data interchange — EDI), или IDocs, которые упрощают форматирование и передачу транзакционных записей. Сокращение накладных расходов, связанное с использованием этих форматов, позволило компаниям автоматически передавать записи в свои вновь созданные Хранилища в реальном времени.
Мгновенная передача сообщений для операционной отчетности в Хранилище данных
В 2003 году, основными претендентами в стандартизации мгновенной передачи сообщений были XMPP и SIMPLE.
Как уже говорилось, XMPP удобен для обработки коротких записей, например SMS-трафика. Но вызывает серьезные накладные расходы при передачи больших объемов транзакций. С другой стороны, недостаток его конкурента (SIMPLE) состоит в том, что он обеспечивает поддержку для простых текстовых сообщений, но не работает для других форматов.Поэтому каждому поставщику приходится разрабатывать свои собственные расширения, которые в итоге оказываются несовместимыми. Еще одна проблема с протоколом SIMPLE — это поддержка протоколов старых пользовательских данных (user data protocol — UDP), а также протокола TCP на уровне передачи. Поскольку UDP не предусматривает серьезного контроля качества, то пакеты данных могут быть потеряны, а возможности возобновления и контроля процесса ограничены. Это очень плохо для крупных систем отчетности, качество работы которых напрямую зависит о своевременных, точных и полных данных.
|
|
Таким образом, первые версии SIMPLE не получили широкого применения для Хранилищ данных в реальном времени и систем отчетности.
Microsoft становится поставщиком средств интеграции приложений
Хотя с протоколом SIMPLE возникает ряд проблем, тем не менее, он стал хорошей платформой для многих поставщиков. В 2003 году компания Microsoft разработала проект под названием Real-Time Communication Server, расширяющий протокол SIMPLE. А в 2004 году была запущена новая версия продукта для передачи сообщений, известного под названием BizTalk Server 2004. Он был призван решать две важные цели. В первую очередь, предполагалось обеспечение интеграции B2B[1]. Во-вторых, этот продукт должен был стать платформой для интеграции корпоративных приложений, в том числе транзакционных систем и средств отчетности внутри организации.
Компания Microsoft обеспечила более удобную альтернативу очень сложному процессу стандартизации, который охватывал несколько десятков пересекающихся стандартов и подходов к EAI. Ключевая архитектура BizTalk Server — это упрощенная серверная система. Для поддержки принятия решений в EAI инфраструктуре Biztalk обеспечивает услуги бизнес-операций (Business Activity Services — BAS), устанавливаемые на исходной системе для обеспечения сообщений. Кроме того, администратор Хранилища может отслеживать процесс загрузки из нескольких исходных систем, используя инструмент мониторинга бизнес-операций (BAM), входящий в состав Biztalk.
Biztalk 2004 был хорошим шагом вперед в области EAI. В процессе развития продукт был дополнен средствами балансировки загрузки сети (network load balancing — NLB) и расширенной консолью управления (enhanced management console — MMC), предназначенной для удаленного управления и конфигурирования множество исходных систем с установленной услугой BAS. В 2006 году вышла новая версия BizTalk Server 2006, вобравшая в себя ряд конструктивных изменений.
***Х***ня какая-то, но больше ниче не нашла!!!!!!