2013-03-28 12 views
6

Chúng tôi phải phát triển và duy trì nhiều ứng dụng dựa trên web Java (cho cùng một công ty) với các kích cỡ, phạm vi và tuổi thọ khác nhau. Một số người trong số họ là rất lớn và những người khác chỉ là các trang đơn giản mà có thể sống chỉ một vài tháng (hoặc ngày), một số đã được thực hiện và cần tái cấu trúc.Cách chia sẻ logic nghiệp vụ giữa nhiều ứng dụng

Có một điểm chung, tuy nhiên, họ cần quyền truy cập vào (gần như) cùng một thông tin.

Vấn đề

Do sự phức tạp của dữ liệu công ty xử lý, chúng ta phải đối phó với nhiều nguồn khác nhau, một số trong số họ thừa hưởng từ thời cổ đại. Các đối tượng miền của chúng tôi có thể được ánh xạ trên nhiều nguồn đó. Ví dụ, một đối tượng miền hợp đồng được ánh xạ tới cơ sở dữ liệu chính của chúng ta nhưng các tệp liên quan (vật lý) của nó được lưu trữ trong một máy chủ tài liệu và hoạt động liên quan đến nó được lưu trữ trong cơ sở dữ liệu NoSQL. Do đó, việc thêm, xóa, tìm kiếm bất kỳ đối tượng nào trong số này bao gồm nhiều hoạt động nội bộ.

nguồn dữ liệu của chúng tôi là (mặc dù nó có thể là bất kỳ):

  • AS400 (sử dụng DB2 như một cơ sở dữ liệu)
  • quản lý tài liệu Documentum
  • Mongo DB
  • dịch vụ web bên ngoài
  • Các nguồn kế thừa khác

Chúng tôi thường sử dụng Glas sfish là máy chủ ứng dụng và maven là công cụ xây dựng của chúng tôi.

Goal

mục tiêu của chúng tôi là tạo ra một lớp kinh doanh hoặc thư viện mà tất cả các ứng dụng của chúng tôi có thể truy cập và nó là:

  • nhỏ gọn
  • nhất quán
  • Dễ sử dụng
  • Dễ bảo trì
  • Có thể truy cập từ người đàn ông khách hàng khác nhau y

gì chúng tôi đã tìm thấy cho đến nay

Chúng tôi đã đấu tranh trong nhiều tuần và chúng tôi vẫn không thể tìm thấy bất cứ điều gì hoàn toàn thỏa đáng. Một số giải pháp:

  • Gói tất cả các logic kinh doanh trong một hoặc nhiều lọ: Rất dễ dàng để chia sẻ, nhưng tất cả các ứng dụng sẽ phải bao gồm tất cả các phụ thuộc jar và các tập tin cấu hình và chăm sóc an ninh, bộ nhớ đệm và khác đồ đạc. Khó duy trì (chúng tôi phải cập nhật các lọ cho mỗi dự án khi có thay đổi).

  • Tạo dự án Ejb chứa tất cả logic và truy cập nó từ xa: Dễ bảo trì, bảo mật, lưu vào bộ nhớ cache và cấu hình chỉ được triển khai một lần. Chúng tôi sợ hình phạt của các cuộc gọi từ xa. Như chúng tôi đã nhận thấy trong nghiên cứu của chúng tôi, nó có vẻ là một thực tế xấu (chúng tôi không có nhiều kinh nghiệm với ejbs).

  • Tạo dự án tai với mọi thứ bên trong và sử dụng quyền truy cập cục bộ: Vâng, đây là phiên bản nhanh hơn phiên bản từ xa nhưng đó là địa ngục để duy trì.

  • Đi cho OSGI: Chúng tôi hơi sợ điều này vì nó không phổ biến như Ejb và chúng tôi chưa bao giờ sử dụng nó nghiêm túc.

Có cách nào phổ biến cho loại sự cố này không?

Rất cám ơn!

+0

Đã một thời gian kể từ khi tôi thực hiện một số EJB. Bạn có thể giải thích lý do tại sao bạn cần BL riêng biệt. Đối với phía dữ liệu, bạn có đang sử dụng các mẫu DAO không? Có thể ánh xạ tới nhiều nguồn thông qua những nguồn đó không? Có thể quản lý nhiều nguồn dữ liệu. –

+0

Cảm ơn câu trả lời siêu nhanh! Đó thực sự là ý tưởng chính. Chúng tôi muốn sử dụng DAO để đóng gói tất cả những thứ bẩn thỉu. Vấn đề là làm cách nào để truy cập các DAO đó từ các ứng dụng 'client'. – danielsan

+0

Tôi muốn giới thiệu phương pháp tiếp cận osgi nếu bạn đang xây dựng một ứng dụng hoàn toàn mới. Nhưng tôi sẽ không khuyên bạn nên nó nếu bạn đang có kế hoạch để cổng rất nhiều thứ và nếu đội bóng là mới để osgi. – techuser

Trả lời

2

Tôi không khuyên bạn nên đặt tất cả logic vào 1 dự án EAR và sử dụng quyền truy cập cục bộ. Nếu bạn có nhiều mã ở một nơi, sẽ khó duy trì, kiểm tra, triển khai, v.v.

Tôi sẽ tạo dự án maven mutlti-module với các phụ thuộc chung. Một trong những phụ thuộc - dịch vụ với logic kinh doanh và truy cập DAO, mà sẽ lộ API. Với dự án Maven, bạn có thể dễ dàng kiểm soát phiên bản của các tệp POM. Các dự án khác nhau có thể hoạt động với các phiên bản dịch vụ thông thường khác nhau. Maven sẽ xử lý kiểm soát phiên bản cho bạn. Tuy nhiên nó đòi hỏi một số nỗ lực cấu hình và thực hiện.

Một tùy chọn khác được đề cập bởi bạn - EAR độc lập với EJB từ xa cũng hoạt động tốt. Đừng lo lắng về hiệu suất và số lượng cuộc gọi từ xa, trừ khi bạn có tải nặng. Chỉ cần lưu cache từ xa EJB trên máy khách để tránh tra cứu JNDI không cần thiết.

Cá nhân tôi thích tùy chọn đầu tiên với phụ thuộc được chia sẻ do Maven quản lý. Rõ ràng và dễ bảo trì, dễ quản lý các phiên bản, triển khai, cấu hình. Với Maven, bạn không cần phải thay đổi tệp jar theo cách thủ công cho từng dự án, bạn có thể chỉ cần sử dụng các công cụ như Nexus

+0

Cảm ơn Anton. Cho đến nay chúng tôi có một dự án maven đa mô-đun bao gồm 6 mô-đun (tất cả các logic nghiệp vụ và các đối tượng miền). Tôi hiểu bạn có nghĩa là chúng tôi có thể có mỗi ứng dụng của khách hàng như một dự án maven độc lập khác và gọi API doanh nghiệp là phụ thuộc, tôi có đúng không? Trong trường hợp đó, có nghĩa là chúng ta sẽ triển khai một API nghiệp vụ với mỗi ứng dụng máy khách, trong trường hợp đó chúng ta sẽ phải sử dụng các máy chủ ứng dụng khác nhau. – danielsan

+0

vâng, nếu bạn trích xuất logic nghiệp vụ của mình để tách dự án maven, bạn có thể bao gồm dưới dạng phụ thuộc vào tất cả các ứng dụng của mình. Trong trường hợp này, bạn có thể sử dụng các máy chủ ứng dụng khác nhau, nếu bạn muốn – Anton