Kiến trúc - Nhiều ứng dụng web hoạt động trên cùng một dữ liệu

Question

Tôi yêu cầu kiến ​​trúc phù hợp cho ứng dụng web Java sau đây:

Mục tiêu là xây dựng một số ứng dụng web hoạt động trên cùng một dữ liệu. Giả sử một hệ thống ngân hàng trong đó dữ liệu tài khoản có thể được truy cập bởi các ứng dụng web khác nhau; nó có thể được truy cập bởi khách hàng (ngân hàng trực tuyến), bởi dịch vụ cá nhân (chủ yếu là đọc) và bởi bộ phận quản trị tài khoản (công cụ quản trị). Các ứng dụng này chạy dưới dạng các ứng dụng web riêng biệt trên các máy khác nhau nhưng chúng sử dụng cùng một dữ liệu và một tập hợp các thao tác dữ liệu phổ biến và các truy vấn tìm kiếm.

Một cách tiếp cận có thể là xây dựng một ứng dụng cốt lõi phù hợp với nhu cầu chung của khách hàng, cụ thể là lưu trữ dữ liệu, thao tác và tìm kiếm cơ sở. Sau đó, khách hàng có thể gọi ứng dụng cốt lõi này để đáp ứng yêu cầu của họ. Yêu cầu là các ứng dụng được xây dựng trên đầu trang của một Wicket/Spring/Hibernate stack như WARs.

Để có hình ảnh, dưới đây là một số phương pháp có thể chúng tôi nghĩ đến:

A Cách tiếp cận nguyên khối. Xây dựng một ứng dụng web lớn phù hợp với mọi nhu cầu (đây không thực sự là một lựa chọn)

B Cách tiếp cận API. Xây dựng một API truy cập cơ sở dữ liệu lõi (JAR) để truy cập/thao tác dữ liệu. Mỗi ứng dụng web được xây dựng như một WAR riêng biệt sử dụng API để truy cập cơ sở dữ liệu. Không có ứng dụng lõi riêng biệt.

C Cách tiếp cận RMI. Ứng dụng lõi chạy như một ứng dụng độc lập (có thể là một WAR) và cung cấp các dịch vụ thông qua RMI (hoặc HttpInvoker).

Cách tiếp cận D WS. Giống như C nhưng thay thế RMI bằng Dịch vụ web

Cách tiếp cận OSGi E. Xây dựng tất cả các thành phần như mô-đun OSGi và chạy trong một thùng chứa OSGi. Có thể sử dụng SpringSource dm Server hoặc ModuleFusion. Cách tiếp cận này không phải là một lựa chọn cho chúng tôi vì một số lý do ...

Hy vọng tôi có thể giải quyết vấn đề. Chúng tôi chỉ đang đi với tùy chọn B, nhưng tôi không tự tin lắm với nó. Ý kiến ​​của bạn là gì? Bất kỳ giải pháp nào khác? Những hạn chế của mỗi giải pháp là gì?

Answer 1

B, C và D là tất cả các cách khác nhau để thực hiện cùng một điều.

Suy nghĩ đầu tiên của tôi sẽ đơn giản là có tất cả mã người tiêu dùng kết nối với cơ sở dữ liệu chung. Điều này chắc chắn có thể thực hiện được và sẽ loại bỏ mã bạn không muốn đặt ở giữa. Hạn chế, tất nhiên, là nếu lược đồ thay đổi, tất cả người tiêu dùng cần phải được cập nhật.

Một giải pháp khác mà bạn có thể muốn xem xét là cung cấp cho mỗi người tiêu dùng cơ sở dữ liệu riêng của mình, sử dụng một số loại sao chép để giữ cho chúng được đồng bộ hóa.

Answer 2

Tôi nghĩ rằng bạn phải đi theo hướng ngược lại - từ dưới lên. Tất nhiên, bạn phải đi ra ngoài và quay lại để xác minh rằng mọi thứ đang phát, nhưng đây là hướng chung:

Hãy suy nghĩ về dữ liệu của bạn - lược đồ DB, giao dịch quan trọng như thế nào (ví dụ:) vv

sau đó xác định phương pháp truy cập thông thường - từ bộ thủ tục được lưu trữ vào công cụ giao dịch phân phối ...

bước tiếp theo là một logic kinh doanh/trình bày - những gì có thể được khái quát hóa và một chủ đề tùy biến là gì.

Và giai đoạn cuối cùng là giao diện, trực quan và báo cáo

Answer 3

