Я не могу понять, что особенно важно в Тибко.
В их маркетинговых материалах подчеркивается, что TCP - это пессимистический транспортный протокол, который не требует подтверждения клиента о получении. Как это может быть правдой?
Для меня Tibco - это в основном протокол TCP, поддерживаемый очередью.
Может кто-нибудь, пожалуйста, помогите мне понять основные пункты продаж Tibco? Я собираюсь рассказать моему менеджеру, говоря ему, что мы полностью сорваны здесь.
Добавленная стоимость должна быть "надежной многоадресной" и независимой от платформы. Вся архитектура с rvd в середине всего выглядит глупо, поэтому, на мой взгляд, вас срывают, как и мы здесь, и все остальные платит им:)
Я предполагаю, что вы собираетесь использовать RV (Rendezvous), поскольку это их основной протокол обмена сообщениями.
Это широковещательный протокол, основанный на UDP, который быстрее, чем TCP, но при этом не обязательно имеет подтверждение клиента.
Существуют конфигурации, которые поддерживают его (сертифицированный обмен сообщениями), поэтому будь то TCP против UDP, это действительно зависит от того, что вы пытаетесь с ним сделать.
Значение, добавленное Tibco (BusinessWorks), заключается в том, что он предоставляет простой, простой разработчик приложений промежуточного программного обеспечения и упрощает развертывание приложений в сбалансированной нагрузке и отказоустойчивой среде. Он дает вам всевозможные разъемы (мыло, http, jdbc, jms и т.д.), Чтобы подключиться к тому, что вам нужно, и выплюнуть его из разных форматов.
Это поможет, если у нас будет больше информации о том, какие вещи вы будете использовать для этого.
пс. вместо RV, перейдите к EMS (реализация JMS.)
RV против EMS:
Хороший вопрос - а вы когда-нибудь пытались подключить 500 потребителей через TCP-сокеты?
Если у вас также есть высокая скорость передачи сообщений ( > 10k msgs/sec), вы получите UDP (одно сообщение для ВСЕХ потребителей, а не копии!). Но тогда у вас нет надежности TCP, в которой находится PGM или TRDP. с таким требованием я нашел TIBCO RV очень полезным/лучшим, что знаю. API C очень быстр (забудьте о Java, если вы превысили 10k msgs/sec).
Конечно, вы можете перевернуть свою собственную надежную многоадресную рассылку, но API RV очень прост в использовании и портирован для МНОГИХ различных платформ. Я думаю, что простота использования - главный аргумент против TCP. Требуется один день, чтобы научить младшего программиста, как писать стабильное и работающее приложение RV pub/sub, требуется месяц, чтобы сделать то же самое с TCP.
Сама rvd просто сидит там и невидима, так почему бы вам побеспокоиться об этом?
Если разветвление не является проблемой (сценарий 1-1 или даже 1-5), посмотрите вместо TIBCO EMS (или другого поставщика JMS) или, возможно, AMQP.
И другое реальное преимущество над TCP - это темы (или темы JMS). Если вы интегрируете 20 различных приложений, это очень помогает.
Это действительно зависит от того, кто вы и каковы ваши цели. Мое знакомство с TIBCO заключается в том, что это была система обмена сообщениями, используемая многими нашими конкурентами в отраслях финансовых услуг для безопасного отправления сообщений с веб-интерфейсов до мейнфрейма для обработки и доставки таких вещей, как котировки акций на наш интерфейс.
У нас был наш собственный продукт обмена сообщениями, который имел странное сходство с продуктом обмена сообщениями, с которым ранее работал один из вышеперечисленных в нашей компании:)
У нас был 300-миллионный технологический бюджет, но имейте в виду, что у нас также было 2 крупных центра обработки данных и несколько производственных центров, а также 3 ветки для развития.
Теперь компания в нашей ситуации может найти неплохо использовать что-то вроде TIBCO из коробки (мы, вероятно, могли бы сэкономить значительную часть этих 300 миллионов).
Если у вас нет такого бюджета, и ваши требования намного меньше, то для вас это действительно может быть "рипфом". Но, чтобы разработать такую систему самостоятельно, для такой организации, как та, на которой я работал... Я уверен, что она будет использовать существенный кусок из 300 миллионов.