Apache Camel và các sản phẩm ESB khác

Này,
nếu chúng ta có Apache Camel tại sao lại sử dụng các giải pháp khác như Apache ServiceMix và Mule?
Có điều gì Apache Camel không thể làm được so với các sản phẩm này?
Khi nào thì sử dụng Mule / ServiceMix và khi nào thì sử dụng Camel?

Apache Camel là một thư viện thực hiện các mẫu tích hợp doanh nghiệp (EIP). Mặc dù nó có thể sử dụng Spring làm khuôn khổ IOC của mình, nó thậm chí không phụ thuộc vào Spring, vì vậy nó hoàn toàn độc lập với nền tảng. Nó "chỉ là" một thư viện. Vì vậy, bạn có thể chạy nó trong bất kỳ môi trường JVM nào, ví dụ như jvm, servlet, ejb, osgi đơn giản. Nó không mang lại bất kỳ lợi ích nào (hoặc chi phí) của một thùng chứa Mule như vậy. Theo tôi, nó có sự tách biệt rõ ràng hơn các mối quan tâm trong lĩnh vực này.

Mule cũng có thể được nhúng trong các môi trường khác nhau, nhưng tôi nghĩ Mule có cả ưu điểm và nhược điểm khi ghép thư viện EIP với vùng chứa của chúng. Khi bạn triển khai Mule bên trong môi trường servlet hoặc ejb, bạn có thực sự muốn mang theo tất cả hành lý đó của thùng chứa Mule không? Tôi không phải là một chuyên gia về Mule, và tôi nghĩ rằng bạn có thể dành một lượng công sức tương đối khiêm tốn và loại bỏ một số khả năng dư thừa. (Lưu ý rằng đây không phải là khả năng xấu trong mọi trường hợp, nó chỉ là dư thừa nếu bạn đang chạy được nhúng bên trong một vùng chứa khác.)

Apache ServiceMix là một vùng chứa OSGI sử dụng Camel để triển khai EIP làm cơ sở của một ESB. Mặc dù ServiceMix có lịch sử bắt đầu với nguồn gốc từ JBI, nó đã rời khỏi JBI và phát triển thành (IMO) một kiến ​​trúc phân lớp tốt đẹp kết hợp tốt nhất của giống Apache CXF, Camel và ActiveMQ trong một vùng chứa OSGI. Giá trị chính ở đây không thực sự là ServiceMix và hỗ trợ JBI của nó, mà là tiêu chuẩn vùng chứa OSGI cơ bảncùng với các phương thức truyền tải Apache đã được chứng minh như CXF cho các dịch vụ web và ActiveMQ cho JMS. OSGI là một tiêu chuẩn hoàn thiện cung cấp một vùng chứa giải quyết các loại "DLL" giống như địa ngục đã gây khó khăn cho Microsoft trước khi .NET ra đời. Mặc dù cả .NET và OSGI đều không giải quyết được sự phức tạp cơ bản của vấn đề cơ bản, nhưng ít nhất chúng cũng cung cấp một phương tiện để giải quyết nó. OSGI cũng có những lợi ích khác, nhưng từ quan điểm lựa chọn sản phẩm, vùng chứa dựa trên tiêu chuẩn là chính và tính năng thiết yếu của nó mà Mule (và Java nói chung) không đề cập là quản lý phụ thuộc.

