GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
B2B-площадки(23570)
Системы электронной коммерции(20557)
Как обмен сообщениями решает проблемы современного бизнеса(13812)
Я зарегистрировался на B2B сайте – что дальше?(13383)
Сколько можно заработать, создавая сайты для американцев(11938)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » Business-To-Business (B2B) » Как обмен сообщениями решает проблемы современного бизнеса

Как обмен сообщениями решает проблемы современного бизнеса


Progress Software
http://www.progresssoftware.ru/

Вступление

Современные организации постоянно ищут пути совершенствования эффективности, и поэтому постоянно оценивают уровень своих возможностей и недостатков. Глобальное присутствие в онлайне и совершенствование технологий предоставляет больше и больше вариантов эксплуатации систем для управления бизнесом. Оценка этих возможностей по эксплуатации систем нуждается в понимании тех ключевых факторов, которые влияют на принятие инфраструктурных решений. Эта статья призвана показать одну из таких инфраструктур - платформу обмена сообщениями. Это описание призвано в простых терминах показать, как работает эта технология, и рассказать о различных проблемах современных организаций, решаемых сегодня с помощью передачи сообщений. Статья описывает различные типы реализации технологии обмена сообщениями и сравнение с альтернативой - RPC-механизмом (удаленный вызов процедур). Когда стоит вопрос о выборе реализации обмена сообщениями, вы должны взвесить ряд критериев, чтобы выбрать соответствующий вашим требованиям продукт. Эта статья призвана предупредить аналитика, принимающего решение по этому вопросу, о ключевых требованиях, которым стоит уделить пристальное внимание.

Что есть технология обмена сообщениями?

По своей сути, платформа обмена сообщениями - это технология, позволяющая двум разнесенным объектам обмениваться сообщениями. Как почтовые системы E-Mail позволяют обмениваться информацией между двумя или более людьми, так и платформа обмена сообщениями позволяет наладить коммуникацию между двумя и более приложениями, без требования участия в этой коммуникации людей. Эти приложения могут располагаться независимо на различных аппаратных платформах.

Рисунок 1. 0

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

Один из фундаментальнейших аспектов обмена сообщениями - их асинхронная природа: посылающий сообщение не должен ожидать получения информации адресатом. Возвращаясь назад к аналогии с E-Mail, если сообщение было послано, посылающий не ждет ответа незамедлительно и в это время может продолжать свою работу. Посылающие приложения могут свободно слать сообщения с приемлемой скоростью, не ожидая момента, когда их сообщения будут обработаны и придет ответ. Тем не менее, возможны ситуации, когда требуется синхронная коммуникация (например, ожидание результата сложной математической операции, перед принятием решения). В этих случаях, очень важно, чтобы реализация системы сообщений поддерживала данный тип коммуникации.

Обмен сообщениями используется сегодня очень широко в технологиях бизнес-бизнес (B2B) и бизнес-покупатель (B2C), причем зачастую через Интернет.

Какие проблемы решает возможность обмена сообщениями?

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

Беспрецедентная системная интеграция

В мире бизнеса слияния и объединения происходят ежедневно. Чаще всего объединяющиеся организации имеют различные системы управления, настроенные на бизнес-практику каждой из компаний. Заставить одну из организаций принять внутреннюю бизнес-систему другой для того, чтобы работать в одном поле данных, зачастую очень затратно и губительно для бизнеса. Люди, принимающие решения о слиянии, часто подразумевают, что требование о сосуществовании этих систем является главным для осуществления такого объединения. Интеграция между приложениями часто требуется и в обыденной жизни предприятия. Специальные программы, обслуживающие техпроцессы, MRP и финансовые приложения, часто используют гетерогенные платформы и должны быть объединены в единое информационное пространство. В этих случаях требуется недорогое, легко внедряемое и гибкое решение. Именно здесь и находят свое применение технологии обмена сообщениями, так как они практически не требуют вносить какие-либо изменения в работающие приложения для обеспечения надежной коммуникации между ними. Таким образом, они являются эффективным решением для обеспечения коммуникации между любым видами приложений на различных платформах.

