Embedded OSGi hoặc Bundle ứng dụng

Question

Tôi vừa dành hai ngày cuối cùng để đọc hết tất cả các thứ OSGi mà tôi có thể nắm được và cuối cùng tôi nghĩ mình đã có được đầu xung quanh nó.

Tôi hiện đang cố tích hợp ứng dụng đó với một ứng dụng hiện có vì nhiều lý do như plugin của bên thứ ba, cập nhật tự động, chưa kể rằng SOA chỉ làm tôi hạnh phúc.

bây giờ tôi có một quyết định tôi đang đấu tranh để thực hiện, đó là thời tiết

1. toàn bộ ứng dụng của tôi nên trở thành một bó OSGi cài đặt theo mặc định trong container; hoặc
2. Ứng dụng của tôi sẽ khởi chạy vùng chứa OSGi được nhúng và tương tác với nó cho tất cả các dịch vụ được cắm.

Tôi thích 1, vì điều này cho phép tôi cập nhật ứng dụng một cách dễ dàng và kiến ​​trúc sẽ nhất quán. Tất nhiên tôi hy vọng sẽ phải cấu trúc lại ứng dụng thành nhiều gói nhỏ hơn. Tuy nhiên 2 làm cho mọi thứ dễ dàng hơn nhiều trong ngắn hạn, nhưng sẽ trở nên khó xử trong tương lai.

Answer 1

Bạn đã xem máy chủ ứng dụng Spring chưa? Điều này không cho phép bạn quản lý công cụ này?

Answer 2

cho tùy chọn 1) bạn thực sự không muốn toàn bộ ứng dụng của mình trong một gói - bạn sẽ mất tất cả lợi ích từ OSGi - nhưng thực sự phụ thuộc vào kích thước ứng dụng của bạn.

Nó thực sự phụ thuộc vào nơi bạn muốn chạy ứng dụng và bạn muốn thực hiện tác vụ nào. Ngoài ra bạn có thể muốn có một số loại điều khiển từ xa để truy cập các dịch vụ tiếp xúc.

trong tùy chọn 1) bạn cần bật một số loại gói http/servlet (có cầu nối) trong tùy chọn 2) bạn có thể chạy bên trong máy chủ ứng dụng để không phải lo lắng về điều đó .

Câu hỏi đầu tiên bạn muốn tự hỏi mình là về môi trường hoạt động. Ai sẽ chạy ứng dụng? Họ có cần/muốn được đào tạo về OSGi không? Họ có thoải mái hơn với ngăn xếp J2EE không?

Tôi nghĩ rằng tùy chọn tốt nhất cho bạn là giữ cho các tùy chọn của bạn mở, không có sự khác biệt thực sự giữa 1) và 2) nhưng đang nhìn chằm chằm vào khung công tác OSGi, mã của bạn hoặc mã khung. Bản thân ứng dụng của bạn, tức là các bó cấu thành ứng dụng của bạn sẽ giống hệt nhau.

Lời khuyên của tôi sẽ không phải lo lắng quá nhiều về thời gian chạy OSGi để bắt đầu - nhưng bắt đầu phát triển OSGi - không có gì ngăn bạn phát triển "kiểu OSGi" và chạy trong môi trường JRE chuẩn.

Answer 3

Tôi nghĩ bạn muốn đi với tùy chọn 1 và yêu cầu ứng dụng của bạn bao gồm một nhóm các gói bên trong hộp chứa OSGi (chủ yếu là ngoài hộp).

1. Nó sẽ cải thiện tính mô đun của mã của riêng bạn. Bạn thậm chí có thể thấy rằng một số phần của nó có thể cung cấp các dịch vụ sử dụng bên ngoài ứng dụng gốc.
2. Việc sử dụng các gói khác từ bên trong OSGi dễ dàng hơn nhiều so với ứng dụng máy chủ. Vì ứng dụng máy chủ không thể thấy các lớp của bó (và các bó chỉ có thể thấy những gì bạn hiển thị rõ ràng từ máy chủ), bạn phải thiết lập một classpath hoặc khu nghỉ mát khá phức tạp để phản ánh để gọi các gói từ bên ngoài vùng chứa.

Vì vậy, tôi muốn nói rằng ngay cả trong ngắn hạn, tùy chọn 1 có thể dễ dàng hơn.

