TECHNICAL
15 years of proven technology
Summary
The first release of the message broker was in 1999 as a customized solution for a very large health care company. At that time, the software was known as The Stahura-Brenner MQSeries Gateway. As more clients came on board, new interfaces and functionality were added to support many technologies in addition to the IBM WebSphere® MQ. The Stahura-Brenner Group is now re-releasing the software under the name of Plexus Message Broker.
Beginnings
The first iteration of the software was for a very large health care company. The crux of the problem was that the legacy back-end mainframes were incapable of processing more than 10 transactions per second yet a much higher throughput was needed. The strategy was to move all IBM MQSeries® (as it was known at the time) communication logic, message routing logic, message transformation logic, and error handling logic to a Windows® environment(s) where multiple, extensible Windows® systems could be configured to achieve the performance characteristics needed.
Components
In time other interfaces were added for other customers: a NetBIOS interface was added for communication with NetWare, an SNA interface was added to access older IBM systems, and so on. Not only were communication interfaces added, but the fundamental architecture was changed to include the concept of a Filter where Filters were stackable modules that could be placed between the two communication endpoints to perform various message handling functions. A Filter could aggregate multiple messages into a single message, spawn new messages in addition to letting the original message go through, ignore certain messages, change the format of a message from a data stream to an XML document and back again, and add function calls to other services to either validate the contents of the message or to add additional information to the message.
Threading
The Plexus Message Broker’s threading architecture consists of multiple threading models. TCP and Microsoft® MSMQ, which are thread agnostic, utilize one kind of threading model. WebSphere® MQ, which requires each session to be on a separate thread, utilizes a different kind of threading model. If a Message Server is interfacing between TCP and WebSphere® MQ, the Message Server also bridges the two threading models. This architecture allows for over 1,000 TCP sessions to be marshalled into a few dozen WebSphere® MQ Integrator (WMQI) MQ threads for optimal resource utilization.
Unmanaged and Managed Code
Around 2007 there was a client requirement to allow the messaging software to interface .Net applications. This required the unmanaged C++ code to interface to managed .NET code. While the implementation of this was “interesting,” the benefit was huge. Not only did it allow message filters to call Microsoft® services such as SOAP and advanced encryption services, but it also allowed the Message Servers of a Plexus Message Broker instance to run in the application domain space of the Plexus Message Broker instance. Thus all global STATIC variables are really local to the individual Plexus Message Broker instance, making running multiple instances of the Plexus Message Broker on the same Windows system infinitely doable.
The integration of the .NET environment also meant that a communication endpoint of a Message Server could be a .NET application written in any .NET language such as C#, Visual Basic, or Java.