Nghiên cứu kiến trúc hướng dịch vụ và đối tượng - 4 pps

Trang 61 4.2.3.2 Cấu trúc phân tầng Standard-based Security Info Exchange Platform Hình 4-2 – Cấu trúc phân tầng Standard-based Security Info Exchange Platform Tầng Trusted Communication Tầng xây dựng dựa đặc tả: SOAP Foundation, WS-Security WS-SecureConversation WS-Security thành phần hỗ trợ để xây dựng tầng liên kết bền vững, đảm bảo luồng thông tin trao đổi cách an tồn • WS-Security thiết kế cách linh hoạt, sử dụng tảng việc xây dựng nhiều mơ hình bảo mật khác nhau, bao gồm Public Key Infrastructure, Kerberos SSL Đặc biệt, WS-Security cung cấp hỗ trợ cho nhiều dạng security tokens, nhiều vùng ủy thác (trust domain), nhiều định dạng chứng thực nhiều thuật tốn mã hóa • WS-Security định nghĩa thêm cấu trúc mở rộng cho phần đầu thông điệp dạng SOAP, nhằm mang thông tin bảo mật (chữ ký điện tử, security token, mã hố…) q trình trao đổi thơng điệp, với mục đích phía nhận thơng điệp tin tưởng vào nội dung nhận đối tượng gửi thông điệp Trang 62 Với WS-SecureConversation, hai bên tái sử dụng lại ngữ cảnh bảo mật (security context) lần trao đổi thông điệp (hai bên không cần phải thực lại thủ tục lần trao đổi đầu tiên) Tầng Trusted Service Tầng thiết kế dựa đặc tả: WS-PolicyAssertion, WS-SecurityPolicy, WS-Authorization, WS-Privacy, WS-PolicyAttachment, WS-Policy Tầng cho phép xây dựng chế tạo định nghĩa policy mở rộng gắn kèm thông tin vào phần thông tin mô tả web service • WS-Policy : định nghĩa mơ hình policy, policy statement, chế xác nhận policy • WS-PolicyAssertion: định nghĩa vài chế xác nhận policy tổng quát • WS-PolicyAttachment: định nghĩa cách gắn policy vào dịch vụ, trực tiếp cách nhúng vào thông tin WSDL, hay gián tiếp thơng qua UDDI • WS-SecurityPolicy: định nghĩa chế xác nhận policy tương ứng cho thuộc tính WS-Security, yêu cầu tồn vẹn thơng điệp, u cầu độ tin cậy thông điệp, yêu cầy loại security token…Đối tượng sử dụng dịch vụ phải lấy thông tin để đáp ứng yêu cầu bảo mật mà dịch vụ đưa Tầng Trusted Management Web Tầng xây dựng dựa đặc tả: WS-Federation, WS-Trust Hai tầng Trusted Communication Trusted Service đảm bảo cho hai đối tượng sử dụng cung cấp dịch vụ tương tác trực tiếp với môi trường bảo mật tin cậy Hai tầng làm điều dựa giả thiết rằng: o Cả hai phía sử dụng cơng nghệ, kỹ thuật bảo mật o Cả hai phía tin tưởng vào domain (ví dụ: tin tưởng vào tổ chức chức thực) Trang 63 Điều có nghĩa là: vấn đề phát sinh bên tương tác thuộc domain khác nhau, sử dụng cơng nghệ mã hóa khác Và vai trò tầng Trust Management Web giải vấn đề WS-Trust ► WS-Trust đưa khái niệm gọi Security Token Service (STS) Nhiệm vụ thành phần cấp phát, kiểm tra chuyển đổi loại security token khác (khi có yêu cầu.) Hình 4-3 – Security Token Service ► Về bản, vai trò STS giống với tổ chức chứng thực PKI (PKI Certificate Authority) Tuy nhiên, vượt trội với hai đặc điểm bậc: o Nó cấp phát tất loại token (về quyền, vai trị ), khơng token dùng để định danh STS không đơn giản cấp phát Trang 64 chứng thực token, mà cịn có khả thực chuyển đổi loại token với (ví dụ như: X.509 certifate Kerberos ticket) Đây tính khiến cho đảm trách vai trò làm trung gian qui trình tương tác đối tượng Và điều đương nhiên rằng, để thực vai trò chuyển đổi thế, STS phải tin cậy, uỷ thác để có khả cấp phát số loại token đó, thân phải tin tưởng vào token STS khác cấp phát ► Vì thế, vai trị STS kết nối hệ thống bảo mật đơn lẻ để tạo thành “mắc xích” liên kết thống với Các hệ thống bảo mật đơn vừa trì sách, sở hạ tầng nội riêng mình, lại vừa thiết lập cách giao tiếp “đáng tin cậy” với hệ thống khác mắc xích ► Các STS phải quản lý cho “trong suốt” (transparent) với đối tượng trình tương tác Ta gọi mạng STS Trusted Management Web Và giống hệ thống mạng mơi trường Internet gồm tập hợp mạng chức khác ( ví dụ, mạng DNS-Domain Name Servers cung cấp dịch vụ phân giải tên miền, mạng SNMP-Simple Network Management Protocol servers cung cấp dịch vụ quản lý ) Trust Management Web cấu thành nhiều mạng STS khác Mỗi mạng STS cung cấp dịch vụ tin cậy khác nhau, máy chủ chứng thực cung cấp khả chức thực STS mạng STS, hay máy chủ quản lý quyền có nhiệm vụ kiểm tra quyền nhiều STS Trang 65 WS-Federation ► Trong WS-Trust đưa mơ hình kiến trúc Trusted Management Web cịn vài vấn đề liên quan đến việc quản trị thành phần bên kiến trúc mà chưa WS-Trust đề cập đến: o Nên chọn mơ hình ủy thác cho mắc xích STSs? Vấn đề WS-Federation giải o Việc quản lý chu kỳ hoạt động thành phần kiến trúc (STS, policy, chế bảo mật tầng ) thực nào? WS-Management xây dựng để xử lý vấn đề o Hệ thống cần phải trang bị chế cho phép quản lý thông tin trạng thái policy token phân tán, cụ thể chế ghi nhớ lại lượng thơng tin Từ đây, dẫn đến phát sinh vấn đề xử lý vấn đề đồng thông tin DNS xem ví dụ cho mơ hình này, DNS server lưu lại kết phân giải, để xử lý yêu cầu tiếp theo, yêu cầu kết đáp ứng mà khơng cần phải truy vấn đến root server o Một vấn đề thiếu sót mơ hình hỗ trợ cho trình lưu lại ghi thông tin trạng thái, kết xử lý… 4.3 Giới thiệu số chuẩn bảo mật XML Phần cung cấp tầm nhìn tổng thể chuẩn bảo mật dành cho thông điệp tựa XML Hình 4-4 minh họa mối liên hệ vị trí tương đối chuẩn bên toàn tầng kỹ thuật hệ thống bảo mật Điều cần làm rõ thân chuẩn không xây dựng để giải vấn đề bảo mật Một hệ thống bảo mật thật tốt phải xây dựng dựa nhiều tầng khác Trang 66 Hình 4-4 – Các tầng kỹ thuật bên hệ thống bảo mật 4.3.1 WS-Security WS-Security chuẩn đề xuất hợp tác hãng IBM, Microsoft Verisign Hiện chuẩn tổ chức OASIS thông qua tiếp tục phát triển WS-Security tảng để giải vấn đề bảo mật cho thông điệp SOAP, với ba mục tiêu chính: • Sử dụng security token phần đầu thông điệp SOAP để hỗ trợ cho việc định danh chứng thực • Sử dụng chuẩn XML-Signature đảm bảo tính tồn vẹn xác thật liệu • Sử dụng chuẩn XML-Encryption đảm bảo độ tin cậy cho liệu Vẫn nhiều vấn đề chưa giải triệt để WS-Security WS-Security loạt chuẩn công bố, mà tương lai hướng đến đưa tảng bảo mật rộng cho Web service Trang 67 Một số chuẩn khác nghiên cứu nhiều hãng tổ chức nhằm giải vấn đề tồn đọng là: vấn đề phân quyền, sách, tin cậy, an tồn tương tác khả liên kết 4.3.2 XML-Signature Chuẩn chứng thực tổ chức W3C Chuẩn quan tâm đến cú pháp cách xử lý việc chứng thực thành phần tài liệu XML cơng nghệ chứng thực khóa đồng hay bất đồng 4.3.3 XML-Encryption Chuẩn đưa W3C, xây dựng để đưa qui tắc cú pháp luật xử lý việc mã hóa giải mã thành phần tài liệu XML Mục tiêu đặt bảo mật liệu 4.3.4 XML Key Management Specification: Đặc tả gồm hai phần: • X-KRSS (XML Key Registration Service Specification) ► Giải cho vấn đề đăng ký thu hồi khóa ngoại • X-KISS (XML Key Information Service Specification) ► Giải vấn đề định vị chứng thực khóa 4.3.5 Security Assertion Markup Language (SAML) Chuẩn đưa tổ chức OASIS (Organization for the Advancement of Structured Information Standard) SAML định nghĩa tảng cho việc trao đổi thông tin bảo mật định dạng XML Những thơng tin bảo mật là: thông tin chứng thực, định phân quyền, thuộc tính đối tượng biểu diễn dạng XML cấp phát nơi cung cấp chứng thực SAML Đặc tả SAML định nghĩa giao thức, qui tắc q trình vận chuyển thơng tin bảo mật Trang 68 4.4 Khai thác tính bảo mật web service thư viện WSE (Web Services Enhancements) Web Service Enhancements 2.0 thư viện lập trình NET, hỗ trợ việc xây dựng web service theo chuẩn WS-Security, WSSecureConversation, WS-Trust, WS-Policy, WS-SecurityPolicy, WS-Addressing, WS-Messaging WS-Attachments Với thư viện này, ta đưa tính liên quan đến bảo mật vào web service lúc thiết kế cách sử dụng mã lệnh, hay vào thời điểm triển khai thông qua việc sử dụng tập tin policy 4.4.1 Những tính thư viện WSE 4.4.1.1 Bảo mật web service WSE sử dụng chế định nghĩa WS-Security để đặt ủy quyền chứng thực (security credential) security token vào thông điệp SOAP WSE sau thực kiểm tra tính hợp lệ security credentials trước chuyển quyền thực thi cho web service WSE 2.0 hỗ trợ loại security token sau: tên/mật khẩu, X.509 Certificate, Kerberos ticket, Security Context token loại security token người dùng định nghĩa WSE cho phép nhà phát triển xây dựng riêng cho dịch vụ security token Các dịch vụ tạo loại security token khác mà dùng q trình tương tác với web service tin tưởng vào dịch vụ Thông qua việc hỗ trợ xác nhận số và/hay mã hóa thơng điệp SOAP tăng cường khả an tồn cho web service • Xác nhận số thông điệp SOAP giúp cho giúp cho đối tượng nhận thông điệp kiểm tra thơng điệp có bị thay đổi hay khơng? Trang 69 Hình 4-5 – Xác nhận số thơng điệp • Mã hóa thơng điệp SOAP đảm bảo cho web service mong muốn đọc nội dung thơng điệp Hình 4-6 – Mã hóa thơng điệp 4.4.1.2 Hỗ trợ Policy WSE hỗ trợ nhà phát triển đưa u cầu q trình gửi nhận thơng điệp cách dùng tập tin cấu hình Trước đây, đối tượng nhận thông điệp SOAP phải dùng mã lệnh để kiểm tra thông tin thơng điệp nhận có xác nhận số hay mã hóa chưa? Và tương tự thế, phía gửi phải viết mã lệnh để lấy yêu cầu từ phía nhà cung cấp Nay u cầu cung cấp thơng qua tập tin cấu hình Khi chế xác nhận policy định: - Các thông điệp SOAP gửi qua trình kiểm tra để đảm bảo chúng thỏa mãn policy assertion phía gửi Nếu khơng thỏa, WSE ném biệt lệ - Các thông điệp SOAP trước nhận vào phải kiểm tra xem có đáp ứng policy assertion phía nhận hay khơng? Nếu khơng, thơng điệp gửi trả hay biệt lệ ném Trang 70 WSE hỗ trợ sẵn vài chế xác nhận policy (ví dụ như: yêu cầu phần body thông điệp phải xác nhận-signed X.509 certificate) Ngoài ra, hệ thống policy cho phép thêm chế xác nhận policy khác người dùng định nghĩa 4.4.1.3 SOAP Messaging Đây tính trội WSE SOAP Messaging hỗ trợ nhiều nghi thức tầng vận chuyển HTTP, TCP, với giao tiêp bất đồng hay đồng Đặc biệt, thực việc gửi nhận thơng điệp theo nghi thức TCP ta khơng cần phải có Web server 4.4.1.4 Điều phối thơng điệp SOAP Ta sử dụng WSE để xây dựng ứng dụng phân tán mà kiến trúc phân tán suốt người dùng Ta sử dụng máy tính trung gian cấu hình chạy WSE router Người dùng gửi yêu cầu đến WSE router thay trực tiếp đến web service WSE router sau chuyển thơng điệp SOAP đến máy chạy web service dựa thơng tin cấu hình router Giải pháp giúp hệ thống ta linh hoạt hơn, bền vững hơn, ta thay đổi thơng tin máy đích có cố xảy Hình 4-7 – Điều phối thông điệp SOAP Trang 73 Chương SOA VÀ VẤN ĐỀ TÍCH HỢP Chương trình bày phân tích nhu cầu số khó khăn gây trở ngại vấn đề tích hợp hệ thống Qua xem xét mơt số giải pháp sử dụng tích hợp, bao gồm giải pháp sử dụng sản phẩm middleware giải pháp ứng dụng SOA Web services: Web Service Integration (WSI) Service-Oriented Integration (SOI) Sau đó, xem xét cụ thể giải pháp ứng dụng SOA Web services tích hợp hệ thống xây dựng NET J2EE tái sử dụng lại hệ thống cũ 5.1 Giới thiệu Enterprise Application Integration 5.1.1 Hiện trạng Hệ thống tổ chức doanh nghiệp ngày trở nên cồng kềnh với việc triển khai hàng loạt ứng dụng phân tán dựa nhiều hệ nền, kỹ thuật, cơng nghệ khác Tình trạng chưa định hình hồn chỉnh chuẩn hỗ trợ vấn đề giao tiếp hệ thống khiến cho việc tương tác, trao đổi thông tin hệ thống khác thực trở thành vấn đề nan giải Khó khăn khơng nhà quản trị hệ thống, mà hãng, công ty cung cấp kỹ thuật, cơng nghệ, giải pháp… Vì thế, việc xây dựng, triển khai hệ thống phân tán đòi hỏi ngày cao chi phí độ phức tạp Ngày nay, nhiều công ty, hãng phát triển, tổ chức bắt tay để xây dựng chuẩn chung Bên cạnh đời hệ NET J2EE thiết kế với nhiều ưu điểm trội tính linh hoạt, tương thích, dễ mở rộng … khả liên kết cao góp phần giải vấn đề khó khăn mà cơng nghệ trước chưa làm Nhưng vấn đề ta thực việc “gỡ bỏ thay mới” hệ thống, ứng dụng chức có Vì chi phí bỏ để xây dựng Trang 74 lại từ đầu hệ thống cao Ngoài vấn đề chi phí, cịn có ngun nhân khác là: hệ thống hành chứng thực tính đắn, hiệu suốt q trình vận hành, hệ thống chưa đảm bảo vấn đề Vấn đề đặt lúc gắn kết cơng nghệ cho hệ thống giữ lại có Chúng ta nói đến khái niệm tích hợp hệ thống 5.1.2 Một số lý khiến tổ chức doanh nghiệp phải quan tâm đến vấn đề tích hợp (xét mặt nghiệp vụ) Thay đổi cấu tổ chức tổng thể • Đây tình trạng tổ chức sáp nhập với tổ chức khác, hay bán chi nhánh tổ chức Khi hệ thống tin học có qui trình xử lý trùng lắp cần phải kết hợp lại với nhằm tăng hiệu hoạt động Một ví dụ ngân hàng sáp nhập lại, hệ thống phục vụ khách hàng cần phải hỗ trợ để quản lý tài khoản mà trước trực thuộc ngân hàng khác Thay đổi cấu tổ chức nội • Mặc dù thay đổi diễn phạm vi nội tổ chức, đưa đến kết tương tự trường hợp đầu Và thơng thường hoạt động cịn diễn với mật độ thường xuyên Sáp nhập hệ thống, ứng dụng: • Nhiều hệ thống tin học tổ chức thường sáp nhập lại hay thay hẳn để tiết kiệm chi phí quản trị hệ thống này, để tăng hiệu hoạt động xử lý nghiệp vụ Ví dụ cơng ty truyền thơng, có nhiều hệ thống toán tương ứng với sở hạ tầng mạng: mạng khơng dây, mạng có dây, mạng băng thơng rộng… tiết kiệm lượng đáng kể thời gian tiền bạc kết hợp hệ thống lại Tình trạng khơng đồng nhất, trùng lắp, phân mảnh liệu Trang 75 • Các liệu quan trọng thường phân bố nhiều hệ thống Và có nhu cầu, liệu phải chia sẻ, kết hợp tinh chế để hỗ trợ cho hoạt động phân tích, thống kê,… đưa định Thay đổi chiến lược kinh doanh • Các cơng ty thường có thay đổi đường lối, chiến lược kinh doanh Điều khiến cho số yếu tố môi trường khác phải thay đổi theo để thích nghi Một phần yếu tố hệ thống tin học Thay đổi để thích nghi với qui định chung • Trong lãnh vực kinh doanh qui định, ràng buộc điều thiếu Và qui trình nghiệp vụ gắn chặt với qui định Một qui định có thay đổi qui trình nghiệp vụ liên quan địi hỏi phải thay đổi theo để thích ứng Khi hệ thống tin học doanh nghiệp phải kịp thời thay đổi, điều chỉnh để hỗ trợ qui trình Tối ưu hóa qui trình nghiệp vụ • Những qui trình xử lý mà đòi hỏi phải nhập liệu cách thủ cơng cần phải thay hệ thống hỗ trợ xử lý tự động luồng giao tác Ví dụ: cơng ty thương mại với qui trình hoạt động lúc trước sau: nhận đơn đặt hàng từ Internet, sau phải thực thao tác thủ công để nhập thông tin vào hai hệ thống quản lý đơn đặt hàng quản lý sản xuất hàng Ta cần đưa giải pháp để tích hợp hai hệ thống vào hệ thống ta, trình chuyển liệu thực cách tự động 5.1.3 Các vấn đề kỹ thuật gặp phải tích hợp hệ thống • Các xung đột qui trình xử lý hệ thống • Sự khác biệt cấu trúc ngữ nghĩa liệu dùng hệ thống • Sự khơng tương thích chuẩn, kỹ thuật, cơng nghệ sử dụng hệ thống Trang 76 5.1.4 Các u cầu cho giải pháp tích hợp • Chi phí triển khai khơng q cao • Dễ nắm bắt quản lý • Khơng làm ảnh hưởng đến hệ thống khơng liên quan • Đáp ứng tốt yêu cầu tính dễ mở rộng, ổn định, hiệu quả, khả chịu lỗi, bảo mật… • Linh hoạt dễ tùy biến để dễ dàng thích nghi với yêu cầu dự án khác 5.1.5 Việc tích hợp áp dụng nhiều tầng khác • Tích hợp liệu ► Quan tâm đến vấn đề tích hợp tầng liệu, thường thực đồng hóa liệu nguồn khác (database, datamarts, data warehouses) Vấn đề khó khăn phải dung hòa lược đồ sở liệu database ngữ nghĩa thành phần liệu • Tích hợp thơng điệp ► Giải vấn đề tích hợp cách định nghĩa xây dựng chế trao đổi thông điệp hệ thống Vấn đề khó khăn chuyển đổi liệu ứng dụng thơng điệp Ngịai phải thực chuyển đổi định dạng thông điệp cho hệ thống hiểu • Tích hợp thành tố ► Xử lý bao bọc hệ thống cũ công nghệ hướng thành tố (CORBA, NET, J2EE) liên kết thành tố lại với thông qua thành phần giao tiếp Khó khăn gặp phải phải thực liên kết thành tố xây dựng công nghệ khác (CORBA NET, J2EE NET) Trang 77 • Tích hợp ứng dụng ► Thực tích hợp ứng dụng cách sử dụng tập hàm APIs, mơ hình đối tượng, định dạng thơng điệp, lược đồ sở liệu hay kỹ thuật mà lập trình viên tiếp cận Khó khăn gặp phải khác mơ hình liệu ứng dụng Mơ hình tích hợp thường dùng cho ứng dụng đóng gói • Tích hợp dịch vụ ► Mơ hình tích hợp tạo dịch vụ nghiệp vụ trừu tượng, không gắn chặt vào sở liệu, mơ hình thành tố hay ứng dụng đóng gói Và sử dụng dịch vụ đơn vị sở việc tích hợp hệ thống Khó khăn mơ hình thường phải địi hỏi phải xây dựng kiến trúc tích hợp hồn chỉnh SOA để thực tách biệt thành phần giao tiếp thành phần thực thi service • Tích hợp tiến trình ► Giải pháp tạo tiến trình nghiệp vụ cách tích hợp tài ngun có sẵn (dữ liệu, thành tố, ứng dụng dịch vụ) Và sau tập trung vào việc quản lý tiến trình nghiệp vụ cách độc lập với ứng dụng riêng biệt Vấn đề gặp phải đạt “thỏa thuận” tổ chức việc định nghĩa tiến trình nghiệp vụ kiến trúc tích hợp hồn chỉnh nhằm hỗ trợ việc tích hợp tài nguyên hệ thống thực cách dễ dàng • Tích hợp thành phần giao tiếp người dùng ► Giải pháp thường có hai cách thực khác nhau: o Sử dụng hệ giao tiếp người dùng hệ thống cũ thành phần giao tiếp để truy cập liệu từ ứng dụng hay giao tác thực Cách không bền vững, đặc biệt hệ giao tiếp người dùng ứng dụng cần lấy liệu bị thay đổi o Việc tích hợp thực tầng thể desktop hay portal Trang 78 5.2 Phân tích số kỹ thuật tích hợp sử dụng Middleware 5.2.1 Khái niệm middleware Middleware sử dụng nhiều ngữ cảnh, ngữ cảnh lại có ý nghĩa khác Trong ngữ cảnh đây, integration, middleware phần mềm hỗ trợ việc tạo môi trường trao đổi liệu hệ thống Middleware che dấu phức tạp giao tiếp hệ thống hay dịch vụ, làm đơn giản hóa phát triển hệ thống, dịch vụ Hình 5-1 thể rõ vai trị middleware kiến Hình 5-1 – Vai trị middleware trúc hệ thống tích hợp 5.2.2 Các sản phẩm Middleware sử dụng tích hợp hệ thống 5.2.2.1 Adapter Mỗi nguồn liệu hệ thống (có thể database hay ứng dụng) truy cập thông qua thành phần gọi adapter Một vài hệ thống không xây dựng sẵn cho thành phần adapter Vì vậy, hệ thống tích hợp vào hệ thống khác địi hỏi phải thiết kế adapter cho Hầu hết hệ thống hay hệ quản trị sở liệu đóng gói ngày kèm với adapter cho Những adapter viết hãng cung cấp gói sản phẩm đó, từ hãng khác Trang 79 5.2.2.2 Message Oriented Middleware (MOM) MOM phần mềm hỗ trợ trao đổi liệu hệ thống hình thức gói tin rời rạc gọi thông điệp Cơ chế thông điệp xây dựng sử dụng từ năm 1970, chế dùng trong trình giao tiếp hệ thống phân tán Nhưng đó, chế thiết kế “cứng” để thỏa mãn yêu cầu Cịn chế thơng điệp xây dựng dựa chuẩn chung Hầu hết sản phẩm MOM cung cấp nhiều tính năng, bao gồm: truyền nhận thơng điệp thơng qua hàng đợi, đảm bảo an toàn cho liệu truyền, hỗ trợ xử lý đồng bất đồng cho phép gửi lúc đến nhiều nơi thông qua chế publish/subscribe • Cơ chế hàng đợi thơng điệp: ► Các sản phẩm “hàng đợi thông điệp” cho phép gửi thông điệp từ ứng dụng đến ứng dụng khác thông qua hàng đợi Một thành phần gọi “quản lý hàng đợi” quản lý chuyện nhận thông điệp vào gửi thông tin xác nhận cho đối tượng gửi Hầu hết thành phần quản lý hàng đợi cung cấp dịch vụ “chuyển liệu an toàn” để đảm bảo liệu nhận đầy đủ trước gửi xác nhận cho đối tượng gửi Hình 5-2 – Cơ chế hàng đợi • Cơ chế Publish/subscribe: ► Cơ chế giao tiếp publish/subscribe tách rời mối liên kết phía gửi phía nhận Đối tượng gửi thay gửi trực tiếp thông tin đến đối tượng nhận gửi thông điệp đến thành phần gọi pub/sub Thành phần Trang 80 nhận dạng tiêu đề thông điệp chuyển đến cho đối tượng đăng ký nhận loại thơng điệp Hình 5-3 – Cơ chế Publish/Subscribe 5.2.2.3 Remote Procedure Call (RPC) RPC xây dựng nhằm hỗ trợ gọi thực thi dịch vụ từ xa cách đơn giản giống gọi thủ tục cục cách dấu chế phức tạp mạng RPC hoạt động theo chế đồng bộ, nghĩa đối tượng gọi bị tình trạng blocked kết trả Nhưng hỗ trợ chế xử lý bất đồng cho RPC thơng qua kỹ thuật đa luồng Hình 5-4 - Remote Procedure Call Một đặc trưng quan trọng RPC cách thiết kế thành phần giao tiếp độc lập với phần thực thi Trang 81 5.2.2.4 Distributed Object Technology (DOT) Đây phiên hướng đối tượng RPC Một ứng dụng sử dụng DOT để định nghĩa tập đối tượng gọi thực thi thơng qua mơi trường mạng Hình 5-5 – Distributed Object Model Object Broker cung cấp môi trường để quản lý, giám sát trình giao tiếp chu kỳ sống tất đối tượng DOT dùng tập tin giao tiếp gọi IDL file (Interface Description Language) IDL ngôn ngữ cấp cao dùng để mô tả thông tin thuộc tính phương thức đối tượng • Common Object Request Broker Architecture (CORBA) ► Đây tập đặc tả phát triển Object Management Group (OMG) Phần thực thi CORBA gọi ORBs (Object Request Brokers) CORBA thiết kế để giải u cầu tính tốn, hỗ trợ tính dễ mở rộng khả chịu lỗi Một ưu điểm CORBA hồn tồn khơng phụ thuộc vào hãng phát triển, cho phép sử dụng nhiều ngơn ngữ lập trình để tạo đối tượng CORBA • Enterprise JavaBeans (EJB) ► EJB kỹ thuật phát triển Sun Microsystem nhằm đáp ứng yêu cầu nhà phát triển Java việc xây dựng ứng dụng phân tán EJB phát triển J2EE, với mục tiêu xây dựng ứng dụng có khả dễ mở rộng, hỗ trợ quản lý giao tác đáp ứng yêu cầu bảo mật Trang 82 • Microsoft Distributed Component Object Model (DCOM) ► DCOM tập khái niệm, giao diện lập trình Microsoft đưa vào năm 1995, nhằm hỗ trợ việc giao tiếp với đối tượng COM thông qua môi trường mạng DCOM sử dụng chế RPC để thực trừu tượng hóa trình gửi nhận thơng tin đối tượng COM 5.3 SOA web service giải vấn đề tích hợp 5.3.1 Cơng nghệ XML web service Những nghiên cứu gần cho thấy rằng: khó khăn việc tích hợp hệ thống khắc phục cách định nghĩa thêm tầng trừu tượng cho hệ thống tin học có xây dựng Tầng xây dựng dựa chuẩn web service Một số giải pháp chung việc dùng web service cho vấn đề tích hợp: • Tích hợp hướng liệu: ► Xác định thông tin liệu cần chia sẻ (các bảng liệu, định dạng file thông điệp) ► Xây dựng lược đồ mô tả XML (Xml Schema) cho thông tin ► Sử dụng SOAP định dạng thông điệp • Tích hợp hướng chức năng/hàm APIs: ► Xác định phương thức từ xa thể web service ► Định nghĩa kiểu liệu XML cho đối số phương thức ► Sử dụng SOAP định dạng thông điệp • Tích hợp hướng thành phần giao tiếp: ► Định nghĩa thông tin mô tả web service (WSDL) Trang 83 ► Tạo đối tượng bọc thực ánh xạ tương ứng thành phần giao tiếp vừa định nghĩa với liệu, thông điệp lời gọi hàm APIs (cần chia sẻ) hệ thống hành Hình 5-6 – Sử dụng web service vấn đề tích hợp Với hỗ trợ kỹ thuật web service, liệu trao đổi hệ thống tự động chuyển đổi sang dạng chuẩn (XML) mà hệ thống hiểu Tại hệ thống chịu trách nhiệm xử lý chuyển đổi liệu từ dạng chuẩn thành kiểu đặc thù q trình nhận thơng điệp thực xử lý ngược lại (chuyển liệu từ định dạng riêng sang dạng chuẩn chung-XML) trình gửi thơng điệp Tuy nhiên, q trình chuyển đổi khơng thật lúc cần thiết Đó hai phía kênh giao tiếp sử dụng định dạng liệu, kỹ thuật, công nghệ … giống Trong trường hợp thế, giải pháp tích hợp ta cần có xử lý linh họat nhằm thực trình chuyển đổi khơng cần thiết, nâng cao hiệu hiệu suất hoạt động hệ thống Trang 84 5.3.2 Web services integration (WSI) Service-oriented integration (SOI) WSI SOI hai giải pháp giành nhìều quan tâm tổ chức doanh nghiệp nhà quản trị hệ thống việc giải vấn đề tích hợp hợp hệ thống 5.3.2.1 Web services integration (WSI) Một dự án WSI thường xây dựng để giải vấn đề trao đổi liệu số lượng nhỏ hệ thống (hai hay bốn) Đầu tiên nhóm phát triển định nghĩa thông điệp SOAP theo sở sau: - Dữ liệu cần trao đổi hệ thống - Các định dạng thông điệp mà hệ thống hành hiểu làm việc - Khả truy cập vào liệu hệ thống thông qua tập phương thức hay hàm APIs mà hệ thống hỗ trợ Tiếp theo, nhóm định nghĩa thơng tin mơ tả service, bao gồm thông tin cách thức giao tiếp, tập phương thức, mẫu trao đổi thông điệp cho đáp ứng yêu cầu dự án (hiện tại) Bên cạnh đó, vấn đề liên quan đến chất lượng dịch vụ bảo mật, an toàn đường truyền, quản lý giao tác, khả xử lý lỗi… xử lý sau (xem phần mở rộng, cần đến đâu thực đến đó.) Một vài ưu điểm giải pháp WSI: • Thời gian triển khai nhanh, đặc biệt số lượng hệ thống khơng nhiều • Chi phí đầu tư thấp Một số hạn chế giải pháp này: • Khơng quan tâm, đầu tư nhiều cho việc xây dựng mơ hình xử lý liệu, dịch vụ… nhằm mục đích tái sử dụng dự án sau Trang 85 • Các hệ thống gửi thông điệp SOAP cách trực tiếp thông qua tầng vận chuyển hay dùng APIs middleware Điều gây khó khăn có nhu cầu chuyển đổi sang tầng vận chuyển hay sản phẩm middleware khác • Vấn đề bảo mật giải không triệt để, nghĩa không đưa kiến trúc hồn chỉnh để dùng chung cho nhiều dự án Vì gặp nhiều khó khăn sau cần thực liên kết, phối hợp hoạt động hệ thống Hình 5-7 – Web services integration (WSI) 5.3.2.2 Service-oriented integration (SOI) SOI giải pháp tích hợp sử dụng web service với nguyên tắc thiết kế kiến trúc hướng dịch vụ (SOA) SOI giải pháp có tính chất chiến lược thích hợp cho dự án mà có quan tâm đến lợi ích lâu dài SOI bắt đầu giai đoạn “khởi tạo” • Xây dựng tảng cho kiến trúc hướng dịch vụ (SOA), qui trình, ngun tắc xử lý, mơ hình cơng cụ hỗ trợ Trang 86 • Xác định mơ hình tập dịch vụ sử dụng Các mơ hình khơng cần phải thật tồn diện, cần xác định rõ ràng thông tin kiểu liệu, thông tin dịch vụ, qui trình cần chia sẻ với hệ thống khác • Thực liệt kê phân lọai toàn dịch vụ dùng dự án nhằm hỗ trợ việc tái sử dụng lại dịch vụ dự án sau Hình 5-8 – Service-oriented integration (SOI) Một dự án SOI thực công việc sau: • Tinh chế lại mơ hình liệu hệ thống cho phù hợp với dự án • Xây dựng đặc tả dịch vụ dựa có phần thơng tin mô tả dịch vụ, bao gồm nguyên tắc xử lý, yêu cầu bảo mật, yêu cầu quản lý… • Xây dựng đối tượng bao bọc hệ thống cũ dựa đặc tả dịch vụ (thực đóng gói lại thành phần xử lý bên hệ thơng này) • Xây dựng dịch vụ cần thiết cho dự án Trang 87 • Xây dựng chuyển đổi liệu nhằm thực chuyển đổi liệu mơ hình liệu khác hệ thống • Xây dựng môi trường thực thi cho web service nhằm hỗ trợ tính mở rộng quản lý giao tác, đảm bảo an tồn thơng điệp truyền, khả xử lý lỗi… Các ưu điểm giải pháp SOI: • Khả tái sử dụng lại mộ hình liệu, dịch vụ qui trinh xử lý nhiều dự án tích hợp sau • Giảm lệ thuộc vào hãng, hay middleware thông qua việc xây dựng tầng trừu tượng dựa chuẩn web service • Thừa hưởng lợi ích web service bảo mật, an toàn đường truyền, quản lý giao tác, xử lý lỗi • Hình thành kiến trúc bảo mật có khả mở rộng để đáp ứng yêu cầu liên kết hệ thống, tổ chức (hỗ trợ việc triển khai single-sign on, …) Một số giới hạn giải pháp này: • Địi hỏi chi phí ban đầu lớn • Thời gian triển khai ban đầu lớn • Nhóm phát triển địi hỏi phải có kỹ trình độ kiến trúc hệ thống • Đòi hỏi hỗ trợ nhà quản lý nghiệp vụ quản lý kỹ thuật 5.4 Ứng dụng SOA web service để tích hợp hệ thống xây dựng NET J2EE Các web service xây dựng nhằm hỗ trợ việc trao đổi liệu ứng dụng hay dịch vụ, cho phép cung cấp phương thức đối tượng để truy cập đối tượng phần mềm hay ứng dụng khác thông qua môi trường mạng ... dụng đóng gói • Tích hợp dịch vụ ► Mơ hình tích hợp tạo dịch vụ nghiệp vụ trừu tượng, không gắn chặt vào sở liệu, mơ hình thành tố hay ứng dụng đóng gói Và sử dụng dịch vụ đơn vị sở việc tích hợp... nhiệm vụ kiểm tra quyền nhiều STS Trang 65 WS-Federation ► Trong WS-Trust đưa mơ hình kiến trúc Trusted Management Web vài vấn đề liên quan đến việc quản trị thành phần bên kiến trúc mà chưa WS-Trust... theo chuẩn WS-Security, WSSecureConversation, WS-Trust, WS-Policy, WS-SecurityPolicy, WS-Addressing, WS-Messaging WS-Attachments Với thư viện này, ta đưa tính liên quan đến bảo mật vào web service