<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ryan Andrews on foojay.io - Friends of OpenJDK</title><link>https://foojayio.github.io/website/today/author/ryan-andrews/</link><description>Articles written by Ryan Andrews on foojay.io - Friends of OpenJDK</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 17 May 2024 09:46:40 +0000</lastBuildDate><atom:link href="https://foojayio.github.io/website/today/author/ryan-andrews/index.xml" rel="self" type="application/rss+xml"/><item><title>A Modern Approach to Middleware with Chronicle</title><link>https://foojayio.github.io/website/today/a-modern-approach-to-middleware-with-chronicle/</link><pubDate>Fri, 17 May 2024 09:46:40 +0000</pubDate><guid>https://foojayio.github.io/website/today/a-modern-approach-to-middleware-with-chronicle/</guid><description>&lt;p&gt;&lt;strong&gt;Financial institutions today face significant challenges in updating their legacy middleware systems which are crucial for supporting millions of lines of code serving critical business functions. Prior to multicast support in modern switching hardware that became prevalent in the early 2000s, message middleware was largely done via proprietary protocols that converged onto TCP/IP. IBM&amp;rsquo;s Websphere MQ was a leader in this space.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Point to point middleware based on TCP/IP requires extra processing power and network bandwidth proportional to the number of consumers, and unreliable or slow consumers can negatively impact performance of the publisher. To combat these challenges, software vendors utilized IP multicast to create messaging platforms that supported topic based publish/subscribe networks.&lt;/p&gt;</description></item></channel></rss>