Tôi nghĩ rằng bạn cần phải có một ứng dụng riêng biệt mà tất cả các ứng dụng máy khách sẽ sử dụng như lớp dữ liệu của họ. Lý do cho điều này là bạn muốn đảm bảo rằng tất cả chúng đều truy cập cơ sở dữ liệu theo cùng một cách. Ngoài ra còn có một số điều kiện chủng tộc bạn có thể nhận được vào các giao dịch cơ sở dữ liệu đó có thể không có khả năng ngăn chặn. Lý do khác là việc sử dụng cơ sở dữ liệu dưới dạng RPC là một mô hình đã biết. Nếu tất cả các ứng dụng của bạn truy cập trực tiếp vào cơ sở dữ liệu, bạn gần như chắc chắn sẽ kết thúc với một số bảng "sự kiện" mà các cuộc thăm dò các ứng dụng khác nhau định kỳ ... không làm điều đó.

Answer 4

Ngoài các câu trả lời được cung cấp, nếu bạn đang xem xét việc có nhiều ứng dụng làm việc với cơ sở dữ liệu cùng một lúc, hãy xem xét một bộ nhớ cache phân phối như một phần của giải pháp của bạn, là tốt. Vẻ đẹp của bộ nhớ cache phân tán là nó có thể được truy cập bởi nhiều ứng dụng cùng một lúc, ngoài việc được phân phối. Tôi không chắc chắn nếu điều này đúng cho tất cả các biến thể Java, chẳng hạn như Ehcache, vv, như tôi không đến từ một nền Java.

gì chúng tôi đang làm là trừu tượng hóa dữ liệu một cấp độ cao hơn so với trước đây. Bây giờ chúng tôi có một DAL có thể được truy cập trực tiếp, nhưng chúng tôi đã đặt một "Nhà máy mẫu" ở phía trước DAL. Mục đích của Nhà máy Model là để môi giới cả cache và lớp dữ liệu, hoạt động như một passthrough. Vì vậy, người gọi luôn gọi Nhà máy mẫu và không phải mã DAL hoặc bộ nhớ đệm trực tiếp. Lớp trừu tượng này về cơ bản sẽ lấy dữ liệu từ DAL vào bộ nhớ cache mà không cần thêm sự phức tạp vào API.

Answer 5

Dường như A và E là ra khỏi hình ảnh như bạn đã nêu trong câu hỏi của bạn vì nhiều lý do. Tùy chọn A sẽ là một ứng dụng rất lớn mà sẽ làm cho bảo trì khó khăn trong tương lai.

B, C và D là về cơ bản kiến ​​trúc tương tự kể từ khi họ tham gia truy cập từ xa đến các thư viện phổ biến từ các ứng dụng web khác nhau, sự khác biệt duy nhất là cơ chế vận chuyển. Tôi sẽ khuyên bạn nên thực hiện điều này trong EJB 3 hoặc Spring nếu có thể thay vì với các thư viện RMI của riêng bạn vì một trong hai thư viện này cung cấp một khung tốt trên RMI/Webservices.

Vì vậy, tôi nghĩ rằng vấn đề này cơ bản để nắm hai tùy chọn sau:

1) Bao gồm các doanh nghiệp và các lớp học lớp DAO như một cái bình thường trong việc triển khai tất cả các ứng dụng web.

Ưu điểm:

• triển khai dễ dàng hơn.
• Ứng dụng sẽ thực hiện tốt ban đầu vì không có truy cập từ xa đến các máy chủ khác.

Nhược điểm:

• Bạn không thể thêm phần cứng hơn để lớp giữa đặc biệt (dịch vụ và DAO lớp) vì nó được bao gồm trong mỗi ứng dụng web.
• đội kinh doanh khác trong tổ chức sẽ không được tiếp cận với dịch vụ kinh doanh của bạn vì không có giao diện từ xa.

2) Triển khai lớp dịch vụ nghiệp vụ và lớp DAO trong máy chủ ứng dụng riêng biệt và hiển thị phương thức kinh doanh từ xa.

Ưu điểm:

• Bạn có thể mở rộng quy mô các dịch vụ kinh doanh và lớp DAO khi cần thiết, tùy thuộc vào tải từ các ứng dụng web khác nhau gọi nó.
• Các ứng dụng khác trong tổ chức có thể sử dụng giao diện của bạn nếu cần.
• Khả năng mở rộng khác
• Bạn nhận được tất cả các ưu điểm của Java EE.

Nhược điểm:

• More triển khai phức tạp.
• Máy chủ khác để duy trì và giám sát.
• Có thể chậm hơn vì các cuộc gọi sẽ được thực hiện qua mạng mặc dù điều này không phải là quá nhiều vấn đề.

Trong cả hai trường hợp nếu giao diện thay đổi mã máy khách sẽ cần phải thay đổi, do đó, đây không phải là yếu tố trong quyết định. Giao dịch phải được xử lý ở cấp phương thức dịch vụ kinh doanh, vì vậy đây cũng không phải là yếu tố.

Tôi nghĩ rằng nó cũng phụ thuộc vào kích thước của ứng dụng và cách giải pháp có thể mở rộng để đảm bảo độ phức tạp thêm của tùy chọn 2 ở trên.