Một số điều quan trọng cần lưu ý khi so sánh Mule với các cộng đồng Apache. Mule giống Redhat theo nghĩa là mặc dù nó là một giấy phép mã nguồn mở nhưng theo quan điểm của tôi, nó không thực sự là một cộng đồng mở. Bất kỳ ai cũng có thể tham gia vào Apache trong khi MuleSoft sở hữu cộng đồng Mule và lộ trình cuối cùng. Thứ hai, mặc dù cộng đồng Mule được cho là khá tích cực, nhưng tôi nghĩ cộng đồng Apache lớn hơn nhiều (và đương nhiên là như vậy vì nó không phải là một cộng đồng được kiểm soát). Cả hai cách tiếp cận đều có cả ưu điểm và nhược điểm. Một điểm tích cực đối với cách tiếp cận Apache là có nhiều nhà cung cấp cho ESB dựa trên Camel, CXF, ActiveMQ và OSGI. Ví dụ: Talend cung cấp ESB trên các công nghệ cốt lõi tương tự mà không có lịch sử ServiceMix JBI. Điều này có cả ưu điểm và nhược điểm trong cộng đồng Apache, nhưng điểm thực sự là làm nổi bật sự khác biệt giữa Apache và Mule. Bạn sẽ không tìm thấy các nhà cung cấp multilple trong cộng đồng Mule. Vì vậy, IMO một Apache ESB như Talend hoặc ServiceMix là một cộng đồng cạnh tranh rộng rãi hơn và toàn diện hơn, và cuối cùng là một cộng đồng khép kín như Mule.

Ed Ost

Bây giờ là năm 2016 và rất nhiều điều đã thay đổi kể từ khi câu hỏi được đặt ra ban đầu, vì vậy tôi muốn xem lại nó cho những người xem mới.

Nói một cách chiến lược

• Apache Camel vẫn đúng với nguồn gốc của nó và không phát triển thành một nền tảng thời gian chạy nặng nề cũng như không chính thức. Nó rất linh hoạt và mô-đun, và có thể chạy:

  1. Được nhúng trong bất kỳ loại vùng chứa Java nào (vùng chứa servlet, máy chủ ứng dụng, Spring Boot).
  2. Độc lập như một quy trình Java.
  3. Bên trong môi trường OSGi ( Apache Karaf ).

• Apache Camel đã tiếp tục phát triển và đạt được sức hút cũng như hoạt động hàng tháng, như được mô tả bằng biểu đồ mà tôi trích xuất từ OpenHub dưới đây . Cơ sở người dùng cũng không ngừng tăng lên.

• Năm 2012, Red Hat mua lại FuseSource , một trong những nhà quảng bá và phát triển chính đằng sau Apache Camel, ActiveMQ, ServiceMix và CXF. Một số người cam kết và thành viên PMC hiện đang được Red Hat tuyển dụng để làm việc trên Apache Camel.

• Mule ESB cung cấp hai phiên bản sản phẩm của họ : Community (miễn phí theo giấy phép CPAL) và Enterprise (trả phí). Họ định nghĩa phiên bản Cộng đồng của họ là:

Lý tưởng để đánh giá hoặc sử dụng trước khi sản xuất.

=> Có nghĩa là bạn nên đăng ký Enterprise trả phí để sử dụng sản xuất.

• Trên thực tế, Mule ESB Community Edition được phân phối theo giấy phép CPAL . Điều này có nghĩa là nếu bạn vẫn quyết định sử dụng phiên bản này, Mule YÊU CẦU RẰNG :

  • Mỗi khi một Mã nguồn thực thi và một Tác phẩm lớn hơn được khởi chạy hoặc chạy lần đầu, một màn hình hiển thị nổi bật Thông tin phân bổ của Mulesoft phải xuất hiện trên giao diện người dùng đồ họa mà người dùng cuối sử dụng để truy cập Mã được bảo vệ đó (có thể bao gồm hiển thị trên màn hình giật gân ), nếu có. => Về cơ bản bạn cần phải quảng cáo rằng bất cứ thứ gì bạn đã xây dựng với Mule đều chạy trên Mule.

  • Nếu việc triển khai Mule ESB của bạn được truy cập qua mạng (nó luôn như vậy, vì đây là một nền tảng tích hợp!), Bạn cũng phải cung cấp Nguồn của việc triển khai của bạn cho bất kỳ ai đang truy cập nó.

