Mule messaging: Power of enterprise messaging system
Enterprise messaging system for the new enterprise
An enterprise messaging system (EMS) can often be used as an all-encompassing term. In most cases, it often refers to messaging between different applications within a single application infrastructure. This occurs through a software application that enables messages to be sent from one program, stored in a message queue, and then processes by the second program when it becomes available. The ability to transport messages makes the EMS a common tool to integrate disparate data among enterprise applications.
Java message service – A popular EMS
The most recognizable enterprise messaging system is based on the Java Messaging standard (JMS) Java API. While it is widely used, JMS has several drawbacks when used stand-alone.
- Manageability: It is difficult to manage as systems get added or removed over time. Since it does not define the message format, both the source and target application require knowledge of each other in order to process messages.
- Scalability: It is challenging to scale as processing takes place on the EMS system. As demand increases, the JMS becomes a single point-of-failure, a performance bottleneck, and will struggle as transaction volumes increase.
- No interoperability: JMS is API level messaging protocol, primarily available to Java application. It is difficult to attain message interoperability for other languages (e.g., C++, Ruby, Python).
Pairing an ESB with a Java messaging service
In order to overcome the drawbacks of a standalone JMS, many companies pair this service with a middleware, such as an Enterprise Service Bus (ESB). An ESB commonly resides on top of the EMS and makes it easier to onboard new systems by managing data transformation, and content routing. This creates an agile application architecture that can more easily adapt to change. An ESB is also designed to scale, and makes it easier to add additional nodes to manage large transaction volumes.
In addition to the JMS, an ESB can house a wide number of connectivity and format options, such as multiple protocols, and messaging formats. This enables an ESB to communicate across different protocols suitable for different programming languages, including legacy formats. This added support ensures the enterprise will have successful communication across the entire system architecture.
Mule as an ESB and Java messaging service
While an ESB can add power and flexibility to a JMS, not all ESBs are created equal. Mule as an ESB is an enterprise service bus that is uniquely qualified to help businesses get the most out of their JMS. Mule’s secure integration platform not only enables developers to use a JMS transport, but also supports emerging protocols such as Advanced Message Queuing Protocol (AMQP) with a low amount of resource utilization. If a company is already using a stand-alone JMS, Mule as an ESB can build on what they have – a business will never need to start over.
Mule as an ESB is a powerful companion of JMS, and as such was used by the Scripps Network to manage their library of media assets. Scripps Network implemented Mule as a core infrastructure component and chose JMS as the messaging communication protocol. When Scripps adds a new digital asset to the system: Mule performs an initial validation using Mule-hosted asset registration service and then uses a JMS queue to register the asset in the system and update the asset repository. Once completed, a final message is set to JMS topic, which sends an “add asset” event to the indexing application, schedule, and any other applications that are interested in the event. By using Mule, Scripps is able to broaden its application reach and transport messages across platforms with multiple delivery mechanisms.
Mule as an ESB as an enterprise messaging system
While Mule as an ESB has a rich history with JMS messaging, it is not limited to this single delivery transport. In fact, Mule as an ESB supports a wide array of enterprise messaging systems (e.g., AMQP) that allow businesses the freedom to access and deliver their information with whichever method works best for them. Since many companies already have workflows with a preferred delivery method, Mule can easily incorporate businesses' best practices, making implementation a breeze. Mule as an ESB is a messaging solution that provides developers the visibility, flexibility, and control they need to power the messaging service.
For businesses that are preparing for a future in the cloud, Mule also supports a number of cloud-based messaging services and has a new iPaaS called CloudHub. These companies can choose to start with Mule as an ESB and then easily migrate to CloudHub when they decide the time is right.
Want to know more about the future of Mule as an ESB?
The Mule development team has released new Development features to the platform, including: