Tibco versus TCP (Encuentro / RV)

Question

No puedo entender qué tiene de especial Tibco.

Su material de marketing enfatiza que TCP es un protocolo de transporte pesimista que no requiere acuse de recibo del cliente. ¿Cómo puede ser esto cierto?

Para mí, Tibco es básicamente un protocolo TCP respaldado por una cola.

¿Puede alguien ayudarme a comprender los principales puntos de venta de Tibco? Estoy a punto de hablar con mi gerente diciéndole que estamos siendo estafados por completo aquí.

Answer 1

Se supone que el valor agregado es la "multidifusión confiable" y la independencia de la plataforma. Toda la arquitectura con rvd en el medio de todo es un poco estúpida, por lo que en mi opinión te están estafando, como a nosotros aquí, y todos los demás les pagan :)

Answer 2

Supongo que vas a usar RV (Rendezvous) ya que ese es su principal protocolo de mensajería.

Este es un protocolo de difusión basado en UDP que es más rápido que TCP, pero aún no necesariamente tiene reconocimiento del cliente.

Existen configuraciones que lo admiten (mensajería certificada), por lo que si se trata de TCP o UDP, realmente depende de lo que intente hacer con él.

El valor que agrega Tibco (BusinessWorks) es que proporciona un diseñador de aplicaciones de middleware simple y directo y facilita la implementación de aplicaciones en un entorno de carga equilibrada y tolerante a fallas. Le ofrece todo tipo de conectores (jabones, http, jdbc, jms, etc.) para conectar lo que necesita y escupirlo en muchos formatos diferentes.

Sería útil si tuviéramos más información sobre para qué tipo de cosas lo usarás.

ps. en lugar de RV, vaya con EMS (una implementación de JMS)

RV vs. EMS:

• RV es UDP, EMS es TCP
• RV está descentralizado: hay un cliente rv en cada host. Excelente para la transmisión de mensajes donde tienes múltiples destinatarios. A menos que use un 'demonio remoto', sus mensajes están contenidos dentro de su subred clase-c, no hay puntos únicos de falla o cuellos de botella,
• EMS está centralizado (concentrador y radio) en un servidor o servidores específicos y puede atravesar subredes sin problemas.
• EMS está sujeto a un SPOF, pero puede agrupar servidores en pares para eliminar esto.
• EMS es mejor para 1-1 o 1-2, pero RV es mucho mejor para 1-muchos

Answer 3

Buena pregunta, pero ¿alguna vez ha intentado conectar 500 consumidores a través de sockets TCP?

Si también tiene una alta tasa de mensajes (> 10k msgs / sec), terminará usando UDP (¡un mensaje para TODOS los consumidores, no copias!). Pero entonces no tiene la confiabilidad de TCP, que es donde entra PGM o TRDP. con tal requisito, encontré TIBCO RV muy útil / lo mejor que sé. La API de C es muy rápida (olvídate de Java si tienes más de 10k msgs / seg).

Por supuesto, podría lanzar su propia multidifusión confiable, pero la API de RV es muy fácil de usar y se traslada a MUCHAS plataformas diferentes. Supongo que la simplicidad de uso es el argumento principal contra TCP. Lleva un día enseñarle a un programador junior cómo escribir una aplicación / pub de RV estable y funcional, lleva un mes hacer lo mismo con TCP.

El propio DVD simplemente se queda allí y es invisible, entonces, ¿por qué te preocupas por eso?

Si el despliegue no es un problema (escenario 1-1 o incluso 1-5), busque TIBCO EMS (u otro proveedor de JMS) o AMQP.

Y otra ventaja real sobre TCP son los temas (o temas JMS). Si está integrando 20 aplicaciones diferentes, eso ayuda mucho.

Answer 4

Realmente depende de quién eres y cuáles son tus objetivos. Mi familiaridad con TIBCO es que era un sistema de mensajería utilizado por muchos de nuestros competidores en las industrias de servicios financieros para enviar mensajes de forma segura desde los front-end basados ??en la web de regreso al mainframe para su procesamiento, y para entregar cosas como cotizaciones de acciones a nuestro front-end.

Teníamos nuestro propio producto de mensajería que tenía un extraño parecido con un producto de mensajería en el que uno de los superiores de nuestra empresa trabajó anteriormente :)

Teníamos un presupuesto de tecnología de 300 millones, pero tenga en cuenta que también teníamos 2 grandes centros de datos y varios centros de producción, así como 3 oficinas para el desarrollo.

Ahora, una empresa en nuestra situación podría encontrar un buen negocio para usar algo como TIBCO de fábrica (probablemente podríamos haber ahorrado una parte sustancial de esos 300 millones).

Si no tiene ese tipo de presupuesto y sus demandas son mucho menores, entonces para usted podría ser una "estafa". Pero, para desarrollar ese tipo de sistema usted mismo, para una organización como la que trabajé ... Estoy seguro de que usaría una parte sustancial de esos 300 millones.