Khung công tác OSGi của doanh nghiệp: So sánh sự trưởng thành Apache Aries vs. Eclipse Gemini

Question

Câu hỏi: Kể từ hôm nay, khuôn khổ nào trong hai khung công tác OSGi của doanh nghiệp trưởng thành hơn: Apache Aries hoặc Eclipse Gemini?

Tôi đã thực hiện một số nghiên cứu cơ bản về khả năng OSGi của Aries và Gemini Enterprise OSGi. Tôi cũng đã trải qua một câu hỏi tương tự: Gemini and Apache Aries blueprint container.

Yêu cầu và phát hiện của tôi bên dưới. Sẽ đánh giá cao các yếu tố đầu vào bổ sung của bạn.

1. Vùng chứa bản thiết kế: Cả hai Aries và Gemini đều có vẻ trưởng thành về mặt thực thi so với thông số kỹ thuật Blueprint.

2. phát triển Web (sẽ được phát triển chống lại JSR 286 sử dụng Spring Portlet MVC):
   Mặc dù Gemini web có nguồn gốc trong mùa xuân DM (do đó ưu tiên ban đầu của tôi về phía khung Gemini), tôi tin rằng Bạch Dương nên kém khả năng làm việc với các ứng dụng Web dựa trên Spring Portlet MVC.

3. JPA: Đây là lĩnh vực quan tâm lớn nhất của tôi. Mặc dù ban đầu tôi nghiêng về phía Gemini hơn (do nguồn gốc từ Spring DM và hỗ trợ từ cộng đồng SpringSource đang hoạt động), tôi cảm thấy rằng sự trưởng thành của Jini Gemini là khá thấp so với Aries JPA. Lý do:

   • Gemini JPA chỉ hỗ trợ tích hợp với EclipseLink là nhà cung cấp JPA. Tôi muốn sử dụng Hibernate. Aries JPA hỗ trợ Hibernate.
   • Tham chiếu đến Gemini JPA limitations: đặc biệt giới hạn # 5: Thiếu sự hỗ trợ cho các giao dịch JTA. Có vẻ như là Aries JPA supports JTA ... Nhưng tôi đã không thể nhận được thông tin chi tiết về mức hỗ trợ.

4. JNDI: Các ứng dụng web mới của tôi sẽ cần phải gọi vào EJB phiên hiện tại từ tầng dịch vụ được lưu trữ bên trong máy chủ ứng dụng JBoss. Do đó hỗ trợ JNDI là rất quan trọng đối với các ứng dụng Web đã bật OSGi của tôi trong tầng máy khách.
   Dường như Gemini đặt tên là yet to be released trong khi Bạch Dương có already got some capability in this area.

Answer 1

cùng một câu hỏi xuất hiện trong đầu của tôi và tôi đã nhận kết quả như sau:

1: Gemini được dựa trên mùa xuân trong đó có còn là một nhiều quá khứ và tỏ ra rất nhiều. Khi tôi nhìn vào mã Gemini dường như sạch hơn một chút với nhiều khả năng mở rộng hơn tuy nhiên tôi đã có vấn đề với các trình xử lý không gian tên. Ngay cả với phiên bản 1.0.0 nó đã không chờ xử lý không gian tên. Bạch Dương chờ xử lý NS theo cách tương tự như nó đợi các tham chiếu bắt buộc. Tôi hỏi các nhân viên OSGi và họ nói rằng thông số Blueprint tiếp theo có thể chứa một API xử lý NS tiêu chuẩn theo ý kiến ​​của tôi sẽ giúp ích rất nhiều. Kết luận của tôi là tôi sử dụng Apache Aries nhưng nó không phải là quyết định cuối cùng. Tôi xem lại chủ đề này trong mỗi quý của năm. Tôi cũng đã thực hiện một số gợi ý về cách cải thiện Kế hoạch chi tiết và tải nó lên OSGi bugzilla. Tôi muốn thực hiện những cải tiến này trong mùa hè và khi tôi xem xét mã, nó sẽ dễ dàng hơn nhiều dựa trên Gemini.

