ESB nên được đóng gói/triển khai như thế nào?

Question

Tôi đang cố gắng quấn đầu quanh Apache Camel, đây dường như là một ESB nhẹ. Nếu tôi hiểu Camel/ESBs một cách chính xác, thì bạn có thể nghĩ về Camel Route như một biểu đồ của các nút và các cạnh. Mỗi nút là điểm cuối trên tuyến đường (có thể tiêu thụ/tạo thông báo). Mỗi cạnh là một tuyến đường giữa hai điểm cuối khác nhau (1 nhà sản xuất và 1 người tiêu dùng).

Giả sử đó là chính xác, tôi có một câu hỏi thực tế: thực hành tốt nhất ra sao về việc triển khai ESB/Tuyến đường Camel của ứng dụng của bạn? Tôi có nên đóng gói nó như là JAR riêng của nó, hay nó xứng đáng là EAR của riêng nó đầy đủ các EJB, Dịch vụ Web và các JAR khác?

Tôi đoán tôi đang hỏi làm thế nào một Camel Route hoặc ESB nên được triển khai/kiến ​​trúc, như:

my-esb.ear/ 
    ejb1.jar/ 
     MyEJB_1.class 
    ejb2.jar/ 
     MyEJB_2.class 
    webservice.war/ 
     MyWebService.class 

Hoặc ...

my-esb.jar/ 
    MyEJB_1.class 
    MyEJB_2.class 
    MyWebService.class 

Answer 1

Từ hiểu biết của tôi, có một vài cách bạn có thể chạy Camel.

1. nhúng trong một ứng dụng Java: Bạn có thể nhúng Camel trong một ứng dụng độc lập Java. Trong trường hợp này, bạn sẽ bắt đầu một Camel Context bên trong ứng dụng của bạn sẽ bắt đầu các tuyến đường vv. Điều này thật tuyệt vời khi ứng dụng của bạn cần giao tiếp với các dịch vụ vv Để làm việc này, bạn cần triển khai Camel và các bên thứ ba cho các thành phần classpath.

2. Được nhúng trong ứng dụng web: Vì mọi người đã chỉ ra điều này có vẻ là một tùy chọn phổ biến. Các lọ Camel và các lọ bên thứ ba được bọc trong một tệp tin WAR và về cơ bản được triển khai tới một thùng chứa web như Tomcat để lưu trữ các dịch vụ Camel.

3. Nhúng trong máy chủ ứng dụng: Tôi đã đọc một số bài viết về cách triển khai Camel tới máy chủ Ứng dụng như JBoss và tôi thậm chí đã đọc về những người đang triển khai Glassfish. Điều này có vẻ rất giống với cách bạn triển khai với Tomcat. JBoss có một số vấn đề tải lớp mà bạn sẽ cần phải giải quyết mà làm cho nó khó khăn. Vì vậy, có bạn có thể triển khai đến một máy chủ ứng dụng bằng cách đi tuyến đường WAR.

4. Triển khai cho OSGi: Bạn có thể làm cho Camel của bạn trở thành gói OSGi tương đối nhanh và triển khai sang khung OSGi như Apache Felix. Nó tương đối đơn giản để chuyển đổi jar thành một gói OSGi thích hợp và sau đó triển khai. Một vấn đề lớn ở đây là một số bên thứ ba có thể không có các gói tương thích OSGi để bạn triển khai.

Sở thích cá nhân của tôi là tuyến OSGi. Nó rất dễ dàng và nhẹ và cho phép tôi lưu trữ các tuyến lạc đà của tôi như các dịch vụ liên tục (ví dụ: dịch vụ cửa sổ, Unix Deamon) với một bản in chân rất nhỏ.

Điều mà bạn nên nhận ra bây giờ là Apache Camel có thể được triển khai theo nhiều cách và bạn thực sự quyết định cách bạn muốn thực hiện điều đó. Tôi đã mất một thời gian để hiểu cách triển khai Camel như tôi phải chơi với các mô hình triển khai khác nhau để có được cảm giác tốt cho nó. Người duy nhất mà tôi chưa chạm đến là triển khai vào Máy chủ ứng dụng vì tôi cảm thấy hầu hết các Máy chủ này đều đủ nặng.

Về mặt kiến ​​trúc, tôi muốn giữ các tuyến đường/ứng dụng khác nhau trong các lọ khác nhau. Vì tôi đang sử dụng OSGi, tôi thích có thể cập nhật một lộ trình cụ thể và triển khai nó mà không phải triển khai lại mọi thứ. Nếu bạn triển khai tất cả mọi thứ trong một cái bình, bạn sẽ cần phải hạ gục thế giới xây dựng lại và triển khai lại cái bình. Tuy nhiên, đây là sở thích cá nhân và số dặm của bạn có thể khác nhau

