Khi nào nên sử dụng Spring Integration vs Camel?

Là một người dùng Spring dày dạn, tôi đã giả định rằng Spring Integration sẽ có ý nghĩa nhất trong một dự án gần đây yêu cầu một số khả năng nhắn tin (JMS) ( chi tiết hơn ). Sau một số ngày làm việc với Spring Integration, vẫn có cảm giác như có rất nhiều chi phí cấu hình được cung cấp với số lượng kênh bạn phải định cấu hình để mang lại một số liên lạc đáp ứng yêu cầu (nghe trên các hàng đợi JMS khác nhau).

Do đó, tôi đã tìm kiếm một số thông tin cơ bản về việc Camel khác với Spring Integration như thế nào, nhưng có vẻ như thông tin ngoài kia khá rảnh rỗi, tôi thấy:

• http://java.dzone.com/articles/spring-integration-and-apache (So ​​sánh rất trung lập giữa việc thực hiện kịch bản tích hợp trong thế giới thực trong Hội nhập mùa xuân so với Lạc đà, từ tháng 12 năm 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternigin.html (So ​​sánh lạc đà với các giải pháp khác, tháng 10 năm 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, tháng 10 năm 2008)

Câu hỏi là: bạn có kinh nghiệm gì khi sử dụng chồng này qua chồng kia? Trong trường hợp nào bạn muốn giới thiệu Camel là Spring Integration thiếu hỗ trợ? Bạn thấy ưu và nhược điểm của mỗi nơi? Bất kỳ lời khuyên từ các dự án trong thế giới thực được đánh giá cao.

Chúng tôi chọn Lạc đà trong Tích hợp Mùa xuân vì API thông thạo thực sự tốt. Chúng tôi thực sự sử dụng nó trong các dự án Spring và sử dụng Spring để cấu hình một phần của nó. Các API lập trình rất rõ ràng và có một bộ lớn các thành phần hợp lý.

Chúng tôi đã thực hiện một cuộc đấu súng quy mô nhỏ và về cơ bản tại thời điểm đó, yêu cầu của chúng tôi đã giành chiến thắng. Chúng tôi sử dụng nó chủ yếu để chuyển các tệp dữ liệu nội bộ đến / từ các bên ngoài thường yêu cầu chuyển đổi định dạng gửi bằng cách sử dụng ftp / sftp / ... hoặc đính kèm vào email và gửi đi.

Chúng tôi thấy chu trình chỉnh sửa-biên dịch-gỡ lỗi giảm. Sử dụng Groovy để thử nghiệm thiết lập các tuyến đường được thêm tiền thưởng.

Tích hợp mùa xuân cũng là một sản phẩm tuyệt vời và tôi khá chắc chắn rằng nó cũng sẽ đáp ứng nhu cầu của chúng tôi.

Tôi chỉ đề xuất Tích hợp mùa xuân nếu bạn đã có một dự án Spring và bạn chỉ cần thêm một số tích hợp "cơ bản" bằng cách sử dụng Tệp, FTP, JMS, JDBC, v.v.

Lạc đà Apache có hai ưu điểm chính:

1. Nhiều, nhiều công nghệ hơn được hỗ trợ.
2. Ngoài ra, một DSL DSL (tốt), có các API thông thạo cho Java, Groovy và Scala.

Vì Apache Camel có khả năng tích hợp rất tốt với Spring, tôi thậm chí sẽ sử dụng nó thay vì Spring Integration trong hầu hết các dự án Spring.

Nếu bạn cần biết thêm chi tiết, bạn có thể đọc kinh nghiệm của tôi trong bài đăng trên blog của tôi: Spoiled for Choice: Sử dụng Khung tích hợp nào - Tích hợp mùa xuân, Mule ESB hoặc Lạc đà Apache?

Gần đây tôi đã tiến hành loạt sút luân lưu Camel vs Spring với mục đích tích hợp Apache Kafka . Mặc dù là một nhà phát triển Spring háo hức, tôi buồn bã thấy sự nghi ngờ của mình với ngăn xếp Dự án đang phát triển của Spring đã khẳng định: Spring thật tuyệt vời khi IOC-Container đóng vai trò là chất keo cho các khung khác, nhưng nó không cung cấp các lựa chọn thay thế khả thi cho các khung đó . Có thể có ngoại lệ cho điều này, cụ thể là mọi thứ phải làm với MVC, nơi Spring đến và nơi nó làm rất tốt, nhưng những nỗ lực khác để cung cấp chức năng mới trên các tính năng của container bị thiếu vì ba lý do và trường hợp sử dụng SI Kafka xác nhận Tất cả bọn họ:

