Тибко против ПТС (Рандеву / Р.В.) - PullRequest
16 голосов
/ 15 сентября 2009

Я не могу понять, что такого особенного в Тибко.

В их маркетинговых материалах подчеркивается, что TCP является пессимистичным транспортным протоколом, который не требует подтверждения клиента о получении. Как это может быть правдой?

Для меня Tibco - это, в основном, протокол TCP, поддерживаемый очередью.

Может кто-нибудь помочь мне разобраться в основных моментах продажи Tibco? Я собираюсь разглагольствовать на моего менеджера, рассказывающего ему, что нас здесь полностью разграбили.

Ответы [ 4 ]

19 голосов
/ 16 сентября 2009

Я предполагаю, что вы собираетесь использовать RV (Rendezvous), поскольку это их основной протокол обмена сообщениями.

Это широковещательный протокол на основе UDP, который работает быстрее, чем TCP, но при этом не обязательно имеет подтверждение клиента.

Существуют его конфигурации, которые поддерживают его (сертифицированный обмен сообщениями), так что, будь то TCP против UDP, это действительно зависит от того, что вы пытаетесь с ним сделать.

Значение, которое добавляет Tibco (BusinessWorks), заключается в том, что он предоставляет простой и понятный конструктор приложений промежуточного программного обеспечения и упрощает развертывание приложений в среде с балансировкой нагрузки и отказоустойчивой средой. Он предоставляет вам всевозможные разъемы (soap, http, jdbc, jms и т. Д.) Для подключения к тому, что вам нужно, и выкладывания его во множество различных форматов.

Было бы полезно, если бы у нас было больше информации о том, для чего вы будете его использовать.

пс. вместо RV перейдите с EMS (реализация JMS.)

RV против EMS:

  • RV - это UDP, EMS - это TCP
  • RV децентрализован: на каждом хосте есть клиент rv. Отлично подходит для трансляции сообщений, когда у вас есть несколько получателей. Если вы не используете «удаленного демона», ваши сообщения содержатся в вашей подсети класса c, нет единой точки отказа или узких мест,
  • EMS централизована (концентратор и луч) на определенном сервере (ах) и может без проблем проходить через подсети.
  • На EMS распространяется действие SPOF, но вы можете объединить серверы в пары для устранения этого.
  • EMS лучше для 1-1 или 1-2, но RV намного лучше для 1-многих
18 голосов
/ 16 сентября 2009

Предполагается, что добавленной стоимостью будет «надежная многоадресная передача» и независимость от платформы. Вся архитектура с rvd в центре всего - какая-то глупость, так что, на мой взгляд, вас обманывают, как и нас здесь, и все остальные платят им :)

7 голосов
/ 17 апреля 2012

Хороший вопрос - но вы когда-нибудь пытались подключить 500 потребителей через TCP-сокеты?

Если у вас также есть высокая скорость передачи сообщений (> 10 кбит / с), вы в конечном итоге будете использовать UDP (одно сообщение для ВСЕХ потребителей, а не копий!). Но тогда вы не обладаете надежностью TCP, в которую входят PGM или TRDP. с таким требованием я нашел TIBCO RV очень полезным / лучшим, что я знаю. C API очень быстр (забудьте о Java, если вы превышаете 10k msgs / sec).

Конечно, вы можете создать собственную надежную многоадресную рассылку, но API RV очень прост в использовании и перенесен на МНОГИЕ разные платформы. Я предполагаю, что простота использования - главный аргумент против TCP. Требуется день, чтобы научить младшего программиста писать стабильное и работающее приложение Pub / Sub RV, и месяц занимает то же самое с TCP.

Сам РВД просто сидит там и невидим, так зачем вам беспокоиться об этом?

Если разветвление не является проблемой (сценарий 1-1 или даже 1-5), посмотрите вместо этого на TIBCO EMS (или другого поставщика JMS) или, возможно, на AMQP.

И еще одно реальное преимущество над TCP - это темы (или темы JMS). Если вы интегрируете 20 различных приложений, это очень помогает.

5 голосов
/ 16 сентября 2009

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

У нас был собственный продукт для обмена сообщениями, который странно напоминал продукт для обмена сообщениями, над которым ранее работал один из руководителей нашей компании:)

У нас был технологический бюджет в 300 миллионов, но имейте в виду, у нас также было 2 больших центра обработки данных и несколько производственных центров, а также 3 офиса для разработки.

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

Если у вас нет такого бюджета и ваши требования намного меньше, то для вас это действительно может быть «грабежом». Но, чтобы разработать такую ​​систему самостоятельно, для организации, подобной той, в которой я работал ... Я уверен, что она использовала бы значительную часть этих 300 миллионов.

...