Các mẫu dịch vụ thông tin Phần 1: Mẫu liên hợp dữ liệu

Tuyên bố giá trị của cách tiếp cận liên hợp dữ liệu Tính trong suốt của sự không đồng nhất bên dưới Với liên hợp dữ liệu, người dùng sẽ thấy một giao diện thống nhất duy nhất. Tính trong suốt về vị trí có nghĩa là ứng dụng sử dụng mẫu này không cần biết rõ nơi lưu trữ dữ liệu. Nó cũng chẳng cần biết cơ sở dữ liệu nguồn hỗ trợ ngôn ngữ hay giao diện lập trình nào, nhờ tính trong suốt thực hiện ứng dụng. Ví dụ, nếu sử dụng SQL, thì với ứng dụng, nguồn dữ liệu hỗ trợ ngôn ngữ SQL nào là điều không quan trọng. Ứng dụng cũng không cần biết cách lưu trữ dữ liệu về mặt vật lý ra sao do tính độc lập của dữ liệu vật lý và sự phân mảnh và tính trong suốt về bản sao --hay giao thức mạng nào được sử dụng, còn gọi là tính trong suốt về mạng.

pdf20 trang | Chia sẻ: lylyngoc | Lượt xem: 1384 | Lượt tải: 2download
Bạn đang xem nội dung tài liệu Các mẫu dịch vụ thông tin Phần 1: Mẫu liên hợp dữ liệu, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
Các mẫu dịch vụ thông tin Phần 1: Mẫu liên hợp dữ liệu Tuyên bố giá trị của cách tiếp cận liên hợp dữ liệu Tính trong suốt của sự không đồng nhất bên dưới Với liên hợp dữ liệu, người dùng sẽ thấy một giao diện thống nhất duy nhất. Tính trong suốt về vị trí có nghĩa là ứng dụng sử dụng mẫu này không cần biết rõ nơi lưu trữ dữ liệu. Nó cũng chẳng cần biết cơ sở dữ liệu nguồn hỗ trợ ngôn ngữ hay giao diện lập trình nào, nhờ tính trong suốt thực hiện ứng dụng. Ví dụ, nếu sử dụng SQL, thì với ứng dụng, nguồn dữ liệu hỗ trợ ngôn ngữ SQL nào là điều không quan trọng. Ứng dụng cũng không cần biết cách lưu trữ dữ liệu về mặt vật lý ra sao do tính độc lập của dữ liệu vật lý và sự phân mảnh và tính trong suốt về bản sao -- hay giao thức mạng nào được sử dụng, còn gọi là tính trong suốt về mạng. Lợi thế về thời gian đưa ra thị trường Một ứng dụng, là một người dùng của máy chủ liên hợp dữ liệu, có thể giao tiếp với chỉ một nguồn dữ liệu ảo. Nếu không sử dụng mẫu liên hợp, ứng dụng đó phải tương tác với nhiều nguồn riêng lẻ thông qua các giao diện khác nhau và các giao thức khác nhau. Các nghiên cứu đã cho thấy rằng việc sử dụng mẫu liên hợp dữ liệu giúp làm giảm đáng kể thời gian phát triển khi phải tích hợp nhiều nguồn. Xem phần Tài nguyên để biết thêm thông tin. Giảm chi phí phát triển và bảo trì Những người dùng tiềm năng có thể cần thông tin tích hợp giống nhau -- hay tương tự. Theo cách tiếp cận, mỗi người dùng có cách thực hiện của riêng mình để tổng hợp thông tin từ nhiều nguồn khác nhau. Một cách khác là, khung nhìn tích hợp được phát triển một lần và nó được sử dụng nhiều lần và được bảo trì ở một nơi duy nhất, như thế tạo ra một điểm thay đổi duy nhất. Cách tiếp cận này làm giảm các chi phí phát triển và bảo trì. Lợi thế về hiệu năng Trong nhiều trường hợp, việc thực hiện mẫu liên hợp dữ liệu với sự tập trung cụ thể vào công nghệ xử lý dữ liệu tiên tiến đã chứng tỏ các đặc tính hiệu năng cao hơn so với phương pháp tổng hợp thông tin truyền thống (xem phần Tài nguyên để biết thêm thông tin). Nhờ sử dụng các khả năng xử lý truy vấn tiên tiến, máy chủ liên hợp có thể phân phối tải công việc một cách tối ưu giữa chính nó và các nguồn khác nhau. Nó sẽ xác định dùng máy chủ nào chạy phần tải công việc nào để có hiệu quả nhất và tối ưu hóa thời gian đáp ứng. Lợi thế về khả năng tái sử dụng Sau khi áp dụng mẫu liên hợp dữ liệu cho một kịch bản tích hợp cụ thể, có thể cung cấp kết quả truy cập liên hợp cụ thể này như là một dịch vụ cho nhiều người dùng. Ví dụ, một kịch bản tích hợp có thể yêu cầu lấy ra dữ liệu yêu cầu bồi thường bảo hiểm có cấu trúc và không có cấu trúc từ rất nhiều nguồn. Trong ví dụ này, mẫu liên hợp dữ liệu có thể cung cấp các giải pháp cho dữ liệu yêu cầu bồi thường tích hợp rồi gửi dữ liệu yêu cầu bồi thường đó qua một cổng thông tin đến một đại lý yêu cầu bồi thường. Sau đó chính truy cập liên hợp ấy có thể được sử dụng như là một dịch vụ cho những người dùng khác như là các quy trình tự động dùng cho các đơn yêu cầu bồi thường tiêu chuẩn hoặc các ứng dụng web hướng về khách hàng chẳng hạn. Việc quản trị được cải thiện Quản trị là một nền tảng quan trọng cho vòng đời SOA. Quá trình quản trị được cải thiện bằng việc sử dụng các mẫu theo hướng tăng cường các cách thực hành tốt nhất với các kết quả có thể dự đoán trước. Việc sử dụng lại các mẫu linh hoạt đã được kiểm chứng trong việc phát triển và tạo ra các hệ thống có thể vừa bảo đảm tính nhất quán và chất lượng, lại vừa làm giảm chi phí bảo trì nhờ có một nguồn duy nhất để cập nhật những thay đổi. Về đầu trang Bối cảnh Việc sáp nhập và mua lại giữa các công ty và tổ chức thường yêu cầu các kiến trúc sư dữ liệu và ứng dụng tích hợp các nguồn dữ liệu khác nhau vào một khung nhìn thống nhất về dữ liệu. Những người dùng thông tin tích hợp này là các ứng dụng truyền thống cần tương tác trực tiếp với các cơ sở dữ liệu và đòi hỏi truy cập vào một tập hợp rộng lớn hơn các nguồn dữ liệu. Việc quyết định cách nào là tốt nhất để cung cấp khung nhìn thống nhất này phải dựa vào tính sẵn có của công cụ, dựa vào kinh nghiệm, chuyên môn và văn hóa của tổ chức. Khi sử dụng các kiến trúc di sản truyền thống, thời gian, công sức và chi phí liên quan đến việc tích hợp có thể vượt quá lợi nhuận kinh doanh. Khi được thực hiện trong một môi trường dựa trên dịch vụ, một cách tiếp cận các dịch vụ thông tin dựa trên-mẫu có thể nâng cao các đặc tính tái sử dụng của hệ thống theo thời gian. Các dịch vụ thông tin là phần cốt lõi của SOA. Những dịch vụ thông tin như vậy cung cấp quyền truy cập CRUD (Create-Read-Update-Delete: Tạo-Đọc-Cập nhật- Xóa) vào các thông tin miền ứng dụng. Chúng cũng làm lộ diện các khả năng xử lý thông tin như là các kết quả của các thuật toán phân tích và tính điểm, các quy tắc làm sạch dữ liệu, v.v. Với mục đích của bài này, chúng tôi sẽ tập trung vào các dịch vụ tích hợp thông tin để cung cấp một khung nhìn thống nhất về dữ liệu, thường liên quan đến việc tích hợp một mảng khó hiểu các nguồn dữ liệu tầng sau khác nhau và các dịch vụ. Khi áp dụng mẫu liên hợp dữ liệu, chúng ta cần phân biệt giữa hai bối cảnh, bối cảnh không-SOA, truyền thống được giải quyết bằng nhiều ứng dụng trước đây và bối cảnh SOA là trọng tâm của bài này. Điều quan trọng cần lưu ý rằng SOA là một cách tiếp cận kiến trúc dẫn đến các dịch vụ tái sử dụng, mở rộng khả năng của các việc thực hiện không-SOA hiện có trong nhiều trường hợp. Bối cảnh truyền thống Trong bối cảnh mà chúng ta gọi là truyền thống, một ứng dụng tạo báo cáo trong một ngân hàng có thể cần phân tích các giao dịch thẻ tín dụng. Khi xem xét khối lượng của dữ liệu này -- có hàng triệu giao dịch mỗi ngày -- để lưu trữ tất cả thông tin này trong kho phân tích thật không hiệu quả. Nhiều dữ liệu cũ hơn rất ít được truy cập, như là thông tin về ngữ cảnh nhất định, chẳng hạn như là một hành trình bay. Việc lưu trữ tất cả dữ liệu giao dịch thẻ tín dụng -- cả hiện tại và đã cũ, cả cốt lõi và chỉ liên quan -- trong kho đều có ảnh hưởng tiêu cực đến hiệu năng. Một giải pháp tốt hơn là tách riêng hai kiểu dữ liệu: dữ liệu thường hay sử dụng, các giao dịch thẻ tín dụng gần đây hơn thì lưu trữ vào một kho trong khi thông tin cũ hơn thì lưu trữ vào các băng từ chẳng hạn. Tuy nhiên, ứng dụng tạo báo cáo không cần biết rõ về việc phân phối dữ liệu này, vì chúng có thể được cung cấp thông qua cách tiếp cận liên hợp dữ liệu. Hình 1. Mẫu liên hợp dữ liệu truyền thống Trong bối cảnh truyền thống, các ứng dụng thường sử dụng các giao diện và các giao thức quan hệ chuẩn để tương tác với máy chủ liên hợp, ví dụ như SQL và JDBC/ODBC. Máy chủ liên hợp, đến lượt nó, kết nối thông qua các bộ thích ứng hoặc các trình bao bọc (wrapper) khác nhau tới một loạt các nguồn dữ liệu, ví dụ như là các cơ sở dữ liệu quan hệ, các tài liệu XML, các ứng dụng đóng gói và các hệ thống quản lý nội dung và cộng tác. Máy chủ liên hợp là một cơ sở dữ liệu ảo có đủ mọi khả năng của một cơ sở dữ liệu quan hệ. Ứng dụng hoặc người dùng yêu cầu có thể thực hiện bất kỳ các yêu cầu truy vấn nào trong phạm vi các quyền hạn truy cập của mình. Sau khi truy vấn xong, máy chủ liên hợp trả về một tập hợp kết quả có chứa tất cả các bản ghi đáp ứng tiêu chí lựa chọn. Điều này được minh họa trong Hình 1. Người ta dự định dùng hình này để minh họa rằng việc triển khai thực hiện truyền thống có thể dựa trên một giao diện lập trình ứng dụng (API) quan hệ bằng cách sử dụng SQL (JDBC/ODBC) hoặc XQuery. Bối cảnh SOA Trong một bối cảnh SOA, một dịch vụ getCustomerCreditCardData có thể cần lấy ra thông tin toàn diện về một khách hàng và các giao dịch thẻ tín dụng gần đây của khách hàng đó. Thông tin này có thể không nằm trong một hệ thống duy nhất. Người ta có thể lưu trữ thông tin khách hàng trong một hệ thống quản lý dữ liệu chủ của khách hàng hoặc trong nhiều kho lưu trữ và các giao dịch thẻ tín dụng có thể được lưu trữ trong một nguồn dữ liệu khác. Liên hợp dữ liệu nối thông tin từ nhiều nguồn khác nhau để nó có thể xuất hiện như là một dịch vụ cho người dùng. Trong bối cảnh SOA này, máy chủ liên hợp có thể hoạt động như một nhà cung cấp dịch vụ và/hoặc một người dùng dịch vụ có sử dụng các giao diện SOA thích hợp. Lưu ý rằng điều này không loại trừ khả năng máy chủ cung cấp sự hỗ trợ cho các giao diện quan hệ, truyền thống. Độ rộng hỗ trợ là một quyết định thực hiện nằm ngoài phạm vi của cuộc thảo luận này. Khi máy chủ liên hợp dữ liệu trưng ra nhiều thông tin tích hợp như là một nhà cung cấp dịch vụ, một người dùng dịch vụ có thể truy cập thông tin tích hợp thông qua một giao diện dịch vụ như WSDL và HTTP/SOAP hoặc các kết buộc đã được chấp thuận khác. Để tích hợp, máy chủ liên hợp dữ liệu có thể tiêu thụ các dịch vụ do nhiều nguồn thông tin cung cấp. Ý nghĩ phía sau việc sử dụng mẫu liên hợp dữ liệu trong bối cảnh SOA là sử dụng và sử dụng lại thông tin tích hợp, có nghĩa là, các dịch vụ tích hợp thông tin theo cách có thể mở rộng cho nhiều người dùng. Việc mô hình hóa và định nghĩa các dịch vụ là một khía cạnh quan trọng của SOA. Cách thực hành tốt nhất đã được thừa nhận phổ biến là thiết kế các dịch vụ sao cho chúng cung cấp việc tái sử dụng và/hoặc tính tương thích trên toàn doanh nghiệp và/hoặc hỗ trợ quy trình nghiệp vụ về thông tin hoặc chức năng. Rất nhiều nếu như không phải là hầu hết các dự án SOA thành công đều tập trung trước hết vào chức năng nghiệp vụ quan trọng nhất, sử dụng rộng rãi nhất được trưng ra như là các dịch vụ. Do vai trò then chốt của các dịch vụ này, nên chúng thường bao trùm nhiều hệ thống tầng sau. Vì thế, việc thu thập thông tin từ nhiều nguồn không đồng nhất là một yêu cầu và khả năng quan trọng mà SOA phải dựa vào. Dịch vụ không phải là một truy vấn như trong bối cảnh truy cập dữ liệu truyền thống, mà đúng hơn nó là một yêu cầu đối với một thực thể (hoặc các thực thể) nghiệp vụ, có thể do dịch vụ liên hợp thực hiện thông qua một loạt các truy vấn và các dịch vụ khác. Hình 2. Mẫu liên hợp dữ liệu trong một bối cảnh SOA Việc tạo nên các dịch vụ tích hợp thông tin trong SOA đòi hỏi chức năng bổ sung chứa đựng quyền truy cập liên hợp trong một giao diện hướng-dịch vụ. Việc này được thực hiện thông qua thành phần Information Service Enablement (Hỗ trợ dịch vụ thông tin). Mục đích của thành phần này là thể hiện các truy vấn liên hợp nhất định trong một giao diện hướng-dịch vụ. Ví dụ, có thể viết một truy vấn liên hợp bằng SQL và có thể xác định quyền truy cập vào thông tin sản phẩm. Thông qua thành phần Information Service Enablement, truy vấn liên hợp này có thể xuất hiện như là một dịch vụ do SCA hoặc WSDL định nghĩa, chẳng hạn. Sau đó có thể chia sẻ dịch vụ này để thực hiện quyền truy cập vào dữ liệu sản phẩm trong toàn doanh nghiệp và ngoài doanh nghiệp. Các giải pháp áp dụng mẫu liên hợp dữ liệu trong bối cảnh truyền thống sử dụng lợi thế về bản chất khai báo và linh hoạt của SQL. Với các ủy quyền về bảo mật thích hợp, những người dùng có thể truy cập bất kỳ dữ liệu nào trong nguồn thông qua hầu hết các truy vấn SQL khác nhau. Những người dùng có tính linh hoạt rất cao để truy cập vào cái gì và định dạng trả về kết quả là gì. Mặc dù tính linh hoạt này là một lợi thế rất lớn trong nhiều tình huống, nhưng nó cũng làm tăng độ phức tạp cho những người dùng. Nhưng người dùng phải hiểu mô hình dữ liệu nguồn và cách xây dựng kết quả từ mô hình nguồn bên dưới này. Mô hình dữ liệu nguồn càng lớn, nhiệm vụ này có thể càng trở nên phức tạp. Một cách tiếp cận SOA tập trung trước hết vào việc định nghĩa và chia sẻ một số lượng tương đối hạn chế các chức năng nghiệp vụ quan trọng nhất như là các dịch vụ trong và trên toàn doanh nghiệp. Vì vậy, các giao diện hướng-dịch vụ được tập trung nhiều hơn vào số lượng hạn chế trong số các yêu cầu thông tin cụ thể cần được thể hiện. Các nhà phát triển được hưởng lợi từ trọng tâm hẹp và rõ ràng này do họ cần ít thời gian hơn để thiết kế yêu cầu thông tin. Họ có thể chỉ cần chọn một dịch vụ thích hợp trong số tương đối ít các tùy chọn đó. Về đầu trang Đặt vấn đề Trong môi trường dựa vào thông tin hiện nay, điều rất phổ biến với các kiến trúc sư và các nhà phát triển là thực hiện một giải pháp liên hợp dữ liệu. Họ phải đối mặt với những thách thức do một số quyết định về kiến trúc gây ra, có thể là do những hạn chế có bản chất về kỹ thuật, nghiệp vụ hoặc theo hợp đồng. Kịch bản này gồm một số trong những hạn chế phổ biến như vậy. Đầu tiên, dữ liệu cần thiết để hỗ trợ các yêu cầu truy cập thông tin của dự án lưu trú trong nhiều nguồn và phải được tích hợp và cung cấp như một kết quả duy nhất tới người dùng. Tiếp theo, không thể nhân bản hoặc sao chép các nguồn dữ liệu đích để thực hiện yêu cầu truy cập. Cuối cùng, giải pháp này phải tích hợp trong một SOA hiện có trong khi vẫn hỗ trợ các ứng dụng không-SOA truyền thống như mô tả trong Hình 3. Hình 3. Truy cập giao diện không đồng nhất Về đầu trang Các mục tiêu của giải pháp Như mô tả trong phần đặt vấn đề, mục tiêu của giải pháp này là tránh dư thừa dữ liệu trong khi cung cấp một khung nhìn tích hợp trên các nguồn không đồng nhất. Máy chủ liên hợp dữ liệu -- đó là, thành phần thực hiện mẫu liên hợp dữ liệu -- phải cung cấp các giao diện truy vấn chuẩn cho bối cảnh SOA không truyền thống. Điều này bảo đảm rằng rất nhiều các ứng dụng cơ sở dữ liệu truyền thống có thể tiêu dùng dữ liệu liên hợp. Máy chủ liên hợp cũng phải cung cấp khả năng tối ưu hóa truy vấn để đáp ứng yêu cầu một cách hiệu quả nhất. Sự phân tán và tính đa dạng của dữ liệu trong bối cảnh này đòi hỏi chú trọng nhiều vào cách chuyển dịch truy cập tốt nhất vào khung nhìn tích hợp và cách phân tích và phân phối tải công việc. Khi hỗ trợ truy cập ghi vào khung nhìn tích hợp, máy chủ liên hợp phải đồng bộ hóa thao tác dữ liệu trong các nguồn khác nhau thành một đơn vị công việc logic. Điều này bảo đảm đáp ứng được tiêu chuẩn nguyên tử, nhất quán, cô lập và độ bền (ACID) cho các giao dịch và tuân thủ tính toàn vẹn tham chiếu. Ngoài những mục tiêu trên để giải quyết bối cảnh truyền thống này, cách tiếp cận này phải vừa vặn trong một SOA. Điều này sẽ cho phép rất nhiều người dùng trong và ngoài doanh nghiệp sử dụng lại có hiệu quả (các) khung nhìn tích hợp. Những người dùng tiềm năng của truy cập liên hợp trong một SOA là các ứng dụng, các cổng thông tin và các hoạt động trong một quy trình nghiệp vụ cần truy cập vào thông tin phân tán. Ví dụ, một nhà sản xuất có thể định nghĩa một dịch vụ để lấy ra thông tin kiểm kê thời gian thực từ các nguồn không đồng nhất. Sau đó, các ứng dụng nội bộ cũng như các ứng dụng của các đối tác kinh doanh bên ngoài truy cập vào dịch vụ tương tự, sử dụng một cách thực hiện nhất quán và hiệu quả nhất của truy cập liên hợp này. Về đầu trang Mô tả giải pháp Trong cả bối cảnh truyền thống cũng như bối cảnh SOA, máy chủ liên hợp dữ liệu cung cấp một giải pháp để nối và xử lý hiệu quả thông tin từ các nguồn không đồng nhất. Mẫu này thực hiện một cách tiếp cận tích hợp thời gian thực, đồng bộ cho dữ liệu phân tán. Máy chủ liên hợp dữ liệu chịu trách nhiệm tiếp nhận một truy vấn gửi tới khung nhìn tích hợp của các nguồn khác nhau. Nó biến đổi truy vấn bằng cách sử dụng các thuật toán tối ưu hóa phức tạp để chia nhỏ truy vấn đó thành một loạt các hoạt động con gọi là phân vùng và viết lại truy vấn, áp dụng các hoạt động con cho các nguồn thích hợp, thu thập các kết quả từ mỗi nguồn, lắp ráp các kết quả tích hợp và cuối cùng trả các kết quả tích hợp về nơi khởi nguồn của truy vấn đó. Trình tự xử lý này diễn ra đồng bộ và theo thời gian thực. Các đặc điểm thời gian thiết kế Mẫu liên hợp dữ liệu đòi hỏi ánh xạ các phần tử dữ liệu từ các nguồn dữ liệu khác nhau trong phạm vi của khung nhìn tích hợp. Ví dụ, có thể lưu trữ thông tin khách hàng, như là tên và địa chỉ của người nắm giữ chính sách, như trong ví dụ đã nói ở trên, trong một bảng duy nhất của một cơ sở dữ liệu và trong nhiều bảng của một cơ sở dữ liệu khác. Để xây dựng một khung nhìn tích hợp, cần ánh xạ các kiểu biểu diễn khác nhau tới khung nhìn chung. Ánh xạ này có thể do các tác nhân con người thực hiện thủ công hoặc được trợ giúp của các công cụ tiên tiến dựa trên các thuật toán ánh xạ khác nhau, cũng đã nắm bắt bất kỳ yêu cầu chuyển đổi cần thiết nào. Điều này cho phép máy chủ liên hợp dữ liệu thu nhận các truy vấn đối với khung nhìn tích hợp và tính toán số lượng và các kiểu hoạt động con tối ưu cần thực hiện. Khi áp dụng mẫu liên hợp dữ liệu trong một bối cảnh SOA, cần tạo nên một tập hợp các truy vấn liên hợp và đăng ký nó như là các dịch vụ trong SOA. Ví dụ, có thể tạo nên khung nhìn tích hợp như là một dịch vụ để lấy ra thông tin có cấu trúc và không có cấu trúc quan trọng về một người nắm giữ chính sách, ví dụ tên, địa chỉ, tình trạng, các tài liệu yêu cầu bồi thường, các dự toán sửa chữa và đánh giá rủi ro và chia sẻ khung nhìn đó giữa nhiều người dùng. Kết quả của việc ánh xạ trong thời gian thiết kế thường là các khung nhìn liên hợp điển hình, tương tự như các khung nhìn cơ sở dữ liệu quan hệ, sau đó có thể được triển khai hoặc được tạo ra trên máy chủ liên hợp. Thời gian vận hành Máy chủ liên hợp dữ liệu nhận một yêu cầu hướng đến khung nhìn tích hợp. Theo định nghĩa ánh xạ, máy chủ liên hợp chia nhỏ truy vấn liên hợp thành nhiều hoạt động con. Có nhiều phần tử ảnh hưởng đến bước này:  Dữ liệu cần thiết để đáp ứng truy vấn liên hợp lưu trú ở đâu?  Những hoạt động nào cần thiết để chuyển đổi các biểu diễn không đồng nhất của các nguồn, như các kiểu dữ liệu khác nhau, hay như mô hình chuẩn hóa so với mô hình không chuẩn hóa chẳng hạn, thành khung nhìn tích hợp chung? Máy chủ liên hợp sử dụng thông tin ánh xạ để giải quyết những câu hỏi này. Có một số các yếu tố khác, ảnh hưởng đến việc xử lý truy vấn liên hợp cần có thông tin, vượt ra ngoài đặc tả ánh xạ như là:  Các hệ thống quản lý các nguồn dữ liệu hỗ trợ những hoạt động nào và máy chủ liên hợp phải bù đắp cho những hoạt động nào nữa?  Những hệ quả hiệu năng là gì khi thực hiện một tập hợp các hoạt động trong các nguồn so với máy chủ liên hợp? Máy chủ liên hợp nên ủy thác các hoạt động nào cho các nguồn để khai thác tốt hơn các khả năng của các nguồn, để giảm chuyển tải dữ liệu và để tối ưu hóa hiệu năng tổng thể? Câu trả lời cho những câu hỏi trên đòi hỏi phải có kiến thức về hệ thống nguồn và các khả năng xử lý truy vấn của nó. Để giải quyết câu hỏi về khả năng xử lý truy vấn, máy chủ liên hợp cũng phải sử dụng rất nhiều thông tin về môi trường vận hành cũng như các số liệu thống kê về các cơ sở dữ liệu nguồn. Một khi máy chủ liên hợp đã xác định chiến lược tốt nhất để thực hiện tất cả các hoạt động con, nó sẽ kết nối với các nguồn dữ liệu -- thông tin có cấu trúc và không có cấu trúc -- để lấy ra dữ liệu có liên quan và nhiều khả năng sẽ sử dụng giao diện đặc trưng của các nguồn ấy. Theo kế hoạch thực hiện truy vấn tổng thể, các hoạt động con sau đó sẽ được áp dụng vào các nguồn. Máy chủ liên hợp thu nhận và tổng hợp kết quả đó thành kết quả của khung nhìn tích hợp, rồi trả kết quả cho người dùng. Trong bối cảnh SOA, người dùng gửi lên một yêu cầu theo một định dạng yêu cầu đã định sẵn tới máy chủ liên hợp. Máy chủ liên hợp chuyển đổi yêu cầu này thành các truy vấn SQL tương ứng hoặc các định nghĩa khung nhìn để hỗ trợ dịch vụ. Từ đây trở đi, bắt đầu thực hiện các bước phân tích, tối ưu hóa và thực hiện truy vấn tương tự như mô tả ở trên. Sự khác biệt duy nhất trong bối cảnh SOA là ở bước cuối cùng. Máy chủ liên hiệp dịch kết quả của cách tiếp cận liên hợp dữ liệu truyền thống thành một đáp ứng dịch vụ rồi trả nó về cho người dùng dịch vụ thông qua giao diện dịch vụ đã định sẵn. Hình 4. Sơ đồ trình tự để liên hợp dữ liệu Có thể thực hiện
Tài liệu liên quan