Cách tốt nhất để bắt đầu với OSGI là gì?

Question

Điều gì làm cho một mô-đun/dịch vụ/bit của ứng dụng hoạt động một ứng cử viên đặc biệt tốt cho một mô-đun OSGi?

Tôi quan tâm đến việc sử dụng OSGi trong các ứng dụng của mình. Chúng tôi là một cửa hàng Java và chúng tôi sử dụng Spring khá rộng rãi, vì vậy tôi đang hướng tới việc sử dụng Spring Dynamic Modules for OSGi(tm) Service Platforms. Tôi đang tìm một cách tốt để kết hợp một chút OSGi vào một ứng dụng như một thử nghiệm. Có ai ở đây sử dụng công nghệ này hay một công nghệ OSGi tương tự? Có bất kỳ cạm bẫy nào không?

@Nicolas - Cảm ơn, tôi đã thấy điều đó. Đó là một hướng dẫn tốt, nhưng tôi đang tìm kiếm thêm ý tưởng về cách thực hiện gói OSGi "thực sự" đầu tiên của tôi, trái ngược với ví dụ Hello World.

@david - Cảm ơn bạn đã liên kết! Lý tưởng nhất, với một ứng dụng greenfield, tôi muốn thiết kế toàn bộ điều năng động. Những gì tôi đang tìm kiếm ngay bây giờ, tuy nhiên, là để giới thiệu nó trong một phần nhỏ của một ứng dụng hiện có. Giả sử tôi có thể chọn bất kỳ phần nào của ứng dụng, một số yếu tố để xem xét điều đó sẽ làm cho mảnh đó tốt hơn hoặc tệ hơn như một con lợn guinea OSGi là gì?

Answer 1

Vâng, vì bạn không thể có một phần OSGi và một phần không phải OSGi, bạn sẽ cần phải tạo toàn bộ OSGi ứng dụng của mình. Ở dạng đơn giản nhất, bạn tạo một gói OSGi duy nhất trong toàn bộ ứng dụng của bạn. Rõ ràng đây không phải là một thực hành tốt nhất nhưng nó có thể hữu ích để có được một cảm giác cho việc triển khai một gói trong một container OSGi (Equinox, Felix, Knoplerfish, vv).

Để chuyển sang cấp độ tiếp theo, bạn sẽ muốn bắt đầu chia ứng dụng của mình thành các thành phần, các thành phần thường có một tập hợp các trách nhiệm có thể được tách biệt với phần còn lại của ứng dụng của bạn thông qua bộ giao diện và phụ thuộc lớp. Xác định những điều này hoàn toàn bằng tay có thể từ khá đơn giản cho một ứng dụng được thiết kế kết hợp chặt chẽ nhưng lỏng lẻo với một cơn ác mộng đối với mã nguồn lồng vào nhau mà bạn không quen thuộc.

Một số trợ giúp có thể đến từ các công cụ như JDepend có thể hiển thị cho bạn khớp nối các gói Java với các gói/lớp khác trong hệ thống của bạn. Một gói có khớp nối thấp efferent nên dễ dàng hơn để giải nén vào một gói OSGi hơn một với khớp nối efferent cao. Thậm chí nhiều kiến ​​thức sâu sắc hơn có thể có với các công cụ chuyên nghiệp như Structure 101.

Hoàn toàn ở cấp độ kỹ thuật, làm việc hàng ngày với một ứng dụng bao gồm 160 gói OSGi và sử dụng Spring DM tôi có thể xác nhận rằng việc chuyển từ "bình thường" mùa xuân sang mùa xuân DM phần lớn là miễn phí. Không gian tên phụ và thực tế là bạn có thể (và nên) cô lập cấu hình Spring OSGi cụ thể của bạn trong các tệp riêng biệt giúp dễ dàng có cả hai trường hợp triển khai OSGi có và không có các kịch bản triển khai OSGi.

OSGi là một mô hình thành phần sâu và rộng, tài liệu hướng dẫn Tôi khuyên bạn nên:

• OSGi R4 Specification: Lấy PDF của Core và đặc điểm kỹ thuật Compendium, họ là kinh điển, có thẩm quyền và rất dễ đọc. Có một phím tắt cho họ tiện dụng mọi lúc, bạn sẽ tham khảo ý kiến ​​của họ.
• Đọc trên thực hành tốt nhất OSGi, có một tập hợp lớn các điều bạn thể làm nhưng một bộ hơi nhỏ hơn điều bạn nên làm và có một số điều bạn nên không bao giờ làm (DynamicImport: * cho thí dụ).

Một số liên kết:

• OSGi best practices and using Apache Felix
• Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
• một khái niệm OSGi chính là dịch vụ, tìm hiểu tại sao và làm thế nào họ thay thế mô hình Listener với Whiteboard pattern
• The Spring DM Google Group là rất nhạy và thân thiện với kinh nghiệm của tôi
  The Spring DM Google Group là no longer active và đã chuyển sang Eclipse.org dưới dạng dự án Blueprint Gemini có diễn đàn here.

Answer 2