2: Gemini chứa Tomcat được nhúng. Nếu bạn chỉ đơn giản là thả các bó vào một phân tích thì nó hoạt động khá tốt. Tuy nhiên nó có chứa một số phụ thuộc vào mùa xuân mà tôi muốn tránh. Tôi thích mùa xuân nhưng tôi muốn phụ thuộc ít hơn khi tôi cần. Tôi không nghĩ rằng Aries có bất kỳ hỗ trợ lớn trong chủ đề này.Cuối cùng tôi đã bắt đầu sử dụng Jetty hoạt động với Myfaces và Jersey cho đến bây giờ. Tôi đã không thử bất cứ điều gì khác cho đến bây giờ. Ngoài ra tôi thích khả năng cấu hình của Jetty hơn. Gói cấu hình có thể được định nghĩa là một biến môi trường có thể giúp ích rất nhiều nếu bạn muốn chạy các phép kiểm thử tích hợp như là một phần của vòng đời xây dựng của bạn. Nếu Gemini hỗ trợ nhiều tùy chọn cấu hình hơn (như đến từ gói), tôi sẽ nghĩ đến việc chuyển sang tùy chọn đó.

3: Vì tôi thích sử dụng JTA, tôi không thể sử dụng Gemini chút nào. Tôi đã sử dụng Aries JPA cho yên tĩnh một thời gian và tôi đã hài lòng với nó. Khi tôi làm việc với nhiều đồng nghiệp, tôi chịu trách nhiệm về hiệu quả của họ. Với Aries JPA, tôi có vấn đề là nó không đợi các dịch vụ DataSourceFactory (nếu kết nối db được định nghĩa trong persistence.xml) hoặc các dịch vụ DataSource (nếu nguồn dữ liệu jta hoặc nguồn dữ liệu không phải jta) được định nghĩa. Điều đó có nghĩa là thứ tự khởi đầu của gói quan trọng khi bạn sử dụng Aries JPA.

Nó không phải là một vấn đề cho đến khi chúng tôi sử dụng Glassfish và JNDI như Glassfish bắt đầu các nguồn lực JNDI trước khi gói OSGI của chúng tôi. Khi chúng tôi dọn dẹp hộp chứa OSGI, chúng tôi bắt đầu có vấn đề và đồng nghiệp của tôi bắt đầu dành một lượng lớn thời gian cố gắng để có được gói bắt đầu đúng.

Cuối cùng, tôi chỉ cần gói Aries JPA vào một gói và viết lại các phần tôi không thích. Điều này có nghĩa là tôi chỉ giữ phần phân tích cú pháp persistence.xml và tạo một dự án riêng tại http://everit.org/osgi/jpa/org.everit.osgi.jpa.container/index.html nơi mà tôi tập trung không gặp khó khăn này. Hiện tại nó hoạt động với Hibernate và tôi đoán (chưa thử) với Eclipselink và biên dịch tăng cường thời gian OpenJPA. Vùng chứa được viết bởi tôi hoạt động tốt với trình quản lý không gian tên org.apache.aries.jpa.container.context và aries jpa blueprint.

4: Nếu bạn sử dụng một máy chủ ứng dụng và bạn chắc chắn rằng môi trường JNDI của bạn bắt đầu trước các gói của bạn hơn là sử dụng nó. Tuy nhiên bạn không thể nắm bắt được sự sửa đổi hoặc loại bỏ một tài nguyên JNDI do đó tôi không đề nghị sử dụng nó bên trong OSGi chút nào. Nếu bạn cần nó vì JPA tôi có thể đề xuất việc triển khai vùng chứa của tôi :) sử dụng trình theo dõi dịch vụ OSGi tiêu chuẩn ngay cả khi bạn sử dụng * -data-source trong persistence.xml của bạn với biểu thức osgi: service/.... Nếu bạn cần một nơi cấu hình trung tâm, tôi khuyên bạn nên kiểm tra tab Configuration của felix-webconsole, các phần Metatype và Configuration Admin của đặc tả OSGi. Nếu bạn định nghĩa một thiết lập cấu hình với sự trợ giúp của các kiểu dữ liệu, chúng sẽ có sẵn trên feilix-webconsole và thông qua API quản trị cấu hình, bạn sẽ có thể nắm bắt các sự kiện thay đổi cấu hình. Tôi đã thử nghiệm và felix-webconsole đã làm việc cho tôi trên cặp Equinox-Jetty.

Hy vọng thông tin đầu vào của tôi hữu ích!