Ngoài ra, tôi đồng ý với xác nhận của Patrick rằng phần lớn mã của bạn không cần phải quan tâm nếu nó chạy trong OSGi hoặc trong một JVM thuần túy. Đặc biệt khi sử dụng các dịch vụ khai báo và nhu cầu sử dụng các giao diện và cơ chế OSGi từ mã của bạn sẽ giảm đáng kể: Bạn chỉ cần thêm một vài tệp mô tả vào META-INF của jar.

Answer 4

Tôi muốn sử dụng tùy chọn 2, Ứng dụng của bạn không phải là một gói mà là một ứng dụng. Nếu bạn muốn bổ sung giá trị OSGi, hãy sinh ra thùng chứa OSGi từ bên trong ứng dụng của bạn. Bằng cách đó, vào một ngày trong tương lai nếu bạn quyết định chuyển từ OSGi, bạn có thể làm một cách đơn giản.

Answer 5

Tôi chắc chắn sẽ giới thiệu 1 - ứng dụng sẽ trở thành một gói OSGi, và không chỉ vì cập nhật dễ dàng. Nếu một nửa mã của bạn nằm trong khung công tác OSGi và một nửa nằm bên ngoài, bạn sẽ phải xây dựng một cây cầu để giao tiếp giữa hai nửa; bạn cũng có thể gặp vấn đề với khả năng hiển thị lớp học.

Ngoài ra còn có nhiều lợi ích từ 1 và không khó đạt được. Những gì tôi muốn giới thiệu như sau:

• Tách riêng ứng dụng trong nhiều mô-đun vì nó có vẻ hợp lý với bạn.

Bạn không bị buộc phải có nhiều mô-đun - OSGi có thể dễ dàng xử lý hai gói 10 MB mỗi gói cũng như 100 gói nhỏ hơn. Sự tách biệt phải là kết quả của bản thân chức năng - một điểm khởi đầu tốt là sơ đồ kiến ​​trúc UML mà bạn có thể đã làm trước khi bạn bắt đầu thực hiện các công cụ. Những nơi mà các bộ phận chức năng khác nhau giao tiếp với nhau chính xác là nơi bạn nên suy nghĩ về việc xác định giao diện thay vì các lớp - và các giao diện này sẽ trở thành dịch vụ OSGi của bạn và triển khai sẽ trở thành gói - và lần sau bạn sẽ có để cập nhật một số phần, bạn sẽ tìm ra nó dễ dàng hơn nhiều để dự đoán hiệu ứng trên các phần khác của ứng dụng vì bạn đã tách nó rõ ràng và khai báo nó trong tệp kê khai của các gói.

• Tách biệt mọi thư viện nguồn mở/bên ngoài bạn sử dụng trong các gói riêng biệt. Họ có lẽ sẽ là những phần mà sẽ phải được cập nhật thường xuyên hơn và trên một dòng thời gian khác với mã của riêng bạn. Nó cũng quan trọng hơn ở đây để xác định các gói phụ thuộc rõ ràng, các phiên bản gói và để tránh phụ thuộc vào các phần triển khai thay vì chỉ trên các giao diện!

• Suy nghĩ về những phần nào của ứng dụng bạn muốn hiển thị với plugin. Sau đó, thực hiện các dịch vụ OSGi từ các phần này - tức là xuất bản các giao diện trong sổ đăng ký OSGi. Bạn không cần phải thực hiện bất kỳ điều cụ thể nào - bạn có thể xuất bản bất kỳ đối tượng Java nào. Các plugin sau đó sẽ sử dụng regitry để tra cứu.

• Cũng vậy với các plugin - hãy nghĩ về những gì bạn muốn nhận từ plugin và xác định giao diện tương ứng mà plugin có thể triển khai và xuất bản và ứng dụng của bạn có thể tra cứu trong sổ đăng ký.

• Và làm mẹo cuối cùng - xem những gói nào đã có sẵn trong khung công tác OSGi mà bạn đã chọn. Có nhiều giao diện OSGi tiêu chuẩn được xác định bởi đặc tả OSGi - cho cấu hình, ghi nhật ký, lưu trữ liên tục, kết nối từ xa, quản trị viên người dùng, sự kiện và nhiều tính năng khác. Vì chúng là tiêu chuẩn, bạn có thể sử dụng chúng mà không trở nên phụ thuộc vào bất kỳ triển khai OSGi cụ thể nào.Và gỡ cài đặt những gì bạn không cần.