Tôi thực sự thích số Apache Felix tutorials. Tuy nhiên, tôi nghĩ rằng nói chung tận dụng OSGi trong ứng dụng của bạn không phải là một trong những ứng dụng "chúng ta hãy sử dụng khung công tác này, bởi vì nó" cường điệu "quyết định. Đó là một câu hỏi thiết kế, nhưng sau đó tất cả mọi thứ mà OSGi cung cấp cho bạn về thiết kế, bạn có thể có với vani Java.

Đối với thời gian chạy, bạn không thể chỉ thêm một ứng dụng hiện có và làm cho nó OSGi được kích hoạt. Nó cần phải được thiết kế để năng động. Spring DM giúp bạn dễ dàng che giấu điều đó khỏi bạn, nhưng nó vẫn ở đó và bạn cần phải biết về nó.

Answer 3

Ứng dụng hiện có của bạn là nguyên khối hoặc được phân tầng trong các quy trình/lớp riêng biệt?

Nếu được xếp theo tầng, bạn có thể chuyển đổi giữa/tầng ứng dụng để chạy trong vùng chứa OSGi.

Trải nghiệm nhóm của tôi, chúng tôi đã tìm cách cố gắng làm những thứ web trong OSGi đau đớn. Các điểm đau khác là Hibernate và Jakarta Commons Logging.

Tôi tìm thấy thông số kỹ thuật OSGi khá dễ đọc và tôi khuyên bạn nên in sơ đồ hiển thị thuật toán để tải lớp. Tôi sẽ đảm bảo bạn sẽ có những khoảnh khắc, "tại sao tôi nhận được một NoClassDefFoundError?": Flowchart sẽ cho bạn biết lý do tại sao.

Answer 4

Có một vài suy nghĩ cần lưu ý nếu bạn bắt đầu với OSGi.

Như đã đề cập ở đâu đó trong chuỗi này, việc biết về việc tải lớp thực sự quan trọng. Theo kinh nghiệm của tôi, mọi người sớm hay muộn đều gặp phải vấn đề với nó.

Một điều quan trọng cần nhớ là: không bao giờ giữ tài liệu tham khảo! Hãy xem mẫu bảng trắng mà khái niệm dịch vụ OSGi đang xây dựng (xem liên kết trong một trong các câu trả lời khác).

Theo kinh nghiệm của tôi, bạn không nên cố gắng chuyển đổi một ứng dụng đơn nguyên thành một ứng dụng dựa trên OSGi. Điều này thường dẫn đến một mớ hỗn độn tồi tệ và không thể quản lý. Bắt đầu lại.

Tải xuống một trong những triển khai oSGi độc lập tự do có sẵn. Tôi thấy Knopflerfish khá tốt và ổn định (tôi sử dụng nó trong nhiều dự án). Nó cũng đi kèm với rất nhiều mã nguồn. Bạn có thể tìm thấy ở đây: http://www.knopflerfish.org

Một hướng dẫn hay khác có thể tìm thấy tại đây. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

Peter Kriens của Liên minh OSGi đã có một cuộc phỏng vấn tốt đẹp: http://www.infoq.com/interviews/osgi-peter-kriens. Trang chủ và blog của anh ấy (luôn đọc tốt ở đây có thể được tìm thấy tại đây: http://www.aqute.biz

Answer 5

Hãy thử http://neilbartlett.name/blog/osgibook/. Cuốn sách này có các ví dụ về thực hành tốt nhất OSGi.

Answer 6

Khi học một công cụ mới, công cụ phong phú sẽ đưa bạn vào những thứ không bị đau đầu nhiều. Tại thời điểm này cộng đồng tại ops4j.org cung cấp một bộ công cụ phong phú gọi là "PAX" trong đó bao gồm:

• Pax Runner: Chạy và chuyển đổi giữa Felix, Equinox, Knopflerfish và hướng dẫn khách dễ dàng
• Pax Xây dựng: Xây dựng, Tổ chức & Xây dựng các dự án OSGi với maven dễ dàng
• Pax Drone: Thử nghiệm gói OSGi của bạn với Junit trong khi độc lập khung (sử dụng PaxRunner)

Sau đó, có nhiều triển khai các dịch vụ tóm tắt OSGi:

• Pax Logging (logging),
• Pax Web (dịch vụ http),
• Pax Web Extender (hỗ trợ chiến tranh),
• Pax Coin (cấu hình),
• Vỏ Pax (triển khai trình bao, một phần của bản phát hành osgi tiếp theo)
• và hơn thế nữa.

.. và có một hữu ích, khuôn khổ independend cộng đồng, - nhưng thats tại quảng cáo ;-)

Answer 7

Câu trả lời này đến gần 3 năm sau khi câu hỏi được hỏi, nhưng link Tôi chỉ tìm thấy là thực sự tốt, đặc biệt là cho người mới bắt đầu sử dụng maven. Một lời giải thích từng bước.

Answer 8

Hãy thử http://njbartlett.name/files/osgibook_preview_20091217.pdf

HOẶC

http://www.manning.com/hall/

Thứ hai không phải là một cuốn sách tôi đã đọc bản thân mình nhưng tôi đã nghe những điều tốt đẹp về nó.

Điều đầu tiên rất hữu ích đối với tôi. Ông sẽ đưa bạn qua kiến ​​trúc ban đầu và sau đó là tay trên OSGi.