2012-07-01 33 views
6

Tôi biết rằng đã có một số câu hỏi liên quan đến chủ đề này nhưng tôi chưa thể tìm được giải pháp thực sự.Làm thế nào để mô đun hóa một ứng dụng doanh nghiệp với OSGi và EE6?

Hiện tại tôi đang phát triển các ứng dụng với EE6, sử dụng JPA, CDI, JSF. Tôi muốn có một cách tiếp cận mô-đun hơn bao gói tất cả mọi thứ vào một WAR hoặc EAR và triển khai toàn bộ điều trên một máy chủ ứng dụng.

tôi đang cố gắng để thiết kế các ứng dụng của tôi như là mô-đun càng tốt bằng cách tách một module vào 3 dự án maven:

  • API - Chứa các giao diện cho các dịch vụ (stateless)
  • Người mẫu - Chứa các Entities JPA cho module cụ thể
  • Impl - Chứa thi hành API, đậu chủ yếu CDI

Quan điểm logic của mỗi mô-đun hiện đang bundeled trong vòng một lớn dự án web, rất xấu. Tôi đã nghĩ về các mảnh web, nhưng nếu tôi truyền các lớp bean và các tệp xhtml trong các tệp jar, tôi sẽ phải triển khai một móc để các tài nguyên có thể được tìm kiếm bởi một ứng dụng web mẹ. Loại giải pháp này ít nhất sẽ cho phép tôi có một dự án thứ tư cho mỗi mô-đun sẽ chứa tất cả logic xem có liên quan đến mô-đun, đó là một khởi đầu tốt.

Điều tôi muốn không chỉ là tôi có thể có 4 loại dự án đó, mà cả mọi dự án đều có thể thay thế được. Điều này đã dẫn tôi đến OSGi, lúc đầu nó thực sự mát mẻ cho đến khi tôi nhận ra rằng các công nghệ EE6 không được hỗ trợ rất tốt trong một Vùng chứa OSGi.

JPA

Hãy nhìn vào JPA đầu tiên. Có một số hướng dẫn giải thích cách tạo Gói OSGi được kích hoạt JPA, nhưng không có hướng dẫn nào trong số này hướng dẫn cách truyền các thực thể thành các gói khác nhau (dự án mô hình của một mô-đun). Tôi muốn có ví dụ ba mô-đun khác nhau

  • Lõi
  • tài
  • Blog

Dự án mô hình của các module blog có một (thời gian biên dịch) sự phụ thuộc vào các dự án mô hình của người dùng. Dự án mô hình của mô-đun người dùng có phụ thuộc (biên dịch) phụ thuộc vào dự án mô hình cốt lõi.

Làm cách nào để JPA hoạt động trong trường hợp như vậy mà không phải tạo đơn vị Persistence cho mỗi dự án mô hình của mô-đun? Tôi muốn có một đơn vị kiên trì nhận thức được tất cả các thực thể có sẵn trong thời gian chạy. Các dự án mô hình trong đó các thực thể nên tất nhiên là có thể thay thế nóng. Có lẽ tôi sẽ cần phải thực hiện một dự án riêng biệt cho mỗi khách hàng nhập khẩu tất cả các thực thể cần thiết của các dự án và chứa một persistence.xml bao gồm tất cả những thứ cấu hình cần thiết. Có bất kỳ plugin maven nào có sẵn để xây dựng một dự án như vậy hay thậm chí các cách tiếp cận khác để giải quyết vấn đề đó không?

CDI

CDI là rất tốt đẹp. Tôi thực sự thích nó và tôi không muốn bỏ lỡ nó nữa! Tôi sử dụng các phần mở rộng CDI như MyFaces CODI và DeltaSpike rất tuyệt vời! Tôi tiêm dịch vụ (không quốc tịch) của tôi vào các dịch vụ khác hoặc vào lớp xem chỉ tuyệt vời. Vì các dịch vụ của tôi là không trạng thái nên không phải là vấn đề khi sử dụng chúng như các Dịch vụ OSGi, nhưng còn về tích hợp CDI trong OSGi thì sao? Tôi tìm thấy một CDI Extension glass [2] mà có thể tiêm các dịch vụ OSGi vào các hạt CDI, nhưng tôi cũng muốn các dịch vụ OSGi là các hạt CDI. Tôi không hoàn toàn chắc chắn làm thế nào để đạt được điều đó, có lẽ tôi sẽ phải sử dụng BeanManager để nhanh chóng triển khai và sau đó đăng ký mọi thực hiện cho giao diện của nó trong ServiceRegistry trong một BundleActivator. Có cách nào tiêu chuẩn để làm điều đó không? Tôi muốn tránh bất kỳ phụ thuộc (biên dịch) phụ thuộc vào khung công tác OSGi.

Tôi cũng muốn sử dụng dịch vụ của mình giống như tôi sử dụng chúng ngay bây giờ mà không thay đổi bất kỳ điều gì (triển khai không được chú thích và điểm phun không đủ điều kiện). Có một dự án phụ/mở rộng JBoss Weld [3] dường như nhắm mục tiêu vấn đề đó nhưng có vẻ như không hoạt động, tôi không thể tìm thấy bất kỳ phương pháp hay cách thực hành nào tốt nhất. Làm cách nào để rời khỏi triển khai của tôi nhưng vẫn có thể sử dụng OSGi? Tôi có nghĩa là nó sẽ không được một thỏa thuận lớn để thêm một chú thích để triển khai kể từ khi thực hiện tất cả đã được chú thích với một chú thích khuôn mẫu, dù sao tôi muốn ngăn chặn điều đó.

