Làm thế nào để cung cấp dịch vụ OSGi mỗi khách hàng

Question

Chúng tôi đang phát triển một ứng dụng web (cho phép gọi nó là một ngân hàng hình ảnh) mà chúng tôi đã xác định được nhu cầu sau:

• Ứng dụng phục vụ khách hàng trong đó bao gồm một tập hợp các người dùng.
• Một khách hàng mới có thể được tạo ra tự động và một khách hàng quản lý đó là người dùng
• Khách hàng có bộ tính năng khác nhau mà có thể thay đổi động
• Khách hàng có thể phát triển các tính năng riêng của họ và họ đã được triển khai.
• Ứng dụng này đồng nhất và có phiên bản hiện tại, nhưng phiên bản nâng của khách hàng vẫn có thể được xử lý riêng lẻ.
• Ứng dụng phải được quản lý tổng thể và khách hàng chia sẻ các tài nguyên dễ dàng để mở rộng quy mô.

Câu hỏi: Chúng ta có nên xây dựng trên một khuôn khổ OSGi tiêu chuẩn hoặc chúng ta sẽ tốt hơn của việc sử dụng một trong những mô hình ứng dụng mới nổi (Virgo, Bạch Dương hoặc tiêu chuẩn OSGi sắp tới)?

More nền và một vài suy nghĩ ban đầu:

Chúng tôi đang xây dựng một ứng dụng web mà chúng tôi hình dung sẽ sớm có hàng trăm khách hàng (công ty) với hàng trăm người dùng mỗi (nhân viên), nếu không tại sao bận tâm;). Chúng tôi muốn làm cho nó mô-đun do đó OSGi. Trong tương lai, khách hàng có thể phát triển và bổ sung các thành phần vào ứng dụng của họ để chúng tôi cần sự cô lập của khách hàng. Chúng tôi cũng có thể muốn các khách hàng khác nhau nhận các bộ tính năng khác nhau.

Cách "chính xác" để cung cấp các triển khai dịch vụ khác nhau cho các ứng dụng khách khác nhau của ứng dụng khi các khách hàng khác nhau chia sẻ cùng một gói như thế nào?

Chúng tôi có thể sử dụng phương pháp tiếp cận ứng dụng-máy chủ (chúng tôi đã xem Virgo) và tải từng gói một lần cho từng khách hàng vào "ứng dụng" của riêng họ. Tuy nhiên nó không cảm thấy giống như ôm OSGi. Chúng tôi không lưu trữ vô số các ứng dụng, 99% các dịch vụ sẽ chia sẻ cùng một impl. cho tất cả khách hàng. Ngoài ra chúng tôi muốn quản lý (cấu hình, giám sát, vv) ứng dụng như một.

Mỗi dịch vụ có thể được đăng ký (được định cấu hình đúng) một lần cho mỗi khách hàng cùng với một số thuộc tính "khách hàng-mã thông báo". Đó là một chút lộn xộn và sẽ phải được xử lý với một mô hình extender hoặc có lẽ một ManagedServiceFactory? Ngoài ra trước khi đăng ký một dịch vụ cho khách hàng Một người sẽ cần phải có được phiên bản A của mỗi phụ thuộc của nó.

Khách hàng "hiện tại" sẽ được biết đến với từng yêu cầu và có thể bị ràng buộc vào chuỗi. Đó là một chút của một mớ hỗn độn có để cung cấp một khách hàng-mã thông báo mỗi khi bạn tìm kiếm một dịch vụ. Nó làm cho nó khó khăn để sử dụng khung thành phần như kế hoạch chi tiết. Để khắc phục sự cố, chúng tôi có thể sử dụng các móc dịch vụ để ủy quyền cho từng loại dịch vụ đã đăng ký và cho phép gửi công văn đến đúng cá thể theo khách hàng hiện tại (chuỗi).

Bắt đầu toàn bộ trải nghiệm OSGi của chúng tôi bằng cách triển khai giải pháp khắc phục sự cố (hack?) Ở trên thực sự có cảm giác giống như chỉ dẫn chúng tôi đang đi sai đường dẫn. Vậy chúng ta nên làm gì? Quay lại Virgo? Hãy thử một cái gì đó tương tự như những gì được nêu ở trên? Một cái gì đó hoàn toàn khác nhau ?!

ps. Cảm ơn bạn đã đọc tất cả các con đường xuống đây!;)

Answer 1

Có một vài khía cạnh cho giải pháp:

Trước hết, bạn cần tìm cách định cấu hình các khách hàng khác nhau mà bạn có. Xây dựng một giải pháp trên đầu trang của ConfigurationAdmin có ý nghĩa ở đây, bởi vì sau đó bạn có thể tận dụng các tiêu chuẩn OSGi hiện có càng nhiều càng tốt. Lý do bạn có thể muốn xây dựng thứ gì đó ở trên là ConfigurationAdmin cho phép bạn định cấu hình từng dịch vụ riêng lẻ, nhưng bạn có thể muốn thêm lớp trên cùng để có thể định cấu hình toàn bộ ứng dụng của mình một cách thuận tiện hơn. Sau đó, một cấu hình như vậy có thể được dịch sang các cấu hình riêng lẻ của các dịch vụ.