Обмен информацией между бизнес-партнерами

Успешное управление бизнесом требует налаженного взаимодействия со многими бизнес-партнерами - как со стороны поставок, так и со стороны закупок. Все партнеры постоянно обмениваются информацией, но не всегда надежно. Например, возникают следующие ситуации:

  • Коммерческие предложения высылаются при помощи факсов и могут быть легко утеряны.
  • Телефонный звонок делается, чтобы узнать о состоянии счета, но менеджер ушел обедать.
  • E-Mail используется для того, чтобы заказать товар, но номер заказа неправильно введен в торговую систему.

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

Автоматизация функций бизнеса

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

Рисунок 2.

Рисунок 2 показывает схему, когда производитель информирует продавцов о скидке на один из товаров. Эта информация посылается через сообщение в систему управления магазином. Система магазина определяет по бизнес-правилам валиден ли заказ и, если валиден, резервирует необходимое количество товара на складской базе.

Трудности при создании приложений нового поколения

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

Рисунок 3.

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

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

Глобальные бизнес-транзакции

При современной глобализации экономики, организации думают и работают на глобальном уровне. Работа на мировом рынке ставит дополнительные наборы проблем. Как будут взаимодействовать системы? Как удержать себестоимость? Как администрировать разнесенные приложения? Технология управления сообщениями удовлетворяет требованиям работы с разнесенными организациями.

Рисунок 4.

Рисунок 4 показывает пример географически распределенного развертывания. Организация имеет региональные представительства в Америке, Европе, и в Азиатском регионе. Каждое из этих представительств обслуживают локальные офисы в этих странах. Системы управления в региональных представительствах работают независимо друг от друга, но они должны регулярно обмениваться между собой информацией. Это распределение требует наличие системы обмена сообщениями, которая предоставляет возможность высокоскоростного обмена информацией между разнесенными локальными офисами региональных представительств, так как и между самими представительствами.

Какие варианты реализаций технологии обмена сообщениями существуют сегодня?

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

Архитектуры Hub-and-spoke

В архитектуре hub-and-spoke (звезда), все приложения подсоединены к центральному процессу, называемому сервером сообщений. Сервер сообщений обслуживает все коммуникации среди подсоединенных приложений и вызывает клиента приложения. Сервер сообщений ответственен за корректную пересылку сообщений, аутентификацию и авторизацию пользовательского доступа, а также за гарантию доставки сообщений. Каждый из клиентов приложений может быть как приемником сообщений, так и их передатчиком или тем и другим.

Выигрыш при использовании этой архитектуры следующий:
  • Уменьшается количество необходимых сетевых подключений. Для того, чтобы послать сообщение любому из клиентов, каждому из них требуется подключение только к серверу сообщений.
  • Гибкое развертывание клиента. Так как сервер сообщений обслуживает весь обмен данными, сервера и клиенты не связаны напрямую друг с другом, и могут быть перемещены и переконфигурированы с минимальным влиянием на систему обмена сообщениями.
  • Минимальные требования к программному обеспечению на клиенте приложения. В связи с тем, что бОльшая часть логики управления сообщениями работает на сервере сообщений, гораздо меньше программного обеспечения может требоваться на клиентах приложений для обеспечения коммуникации.
Рисунок 5.

Рисунок 5 показывает базовую топологию архитектуры hub-and-spoke. Тем не менее, в практических реализациях, сервер сообщений состоит из нескольких процессов, часто на разнесенных машинах, которые формируют единый логический сервер сообщений. Эта мультипроцессная конфигурация называется кластерной. Кластеры поддерживают высокий уровень сопротивляемости сбоям; если один конкретный сервер отключается - клиенты приложений могут подключиться к другому серверу кластерной архитектуры.

Магистральная архитектура

В магистральной архитектуре (bus architecture), нет единого централизованного сервера сообщений, координирующего доставку сообщений. Взамен, каждый клиент приложения содержит функциональность, обычно принадлежащую серверу сообщений (такую как гарантию доставки, поддержку транзакций и безопасности). Все клиенты приложений подключены к единой магистрали сообщений, обычно - к особому уровню сетевого IP протокола. Этот уровень обеспечивает прохождение сообщений между клиентами, но клиентам необходимо самим заботиться, чтобы сообщение доставлялось надежно и с соблюдением мер безопасности.

