Ultra Messaging Technical Product Overview 1
Overview What is messaging? Tibco RV, Tibco EMS, IBM MQ, ActiveMQ, MSMQ, etc. Overview of Ultra Messaging Future Proof Design for the Enterprise Parallel Persistence Queuing Load Balancing Caching LAN/WAN Bridging & Desktop Fan-out Extending UM over the Web Management Monitoring 2
How to move data from A to B? 3
Legacy Server-Based Designs Sending CPU Messaging Server CPU Receiving CPU Application A Comm Library App Network Message Router App Network Application B Comm Library App Network TCP TCP Network Message Server CPU is a performance bottleneck TCP doesn t scale, delivery not fair 4 4
Legacy Daemon-Based Design Sending CPU Receiving CPU Application A Comm Library Local Daemon Local Daemon Application B Comm Library TCP Loopback TCP Loopback UDP Reliable Multicast LAN NAK storm problems Crybaby receiver problems More daemons required for receivers on other LANs 5 5
Messaging Choke Points Server-Based Designs Daemon-Based Designs 6 6
Legacy Designs Choke Points Messages must move through central servers or brokers Local daemons slow delivery by introducing overhead Scalability Issues Servers and brokers can only handle so much load Made worse by aggregating all of the message traffic through the points Single points of failure Failure of a server or broker can cripple the entire message system 7
EMS (Enterprise Message Service) Server based design API s: JMS, C,.NET, Cobol, Java UM Lead: more efficient (cut infrastructure cost), reliable (uptime), more scalable (grow) Rendezvous (original pub/sub) Legacy daemon based design (RVRD) API s C, C++, C#, Java, Perl, COM UM Lead: more efficient, more functional, more reliable, future life Smart Sockets (acquired through Talarian) Legacy daemon based design for pragmatic multicasting (PGM) Proprietary (EOL) UM Lead: more efficient, more functional, more reliable, future life FTL (Faster Than LBM??) Modern nothing in the middle type design (stated copy!) RV compatibility stated / announced UM Lead: 6 years behind UM, more functionality (persistence, queuing, etc.), more proven, more open (less re-write) 8
websphere MQ (original queuing) Legacy server design, very functional, very robust API s: JMS, C,.NET, Cobol UM Lead: lower costs, more efficient & flexible, easier to use websphere MQ LLM Modern nothing in the middle design API s: MQ, JMS, RV, UM Lead: proven (production references), easier to use 9
11 Ultra Messaging Design and UMS
The Nothing in the Middle Design: No Brokers or Daemons Required Sending CPU Receiving CPU Application A UM Library Application B UM Library User Kernel ➀ ➁ User Kernel Message Flow Reliable Multicast, Reliable Unicast, or TCP Network Topic-based Addressing Choice of reliable and scalable transport mechanisms Cross-platform C, C# /.NET, and JAVA APIs with JMS support 12 12
Ultra Messaging Key Facts Single API for Streaming, Persistence/Guaranteed Delivery, and Queuing/Load Balancing Out-of-the-box support for TCP, Reliable Unicast, Reliable Multicast, and IPC/Shared Memory Native Infiniband and RDMA C, Java, and.net APIs plus JMS Support 13
Our Reliable Multicast Approach is Different Reliable multicast has historically been considered unstable Prone to NAK storms Retransmission storms can seriously impact network performance by reducing available bandwidth Ultra Messaging s proprietary reliable multicast implementation solves these issues entirely in user space, requiring no special permissions, modules or hardware. Control network behavior Allocate bandwidth for specific traffic like retransmissions Maintain network stability 14
Our Reliable Multicast Maintains Control Retransmission rate controls and NAK ignore, back-off and suppression algorithms ensure stable behavior. UM multicast design doesn t get tripped up by a consumer that cannot keep up If a consumer cannot keep up, it experiences loss Other consumers which are able to keep up are not impacted UM controls the amount of bandwidth allocated to retransmissions resulting in stable and predictable network behavior Configurable limits can also be set on transmission bandwidth Publishers sending too much within a short interval have a choice of waiting for bandwidth or having send requests fail (allowing for conflation and similar strategies) UM maintains network stability with all of the advantages provided by multicasting 15
Inter-Process Communication Transport Sub 500 nanosecond latency Transparent to applications Change configuration, not code Publishers choose transport mechanism on per-topic basis Subscribers automatically use publishers chosen transport All semantics and QoS supported Streaming, guaranteed delivery and queued / load-balanced delivery Supported using the same API as all other transports Optional receiver pacing 16
Adding Guaranteed Delivery / Persistence UMP 19
Persistence/Guaranteed Delivery Many use cases require message delivery even in cases of hard failures in the sending and receiving applications Ultra Messaging offers Persistence for Guaranteed Delivery, Durable Subscription & Late Join of message streams, regardless of message format, content or meaning Not to be confused with Caching which is content-aware processing / transformation, storage and retrieval of data Parallel Persistence Ultra Messaging s breakthrough persistence architecture provides an order of magnitude reduction in latency and a substantial increase in throughput over competing solutions 20
Legacy: Persistence with a Central Server Sending CPU Messaging Server CPU Receiving CPU Application A Comm Library Message Router Application B Comm Library Persistent Storage Store and Forward Messages do not continue receivers until stored Speed of the system is no more than the speed of the store 21 21
Next Generation Architecture: Parallel Persistence Sending CPU Persistent Store CPU Receiving CPU Application A UM Library Ultra Messaging Persistent Store Application B UM Library Persistent Storage TCP, UDP Reliable Multicast, or UDP Reliable Unicast No delays added by Parallel Persistence Messages move to receivers at full speed Speed of the store no longer impacts message delivery speed 22 22
Key Design Advantages Decoupled persistence and delivery functions Industry leading performance Determinism for latency and throughput on commodity hardware Applications are not delayed by using persistence Unique high availability LAN and WAN configurations provide zero latency failover Eliminates the need for specialized servers or expensive SANs Flexible implementation offers choice of transports and QoS on a per topic basis 23
Adding Queuing Semantics: Once and Only Once Delivery plus Load Balancing UMQ 24
UMQ Overview Adding queuing semantics to UM environment Low latency capable receivers can receive messages at top speed Slower receivers can receive messages in order / without loss even if they cannot keep up with raw message flow Source / receiver decoupling Data persistence / resiliency Load Balancing Indexed Queuing Allows consistent processing of related messages through a queue. 25
UMQ Semantics and Features Once And Only Once delivery (OAOO) Sources / Receivers Decoupled Queue or mailbox abstraction Allows connection of low latency messaging with slower receivers without impacting low latency messages Both can automatically discover queues Sources Multiple source and topics can send to same Queue Simultaneously send to Queues as well as UMS and UMP receivers Receivers Multiple receivers for individual messages Application sets under receiver control Innovative Capabilities Application Sets Indexed Queuing 26
Application Set A Application Set B UMQ High Level Components Sources submit messages Receiver Source Data and ACK Queue Queue Instance Queue Instance Instance Data and ACK Receiver Receiver Queue Instances persist and assign messages; multiple queue instances provide resilience Receivers consume messages from the queues; multiple receiver instances provide receiver resilience and scalability Receiver Receiver Receiver 27
UMQ Application Sets Settlement App Set Settlement Server 1 Read X Trade Persistence is per-trade and per-application Settlement Server 2 Settlement Server 3 Read Capture Reporting App Set Reporting Server 1 Read Reporting Server 2 Read Both Application Sets read from a single queue each app set gets the message OAOO Much simpler Trade Capture app sends only to a single queue Greatly improved failure resilience offload resilience support to UMQ Messages in the queue get delivered even if sending application fails 28
Using Ultra Messaging Indexed Queuing for Exchange Connectivity Order 1 Orders Server 1 DB 1 Order Queue Next Next Exchange 1 Exchange 2 Order 2 Cancel 2 Orders Server 2 DB 2 Cancel index=2 follows Order index=2 with indexed queuing even though Server 1 is Next Only one queue shown, but failure-resilient backup queues are easily configured 29
Ultra Load Balancing (ULB) Ultra-low latency load balancing Load balancing done at the source with nothing in the middle brokerless queuing Per-source queuing, not shared-source queuing Indexed queuing Messages held in volatile storage at the source Faster load balancing 30
Indexed Load Balancing Establishes subscriber process affinity based on application supplied Index Subsequent messages containing this index are routed to the same subscriber within a load balanced application set Ideally suited for routing of Modify/Cancel Orders to an Exchange Gateway Instance Can be used to insulate Order level acknowledgements from costly database lookups Available in both brokered and brokerless (ULB) configurations 31
JMS Support Broker-less design tightly integrated with UM Interoperability with all of Ultra Messaging Allow JMS-based applications to receive and send messages on a UM backbone JMS attributes and properties become UM application headers JMS payloads map directly to UM payloads Supports send / receive using native C,.NET, or JAVA APIs 32
JMS Support Allows other applications to leverage the UM message bus 3 rd party applications can access to UM message flow Integration with other Informatica applications such as PowerCenter and CEP for example Compatible with 1.0 and 1.1 JMS specs Except XA transactions Bundled with UMQ Shipping now 33
34 Caching using UMCache
Ultra Messaging Cache Receives, processes, indexes, stores and in some cases republishes messages, providing: Conflation or merger of data streams Delayed market data Content-based routing Bridging between messaging systems Out-of-the-box capabilities High speed archival and replay Snapshot requests i.e. Last Value Cache 35
Caching Architecture Framework-based plugin architecture supports customization and extension We provide pre-built modules (with source) for last value caching and archival and replay at multiples of original rate Client Requests Command and Control Module Utility Module Reception Module Processing Modules PROC 3 PROC 2 PROC 1 Indexing Modules IDX 1 Storage Module IDX 2 36
Ultra Messaging Cache Use Cases Besides the common use cases (replay and LVC server) Conversion of TCP/UDP connections to UMS topics Conversion of Tibco topic streams to/from UM High speed ingest (topics) into a database Data Translation of messages on a topic 37
Reaching Unmanaged Consumers using UMDS 38
UMDS - Desktop Connectivity for Data Center Services Ultra Messaging Backbone UMDS Server UMDS Server UMDS Server Controlled Infrastructure Uncontrolled Infrastructure TCP TCP UMDS Client Library Client Application Desktop UMDS Client Library Client Application Desktop Pure Java, fully managed.net assemblies Only requires single TCP connection for all traffic Server in data center provides desktop connectivity User authentication 39
UMDS 1.1 Proxy sources created in UMDS server at request of UMDS clients Server retains control over source configuration Topic queues per client Dedicated space per topic stream Per-topic conflation of streams for slow consumers Late join in both UM source and in server cache XML Configuration per topic (like UM XML config) 40
41 Extending UM over the Web with UMWeb
Extending Messaging to the Web OS Native Applications UMWeb Bridges the Gap Web Applications Browser Clients Your Firewall Their Firewall DMZ Proxy Server Mobile Clients WANs Intranets WebSocket Gateway 42
Bridging Network or Application Domains with the UM Gateway 43
Ultra Messaging Gateway Ultra Messaging Gateways extend the usage of UM: Enable transparent bridging of network or application domains Preserves all Ultra Messaging semantics Maintains all qualities of service Capabilities include: Subscription-based forwarding, driven by receiver interest Per-topic or wildcard permit/deny policies Bi-directional and multi-hop forwarding Single TCP tunnel connection between Gateways Tunnel compression, encryption and encapsulation Highly available configurations (master/slave, multiple paths) Comprehensive monitoring via published statistics and web interface 44
Ultra Messaging Gateway Filters and forwards traffic between topic resolution domains Now with multi-hop, failure resilience, wildcard receivers, request/response forwarding and more Applications Relay production traffic to development but block return traffic Selectively forward topics based on policy Connectivity between IPC and network resolution domains 45
IPC Local & Remote Receivers using the Gateway UM Gateway Process Sending Process UM Library Receiving Process UM Library User Kernel Message Flow to Processes on Other Machines Network 46
47 Ultra Messaging Manager - UMM
Ultra Messaging Manager The next step up for our management and configuration capabilities Ultra Messaging has always been highly configurable and controllable but now it is easier to manage GUI configuration view Ease of setting options Ability to apply security, templates, change management to configuration Ease of distribution of configurations 48
UMM Overview Ultra Messaging Manager GUI This is what the UM administrator sees and interacts with Provides a GUI configuration and management interface for UM Provides Management of UM Networks Distributed configuration of UM senders/receivers User / application authentication Auditing and capture of configuration changes Eliminates the need for manual configuration file editing Supports transport-level configuration UMP ands UMQ stores and queues coming in future releases Detects and notifies of common misconfiguration errors Supports templates and policies for consistent configuration Distributed as part of UMP 49
UMM Technical Architecture 50
UMM GUI 51
UMM Templates Allows setting default options that applications can override Enables setting option policies that applications cannot override Multiple templates can be applied hierarchically 52
UMM Receiver Configuration 53
UMM Source Configuration 54
55 Monitoring & Management
Ultra Messaging Monitoring Overview Applications can self-monitor transport metrics through the API, including how long messages spend in the API and how long the application spends processing them Automatic monitoring to publish metrics to the network, sample code provided to receive, collect and display SNMP agent available for use with any SNMP compliant management station (e.g. InterMapper, HP OpenView, etc.) for centralized monitoring Wireshark dissectors for packet level inspection Partner with firms such as Correlix, Corvil, ITRS for passive latency monitoring and dashboard views 56
Measuring Latency and Monitoring Possible Causes Ultra Messaging SNMP Agent Bring messaging, OS, and network statistics together for possible correlation Geneos, Intermapper probes, Solarwinds, OpenNMS Interesting Statistics LBT-RM Receiver Out_of_order: Count of datagrams that fill a gap but are not retransmissions Dgrams_dropped_*: Count of datagrams dropped and why Event Queues Min/Mean/Max service times (how long callback ran in microseconds) Min/Mean/Max event age when dequeued (how long event was queued) 57
Questions? Topic Resolution 58
59