• Giới thiệu một DSL khó sử dụng cho cấu hình XML.
• Các trang của mã cấu hình xml để có được tất cả các thành phần khung có dây.
• Thiếu tài nguyên để cung cấp chức năng ngang bằng với các khung chuyên dụng.

Bây giờ, trở lại với kết quả của loạt sút của tôi: quan trọng nhất là tôi bị ấn tượng bởi khái niệm tổng thể của Camels về các tuyến đường giữa các điểm cuối . Kafka tích hợp liền mạch với khái niệm này và ba dòng cấu hình là đủ để mọi thứ luôn hoạt động. Các vấn đề gặp phải trong quá trình được giải quyết gọn gàng bằng tài liệu phong phú từ nhóm dự án cũng như rất nhiều câu hỏi về Stackoverflow. Cuối cùng nhưng không kém phần quan trọng, có một sự tích hợp toàn diện vào Mùa xuân mà không có điều ước nào không được thực hiện.

Ngược lại với SI, tài liệu về tích hợp Kafka khá dữ dội và vẫn không giải thích rõ ràng cách tích hợp Kafka. Sự tích hợp của Kafka được nhấn vào cách làm SI, làm tăng thêm độ phức tạp. Các tài liệu khác, ví dụ như trên Stackoverflow cũng ít phong phú và ít hữu ích hơn so với Camel.

Kết luận của tôi: cobbler bám sát giao dịch của bạn - sử dụng Spring làm container và Camel làm khung tích hợp hệ thống.

Nó thực sự phụ thuộc vào những gì bạn muốn làm. Nếu bạn cần mở rộng một cái gì đó để xây dựng giải pháp nhắn tin của riêng mình, Spring Integration có mô hình lập trình tốt hơn. Nếu bạn cần một cái gì đó hỗ trợ nhiều giao thức mà không cần mã tùy chỉnh, Camel sẽ đi trước Spring Integration.

Có một cuộc đấu súng quy mô nhỏ là một ý tưởng rất tốt, chỉ cần đảm bảo rằng bạn đang cố gắng thực hiện loại công việc mà bạn thường làm trong dự án.

--disclaimer: Tôi là một thành viên hội nhập mùa xuân

Hầu hết các so sánh về Lạc đà và SI mà tôi từng thấy không tính đến các yếu tố sau:

1.) Ảnh hưởng của Spring Boot đối với năng suất của nhà phát triển đối với Tích hợp Spring

2.) Hiệu ứng của Spring XD đã có trong việc làm cho các ứng dụng Tích hợp Spring có sẵn mà không cần biên dịch mã - cũng như các nguồn và chìm của Spring XD chỉ đơn giản là các bộ điều hợp kênh Spring Integration, khi bạn đang tìm cách mở rộng Spring XD.

3.) Hiệu quả của Spring XD đã tạo ra sự hợp nhất Spring Integration, Spring Batch, Spring Data (+ Hadoop!) Trong một ngăn xếp, mang lại hiệu quả xử lý hàng loạt và xử lý luồng, hỗ trợ HDFS / Apache Hadoop và nhiều hơn nữa cho Spring Integration.

4.) Hiệu ứng của DSL Java mùa xuân 4.0 sắp được phát hành https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Để bạn xem xét,

/ Pieter (từ chối trách nhiệm tôi làm việc tại Pivotal)

Chúng tôi đang sử dụng Spring Integration cho ứng dụng của mình và hiện đang xem xét chuyển sang Apache Camel vì chúng tôi gặp phải nhiều vấn đề với khung Tích hợp Spring. Dưới đây là một số vấn đề.

1. Bộ nhớ đệm kết nối mà Spring cung cấp sẽ mở 1000 kết nối nhàn rỗi trong IBM MQ và không có gì đảm bảo rằng các kết nối này được sử dụng lại. Và các kết nối này sẽ vẫn mở mãi mãi, điều này tạo ra những rắc rối về phía MQ. Phải khởi động lại ứng dụng mỗi tuần trong môi trường thấp hơn chỉ để làm mới các kết nối. Apache Camel cũng cung cấp bộ nhớ đệm và các kết nối dường như tăng / giảm dựa trên tải.

