Ich habe das Web auf MULE erkundet und musste verstehen, dass Apps für die Kommunikation untereinander - selbst wenn sie in der gleichen Mule-Instanz eingesetzt werden - TCP oder HTTP verwenden müssen oder JMS-Transporte.Mule Inter - App Kommunikation in der gleichen Instanz
VM wird nicht unterstützt.
Allerdings finde ich das ein wenig im Widerspruch zu ESB-Prinzipien. Wir sollten im Idealfall in der Lage sein, Endpunkte in und ESB zu definieren und mit jedem Transport eine Verbindung herzustellen. Ich kann mich irren. Da alle Apps die gleiche JVM teilen, würde man erwarten, dass sie über die In-Memory-VM-Warteschlange kommunizieren können, anstatt sich auf ein transaktionsloses HTTP-Protokoll zu verlassen, oder TCP, wo die Anzahl der Verbindungen von Serverressourcen abhängt. Selbst für JMS müssen wir eine andere Warteschlange definieren und verwalten und für eine starke Nutzung, die sich auf die Leistung auswirken kann. Obwohl ich stimme zu, wenn wir verteilte und geclusterte Systeme haben, kann HTTP oder JMS nur Optionen sein.
Gibt es Pläne, VM als Inter-App-Kommunikationsprotokoll einzubinden, oder gibt es eine andere Möglichkeit, wie ein Flow mit einem anderen Flow-Endpunkt kommunizieren kann, jedoch in einer anderen App?
EDIT: - Antwort von MuleSoft http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Ja, wir denken über inter-App-Kommunikation für eine zukünftige Version. Noch ist nicht klar, wann wir es tun werden, aber wir haben ein paar Ideen darüber, wie wir wollen, dass sich dieses Feature verhält. Wir können eine Konfiguration auf Serverebene erstellen, in der Sie Ressourcen definieren können, die in allen Ihren Apps verwendet werden. Dort könnten Sie einen VM-Connector definieren und ihn zum Senden von Nachrichten zwischen Apps auf demselben Server verwenden. Wie gesagt, das ist nur eine Idee.
Dank Victor. Ich stimme zu, dass Apps isoliert darauf gespeichert werden sollten. Aber sie sollten über Endpunkte erreichbar sein. Was wir derzeit auf Mule sehen, ist die Möglichkeit, zwischen Apps auf derselben JVM zu kommunizieren, wobei man sich immer noch auf HTTP oder ein externes MoM wie AMQ verlassen muss, das die Anfrage auf JMS überträgt. Das habe ich als Overhead empfunden. Eine auf derselben JVM bereitgestellte App sollte nahtlos mit einer anderen App kommunizieren können, die VM verwendet. Sie sind immer noch isoliert, aber bei Bedarf logisch integriert. Bitte korrigieren Sie mich, wenn ich das Gegenteil behaupte. – Soumya
Das Problem mit diesem Ansatz ist, dass Clustering von Natur aus deaktiviert wäre. Sie verbieten das Design. Ein guter Ansatz wäre, die Mule Enterprise Edition VM (die heute wie heute einen schrecklichen Namen hat, weil sie nicht im Transport von virtuellen Maschinen, sondern im Speichertransport bedeutet) nicht nur lokal zwischen in vm apps, sondern auch in der Cluster (siehe [Zuverlässigkeitsmuster] (http://www.mulesoft.org/documentation/display/current/Reliability+Patterns)). –
Verwenden Sie Community oder Unternehmen? Wenn Sie EE nicht verwenden, sollte es nicht schwierig sein, einen Transport zu schreiben, der eine gemeinsame statische ConcurrentLinkedQueue nutzt, um mit dem [DevKit] (http://www.mulesoft.org/documentation/display/current/Mule+) in der VM zu kommunizieren DevKit). Ich würde lieber redis, hornetq oder ein gemeinsames Speichersystem für schnelle lokale und gruppierte Kommunikation verwenden. –