• Như ai đó đã đề cập ở trên, Apache Camel là một dự án hoàn toàn mở và được định hướng bởi cộng đồng, vì cộng đồng . Tất cả mã nguồn đều có sẵn công khai và mọi người được khuyến khích gửi yêu cầu kéo, đóng góp các thành phần và trợ giúp hoặc hỏi trong diễn đàn. Ngược lại, cộng đồng Mule là một cộng đồng gated .

• Cuối cùng nhưng không kém phần quan trọng; có lẽ là phần quan trọng nhất. Đây là những gì Google Xu hướng nói về Mule ESB so với Apache Camel . Lưu ý rằng tôi đang sử dụng phép đo chủ đề ngữ nghĩa mới để có độ chính xác cao hơn thay vì từ khóa truy vấn tiêu chuẩn . Bằng cách đó, chúng tôi không đo lường mức độ phổ biến của các loài động vật (Mule vs Lạc đà), mà là của Phần mềm! Giải thích: Mule có xu hướng giảm mạnh từ năm 2007 đến năm 2011, trong khi Apache Camel có xu hướng tăng. Kể từ năm 2011, Mule đã tăng trưởng ổn định, trong khi Apache Camel tiếp tục có xu hướng tăng lên một cách lành mạnh!

Sự phát triển kỹ thuật của Apache Camel

Chỉ muốn cung cấp cho bạn một số chỉ số chức năng về sự phát triển của Apache Camel kể từ ngày 25 tháng 9 năm 2010, khi bạn đặt câu hỏi ban đầu. Đây là cây nguồn tại thời điểm đó .

• Hồi đó, Camel có 88 thành phần, hiện nó có 220 thành phần bao gồm tích hợp với Facebook, Twitter, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark, v.v.
• Nhiều, nhiều cải tiến kỹ thuật: Công cụ định tuyến không đồng bộ, Lịch sử thông báo, EIP ngắt mạch, nhiều cải tiến và nâng cao cho EIP như Tổng hợp, Tách, Định tuyến động, v.v.
• Hệ sinh thái đã phát triển đến nay cũng bao gồm Hawtio để giám sát và quản lý, Fabric8 để triển khai, v.v.
• Kể từ đó, hơn 5500 vé đã được giải quyết bao gồm các tính năng mới, cải tiến, lỗi, v.v.
• Và nhiều, nhiều hơn nữa!

Ghi chú cuối cùng

Cả hai sản phẩm đã phát triển rất nhiều trong vòng 5,25 năm qua! Tuy nhiên, do sự khác biệt về giấy phép và bản chất cộng đồng của Mule ESB và Apache Camel, tôi không nghĩ chúng có thể so sánh được với nhau nữa.

Apache Camel hoàn toàn là Mã nguồn mở ❤️, trong khi Cộng đồng Mule ESB yêu cầu người dùng thuộc tính Mulesoft và xuất bản mã nguồn của phần mềm sử dụng Mule. Giấy phép Phần mềm Apache là một giấy phép thân thiện với doanh nghiệp : bạn có thể tự do sử dụng Camel mà không cần quy định hay bất kỳ yêu cầu nào khác. Thực sự miễn phí như trong bia !

Hy vọng sự suy ngẫm về những năm qua sẽ giúp ích cho những người xem mới! :)

Tuyên bố từ chối trách nhiệm: Tôi là người cam kết và thành viên PMC tại dự án Apache Camel.

Bài đăng trên blog của tôi trả lời chính xác câu hỏi này: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel là một khung tích hợp nhẹ, ServiceMix và như vậy là các ESB đầy đủ.

Camel là một công cụ dàn xếp trong khi Mule là một nền tảng tích hợp trọng lượng nhẹ. Sự khác biệt là Mule cung cấp tất cả các khả năng của một ESB bao gồm một vùng chứa để triển khai các ứng dụng, REST và Dịch vụ Web. Mule có thể được nhúng theo cách tương tự Camel để cho phép các nhà phát triển ứng dụng nhúng mã ứng dụng vào đó với mã tích hợp của họ. Cả hai hòa nhập chặt chẽ với mùa Xuân.