2. Spring không cung cấp trình ánh xạ cho các tham số QoS. Ngay cả khi bạn kích hoạt QoS, chế độ phân phối và các thuộc tính hết hạn / thời gian sẽ bị mất (tôi sẽ nêu ra vấn đề JIRA cho việc này). Apache Camel xử lý điều này và các tham số QoS được gửi đến các ứng dụng ngược dòng và không bỏ nó.

Bây giờ tôi đang xử lý các vấn đề với việc xử lý các ngoại lệ và giao dịch với Apache Camel mà Spring dường như xử lý tốt hơn với AOP.

Trên thực tế, tôi muốn nói rằng FTP đã tốt nghiệp thời kỳ ủ bệnh. Bạn có thể thực hiện tìm kiếm đơn giản trên các diễn đàn SI / JIRA để xem những tính năng mới nào đã được triển khai và các lỗi đã được sửa. Từ những cuộc trò chuyện khác nhau, có vẻ như đã có một số cách sử dụng sản xuất từ ​​nó, vì vậy tôi sẽ đề nghị cung cấp cho nó một cái nhìn thứ hai và tất nhiên là truyền đạt mối quan tâm của bạn cho chúng tôi thông qua

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

Chúc mừng Oleg

Tuyên bố miễn trừ trách nhiệm: Tôi là thành viên hội nhập mùa xuân

Apache Camel là một khung công tác rất tốt và cũng rất đầy đủ. Nhưng nếu ứng dụng của bạn sử dụng mùa xuân, lời khuyên cá nhân của tôi là sử dụng Spring Integration.

Tích hợp mùa xuân là khung khiếu nại EIP tích hợp của hệ sinh thái Nguồn mùa xuân. Nó có sự tích hợp tuyệt vời với hệ sinh thái: Spring boot, Batch, XD; ngay cả lõi cũng sử dụng tính trừu tượng tương tự bắt đầu từ Spring Framework 4. Một số trừu tượng hóa tin nhắn đã được di chuyển trong khung, như một bằng chứng cho thấy sự trừu tượng hóa nhắn tin cơ bản của Spring Integration rất mạnh. Bây giờ, Spring framework sử dụng sự trừu tượng hóa tin nhắn cho Spring Web, hỗ trợ ổ cắm web.

Một điều tốt khác trong một ứng dụng Spring với sự tích hợp Spring để sử dụng Apache Camel là với tích hợp Spring, bạn chỉ có thể sử dụng một Bối cảnh ứng dụng. Hãy nhớ rằng bối cảnh lạc đà là một bối cảnh mùa xuân. nếu bạn có cơ hội sử dụng phiên bản Spring mới, tôi khuyên bạn nên sử dụng DSL DSL tích hợp Spring để cấu hình. Tôi sử dụng nó cho các dự án mới của tôi, và nó cảm thấy dễ đọc và rõ ràng hơn. Tôi hy vọng rằng sự phản ánh này có thể giúp bạn cho các đánh giá của bạn.

Một lý do để sử dụng Camel over Spring Integration là khi bạn cần một bộ EIP đặc trưng hơn. Tích hợp mùa xuân không cung cấp trừu tượng hơn những thứ như ThreadPool.

Lạc đà cung cấp các cấu trúc bổ sung để đơn giản hóa một số khía cạnh làm việc với mã đồng thời:

http://camel.apache.org/camel-23-threadpool-configuration.html

Nếu bạn không có nhu cầu về loại điều này và chỉ muốn kết nối tệp, JMS, điểm cuối FTP, v.v ... thì chỉ cần sử dụng Spring Integration.

Lạc đà đóng vai trò là phần mềm trung gian cho ứng dụng nơi người ta có thể thực hiện mô hình hóa dữ liệu, chuyển đổi các giá trị tin nhắn và vũ đạo của tin nhắn.

Nếu ứng dụng hiện tại của bạn đang ở trong Spring và yêu cầu các tính năng được Spring Integration của EIP hỗ trợ thì Spring Integration là tùy chọn tốt nhất khác yêu cầu nhiều định dạng hỗ trợ / giao thức / định dạng tệp của bên thứ ba, v.v.