Рисунок 6.

Рисунок 6 показывает типичную реализацию магистральной архитектуры. Все клиенты приложений могут взаимодействовать посредством магистрали сообщений. Магистраль поддерживает всю маршрутизацию, таким образом, каждый клиент не имеет данных о местонахождении других клиентов. Один главный недостаток использования группы (multicast) в магистральной архитектуре то, что администраторы могут запретить передачу сообщений через их модуль безопасности (firewall). Таким образом, если развертывание системы предполагается через Интернет, избегайте использования multicast и магистральной архитектуры.

Что можно сказать о механизме дистанционного вызова процедур (RPC)?

Сообщения - не единственный путь для коммуникации между приложениями. Другие технологии, такие как CORBA, Java's RMI, and Microsoft's DCOM, все они используют дистанционный вызов процедур (RPC) - механизм для переноса информации между приложениями.

Рисунок 7.

Рисунок 7 показывает типичную реализацию RPC-механизма. В этой топологии, клиенты и серверы полностью взаимосвязаны для симуляции одного общего процесса. Все входящие в технологию компоненты, должны иметь полную информацию друг о друге, и все подключения должны произойти до начала обмена данными. Если вам необходимо добавить клиента приложения к этой топологии, все остальные участники должны быть настроены на нового клиента, и вы должны обеспечить сетевые подключения к каждому из клиентов. Когда большое число клиентов приложений участвует в архитектуре, топология становится очень сложной. Сравните вышеизложенную архитектуру с топологией поддержки безотказных связок, требующуюся для поддержки асинхронного механизма обмена сообщениями на следующем рисунке:

Рисунок 8.

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

Какие существуют реализации обмена сообщениями?

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

Мультидоменная поддержка

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

Модель Publish-and-subscribe

Publish-and-subscribe - pub/sub (публикация по подписке) - суть модели состоит в том, что посылающее приложение или публикатор передает отдельно взятое сообщение нескольким принимающим приложениям, или подписчикам.

Рисунок 9.

Рисунок 9 показывает один-ко-многим метод в pub/sub модели. Издатель шлет сообщение в тему, которая расположена на сервере сообщений. Сервер сообщений затем доставляет это сообщение всем подписчикам, которые подписались на эту тему. Механизм pub/sub используется, когда вы хотите транслировать ту же самую информацию широкой аудитории. Например, обновления индекса цен по акциям, уведомления о промоушенах, запросы коммерческих предложений.

Модель Point-to-point

В модели point-to-point (P2P) - точка-к-точке, организован обмен информацией между посылающим приложением - передатчик и одним реципиентом - приемник.

Рисунок 10.

Рисунок 10 показывает простую P2P модель. Одиночный передатчик посылает сообщение в очередь, которая расположена на сервере сообщений. В этом случае, два приемника зарегистрировались в сервере сообщений как потенциальные потребители информации в этой очереди. Первый приемник, опросивший первым очередь, принимает сообщение. Если приемник принял сообщение, оно исчезает из очереди, и ни один приемник не может более получить это сообщение. P2P модель применяется, когда сообщения используются одноразово. Например, установка цен на акции, отправка заказов или резервация билетов.

Гарантированная доставка

Системы критичные к надежности виды бизнесов требуют надежных линий коммуникаций, и Интернет не может рассматриваться как такая линия. Нет никакого преимущества в распространении информации со скоростью света, если нет гарантии доставки ее реципиенту. Реализация сервера сообщений должна поддерживать различные уровни сервиса для обеспечения гарантированной доставки сообщений. Критична ли информация, что сообщение было получено? В случае установки цен на акции, это не важно - следующее изменение будет скоро опубликовано, но для случая торгового заказа на акции, посылающий должен быть уверен, что его заказ получен и будет выполнен.

Развитые функции безопасности