Hy vọng điều này sẽ giúp ích một chút.

Answer 2

đó phụ thuộc vào nhu cầu của bạn. Không có câu trả lời chân lý nào tốt hơn.

Lạc đà có thể thích ứng với cơ sở hạ tầng và nền tảng thời gian chạy hiện tại của bạn. Vì vậy, đóng gói các ứng dụng của bạn với Camel nhúng cách nền tảng này có thể làm điều đó và theo cách bạn muốn.

Ví dụ sử dụng Camel trong một ứng dụng web (WAR), bạn có thể thấy liên kết này: http://camel.apache.org/tutorial-on-using-camel-in-a-web-application.html

Answer 3

Bạn đang cân nhắc .ear nhúng, tôi thấy.

Tôi khuyên bạn nên suy nghĩ kỹ về việc nhúng Camel vào bên trong một máy chủ Java EE đầy đủ tính năng. Nó chắc chắn là khả thi, nhưng bạn sẽ nhận được một số công việc để kết nối chúng (với commonJ, WorkManagers, JNDI references etc). Cụ thể, cho phép Camel xử lý luồng là một điểm cộng lớn.

Nhúng Camel bên trong ứng dụng web mùa xuân (.WAR) là mục yêu thích cá nhân của tôi để triển khai trong Jetty hoặc Tomcat. Sau đó, bạn có thể truy cập vào một thùng chứa servlet, một thời gian chạy có thể thực hiện một số thứ, v.v.

Thực ra, tôi đã sử dụng tải xuống tiêu chuẩn ActiveMQ trong một số môi trường sản xuất với Camel được tích hợp. rất nhiều ESB, nhưng vẫn còn, nó có thể là một sự lựa chọn hợp lệ nếu ActiveMQ là xương sống tin nhắn của ESB của bạn.

Answer 4

Giống như trong các câu trả lời khác, nó phụ thuộc vào nhu cầu của bạn nhưng ESB thường là sự kết hợp của các quy trình tích hợp khác nhau mà không nhất thiết phải chia sẻ cùng một vòng đời.

Nếu đây là trường hợp của bạn, tôi khuyên bạn nên sử dụng phương pháp tiếp cận quá trình hội nhập jar. Bằng cách đó bạn có thể có vòng đời phát triển khác nhau cho mỗi khác nhau của jar 's và bạn có thể đảm bảo với khách hàng của bạn rằng bạn đã không chạm vào bất kỳ mã nào ngoại trừ một trong đó jar.

Điều này không có nghĩa là bạn phải đi với giải pháp ear. Bạn hoàn toàn có thể đóng gói mã cho các quy trình khác nhau của mình trong một tệp war mà không có chi phí ear.

Answer 5

Hãy để tôi trả lời câu hỏi của bạn từng người một:

Cung cấp một, danh sách không mơ hồ mô tả các yếu tố chung mà nên được sử dụng để xác định làm thế nào để triển khai tốt nhất một ESB (hoặc như một EAR đơn với mỗi điểm cuối là một JAR được nhúng hoặc là một "nguyên khối" duy nhất JAR);

Bình hoặc khối nguyên khối không quan trọng. Những vấn đề nào được đưa vào hoặc triển khai chiến tranh. Trong trường hợp của Standalone bó, bạn có thể kết thúc với một kho lưu trữ triển khai rất chất béo có rất nhiều lọ để giải quyết sự phụ thuộc.

Hoàn toàn giải thích tại sao Camel có thể không chơi độc đáo với ứng dụng Java EE máy chủ như JBoss hoặc GlassFish

1. Chủ đề/Resource/Cảng Quản lý App-Server/container có thể áp đặt hạn chế.

2. Xung đột thường được sử dụng Thư viện Version

3. Xung đột trên cơ chế ClassLoading

logic, nếu container của bạn hỗ trợ OSGi sau đó Camel nên không gặp phải bất kỳ vấn đề.

1. Như Apache Camel là một rất nhẹ nhắn Router, Vì vậy, bạn có thể chắc chắn bạn có thể gói nó trong tai của bạn cùng với ứng dụng web của bạn như là một chiến tranh tập tin. Nếu bạn đang sử dụng maven/Ivy và thùng chứa web của bạn hỗ trợ osgi, thì Bingo! Cuộc sống sẽ dễ dàng hơn nhiều.
2. tùy chọn thứ hai là triển khai ứng dụng của bạn như một bó
3. và khác là độc lập Java SE jar.

Thực hiện theo các liên kết bên dưới [Mặc dù, lỗi thời đủ], những người sẽ cung cấp cho bạn bước theo các bước hướng trên bao bì, at-nhất rõ ràng về cơ chế đóng gói:

Camel Step By Step

Camel in a Web Application

Camel Real Life Packaging & Deployment in OSGi environment