Thêm thuộc tính vào các dịch vụ có triển khai cụ thể của khách hàng có ý nghĩa rất nhiều. Bạn có thể thiết lập chúng bằng cách sử dụng ManagedServiceFactory và thuộc tính giúp dễ dàng tra cứu dịch vụ cho đúng khách hàng bằng bộ lọc. Bạn thậm chí có thể xác định một kịch bản dự phòng nơi bạn hoặc tìm kiếm một dịch vụ khách hàng cụ thể, hoặc một dịch vụ chung (vì không phải tất cả các dịch vụ có thể sẽ là khách hàng cụ thể). Vì bạn cần thêm các bộ lọc như vậy vào các phụ thuộc của bạn, tôi khuyên bạn nên sử dụng giải pháp quản lý phụ thuộc hiện có và mở rộng nó cho trường hợp sử dụng cụ thể của bạn để phụ thuộc tự động thêm đúng bộ lọc cụ thể của khách hàng mà bạn không phải chỉ định bằng tay. Tôi nhận ra rằng tôi có thể phải đi vào chi tiết hơn ở đây, chỉ cần cho tôi biết ...

Câu hỏi tiếp theo là, cách theo dõi "ngữ cảnh" của khách hàng trong ứng dụng của bạn. Theo truyền thống, chỉ có một vài tùy chọn ở đây, với ngữ cảnh cục bộ chủ đề là ngữ cảnh được sử dụng nhiều nhất. Tuy nhiên, các chủ đề ràng buộc với khách hàng có xu hướng hạn chế bạn về các tùy chọn triển khai, như nói chung nó có nghĩa là bạn phải cấm các nhà phát triển tạo chủ đề và khó tải các nhiệm vụ nhất định cho các nhóm công việc. Nó thậm chí còn tệ hơn nếu bạn quyết định sử dụng Dịch vụ từ xa vì điều đó có nghĩa là bạn sẽ hoàn toàn mất bối cảnh.

Vì vậy, để thông qua trên việc xác định khách hàng từ một trong những thành phần khác, cá nhân tôi thích một giải pháp mà:

1. Ngay sau khi yêu cầu đến (ví dụ như trong servlet HTTP của bạn) bằng cách nào đó xác định khách hàng ID.
2. Chuyển hoàn toàn ID đó xuống chuỗi phụ thuộc dịch vụ.
3. Chỉ sử dụng các giải pháp như sử dụng địa chỉ chuỗi trong đường viền của một gói, ví dụ: bạn đang sử dụng thư viện của bên thứ ba bên trong gói cần theo dõi khách hàng.

Answer 2

Tôi đã suy nghĩ về cùng một vấn đề này (tôi nghĩ) trong một thời gian và muốn ý kiến ​​của bạn về sự tương tự sau đây.

Xem xét một loạt ứng dụng web mà bạn cung cấp kiểm soát truy cập bằng cơ sở hạ tầng đăng nhập một lần (SSO). Người dùng xác thực khi sử dụng máy chủ SSO và - khi có yêu cầu - ứng dụng web đích yêu cầu máy chủ SSO cho dù người dùng (vẫn) được xác thực và tự xác định liệu người dùng có được ủy quyền hay không. Thông tin ủy quyền cũng có thể được cung cấp bởi máy chủ SSO.

Bây giờ hãy nghĩ rằng gói ứng dụng của bạn là các ứng dụng nhỏ. Mặc dù chúng không phải là các ứng dụng web, sẽ không có ý nghĩa gì khi có một số loại gói SSO sử dụng các kỹ thuật SSO để thực hiện xác thực và cung cấp thông tin ủy quyền? Mỗi gói ứng dụng sẽ phải được phát triển hoặc được định cấu hình để sử dụng gói SSO để xác thực xác thực (mã thông báo SSO) và xác thực ủy quyền bằng cách yêu cầu gói SSO nếu người dùng được phép truy cập gói ứng dụng này.

Gói SSO duy trì một số loại kho lưu trữ phiên và cũng cung cấp các thuộc tính người dùng, ví dụ: thông tin để xác định kho dữ liệu (của một số loại) của người dùng này. Bằng cách này, bạn cũng sẽ không chuyển qua một mã thông báo dịch vụ khách hàng (có ý nghĩa) "", mà là một mã thông báo SSO bí mật được cung cấp và quản lý bởi gói SSO.

Answer 3

Xin vui lòng không phải là Virgo là một thùng chứa OSGi dựa trên Equinox, vì vậy nếu bạn không muốn sử dụng một số tính năng Virgo cụ thể, bạn không cần phải. Tuy nhiên, bạn sẽ nhận được rất nhiều benefits nếu bạn sử dụng Xử Nữ, ngay cả đối với một ứng dụng OSGi cơ bản. Nghe có vẻ, mặc dù, giống như bạn muốn hỗ trợ web, mà đi ra khỏi hộp với máy chủ web Virgo và sẽ giúp bạn tiết kiệm những rắc rối của cobbling nó với nhau cho mình.

Tiết lộ đầy đủ: Tôi dẫn đầu dự án Xử Nữ.