Говоря о безопасности транзакций, Интернет ассоциируется с прорывами защит известных игроков на рынке. Сегодня существуют ежедневные отчеты о международных преступлениях против различных организаций. В то время когда все больше и больше бизнес-процессов управляются через Интернет, участники должны быть уверены, что информация будет передана только тем, кто авторизован для ее получения. Реализация обмена сообщениями должна быть способна поддерживать многочисленные архитектуры безопасности, которые требуются для работы через Интернет. Эти архитектуры включают поддержку SSL, авторизацию и аутентификацию, и технологии файерволов. Без поддержки этих технологий пользователи рискуют, передавая информацию через небезопасный канал.

Массивная масштабируемость

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

Стандарты реализаций

Спецификация Java Message Service (JMS), созданная Sun Microsystems, определяет, как клиенты и серверы общаются в асинхронной среде. Этот стандарт стал общепринятым для рынка Middleware. Реализацию сервера сообщений, придерживающуюся последних открытых стандартов в связи и дизайне приложений, гораздо легче разработать, чем ту, которая требует специальные патентованные знания. JAVA-программист может легко понять спецификацию и писать под Java-based интерфейс. Таким образом, патентованные системы, такие как IBM's MQSeries, требуют детальных программистских знаний, специфичных для этого продукта. Найти и нанять таких программистов представляет значительные трудности, не говоря уже о затратах.

ЕXtensible Markup Language (XML) - быстроразвивающийся язык, стал общепринятым для бизнеса через Интернет. XML позволяет обеспечить стандартное форматирование передаваемых данных, для того, чтобы любое приложение могло без специальной обработки "понимать" информацию, находящуюся в XML-файле.

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

Связь с другими системами обмена сообщениями

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

Нейтральность сервера приложений

Сервера приложений широко используются для централизации вычислений на наиболее мощных машинах. Некоторые сервера приложений имеют инфраструктуры для обмена сообщениями, которые позволяют им связываться с другими приложениями в асинхронном режиме, и легко взаимодействовать встроенными интерфейсами. Однако использование встроенных функций обмена сообщениями значит, что в каждый из узлов этой технологии требуется реализовать сервер сообщений. Процессорное время, которое требуется для сервера сообщений, вместе со стоимостью поддержки и управления такой технологией, перевесят любые преимущества, которые эта технология может противопоставить отдельной, невстроенной реализации технологии обмена сообщениями. Реализация сервера сообщений не должна полагаться на сервер приложений для обеспечения нормальной работы инфраструктуры для обмена сообщениями. Тем не менее, реализация обмена сообщениями должна сосуществовать с архитектурой серверов приложений там, где эта технология востребована.

Глобальная поддержка производителей

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

Каким образом работает реализация SonicMQ?

SonicMQ от корпорации Sonic Software - это 100% Java сервер сообщений, базирующийся на стандарте JMS. Он предоставляет поддержку обоих моделей (publish-and-subscribe и point-to-point), через архитектуру hub-and-spoke (звезда). Для облегчения загрузки от потенциально тысяч соединений клиентов к одному серверу сообщений, реализация SonicMQ поддерживает кластерную архитектуру серверов, показанную на рисунке 11:

Рисунок 11.