Mule không sử dụng JBI vì những lý do chính đáng và bây giờ thông số JBI đã bị giải tán (không có nhóm làm việc nào, thuộc sở hữu của Oracle, người đã chuyển giao thông số JBI ban đầu) thì không có lý do chuyên môn hay kỹ thuật nào để sử dụng JBI.

Có một số mục Câu hỏi thường gặp tại Apache Camel làm sáng tỏ điều này http://camel.apache.org/faq

Và bộ sưu tập liên kết tại Apache Camel http://camel.apache.org/articles.html

Có một số liên kết nơi mọi người trong cộng đồng nói chuyện và so sánh Camel với các dự án khác.

Claus, có một số lỗi trong Câu hỏi thường gặp về lạc đà, không ngạc nhiên, không có lỗi nào trong số đó có lợi cho chúng tôi :)

• mô hình UMO trong Mule không còn ở Mule nữa. Chúng tôi bắt đầu loại bỏ mô hình đó trong Mule 2 và nó đã được thay đổi hoàn toàn trong Mule 3. Giờ đây, chúng tôi có một mô hình Bộ xử lý thông báo rất đơn giản khiến tuyên bố của bạn về nó là thừa
• Mule đã có chuyển đổi loại rõ ràng trong một vài năm nay, đây không phải là điểm khác biệt cho Camel
• Mule được cấp phép theo giấy phép CPAL 1.0 được OSI phê duyệt . Đây là giấy phép nguồn mở không phải là giấy phép thương mại. Vui lòng cập nhật điều này càng sớm càng tốt

Trước tiên, bạn cần hiểu rằng Service Mix giống như một thùng chứa có thể chạy mã Apache Camel và Mule ESB là một sản phẩm riêng biệt.

Có thể có rất nhiều sự khác biệt mà bạn có thể cung cấp giữa các sản phẩm ESB.

Bạn nên biết một vài điều trước khi tìm hiểu sự khác biệt. họ đang

1. Làm thế nào các sản phẩm được phát triển
2. Cấp phép của nó
3. Các tính năng hỗ trợ của nó
4. Nguồn mở hay không
5. Nếu nguồn mở thì nguồn có thể được sửa đổi và sử dụng, v.v.

Trên đây sẽ là những yếu tố tốt nhất mà bạn cần xem xét trước khi đưa ra lựa chọn. Ở trên là chung cho hầu hết các lựa chọn sản phẩm và nó cũng cần được chú ý đặc biệt ở đây.

Sự khác biệt của sản phẩm thứ cấp sẽ dành riêng cho các công cụ và miền của nó. Đây có thể là câu trả lời mà bạn đang tìm kiếm. Tìm danh sách mà bạn cần xem xét trước khi lựa chọn.

1. Sự đóng góp cho cộng đồng
2. Chồng sản phẩm
3. Khả năng mở rộng về mặt sửa đổi mã của riêng bạn
4. Khả năng học hỏi và khả năng sử dụng
5. Hỗ trợ sản phẩm khi mua dưới dạng doanh nghiệp

Đây có lẽ là một nghiên cứu mà bạn cần phải tự mình thực hiện để chọn ra sự khác biệt. Bất kỳ cách nào cũng có nhiều giá trị cộng thêm khiến sản phẩm phù hợp với tổ chức của bạn hơn là nói tốt nhất trên thị trường.

Khi nói đến lạc đà Apache hoặc ESB khác. Sự khác biệt sẽ tạo ra là

1. Số lượng phương tiện giao thông
2. Apache Camel cung cấp cho bạn Nhiều loại DSL trên Mule và khác là họ không có nhiều DSL như trong Camel.
3. Mule trong ngăn xếp sản phẩm của nó chứa quản lý API và các trình kết nối Đám mây nội bộ trong đó Apache Camel là một khuôn khổ khi FUSE ESB được tính đến JBoss Stack cung cấp một lượng lớn các sản phẩm khác có thể bổ sung cho lựa chọn của bạn.