Przeszukałem internet w MULE i zrozumiałem, że aby aplikacje mogły komunikować się między sobą - nawet jeśli są wdrożone w tej samej instancji Mule - będą musiały używać TCP, HTTP lub transporty JMS.Mule Inter - Komunikacja aplikacji w tym samym wystąpieniu
Maszyna wirtualna nie jest obsługiwana.
Jednak uważam, że jest to nieco sprzeczne z zasadami ESB. Powinniśmy być w stanie zdefiniować punkty końcowe w ESB i połączyć się z nimi za pomocą dowolnego Transportu? Mogę się mylić. Ponieważ wszystkie aplikacje dzielą tę samą maszynę JVM, można oczekiwać, że będą w stanie komunikować się za pośrednictwem kolejki pamięci wirtualnej w pamięci, zamiast polegać na protokole HTTP bez transakcji, lub TCP, w którym liczba połączeń, które można wykonać, zależy od zasobów serwera. Nawet w przypadku JMS musimy zdefiniować inną kolejkę i zarządzać nią, a także do intensywnego użytkowania, które może mieć wpływ na wydajność. Chociaż zgadzam się, jeśli mamy dystrybuowane i systemy klastrowe mogą być HTTP lub JMS będzie tylko opcjami.
Czy jest jakiś plan włączenia VM jako protokołu komunikacji między aplikacjami lub czy istnieje inny sposób, w jaki jeden Flow może komunikować się z innym Flow Endpoint, ale w innej aplikacji?
EDIT: - Odpowiedź z Mulesoft http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Tak, myślimy o komunikacji między aplikacjami dla przyszłej wersji. Nadal nie jest jasne, kiedy zamierzamy to zrobić, ale mamy kilka pomysłów na temat tego, jak chcemy, aby ta funkcja się zachowywała. Możemy utworzyć konfigurację na poziomie serwera, w której możesz zdefiniować zasoby, które będą używane we wszystkich twoich aplikacjach. Tam można zdefiniować złącze VM i używać go do wysyłania wiadomości między aplikacjami na tym samym serwerze. Jak już powiedziałem, to tylko pomysł.
Dzięki Victor. Zgadzam się, że powinna to być izolacja aplikacji wdrożonych na nim. Ale powinny być dostępne za pośrednictwem punktów końcowych. To, co widzimy obecnie w Mule, to móc komunikować się między Apps na tej samej maszynie JVM, ale nadal musimy polegać na HTTP lub zewnętrznym MoM takim jak AMQ, który będzie realizował żądanie w JMS. To właśnie czułem jako obciążenie. Jedna aplikacja wdrożona na tej samej maszynie JVM powinna płynnie komunikować się z inną aplikacją przy użyciu maszyny wirtualnej. Są nadal odizolowane, ale w razie potrzeby logicznie zintegrowane. Proszę mnie poprawić, jeśli stwierdzam, że coś jest nie tak. – Soumya
Problem z tym podejściem polega na tym, że klastrowanie byłoby z natury wyłączone. Jesteś przez projekt zabraniający tego. Dobre podejście polegałoby na włączeniu maszyny wirtualnej Mule Enterprise Edition (która dziś, jak dzisiaj, ma straszliwą nazwę, ponieważ nie oznacza to w transporcie maszyny wirtualnej, ale w transporcie pamięci) do komunikowania się nie tylko lokalnie w aplikacjach vm, ale także w klaster (zobacz [wzór niezawodności] (http://www.mulesoft.org/documentation/display/current/Reliability+Patterns)). –
Czy używasz społeczności lub firmy? Jeśli nie korzystasz z EE, nie powinno być trudno napisać transport, który wykorzystuje wspólny statyczny ConcurrentLinkedQueue do komunikacji w VM przy użyciu [DevKit] (http://www.mulesoft.org/documentation/display/current/Mule+ DevKit). Wolałbym używać redis, hornetq lub jakiegoś wspólnego systemu pamięci do szybkiej komunikacji lokalnej i klastrowej. –