В этой кластерной технологии, каждый из серверов сообщений SonicMQ подсоединен к каждому из других серверов SonicMQ в кластере. Подсоединение к любому из серверов сообщений в кластере клиента приложения позволяет передавать сообщения любому другому клиенту приложения, подсоединенному к любому из серверов сообщений в кластере. Клиенты приложений, не имеют информации друг о друге, и взаимном нахождении. Они просто направляют сообщения к серверу SonicMQ, который и определяет как и каким маршрутом будет доставлено сообщение клиенту-адресату. Кластерные технологии чаще всего используются для разделения нагрузки по нескольким машинам, потому сервера могут быть на разных машинах, являясь частью кластера. Это позволяет управлять бизнес-транзакциями глобально, потому что нет никаких географических ограничений на местонахождение серверов кластера, и посылающие сообщения клиенты не имеют никакой информации о местах нахождения принимающих эти сообщения. Кластерные технологии также добавляют некоторую избыточность. Если один из серверов откажет, по любым причинам, клиенты могут переподсоединиться к любой из работающих в кластере машин и продолжить работу. Тем не менее, существуют некоторые унаследованные трудности в кластерных топологиях. Каждый из серверов подключен к каждому другому серверу в кластере. Если требуется большое количество серверов в кластере, это может потребовать сложных топологий соединений, которые могут стать неуправляемыми. Если сервер не очень загружен, он отнимает ресурсы сети. Также, для того, чтобы установить эти сетевые соединения, сервера должны иметь информацию о безопасности доступа каждого из серверов. Обобщать такого рода информацию неприемлемо. Для решения этих вопросов SonicMQ представляет динамическую архитектуру маршрутизации - Dynamic Routing Architecture (DRA). DRA позволяет серверам и кластерам оперировать независимо от друг друга, но позволять им объединяться, когда потребуется.

Рисунок 12.

Рисунок 12 показывает базовую реализацию DRA. Одиночный сервер SonicMQ на левой части рисунка доставляет сообщения между двумя клиентами приложений. Справа, кластер SonicMQ, состоящий из двух серверов маршрутизируют сообщения между клиентами. Каждая из этих систем - отдельный SonicMQ-домен, работающий независимо от других. Когда сообщение из одного домена должно быть маршрутизировано в другой домен, SonicMQ's DRA устанавливает динамическое соединение между ними так, что информация может быть переслана в нужный домен. Когда связь завершена, соединение между доменами может быть разорвано. Системы работают быстрей, поскольку "дорогие" ресурсы высвобождаются. Теперь целый домен может быть перемещен или заменен без влияния на работу других доменов и лишь ограниченная информация о безопасном доступе соединения распространяется по сети. С реализацией SonicMQ's DRA, организации могут легко разрабатывать и развертывать виртуальные торговые площадки, а также управлять глобальным бизнесом с наименьшими затратами. Поддержка XML-форматированных сообщений делает SonicMQ приемлемым для кросс-организационных применений, также как и для кросс-приложений. Возможность подсоединения к другим системам обмена сообщениями доступна с помощью серий Мостов (Bridges) для SonicMQ. Эти мосты позволяют осуществить двунаправленную коммуникацию между системами SonicMQ и другими инфраструктурами.

На сегодняшний день доступны мосты и клиенты:
  • SonicMQ Bridge для MQSeries. Позволяет организовать двунаправленную коммуникацию через "родной" интерфейс к IBM's MQSeries
  • SonicMQ Bridge для TIBCO TIB/Rendezvous. Аналогично SonicMQ Bridge для MQSeries
  • SonicMQ Bridge для JMS. Позволяет организовать двунаправленную коммуникацию к широкому спектру реализаций для обмена сообщениями, использующими JMS стандарт.
  • SonicMQ Bridge для FTP. Позволяет превратить FTP в систему обмена сообщениями. Гарантированно доставлять файлы.
  • SonicMQ Bridge для E-Mail. Позволяет системе e-mail слать письма внутри инфраструктуры обмена сообщениями, гарантированно доставлять e-mail сообщения.
  • SonicMQ C/C++ Client
  • SonicMQ COM/ActiveX Client
  • 4GL Client

SonicMQ разработан компанией Sonic Software Corporation, независимым подразделением холдинга Progress Software Corporation.

Итоги

Системы E-Mail долго использовались и используются для установления коммуникации между людьми. Тот же самый уровень взаимодействия сегодня требуется между приложениями. Системы управления сообщениями имеют большую популярность, как технологии, позволяющие осуществить взаимодействие приложений и быть решением большого набора современных проблем бизнеса. Последние реализации систем обмена сообщениями, такие как SonicMQ, предлагают богатую функциональность, как простым задачам интеграции приложений, так и сложным, распределенным в мировом масштабе виртуальным торговым площадкам и порталам, предоставляя массивную масштабируемость, надежность 24х7 и серьезную систему безопасности, требующуюся для подобных систем.

 
27.02.2003
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.