MuleSoft - an iPaaS Integration

Describes about Message Oriented Middleware and role of MuleSoft

Transcript

1. MuleSoft – An iPaaS Integration Author : Arun V S
2. Integration Approaches The approaches to address the problem of integrating applications include  File Transfer (Common shared file between applications while one read when other writes. The two application must agree upon the filename, location, format and time when to read or write)  Shared Database (A common shared database to overcome the problem of synchronization between sender application and receiver application)  Remote Procedure Call (An application exposes a functionality, so that it can accessed remotely by other applications consuming it)  Messaging: (An application publishes message to a common message channel. Other applications can read messages later. Communication is asynchronous)
3. Messaging Approach got popular and widely used  It got so popular, as it uses a Messaging System - Message Oriented Middleware (MOM).  It is essentially needed because  MOM like "MuleSoft", "Dell Bhoomi", "IBM" etc., are reliable and persistent. It ensures a guaranteed delivery of messages. Senders can be configured with "Fire and Forget" strategies. Sender will send message to middleware and it take care of the rest. Risk of losing the messages due to network failure or reciever's availability will be taken care by middleware. Middleware is constructed in such a way that it maintains a internal queue to track and send the messages to reciever.  It can able to follow a common messaging paradigm, i.e, Language/Platform independent,  Since the MOM is asynchronous, every messages are executed in different threads. Since the messages are processed in batch, it does not care about the order of message execution and there is no dependency between one message to another. ETL message processing can be efficiently done voluminously.
4. Messaging Approach got popular and widely used (Contd.)  Asynchronous processing is similar to voice mail while synchronous processing is like telephone system. Sender do not require immediate response. Whenever receiver is available, it can process the message and reply back. Sender is not interested in real time response. On such occasions. MOM play a vital role in business transformation.  It just act as a "Mediation". If an application disconnected, it just connect with messaging system rather than connecting with all the other applications it wish to share the data.  It achieves "Variable Timing". Sender and receiver can process (sending and receiving rate) messages in different rates.
5. Challenges There is also many challenges associated with this system.  We might get into vendor-lock in. One messaging system to another, there may be a huge technology gap between them. Migration process is tough to get locked in single vendor.  Logic of "Event Driven Programming" looks a bit complex in implementation perspective. Even though it gives better performance, complex logic is written to achieve it.  If the execution of messages depends on previous messages, then order of execution is to be maintained and it will be synchronous in nature.
6. Challenges (Contd.)  Improper integration in middleware leads to failure of multiple domains or business units within an organisation. So, the Central IT team or integration team need to have both technical and business knowledge.  There are some use cases which expects the response to be synchronous. If we make MOM to respond in synchronous fashion, performance will be greatly degraded when application scale up.
7. Conclusion There is tough decision to be taken to choose between synchronous and asynchronous messaging pattern within an application. Mix of them with proper understanding of application and its underlying architecture leverages the performance.