1 / 35

SonicMQ for LDIWG

SonicMQ for LDIWG. Kris Kostro, Francesco Calderini AB/CO. Layout. SonicMQ in CMW JMS Characteristics of SonicMQ Connectivity Does it fulfill the LDIWG requirements? How could LDIWG be implemented with SonicMQ. SonicMQ in CMW.

marv
Download Presentation

SonicMQ for LDIWG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SonicMQ for LDIWG Kris Kostro, Francesco Calderini AB/CO

  2. Layout • SonicMQ in CMW • JMS • Characteristics of SonicMQ • Connectivity • Does it fulfill the LDIWG requirements? • How could LDIWG be implemented with SonicMQ

  3. SonicMQ in CMW • 1999 requirement capture for CMW, product studies, recognized need for MOM • May 2000 Preference for JMS, product evaluations • Sept. 2000 presentation by by Mitchell Horovitz, the Technical Product Manager of SonicMQ • February 2001 SonicMQ has been selected as the messaging product for the CMW project. Purchased 4 licences. • August 2001 First real use for timing events delivery

  4. What is JMS? Java Message Service • Industry-standard messaging specification • Developed by Sun and other leading vendors • Required component in J2EE 1.3 • Common set of APIs and semantics • Publish and subscribe • Point-to-point • Message delivery Quality of Service (QoS) • Guaranteed • Once-and-only-once • At-most-once • Message content (properties), message types, filtering, etc. well defined • Deployment architecture not addressed

  5. SonicMQ JMS implementation • Hierarchical namespace (topics) • XML support on top of text message (for DOM2, JAXP, SAX) • Multiple levels of Quality of Service • Connectivity beyond JMS

  6. SonicMQ • JMS implementation (in Java) • Market leader for JMS • Hub-and-spoke architecture • Scalable (clusters, load balancing, …) • High availability (parallel servers, queues, topics, persistent topics, etc) • Security (SSL, certificates, HTTP tunneling, firewalls etc.)

  7. Integrating SonicMQ with C/C++ Clients

  8. Connectivity • HTTP • C, C++ • COM • FTP • SNMP • Bridges to proprietary systems (MMQ) • Bridges to other JMS systems

  9. How can SonicMQ fulfill the LDIWG requirements?

  10. Reliability Scalability Availability Connectivity Security Enterprise Messaging Requires… …and Sonic delivers!

  11. LDIWG requires • Availability (2, 3) • SonicMQ is typically used in areas which much higher availability requirements • Intrinsically high availability architecture. Brokers can be set up as redundant, can be clustered or partitioned into independent domains

  12. Availability Connection Management Removing Bottlenecks and Points of Failure • Distribution of client connections across cluster • Connection-time load balancing • One or more brokers from list used as initial connection points • Clients redirected to other brokers via weighted round-robin algorithm • High availability of server connections • Connect time failover • Clients connect to 1st available broker in list • Subsequent failover • Reconnect on notification of connection loss

  13. LDIWG requires • Reliability (4, 5) • Publisher down -> watchdog mechanism (outside of SonicMQ) • Control frequency -> No, should be assured by the domain, authentication possible • Guaranteed delivery possible

  14. Reliability Guaranteed Delivery Handles Failure at Any Point in Lifecycle • Messages delivered even in the most challenging situations • Persistent messages are stored and flushed to disk before being acknowledged • Patent-pending storage mechanism offers reliability and high performance • Dead Message Queue • Includes large message support and client-side persistence • Supports local or distributed (2-phase) transactions • Reliable groups of actions

  15. LDIWG requires (cont.) • Synchronisation (6) • Timestamp is part of JMS (ms), in LHC all data will be time-stamped at the source

  16. LDIWG requires (cont.) • Latency (7) • Latency depends on configuration and required throughput • Performance (8) • Guarantee of delivery (different levels) • Throughput depends on configuration and QoS • Extensive performance figures available

  17. Scalability Built to Scale • Multi-threaded Broker • Architected for high capacity* • Connections > 2000 • Destinations > 80,000 • Messages > 8,000/s (persistent) • Latency < 10ms • Actual figures depend on environment • Single Cluster • Required when single broker capacity is exceeded • Multiple brokers in cluster act as single virtual broker • Communities of Clusters • Linked via Dynamic Routing Architecture™ (DRA) *Tested on 4-way 550MHz Windows NT Server (1K message size)

  18. Scalability Head Office Business Application BusinessApplication BusinessApplication Broker Broker Cluster Broker BusinessApplication Broker Expanding the Cluster Achieve Linear Scalability • No limits on cluster size • Current deployments up to 64 brokers • Clients are load-balanced across the cluster • Messages routed through inter-broker connections where necessary

  19. LDIWG requires (cont.) • Adaptability (9) • Fully dynamic configuration • Protocol features • (10) JMS is an industry standard • (11) Supports several platforms (see list) • (12) On change semantics must be assured by the producer

  20. LDIWG requires (cont.) • Protocol features (cont.) • (13) Grouping -> performance issue • (14) Last published value ->posibility of persistence with timeout. Request for last value can be implemented outside of SonicMQ • (15) JNDI can be used as naming and directory service • (16) Hierarchical namespace with wildcards

  21. LDIWG constrains • Constrains • (17) Can do much better than 10 messages/s but it is really scalability issue • (18) Can do much better for latency, again scalability issue • (19) No known blocking problems • (20) No flow control inside SonicMQ (domain responsibility) • (21) User-based identification and topic-level authorization via ACL • (23) Administration utilities available

  22. Security Comprehensive Security Flexible Deployment Options • Encryption • Built-in payload encryption • Secure messaging without performance cost of SSL • Channel encryption • SSL with up to 168-bit keys • Authentication • Built-in username/password authentication • Supports digital certificates for user authentication • Authorization • Specify rights of authenticated users • Exploit destination hierarchies and groups of users to simplify administration

  23. SonicMQ Explorer

  24. How could LDIWG be implemented with SonicMQ

  25. How could LDIWG be implemented with SonicMQ • Hierarchical namespace to deal with “private” domain naming • XML as common, self-describing data format • Bridge for each domain (SonicMQ Bridges technology?) • Common administration

  26. CERN PS SPS CMS ST Magnet BPM Class N Magnet1 Status Current Magnet2 Device instance N Example topics hierarchy • Common root CERN • Partitioned into administration domains (PS, LHC, ST, Alarms, CMS ..) • Every domain defines it’s own hierarchy • All accelerator domains follow the class/device hierarchy Root Domain Class Device Property Can subscribe to status of all magnets: CERN.SPS.Magnet.*.Status

  27. How could LDIWG be implemented with SonicMQ • Hierarchical namespace to deal with “private” domain naming • XML as common, self-describing data format • Bridge for each domain (SonicMQ Bridges technology?) • Common administration

  28. XML as common, self-describing data format • Support within SonicMQ • Used for LHC logging following String 2 experience • Will probably be used in other domains (post-mortem, alarms) • Self-describing data, no need to negotiate between domains, Web support

  29. How could LDIWG be implemented with SonicMQ • Hierarchical namespace to deal with “private” domain naming • XML as common, self-describing data format • Bridge for each domain (SonicMQ Bridges technology?) • Common administration

  30. Bridge for each domain • CMW – has been done in the past - easy • PVSS – has been done (in one direction) • DIM – easy to do as there are similar concepts (namespace) and there is JAVA API • Smartsockets

  31. SonicMQClient SonicMQServer SonicMQClient CMWServer CMW Agent CMW Server SonicMQ Domain Gateway Listener Topic Controls DB

  32. SonicMQ Bridges Connectivity to Internet services andmessaging systems • Bi-directional message forwarding • Between messaging systems • Across other Internet services • Transparent to client applications • Mappings held in XML configuration file • Administration through SonicMQ • Common exception handling and logging

  33. XML Mapping Files Topic SonicMQ  MQSeries Mapping MQSeries SonicMQ Mapping Queue SonicMQ Bridges SonicMQ Bridge SonicMQClient SonicMQServer SonicMQClient MQSeriesClient MQSeriesBroker Mqseries Client

  34. XML Mapping Files Topic Listener SonicMQ Bridges SonicMQ Bridge SonicMQClient SonicMQServer SonicMQClient CMWServer CMW SonicMQ Mapping CMW Agent CMW Server

  35. Reasons to use SonicMQ • Solid industrial product by market leader • Implements standard, hence certain product independence • Scalable: Start with one broker and expand later if needed • Inexpensive • Good connectivity (some non-standard) • Fulfills LDIWG requirements and more • Easy to implement LDIWG

More Related