У нас был следующий сценарий в нашем проекте Mule:
5 Flows using Quartz Connector
20 Flows using Soap HTTP Endpoint
Он был развернут в автономном Mule 3.3
В конечных точках HTTP мы имеем следующее:
http:inbound-endpoint -> cxf:jaxws service (CXF Component) <--- Everything in JAVA.
- Third party system calls in Java/ Database calls in Hibernate only endpoints
exposed in Mule.
- Spring Beans were configured all over for DI
Следующие системы обменивались данными с Mule ESB
Sharepoint UI (Small) <-- use HTTP
Java UI (HIge) <-- use HTTP
React js Application (Small) <-- use HTTP
Third Party System <-- Use HTTP of ESB
Financial System <--- Use HTTP but not Mule one but Java Code
Document Archival System <--- Use HTTP but not Mule one but Java Code
Active Directory <--- Use HTTP but not Mule one but Java Code
Sharepoint Library <--- Use HTTP but not Mule one but Java Code
Thats it....
В будущем мы получаем все больше и больше конечных точек и сервисов SOAP.
Согласно архитектуре, мы не используем возможности Mule ESB иэто не требуется, это не подходит, в то время как 4 системы работают с ESB, а также настроено 5 кварцевых заданий.
Как разработчики Mule ESB и Spring Integration смотрят на этот сценарий?