JSF

Như đã đề cập trước khi tôi muốn để có thể lây lan mô-đun logic xem tôi khôn ngoan. Theo như tôi biết điều này là không thực sự có thể ra khỏi hộp. Pax Web [4] nên giải quyết bằng cách nào đó, nhưng tôi không quen thuộc với nó.

Tôi muốn có một dự án "CoreWeb" trong mô-đun "lõi" có chứa mẫu Facelet, hãy gọi nó là "template.xhtml". Trang JSF trong một dự án có tên là "BlogWeb" trong "blog" mô-đun sẽ có thể tham chiếu đến mẫu đó và áp dụng một bố cục.

Để có thể mở rộng chế độ xem, tôi sẽ giới thiệu giao diện java "Phần mở rộng" có thể được triển khai bởi một lớp học cụ thể của mô-đun. Một bộ điều khiển cho một khung nhìn sau đó sẽ tiêm tất cả các hiện thực của phần mở rộng. Ví dụ: tiện ích mở rộng sẽ cung cấp danh sách các bản xem phụ sẽ được đưa vào chế độ xem chính.

Cơ chế mở rộng được mô tả có thể được thực hiện một cách dễ dàng, nhưng các yêu cầu sau đây phải được đáp ứng:

  • Khi thêm mới OSGi Gói đến máy chủ ứng dụng, thiết lập các phần mở rộng có sẵn có thể thay đổi, các phần mở rộng phải có sẵn cho bộ điều khiển của chế độ xem.
  • Các bản xem trước (từ một gói riêng) cần được đưa vào chế độ xem chính sẽ có thể truy cập được.

Khái niệm về một ứng dụng đơn lẻ nhưng nhiều lát của Spring Slices [5] rất thú vị, nhưng dường như bị giới hạn ở Spring DM Server và dự án cũng có vẻ không hoạt động.

Tóm tắt

Sau khi tất cả các ví dụ và hành vi tôi đã mô tả Tôi hy vọng rằng bạn biết những gì tôi muốn đạt được. Nó chỉ đơn giản là một ứng dụng EE6 rất năng động và mô đun hóa.

Điều tôi tìm kiếm ở phần cuối là ít nhất tài liệu về cách để mọi thứ hoạt động như tôi mong đợi hoặc thậm chí tốt hơn một giải pháp đã hoạt động!

[1] http://jaxenter.com/tutorial-using-jpa-in-an-osgi-environment-36661.html

[2] https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi

[3] http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi

[4] http://team.ops4j.org/wiki//display/paxweb/Pax+Web

[5] https://jira.springsource.org/browse/SLICE

Trả lời

1

Để trả lời một số câu hỏi của bạn , bằng cách sử dụng một đơn vị kiên trì duy nhất nhưng truyền bá các thực thể của bạn trên nhiều gói ple is not recommended, but may occasionally work. Tuy nhiên, nếu các thực thể của bạn có liên quan chặt chẽ tới mức chúng cần chia sẻ một đơn vị kiên trì, việc chia chúng thành các mô-đun có thể không có ý nghĩa. Ngoài ra, đừng quên bạn có thể xử lý các phụ thuộc biên dịch-thời gian bằng cách tách việc triển khai thực hiện và giao diện cho mỗi thực thể - giao diện và thực hiện không cần phải ở trong cùng một gói.

Để tiêm phụ thuộc, bạn có thể muốn Blueprint. Một số triển khai có sẵn và hầu hết các máy chủ ứng dụng có hỗ trợ hỗ trợ OSGi dành cho doanh nghiệp Blueprint ra khỏi hộp. Nó sử dụng XML để thêm siêu dữ liệu, do đó, các lớp sẽ không cần bất kỳ sửa đổi nào.

+0

Mô-đun cốt lõi cũng chứa quyền truy cập chung cho các thực thể có sẵn vì vậy tôi phải có chính xác một PU, nhưng sẽ rất tuyệt nếu tôi không phải gói chúng vào một tệp jar. Có lẽ một số bổ sung maven sẽ làm bao bì, nhưng IMO nó bằng cách nào đó không giống như OSGi. Tôi đã xem xét một số ví dụ về Blueprint và tôi không thích cấu hình xml không an toàn. Nếu không có tùy chọn nào khác, thì có lẽ tôi sẽ phải tự mình sử dụng hoặc thực hiện giải pháp CDI. –

+0

Christian, bạn đã tìm thấy giải pháp hoàn hảo nào cho ứng dụng mô-đun của mình chưa. bạn có thể chia sẻ với tôi không. Tôi có cùng một vấn đề? – Suraj

+0

Tôi không thể tìm thấy bất kỳ giải pháp trực tiếp nào cho điều đó. Tôi đang chờ đợi Java 9 (Jigsaw) và một bản phát hành EE sử dụng các mô-đun. Giải pháp hiện tại cho các dự án JPA: Sử dụng một dự án kiên trì bao gồm các tệp orm.xml của các mô-đun con. Giải pháp hiện tại cho các dự án CDI: Để các dự án tách biệt như dự án và cẩn thận khi thêm các phụ thuộc. Giải pháp hiện tại cho dự án Web: Xác định nội dung nếu có thể thành các tiểu dự án và kết hợp mọi thứ trong bản dựng. Triển khai lại nếu bạn muốn thêm mô-đun mới hoặc đặt tất cả các mô-đun trong ứng dụng nhưng chỉ hiển thị các tập hợp con. –

Các vấn đề liên quan