Đồ án Thiết kế và xây dựng các hệ thống sử dụng các thành phần phần mềm không đồng nhất

OAP và chứa yêu cầu dịch vụ. Thành phần sử dụng gửi tài liệu tới một SOAP server. Dịch vụ mạng nhận thông điệp SOAP và gửi thông điệp như một lời gọi dịch vụ tới ứng dụng cung cấp dịch vụ được yêu cầu. Đáp ứng từ dịch vụ được trả về cho SOAP server và thông điệp này sẽ được gửi trả thành phần yêu cầu dịch vụ nhờ giao thức SOAP. SOAP và XML SOAP là một ứng dụng của đặc tả XML. Các định nghĩa và hàm của SOAP chủ yếu dựa trên các chuẩn XML như lược đồ XML và không gian tên XML. Tất cả các thông điệp SOAP đều được mã hoá bằng XML. Một ứng dụng SOAP cần bao gồm không gian tên SOAP phù hợp trên tất cả các phần tử và thuộc tính được định nghĩa bởi SOAP trong các thông điệp mà nó sinh ra. Một ứng dụng SOAP phải có khả năng xử lý các không gian tên SOAP trong các thông điệp nhận được. Nó phải huỷ bỏ các thông điệp chứa các không gian tên không đúng và nó có thể xử lý các thông điệp SOAP không cần các không gian tên SOAP mặc dù chúng có các không gian tên đúng. Thông điệp SOAP Một thông điệp SOAP bao gồm một vỏ bao chứa một phần đầu (header) tuỳ chọn và một phần thân (body) bắt buộc. Phần đầu chứa các khối thông tin chỉ ra cách thức thông điệp được xử lý, bao gồm các thiết lập chọn đường và phân phối, các khẳng định sự xác thực hoặc bản quyền, và các ngữ cảnh giao dịch. Phần thân chứa thông điệp thực sự được gửi đi và được xử lý. Bất cứ cái gì có thể biểu diễn bằng cú pháp XML đều có thể chứa trong phần thân của thông điệp. Hình 2.2: Cấu trúc thông điệp SOAP Cú pháp XML để biểu diễn thông điệp SOAP dựa trên không gian tên Không gian tên này chỉ ra một lược đồ XML định nghĩa cấu trúc của một thông điệp SOAP. Sau đây là một tài liệu SOAP biểu diễn bằng XML. <s:Envelope xmlns:s=''> <m:transaction xmlns:m=''soap-transaction'' s:mustunderstand="true"> 1234 Christogher Robin Accounting Pooh Bear Honey 1 Pooh Stick Ví dụ này minh hoạ tất cả các thành phần cơ bản của đặc tả vỏ bao SOAP, trong đó: : thành phần chứa ở mức cao nhất của thông điệp SOAP. : chứa các khối bổ sung thông tin về cách thức xử lý thông điệp. : phần tử chính chứa thông điệp thật sự cần được xử lý. SOAP Fault (lỗi SOAP) Lỗi SOAP là một loại thông điệp đặc biệt nhằm truyền tải thông tin về lỗi có thể xảy ra trong quá trình xử lý thông điệp SOAP. Phần tử SOAP Fault được sử dụng để truyền thông tin trạng thái hoặc lỗi trong một thông điệp SOAP. Nếu có trong thông điệp, phần tử này phải xuất hiện như một điểm vào phần thân và không được xuất hiện quá một lần trong phần tử body. Phần tử SOAP Fault định nghĩa 4 loại phần tử con sau: Faultcode: Phần tử faultcode được sử dụng bởi phần mềm để cung cấp một cơ chế toán học cho phép xác định lỗi. Faultcode phải có mặt trong một phần tử SOAP Fault. SOAP định nghĩa một tập nhỏ các mã lỗi SOAP cho các lỗi SOAP cơ bản. Faultstring: Phần tử faultstring cung cấp một giải thích lỗi mà người dùng có thể đọc được, không dùng để xử lý toán học. Faultactor: Phần tử faultactor cung cấp thông tin về người gây ra lỗi trong đường dẫn thông điệp. Nó tương tự như thuộc tính SOAP actor nhưng thay vì chỉ ra đích của điểm vào phần đầu, nó chỉ ra nguồn của lỗi. Giá trị của thuộc tính faultactor là một URI xác định nguồn gây ra lỗi. Các ứng dụng không phải là đích cuối cùng phải chứa phần tử faultactor trong phần tử SOAP Fault. Đích cuối cùng của thông điệp có thể sử dụng phần tử faultactor để chỉ ra nguồn gây lỗi một cách tường minh. Detail: Phần tử detail được dùng để truyền thông tin lỗi của ứng dụng cụ thể có liên quan đến phần thân. Nó phải có mặt nếu nội dung của phần thân có thể không được xử lý thành công. Nó không được sử dụng để mang thông tin về lỗi của phần đầu. Thông tin chi tiết về lỗi của điểm vào phần đầu phải được truyền trong các điểm vào của phần đầu. Sự vắng mặt của phần tử detail trong phần tử Fault chỉ ra rằng lỗi không liên quan tới xử lý phần thân, do vậy, nó được dùng để xác định xem phần thân có được xử lý hay không trong trường hợp có lỗi xảy ra. Tất cả các phần tử con trực tiếp của phần tử detail được gọi là các điểm vào cụ thể và mỗi điểm vào cụ thể được mã hoá như một phần tử độc lập trong phần tử detail. Các quy tắc mã hoá cho các điểm vào cụ thể như sau: Một điểm vào cụ thể được xác định bằng tên đầy đủ của phần tử, bao gồm không gian tên URI và tên địa phương. Thuộc tính encodingStyle có thể được sử dụng để chỉ ra cách mã hoá cho các điểm vào cụ thể. Mô hình truyền thông điệp SOAP SOAP hỗ trợ hai kiểu truyền thông điệp: Lời gọi thủ tục từ xa (Remote Procedure Call - RPC): cho phép xử lý thông điệp dạng yêu cầu-đáp ứng, trong đó, đích nhận một thông điệp hướng thủ tục và trả lại một thông điệp đáp ứng. Truyền tải thông tin hướng thông điệp: hỗ trợ các tổ chức và ứng dụng cần truyền tải nghiệp vụ hoặc các tài liệu khác, trong đó, một thông điệp được gửi nhưng người gửi không yêu cầu phải trả lời ngay. Các thông điệp SOAP phần lớn được truyền theo kiểu một chiều từ người nhận đến người gửi. Các thông điệp SOAP thường được kết hợp để cài đặt các mẫu như request/response. Các cài đặt SOAP có thể được tối ưu hoá để khai thác các đặc trưng của các hệ thống mạng cụ thể. Ví dụ, kết nối HTTP cho phép các thông điệp SOAP đáp ứng được truyền như các đáp ứng HTTP, sử dụng cùng một kết nối giống như thông điệp yêu cầu. Không phụ thuộc vào giao thức mà SOAP bị ràng buộc, các thông điệp được định hướng dọc theo một “đường dẫn thông điệp” (message path), cho phép xử lý tại một hoặc nhiều nút trung gian ngoài đích cuối cùng. Ứng dụng SOAP nhận thông điệp SOAP phải xử lý thông điệp đó bằng cách thực hiện các hành động sau theo thứ tự được liệt kê dưới đây: Xác định tất cả các thành phần của thông điệp SOAP được chuyển tới cho ứng dụng dó. Xác nhận rằng tất cả các thành phần cơ bản được xác định ở bước 1 được hỗ trợ bởi ứng dụng cho thông điệp này và xử lý chúng một cách thích hợp. Nếu không thì huỷ bỏ thông điệp. Bộ xử lý có thể bỏ qua các phần tuỳ chọn được xác định ở bước 1 mà không ảnh hưởng tới kết quả của quá trình xử lý. Nếu ứng dụng SOAP không phải là đích cuối cùng của thông điệp thì xoá bỏ tất cả các phần được xác định trong bước một trước khi chuyển tiếp thông điệp. Việc xử lý một thông điệp hoặc một phần của thông điệp yêu cầu bộ xả lý SOAP hiểu mẫu truyền tải được sử dụng (một chiều, yêu cầu/ đáp ứng, gửi đồng thời…), vai trò của người nhận trong mẫu đó, việc sử dụng các cơ chế RPC, biểu diễn hoặc mã hoã dữ liệu, cũng như các ngữ nghĩa cần thiết để xử lý đúng. Mã hóa dữ liệu SOAP SOAP định nghĩa các kiểu phù hợp với các mẫu cấu trúc sau thường được tìm thấy trong các ngôn ngữ lập trình: Struct (cấu trúc): Một cấu trúc là một giá trị phức hợp trong đó, tên các điểm truy cập là điểm khác biệt duy nhất giữa các giá trị thành viên, và không có điểm truy cập nào có cùng tên. Array (mảng): Một mảng là một giá trị phức hợp trong đó số thứ tự vị trí đóng vai trò phân biệt các giá trị thành viên. SOAP cũng cho phép sự truyền theo thứ tự (serialization) của dữ liệu không phải là một cấu trúc hay một mảng, ví dụ, các dữ liệu trong mô hình “đồ thị được gán nhãn trực tiếp” trong đó mỗi đỉnh đơn có nhiều các điểm truy cập phân biệt, một vài trong số chúng lại có thể xuất hiện nhiều hơn một lần. Việc truyền theo thứ tự không cho phép các mô hình dữ liệu cơ sở tạo một sự phân biệt về thứ tự giữa các điểm truy cập, nhưng nếu một thứ tự như thế tồn tài, các điểm truy cập phải được mã hoá theo đúng trình tự đó. Truyền tải SOAP SOAP là một giao thức đóng gói chuẩn hoá được đặt trên cùng của các lớp mạng và vận tải. Giống như một giao thức đóng gói, SOAP không quan tâm các giao thức vận tải nào được sử dụng để trao đổi thông điệp, do đó, làm cho SOAP rất linh hoạt trong việc sử dụng. Vì sự phát triển của HTTP trên Internet, giao thức này trở thành giao thức truyền thông chung để trao đổi các thông điệp SOAP. 2.3. Đặc tả mô tả và tích hợp tìm kiếm UDDI UDDI vẫn chưa phải là một chính thức, nó đang là một dự án đang được phát triển bởi các tổ chức thành viên nhằm tạo ra khả năng tìm kiếm và giao dịch nhanh chóng, dễ dàng. Chức năng của UDDI cho phép các tổ chức: Mô tả nghiệp vụ và dịch vụ của mình. Tìm kiếm các tổ chức khác cung cấp dịch vụ theo đúng yêu cầu đưa ra. Tích hợp với các tổ chức này Về cơ bản, UDDI gồm hai phần: đặc tả kỹ thuật và thành phần đăng ký dịch vụ UDDI. Thành phần đăng ký dịch vụ UDDI là một dịch vụ phân tán kết nối thông qua các nút đăng ký. Các nút này được điều hành bởi các thành viên của UDDI như IBM, HP, Microsoft… Ngoài một thành phần đăng ký dịch vụ toàn cầu, có thể cài đặt các thành phần đăng ký cục bộ cho các mạng nội bộ hoặc mạng riêng. Thành phần đăng ký dịch vụ tương tự như một quyển danh bạ điện thoại: các trang trắng chứa thông tin chung về tổ chức bao gồm tên, mô tả, địa chỉ… Các trang vàng chứa các phân loại tổ chức theo ngành công nghiệp, theo sản phẩm… dựa trên các nguyên tắc phân loại chuẩn. Cuối cùng là các trang xanh chứa thông tin kỹ thuật về dịch vụ mạng như vị trí và cách thức để triệu gọi nó. Các kiểu dữ liệu chính của UDDI: bussinessEntity: chi tiết về tổ chức (tên, địa chỉ liên hệ…) bussinessService: các dịch vụ mạng mà tổ chức cung cấp (đặt hàng trực tuyến…) bindingTemplate: chi tiết kỹ thuật để gọi dịch vụ mạng. tModel: các cấu trúc siêu dữ liệu cho đặc tả dịch vụ. publisherAssertion: chỉ ra mối quan hệ giữa các thực thể nghiệp vụ. Hình 2.3: Các kiểu dữ liệu chính trong UDDI Ví dụ: Cấu trúc kiểu dữ liệu UDDI: <businessEntity businessKey="35AF7F00-1419-11D6A0DC-000C0E00ACDD" authorizedName="0100002CAL" operator="www-3.ibm.com/services/uddi"> BooksToGo The source for all professional books Ramesh Mandava (877)1111111 Một nơi đăng ký sẽ không có ích nếu không cho phép truy cập vào nó. Chuẩn UDDI xác định hai giao diện SOAP cho thành phần sử dụng dịch vụ và thành phần cung cấp dịch vụ tương tác với nơi đăng ký. Thành phần dùng dịch vụ sử dụng InquireSOAP để tìm dịch vụ, và thành phần cung cấp dịch vụ sử dụng PublishSOAP để xuất bản một dịch vụ. Các dịch vụ này được mô tả bằng WSDL. Giao diện cho thành phần cung cấp dịch vụ định nghĩa các thao tác cho một nhà cung cấp dịch vụ quản lý các điểm vào của mình tại một nơi đăng ký UDDI: Get_authToken: Lấy về một thẻ bài được cấp phép. Tất cả các thao tác giao diện cho thành phần cung cấp dịch vụ đều yêu cầu một thẻ bài được cấp phép phải được đệ trình cùng với yêu cầu. Discard_authToken: Thông báo cho nơi đăng ký UDDI để không chấp nhận một thẻ bài được cấp phép nào đó. Bước này tương đương với việc log out khỏi hệ thống. Save_business: tạo mới hoặc cập nhật thông tin về thực thể nghiệp vụ chứa trong nơi đăng ký UDDI. Save_service: tạo mới hoặc cập nhật thông tin về các dịch vụ mạng mà đối tượng nghiệp vụ cung cấp. Save_binding: tạo mới hoặc cập nhật thông tin kỹ thuật liên quan đến cài đặt một dịch vụ mạng. Save_Tmodel: tạo mới hoặc cập nhật đăng ký của các tModel được quản lý bởi nơi đăng ký UDDI. Delete_business: xoá bỏ hoàn toàn các đối tượng nghiệp vụ khỏi nơi đăng ký UDDI. Delete_service: xoá bỏ các web service khỏi nơi đăng ký UDDI. Delete_binding: xoá bỏ các chi tiết kỹ thuật về một web service khỏi nơi đăng ký UDDI. Delete_Tmodel: xoá bỏ các Tmodels khỏi nơi đăng ký UDDI. Get_registeredInfo: trả về tất cả các thông tin mà nơi đăng ký UDDI lưu giữ về người dùng, bao gồm tất cả các doanh nghiệp, các dịch vụ, và các Tmodels. Giao diện cho thành phần sử dụng dịch vụ định nghĩa các thao tác cho việc tìm kiếm nơi đăng ký UDDI và lấy thông tin chi tiết về các đăng ký: Find_binding: trả về một danh sách các web service phù hợp với tập điều kiện tìm kiếm dựa trên thông tin liên kết kỹ thuật. Find_business: trả về một danh sách các thực thể nghiệp vụ phù hợp với tập điều kiện tìm kiếm. Find_ltservice: trả về một danh sách các web service phù hợp với tập điều kiện tìm kiếm. Find_Tmodel: trả về một danh sách các Tmodel phù hợp với tập điều kiện tìm kiếm. Get_bindingdetail: trả về thông tin đăng ký đầy đủ của một web service. Get_businessDetail: tả về thông tin đăng ký của một thực thể nghiệp vụ, bao gồm tất cả các dịch vụ mà thực thể cung cấp. Get_businessDetailExt: trả về thông tin đăng ký đầy đủ của một thực thể nghiệp vụ. Get_serviceDetail: trả về thông tin đăng ký đầy đủ của một web service. Get_TmodelDetail: trả về thông tin đăng ký đầy đủ của một Tmodel. Một ví dụ về tìm kiếm trong UDDI: Để tìm kiếm một công ty, chẳng hạn là Microsoft, chúng ta phải tạo ra một câu truy vấn trong một vỏ bao SOAP như sau:        Microsoft <businessList generic="1.0" operator="Microsoft Corporation" truncated="false" xmlns="urn:uddi-org:api"> <businessInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3"> Microsoft Corporation Empowering people through great software - any time, any place and on any device is Microsoft's vision. As the worldwide leader in software for personal and business computing, we strive to produce innovative products and services that meet our customer's <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="1FFE1F71-2AF3-45FB-B788-09AF7FF151A4"> Web services for smart searching <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="8BF2F51F-8ED4-43FE-B665-38D8205D1333"> Electronic Business Integration Services <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="611C5867-384E-4FFD-B49C-28F93A7B4F9B"> Volume Licensing Select Program <serviceInfo businessKey="0076B468-EB27-42E5-AC09-9955CFF462A3" serviceKey="A8E4999A-21A3-47FA-802E-EE50A88B266F"> UDDI Web Sites UDDI được phát triển đầu tiên bởi Microsoft, IBM và Ariba, và hiện nay đang được quản lý bởi một tập đoàn các công ty công nghiệp. Thông qua việc định nghĩa một định dạng đăng ký được chuẩn hoá và giao diện kiểu cổng, UDDI cho phép các nhà cung cấp dịch vụ và những người dùng dịch vụ tìm kiếm và tích hợp động với nhau. Các vấn đề với UDDI Có một số vấn đề với UDDI cần phải được giải quyết trong những phiên bản tương lai của đặc tả này. Cơ chế bảo mật yếu là một trong số đó. Hiện tại, bất kỳ ai cũng có thể giả danh một ai đó để tạo một điểm vào trong một kho đăng ký UDDI. Ví dụ, chúng ta hoàn toàn có thể giả danh Microsoft để tạo một điểm vào, và điều này là rất nguy hiểm. Một vấn đề khác là sự gia tăng nhanh của các “đường dẫn tồi” (“bad link”) trong các kho UDDI công cộng. Các điểm liên kết tới các công ty hoặc dịch vụ này không tồn tại hoặc không sẵn dùng. Có một sự thiếu hiểu biết trong các công ty về mục đích và ứng dụng của UDDI. Điều này có thể làm cản trở sự thông qua của chuẩn này trong tương lai. Thậm chí trong số các công ty có hiểu biết về nó, vẫn có những ý kiến nghi ngờ về sự hữu ích của các kho UDDI công cộng trong một thời gian dài. 3. Các kiểu liên kết trong dịch vụ mạng. Có hai kiểu liên kết đến dịch vụ mạng để thực thi nó, đó là liên động và liên kết tĩnh. 3.1 Liên kết tĩnh Một thành phần sử dụng dịch vụ sẽ sử dụng liên kết tĩnh khi chỉ có duy nhất một cài đặt dịch vụ được sử dụng trong thời gian chạy. Liên kết tĩnh được tạo ra trong thời gian xây dựng bằng cách định vị định nghĩa cài đặt của dịch vụ cho một dịch vụ mạng duy nhất sẽ được sử dụng bởi thành phần dùng dịch vụ. Định nghĩa cài đặt dịch vụ chứa một tham chiếu tới giao diện dịch vụ được sử dụng để sinh ra mã uỷ nhiệm dịch vụ (service proxy). Uỷ nhiệm dịch vụ chứa một cài đặt hoàn chỉnh để thành phần sử dụng dịch vụ có thể gọi được dịch vụ mạng. Hình 2.4: Liên kết tĩnh Các bước xây dựng: Tìm kiếm định nghĩa cài đặt dịch vụ: Trong thời gian xây dựng, người yêu cầu dịch vụ phải định vị định nghĩa cài đặt dịch vụ cho Web service. Định nghĩa cài đặt dịch vụ chữa một tham chiếu tới định nghĩa giao diện dịch vụ và vị trí dịch vụ có thể được truy cập. Tạo uỷ nhiệm dịch vụ: Thông tin về định nghĩa giao diện dịch vụ và vị trí dịch vụ được sử dụng để tạo ra cài đặt của uỷ nhiệm dịch vụ. Cài đặt của uỷ nhiệm dịch vụ sẽ phù hợp với giao diện dịch vụ và luôn cố cố gắng truy cập dịch vụ tại cùng một vị trí. Kiểm thử uỷ nhiệm dịch vụ: Trước khi triển khai uỷ nhiệm dịch vụ thì phải kiểm thử để kiểm chứng rằng nó có thể tương tác với Web service. Các bước triển khai: Triển khai ủy nhiệm dịch vụ: Sau khi uỷ nhiệm dịch vụ đã được kiểm thử để kiểm chứng rằng nó hoạt động đúng, uỷ nhiệm dịch vụ được triển khai với ứng dụng khách trong môi trường thời gian chạy. Các bước hoạt động: Gọi Web service: Chạy ứng dụng yêu cầu sử dụng uỷ nhiệm dịch vụ để gọi dịch vụ mạng. 3.2. Liên kết động trong thời gian xây dựng. Loại liên kết này được sử dụng khi một thành phần sử dụng dịch vụ muốn sử dụng một kiểu dịch vụ mạng cụ thể nào đó nhưng cài đặt của nó thì hoặc là không được biết cho đến khi chạy hoặc là có thể thay đổi trong thời gian chạy. Kiểu dịch vụ được định nghĩa trong một mô tả giao diện dịch vụ Hình 2.5: Liên kết động thời gian xây dựng Các bước xây dựng: Tìm kiếm định nghĩa giao diện: Bước đầu tiên là định vị định nghĩa giao diện dịch vụ cho kiểu dịch vụ sẽ được sử dụng bởi yêu cầu dịch vụ. Giao diện dịch vụ chỉ chứa định nghĩa trừu tượng của các thao tác dịch vụ mạng. Sinh ra uỷ nhiệm dịch vụ chung: Sử dụng định nghĩa giao diện dịch vụ, một uỷ nhiệm dịch vụ chung có thể được sinh ra. Uỷ nhiệm dịch vụ này có thể được sử dụng để truy cập bất kỳ cài đặt nào của giao diện dịch vụ. Điểm khác biệt duy nhất giữa uỷ nhiệm dịch này và uỷ nhiệm dịch vụ được sinh ra trong liên kết tĩnh là liên kết tĩnh chứa thông tin về cài đặt một dịch vụ cụ thể; có nghĩa là uỷ nhiệm dịch vụ chung sẽ chứa mã để định vị một cài đặt dịch vụ bằng cách tìm kiếm trong một nơi đăng ký dịch vụ. Kiểm thử uỷ nhiệm dịch vụ: Trước khi triển khai uỷ nhiệm dịch vụ, cần phải kiểm thử để xác nhận rằng nó có thể tương tác với một loại Web service đã được chỉ ra. Điều này có thể thực hiện bằng cách tìm một cìa đặt của giao diện dịch vụ. Các bước triển khai Triển khai uỷ nhiệm dịch vụ: Sau khi uỷ nhiệm dịch vụ được kiểm thử, nó có thể được triển khai trong môi trường thời gian chạy. Quá trình này có thể bao gồm việc triển khai ứng dụng yêu cầu có sử dụng uỷ nhiệm dịch vụ. Môi trường thời gian thực mà uỷ nhiệm dịch vụ được triển khai phải có truy cập tới nơi đăng ký dịch vụ để tìm kiếm một cài đặt cho giao diện dịch vụ. Các bước hoạt động: Tìm định nghĩa cài đặt dịch vụ: Trước khi uỷ nhiệm dịch vụ có thể gọi một dịch vụ, một cài đặt của dịch vụ phải được định vị trong một nơi đăng ký dịch vụ. Uỷ nhiệm dịch vụ được sinh ra có thể chứa tất cả mã được yêu cầu để tìm kiếm nơi đăng ký dịch vụ cho một cài đặt của giao diện dịch vụ. Gọi dịch vụ mạng: Sau khi một cài đặt dịch vụ được tìm thấy, uỷ nhiệm dịch vụ có thể được sử dụng để gọi dịch vụ mạng. 3.3. Liên kết động trong thời gian chạy. Liên kết động thời gian chạy tương tự như liên kết động thời gian xây dựng. Một giao diện dịch vụ được sử dụng để sinh ra một giao diện uỷ nhiệm dịch vụ tổng quát có thể được sử dụng để gọi bất kỳ cài đặt nào của giao diện dịch vụ. Kiểu liên kết này khác biệt ở chỗ giao diện dịch vụ được tìm thấy trong thời gian chạy. Sau khi giao diện được tìm thấy, mã uỷ nhiệm được sinh ra, biên dịch, và sau đó được thực thi. Kiểu liên kết này thường được sử dụng với một giao diện người dùng, vì khả năng tương tác động giữa máy với máy là không thể. Hình 2.6: Liên kết động thời gian chạy Các bước xây dựng: Xây dựng ứng dụng yêu cầu: Ứng dụng yêu cầu dịch vụ được xây dựng bằng cách dùng một giao diện liên kết động trong thời gian chạy. Giao diện này được sử dụng để tìm ra một cài đặt dịch vụ, và sau đó nhận về giao diện dịch vụ gắn với cài đặt dịch vụ. Các bước triển khai: Triển khai ứng dụng yêu cầu: Triển khai ứng dụng yêu cầu để nó chạy và sử dụng dịch vụ mạng trong môi trường thời gian chạy. Các bước hoạt động: Tìm định nghĩa cài đặt dịch vụ: Ứng dụng yêu cầu dịch vụ sử dụng môi trường thời gian chạy để tìm một định nghĩa cài đặt dịch vụ. Có rất nhiều phương pháp khác nhau có thể sử dụng để định vị một cài đặt dịch vụ trong một nơi đăng ký dịch vụ. Cài đặt dịch vụ có thể được tìm thấy bằng cách: đầu tiên, định vị một doanh nghiệp hay một kiểu doanh nghiệp, sau đó, xác định các dịch vụ mà các doanh nghiệp đó cung cấp. Cài đặt dịch vụ cũng có thể được định vị bằng cách tìm kiếm một phân lớp dịch vụ, hoặc bằng cách định vị một kiểu dịch vụ (hoặc giao diện dịch vụ). Nếu giao diện dịch vụ là đích của thao tác tìm kiếm thì nó được sử dụng để định vị các cài đặt của giao diện dịch vụ. Tạo và triển khai uỷ nhiệm dịch vụ: Sử dụng giao diện dịch vụ cùng với cài đặt dịch vụ để sinh ra mã uỷ nhiệm dịch vụ được sử dụng để gọi dịch vụ. Sau khi mã được sinh ra, nó được biên dịch để chạy trong môi trường thời gian chạy. Gọi dịch vụ mạng: Mã uỷ nhiệm dịch vụ đã sinh ra được sử dụng để gọi dịch vụ mạng. 5. Xây dựng dịch vụ mạng 5.1. Vòng đời của dịch vụ mạng Vòng đời của dịch vụ mạng gồm 5 giai đoạn, đó là: mô tả - cài đặt – xuất bản, tìm kiếm và liên kết – gọi và thực thi – trả về kết quả. Mô tả: Định nghĩa trừu tượng của điểm cuối dịch vụ mạng được mô tả bằng file WSDL. WSDL mô tả dịch vụ mạng như là một tập hợp của các điểm cuối hoặc cổng. Cài đặt: SOAP được sử dụng để mô tả các yêu cầu và đáp ứng từ một dịch vụ mạng. Xuất bản, tìm kiếm và liên kết: Để máy khách có thể truy cập được, cài đặt của dịch vụ mạng cần được xuất bản trong nơi đăng ký UDDI. Nơi đăng ký UDDI mô tả thông tin về cách kết nối và tương tác với dịch vụ. Gọi và thực thi: Bộ phận lắng nghe SOAP nhận một yêu cầu và thông báo cho các thành phần quan tâm, có thể là ứng dụng hoặc dịch vụ mạng. Sau khi nhận được mọt thông điệp trả lời, SOAP xác thực thông điệp dựa trên lược độ XML mô tả trong WSDL. Cuối cùng, thông điệp SOAP được gửi đến dịch vụ mạng thích hợp. Trả về kết quả: kết quả của dịch vụ mạng được trả về cho máy khách gọi dịch vụ mạng tương ứng. 5.2. Bảo mật trong dịch vụ mạng Mô hình STRIDE Do bản chất tự nhiên, nhiều dịch vụ mạng được đặt trong một môi trường không an toàn – Internet. Vì lý do này, các dịch vụ mạng phải được triển khai những công nghệ bảo mật thích hợp. Trước khi xây dựng các hệ thống của mình, chúng ta nên đặt ra các câu hỏi sau: Một tin tặc chiếm quyền điều khiển giỏ hàng trực tuyến như thế nào? Mức độ ảnh hưởng khi một kẻ tấn công bằng cách từ chối sự truy cập vào dịch vụ của những người dùng hợp lệ là gì? Một kẻ tấn công có thể xem hoặc thay đổi dữ liệu truyền từ dịch vụ tới người dùng bằng cách nào? Để làm được điều này, chúng ta sử dụng mô hình STRIDE. STRIDE là một từ viết tắt của sáu loại nguy cơ an toàn sau: Sự giả mạo định danh (Snoofing identity): Sự giả mạo có nghĩa là việc truy cập một cách bất hợp pháp và sau đó sử dụng thông tin thẩm định quyền của người dùng khác, như username và mật khẩu. Sự giả mạo dữ liệu (Tampering with data): Sự giả mạo dữ liệu bao gồm việc cố tình sửa đổi dữ liệu, ví dụ: thực hiện các thay đổi không được phép đối với dữ liệu, thay đổi dữ liệu khi dữ liệu truyền giữa hai máy tính trên một hệ thống mạng mở như Internet. Từ chối (Repudiation): Từ chối xảy ra khi các người dùng từ chối thực hiện những hành động mà các bên khác không có cách nào để chứng minh điều ngược lại – ví dụ, một người dùng thực hiện một thao tác bất hợp pháp trong hệ thống không có khả năng ghi lại các thao tác bị cấm. Sự không thể chối từ là khả năng của hệ thống có thể chống lại các nguy cơ từ chối. Ví dụ, nếu một người dùng mua một món hàng thì anh ta sẽ phải ký vào mặt hàng này trên biên lai. Người bán hàng có thể sử dụng biên lai đó như một bằng chứng là khách hàng đã nhận được gói hàng. Sự lộ thông tin (Information disclosure): các nguy cơ lộ thông tin bao gồm việc phơi bày thông tin cho những người không được truy cập vào nó. Ví dụ, một người dùng có khả năng được được file mà mình không có quyền truy cập hoặc khả năng mọt kẻ đột nhập có thể đọc dữ liệu truyền giữa hai máy tính. Từ chối dịch vụ (Denial of Service): Các tấn công từ chối dịch vụ đối với những người dùng hợp lệ, ví dụ, bằng cách làm cho Web server tạm thời bị vô hiệu hóa. Sự nâng đặc quyền (Elevation of privilege): trong loại nguy cơ này, một người dùng không có quyền nhận được quyền truy cập và do đó, có khả năng truy cập để làm tổn hại hoặc phá hủy toàn bộ hệ thống. Quay trở lại các câu hỏi được đặt ra trước khi xây dựng hệ thống, chúng ta thấy rằng câu hỏi đầu tiên liên quan tới nguy cơ giả mạo dữ liệu (T), câu hỏi thứ hai liên quan tới nguy cơ từ chối dịch vụ (D) và câu hỏi thứ ba liên quan tới nguy cơ lộ thông tin và nguy cơ giả mạo thông tin (I và T). Một cách đơn giản nhất để áp dụng mô hình STRIDE cho ứng dụng là xem xét mỗi loại nguy cơ sẽ có ảnh hưởng tới mỗi thành phần và các kết nối giữa các thành phần như thế nào. Thực chất của việc này là xem xét mỗi phần của ứng dụng và quyết định xem nguy cơ S, T, R, I, D hay E tồn tại ở thành phần hoặc quy trình đó và ghi chúng lại. Lựa chọn các kỹ thuật để làm giảm nguy cơ. Bước tiếp theo là xác định các kỹ thuật làm giảm nguy cơ thích hợp. Bảng dưới đây chỉ ra một số kỹ thuật và công nghệ đó. Loại nguy cơ Kỹ thuật giảm nhẹ nguy cơ Giả mạo định danh Các quy tắc thẩm định quyền sử dụng các công nghệ như thẩm định cơ bản, thẩm định cốt yếu, chứng nhận X.509, thẩm định .NET Passport, và các thẩm định dựa form khác. Lưu ý rằng một số trường hợp cần thẩm định máy khách, còn một số trường hợp lại cần thẩm định máy chủ. Chúng ta cũng có thể chứng minh rằng dữ liệu đến từ một nơi nào đó bằng cách ký và xác nhận chữ ký. Không lưu giữ các thông tin mật một theo cách không an toàn, đặc biệt là các thông tin thẩm định quyền như mật khẩu hay số định danh cá nhân (PIN). Giả mạo thông tin Bảo vệ dữ liệu với các danh sách điều khiển truy cập (ACL – Access Control List) hoặc các quyền hợp lý. Xác định xem dữ liệu có bị làm giả không bằng cách sử dụng các mã băm hoặc các mã thẩm định thông điệp. Từ chối Bảo vệ khỏi nguy cơ từ chối bao gồm sự thẩm định và dữ liệu được ký, cũng như việc ghi và kiểm tra log. Lộ thông tin Dữ liệu có thể bảo vệ bằng cách sử dụng các danh sách điều khiển truy cập và các quyền hợp lý. Các kỹ thuật đảm bảo tính riêng tư như mã hóa có thể có ích nếu các khóa được sử dụng để mã hóa và giải mã cũng được bảo vệ khỏi nguy cơ bị lộ. Từ chối dịch vụ Các nguy cơ từ chối dịch vụ rất khó để chống lịa vì rất khó xác định khi nào máy chủ bận thật sự và khi nào nó bị tấn công. Nếu chúng ta hạn chế các yêu cầu người dùng, chúng ta có thể sẽ ngăn cản những truy cập của người dùng hợp lệ. Một kỹ thuật đơn giản là hạn chế những hành động mà người dùng vô danh có thể thực hiện. Ví dụ, chúng ta sẽ cấp phát 10% tài nguyên cho người dùng vô danh và 90% tài nguyên cho người dùng hợp lệ. Một số giải pháp khác không nằm trong tầm kiểm soát ứng dụng một cách trực tiếp bao gồm tường lửa và các bộ định tuyến lọc gói tin. Nâng đặc quyền Không yêu cầu các đặc quyền mà mình không cần đến. Bằng cách đó, nếu kẻ tấn công có biết được mã số an toàn thì cũng không thể gây nhiều tổn hại vì anh ta không có nhiều quyền. Một ví dụ về dịch vụ mạng. Xét một trường hợp đơn giản, trong đó một người dùng trao đổi thông tin với dịch vụ mạng, dịch vụ mạng sau đó lại trao đổi thông tin với một cơ sở dữ liệu và trả lại nội dung cho người dùng như trong hình dưới đây. Hình 2.7: Một ví dụ dịch vụ mạng Bảng dưới đây liệt kê một số nguy cơ đối với hệ thống và cách thức làm giảm nhẹ mức độ ảnh hưởng của những nguy cơ này. Đích ID Loại nguy cơ Mô tả Các kỹ thuật làm giảm nguy cơ Dịch vụ mạng 1 1 S Kẻ tấn công tấn công dịch vụ mạng bằng cách sử dụng tấn công từ chối dịch vụ phân tán và đặt dịch vụ của chính mình lên Internet. Ứng dụng của người dùng không biết rằng đang truyền thông với một dịch vụ giả mạo. Sử dụng một kết nối SSL/TLS từ người dùng để thẩm định máy chủ. Trên đường dữ liệu từ người dùng đến dịch vụ 22 T và I Kẻ tấn cống xem hoặc thay đổi thông tin trên đường từ người dùng tới máy chủ và ngược lại. Sử dụng SSL/TLS hoặc IPSec để mã hóa dữ liệu khi nó vào/ra khỏi dịch vụ mạng Trên đường dữ liệu từ người dùng đến dịch vụ 33 E Kẻ tấn công xem dữ liệu mật khẩu trên đường từ người dùng đến máy chủ, nếu người dùng là một quản trị hệ thống, kẻ tấn cống có thể sử dụng username và mật khẩu. Sử dụng một cơ chế thẩm định quyền không truyền mật khẩu dưới dạng tường minh hoặc sử dụng SSL/TLKS hoặc IPSec để bảo vệ kênh truyền tin. Dịch vụ mạng 44 D Kẻ tấn công làm quá tải dịch vụ mạng bằng hàng nghìn yêu cầu không có thật và làm dịch vụ mạng chậm lại. Sử dụng một tường lửa để giới hạn dữ liệu nào là được phép. Xây dựng các logic giới hạn lượng dữ liệu được gửi bởi một người dụng hoặc một địa chỉ IP. Việc giới hạn bằng các địa chỉ IP có thể là khó giải quyết, tuy nhiên, nhiều người dùng hợp lệ sử dụng các ISP có một số lượng hạn chế các địa chỉ IP, vì vậy, nhiều yêu cầu có thể đến từ cùng một địa chỉ IP trong khi thực tế thì chúng từ các người dùng khác nhau trong cùng một máy chủ ủy nhiệm (proxy server). Dữ liệu SQL Server 55 T và I Kẻ tấn công truy cập dữ liệu trong SQL Server một cách trực tiếp mà không thông qua dịch vụ mạng Giới hạn những dữ liệu được phép sử dụng để xây dựng các truy vấn SQL. SQL Server 66 S, T, R, I, D, E Kẻ tấn công sử dụng các thủ tục lưu (stored procedure) xp_cmdshell được xây dựng sẵn trong SQL Server để gọi mã nguy hiểm trong cơ sở dữ liệu SQL. Lệnh này có thể gọi bất kỳ lệnh nào tại máy chủ. Giới hạn những dữ liệu nào được phép sử dụng để xây dựng các truy vấn cơ sở dữ liệu. Loại bỏ các thủ tục lưu (stored procedure) mở rộng như xp_cmdshell. Không kết nối tới SQL Server bằng tài khoản của người quản trị hệ thống vì tài khoản này có thể thực hiện bất kỳ nhiệm vụ SQL Server nào, bao gồm cả việc gọi xp_cmdshell. Các công nghệ bảo mật dịch vụ mạng. Bước thứ ba trong quy trình mô hình hóa nguy cơ bao gồm việc chọn lựa các công nghệ phù hợp để áp dụng các kỹ thuật giảm tác hại của các nguy cơ đã được chọn lựa. Thẩm định quyền các dịch vụ mạng: Thẩm định quyền là khả năng chứng minh một thực thể - ví dụ, một người sử dụng hoặc một máy tính – đúng là thực thể như nó khẳng định. Chúng ta có thể xác nhận điều khẳng định này bằng cách sử dụng một thực thể được gọi là một ủy nhiệm cung cấp chứng nhận. Chứng nhận thường bao gồm tên người dùng (username) và mật khẩu. Một dịch vụ mạng chạy trên IIS có một số các giao thức thẩm định quyền cho nó, đáng chú ý nhất trong số đó là: Thẩm định người dùng vô danh. Thẩm định cơ sở. Thẩm định cốt yếu. Thẩm định Windows. Thẩm định dựa trên chứng thực. Thẩm định dựa trên form. Thẩm định .NET Passport. Quyền hạn của các dịch vụ mạng: Khi ứng dụng xác định một ủy nhiệm bằng cách sử dụng một cơ chế thẩm định quyền, nó cần xác định xem người dùng có truy cập tới các tài nguyên được bảo vệ hay không và có thể gọi các hàm cụ thể, trong đó đáng chú ý nhất là sự sử dụng các danh sách điều khiển truy cập. Một danh sách điều khiển truy cập gồm nhiều điểm vào kiểm soát truy cập (ACE – Access Control Entries). Mỗi điểm vào kiểm soát truy cập liệt kê một ủy nhiệm và chứa các thông tin về ủy nhiệm và các thao tác có thể thực hiện trên tài nguyên. Ví dụ, một vài người được trao quyền đọc và một số khác có thể có toàn quyền. Điểm mạnh thật sự của các danh sách điều khiển truy cập là ở chỗ chúng luôn luôn được tuân theo theo cùng một cách thức, không quan tâm tới cơ chế truy cập.Vì vậy, nếu vì một vài lý do nào đó mà một kẻ tấn công có thể qua được dịch vụ và do đó phá hỏng logic quyền hạn ở mức ứng dụng và truy cập tài nguyên một cách trực tiếp thì chính sách quyền hạn trong các danh sách điều khiển truy cập của tài nguyên vẫn còn có hiệu lực. 5.3. Tính liên thông giữa các dịch vụ mạng Khi dịch vụ mạng được sử dụng rộng rãi, các nhà cung cấp lại cố gắng thêm nhiều tính năng và nhiều chuẩn vào framework của mình để việc truyền thông giữa các hệ thống phong phú và mạnh hơn. Vì WSDL là một ngôn ngữ mà máy có thể hiểu được (file XML), các công cụ và hạ tầng quanh nó có thể được xây dựng một cách dễ dàng. Ngày nay, các nhà phát triển có thể sử dụng các định nghĩa WSDL để sinh mã có khả năng biết cách tương tác một cách chính xác với dịch vụ mạng mà nó mô tả. Loại sinh mã này che giấu những chi tiết nhàm chán không cần thiết trong việc gửi và nhận các thông điệp SOAP qua nhiều giao thức khác nhau và làm cho các dịch vụ mạng có thể được tiếp cận dễ dàng. Microsoft .NET Framework có tiện ích dòng lệnh wsdl.exe cho phép sinh các lớp từ các định nghĩa WSDL. Wsdl.exe có thể sinh ra mọt lớp dành cho việc sử dụng dịch vụ và lớp khác dành cho việc cài đặt dịch vụ. Apache Axis cũng có một tiện ích tương tự là WSDL2Java thực hiện chức năng tương tự cho các lớp Java. Các lớp được sinh ra từ cùng một định nghĩa WSDL có khả năng tương tác với nhau thông qua giao diện WSDL được cung cấp, không bị gắn chặt với ngôn ngữ lập trình dùng để viết ra chúng. Hình 2.8: WSDL và việc sinh mã 6. Kết luận chương Công nghệ dịch vụ mạng khá thích hợp để cài đặt một kiến trúc hướng dịch vụ. Về bản chất, các dịch vụ mạng có khả năng tự mô tả và là các ứng dụng có tính mô đun có thể thể hiện logic nghiệp vụ như các dịch vụ được xuất bản, tìm kiếm và thực thi qua Internet. Dựa trên chuẩn XML, dịch vụ mạng có thể được phát triển như các thành phần ứng dụng gắn kết không chặt chẽ với nhau, không quan tâm tới bất kỳ ngôn ngữ lập trình, giao thức hay nền tảng nào. Điều này làm các ứng dụng nghiệp vụ được xây dựng thành dịch vụ được có thể được truy cập bởi bất kỳ ai, vào bất kỳ thời điểm nào, tại bất kỳ vị trí nào và sử dụng bất kỳ nền tảng nào. Trong chương sau, NVĐA sẽ trình bày việc xây dựng chương trình tra cứu từ điển đa ngôn ngữ để minh họa cho những lý thuyết đã được đề cập ở chương I và chương II. Chương III: CÀI ĐẶT ỨNG DỤNG Sau khi lý thuyết kiến trúc hướng dịch vụ và dịch vụ mạng được trình bày trong các chương trước, chương này sẽ xây dựng ứng dụng tra từ điển đa ngôn ngữ (Anh – Việt, Việt – Anh, Pháp – Việt, Việt - Pháp) từ các dịch vụ từ điển để minh họa cho các lý thuyết trên. Nội dung sẽ trình bày: Nhắc lại yêu cầu của một hệ thống theo kiến trúc hướng dịch vụ. Mô tả bài toán xây dựng từ điển. Cài đặt bài toán tra từ điển. Đánh giá về ứng dụng. 1. Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ Nhìn ở mức cao, kiến trúc hướng dịch vụ bao gồm 3 thành phần: thành phần cung cấp dịch vụ, thành phần sử dụng dịch vụ và thành phần đăng ký dịch vụ. Vai trò của thành phần cung cấp và thành phần sử dụng dịch vụ là khá rõ ràng, còn thành phần đăng ký dịch vụ là trung gian giữa các thành phần này. Hình 3.1: Mô hình kiến trúc hướng dịch vụ ở mức cao Thành phần cung cấp dịch vụ đăng ký với thành phần đăng ký dịch vụ và thành phần sử dụng dịch vụ truy vấn thành phần đăng ký dịch vụ để tìm thành phần cung cấp dịch vụ. Sử dụng thành phần đăng ký dịch vụ trong kiến trúc hướng dịch vụ đem lại các lợi ích sau: Các dịch vụ có thể thêm dần vào thành phần đăng ký dịch vụ. Phân tách thành phần sử dụng và thành phần cung cấp dịch vụ. Cho phép cập nhật “nóng” dịch vụ. Cung cấp dịch vụ tìm kiếm, tra cứu cho thành phần sử dụng. Cho phép thành phần sử dụng chọn lựa các thành phần cung cấp dịch vụ trong thời gian thực thi, không phải gắn cứng vào một nhà cung cấp cụ thể nào đó. Các lợi ích của việc xây dựng ứng dụng theo định hướng dịch vụ là khá rõ ràng. Để xây dựng được những ứng dụng như vậy thì các dịch vụ tạo thành phải có các tính chất sau: Các dịch vụ là có thể tìm kiếm được. Các dịch vụ có tính liên thông. Các dịch vụ không được gắn kết chặt chẽ với nhau. Các dịch vụ trong suốt về vị trí. Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có tính tự chứa đựng và mức độ đóng gói cao (coarse-grained). Một dịch vụ cần có khả năng được phát hiện ra một cách công khai bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên kết động tới dịch vụ. Một dịch vụ cần đảm bảo tính liên thông bằng cách hỗ trợ các giao thức truyền thông được chuẩn hóa và các định dạng dữ liệu rõ ràng. Việc xây dựng từ điển đa ngôn ngữ không phải là vấn đề mới, tuy nhiên, ở đây tôi sẽ thực hiện việc xây dựng từ điển theo định hướng dịch vụ và cài đặt bằng dịch vụ mạng. 2. Mô tả bài toán Bài toán cần xây dựng là một ứng dụng cho phép tra từ điển trực tuyến đa ngôn ngữ. Ứng dụng được xây dựng theo kiến trúc hướng dịch vụ nên có 3 thành phần sau: Thành phần cung cấp dịch vụ: Thành phần cung cấp dịch vụ là các dịch vụ mạng có phương thức có đầu vào là từ cần tra nghĩa và đầu ra là nghĩa của từ đó (có 4 dịch vụ mạng cung cấp các từ điển Anh – Việt, Việt – Anh, Pháp – Việt, Việt – Pháp). Thành phần sử dụng dịch vụ: Thành phần sử dụng dịch vụ là ứng dụng từ điển của người dùng. Ứng dụng này sẽ tìm kiếm và tích hợp 4 dịch vụ mạng được cung cấp ở trên để xây dựng nên ứng dụng, do đó, việc phát triển diễn ra rất nhanh chóng và đảm bảo do các dịch vụ trên đã được xây dựng và kiểm thử. Thành phần đăng ký dịch vụ: Dịch vụ UDDI được tích hợp trong các phiên bản Windows 2003 (trừ phiên bản Web Edition) cho phép đăng ký, cập nhật, tìm kiếm thông tin về các dịch vụ cũng như các thành phần cung cấp dịch vụ. Yêu cầu của bài toán đặt ra là tách biệt giữa thành phần cung cấp và thành phần cài đặt dịch vụ. Ứng dụng tra từ điển của người dùng sẽ chỉ cần biết giao diện của dịch vụ cung cấp từ điển mà không cần quan tâm tới cài đặt chi tiết cũng như vị trí của dịch vụ và các dịch vụ được sử dụng để tạo nên ứng dụng cũng độc lập với nhau (ứng dụng được tạo thành từ 4 dịch vụ từ điển khác nhau). Các biểu đồ trường hợp sử dụng của ứng bài toán ở mức cao: Hình 3.2: Biểu đồ trường hợp sử dụng của bài toán 3. Cài đặt bài toán 3.1. Thành phần cung cấp dịch vụ Các bước xây dựng thành phần cung cấp dịch vụ: Tạo đặc tả giao diện WSDL. Cài đặt dịch vụ theo đặc tả giao diện đã có. Kiểm thử dịch vụ. Triển khai (đăng ký) dịch vụ. Ta cũng có thể xây dựng dịch vụ trước rồi sau đó tạo ra đặc tả giao diện nhờ các công cụ (wsdl.exe, Java2WSDL …): Hình 3.3: Cài đặt dịch vụ mạng Tạo cài đặt dịch vụ: Dữ liệu cho dịch vụ từ điển được cung cấp bởi T.S Hồ Ngọc Đức tại địa chỉ: (Anh - Việt, Việt – Anh ) và (Pháp - Việt, Việt – Pháp ) Cấu trúc của dữ liệu từ điển tuân theo định dạng chuẩn được đưa ra tại như sau: File data: chứa thông tin theo định dạng sau: @từ_cần_tra *từ_loại định_nghĩa_1 = ví_dụ_1 + nghĩa_của_ví_dụ_1 định_nghĩa_2 = ví_dụ_2 + nghĩa_của_ví_dụ_2 !thành_ngữ_1 định_nghĩa_thành_ngữ_1 = ví_dụ_thành_ngữ_1 + nghĩa_của_ví_dụ_thành_ngữ_1 *từ_loại định_nghĩa_3 Ví dụ: @acceptance * danh từ - sự nhận, sự chấp nhận, sự chấp thuận - sự thừa nhận, sự công nhận - sự hoan nghênh, sự tán thưởng, sự tán thành; sự tin =his statement will not find acceptance+ lời tuyên bố của ông ta sẽ không được ai tin - (thương nghiệp) sự nhận thanh toán (hoá đơn); hoá đơn được nhận thanh toán =general acceptance+ sự nhận thanh toán không cần có điều kiện =qualified acceptance+ sự nhận thanh toán có điều kiện !acceptance of persons - sự thiên vị File index: chứa từ cần tra (HeadWord), địa chỉ của từ tính từ đầu file (tính theo byte) dưới dạng mã BASE64, độ dài của từ (tính theo byte) dưới dạng mã BASE64 Ví dụ: acceptable MkG DB Dịch vụ sẽ cung cấp 2 phương thức: string LookUp (string HeadWord): trả về xâu biểu diễn định nghĩa của từ đúng như trong file data. Ví dụ: LookUp(acquit) sẽ trả về xâu: @acquit * ngoại động từ - trả hết, trang trải (nợ nần) =to acquit one's debt trang trải hết nợ nần+ tha bổng, tha tội, tuyên bố trắng án =to be acquitted of one's crime+ được tha bổng - to acquit oneself of làm xong, làm trọn (nghĩa vụ, bổn phận...) =to acquit oneself of a promise+ làm trọn lời hứa =to acquit oneself of one's task+ làm trọn nhiệm vụ !to acquit oneself - làm bổn phận mình, làm trọn phận mình; xử sự =to acquit oneself ill+ làm không tốt phần mình, xử sự xấu string LookUpXML(string HeadWord): trả về xâu biểu diễn nghĩa của từ dưới dạng XML (để có thể định dạng bằng file CSS). Ví dụ: LookUpXML(acquit) sẽ trả về xâu: acquit ngoại động từ trả hết, trang trải (nợ nần) to acquit one's debt trang trải hết nợ nần tha bổng, tha tội, tuyên bố trắng án to be acquitted of one's crime được tha bổng to acquit oneself of làm xong, làm trọn (nghĩa vụ, bổn phận...) to acquit oneself of a promise làm trọn lời hứa to acquit oneself of one's task làm trọn nhiệm vụ to acquit oneself làm bổn phận mình, làm trọn phận mình; xử sự to acquit oneself ill làm không tốt phần mình, xử sự xấu Cài đặt dịch vụ sử dụng cấu trúc cây AVL là cấu trúc điển hình trong việc xây dựng ứng dụng từ điển. Cây AVL là một dạng của cây nhị phân, tuy nhiên, không giống như cây nhị phân, thời gian tìm kiếm xâu nhất của cây AVL là O(logn). Cấu trúc dữ liệu AVL đạt được thời gian tìm kiếm nhanh như vậy do nó giới hạn sự chênh lệch về chiều cao giữa các cây con của cùng một nút và nó thực hiện việc cân bằng lại nếu giới hạn này bị vi phạm. Dịch vụ từ điển được tạo thành từ các lớp sau: public class AvlNode: Cài đặt cấu trúc của mỗi nút trong cây avl public class AvlTree: Cài đặt cây avl. public class LoadDict: Tải từ điển vào cây avl và cài đặt phương thức tra cứu từ. public class BASE64Converter: Chuyển đổi giữa dạng số thập phân và mã BASE64. public class XMLGenerator: Sinh ra xâu có nội dung là một file XML từ xâu trả về khi tra cứu nghĩa của từ. Tạo đặc tả giao diện WSDL: Giả sử dịch vụ sau khi được tạo ra có địa chỉ như sau: Khi đó, ta có thể xem file đặc tả giao diện WSDL tại địa chỉ: Kiểm thử: VS .NET tự động cung cấp trang kiểm thử cho dịch vụ mạng được tạo ra. Trang này có giao diện như sau: Hình 3.4: Trang kiểm thử dịch vụ mạng Nhập từ vào ô HeadWord và ấn Invoke để xem kết quả Triển khai (đăng ký) dịch vụ: Sau khi dịch vụ được kiểm thử, có thể đăng ký với dịch vụ UDDI. Hình 3.5: Đăng ký dịch vụ với UDDI 3.2. Thành phần sử dụng dịch vụ. Thành phần cung cấp dịch vụ và thành phần sử dụng dịch vụ liên kết động với nhau, theo như mô hình liên kết động trong chương 2, phần 3. Hình 3.6: Mô hình liên kết dịch vụ mạng động Các bước xây dựng: Tìm đặc tả cài đặt dịch vụ Tạo và triển khai ủy nhiệm dịch vụ. Gọi dịch vụ. Tìm đặc tả cài đặt dịch vụ: Đặc tả về dịch vụ được tìm kiếm nhờ dịch vụ UDDI. Hình 3.7: Tìm kiếm trong UDDI Tạo và triển khai ủy nhiệm dịch vụ: Sau khi tìm được đặc tả giao diện phù hợp, bước tiếp theo sẽ là tạo ra ủy nhiệm dịch vụ nhờ công cụ wsdl.exe của .NET. Hình 3.8: Sử dụng công cụ wsdl.exe Gọi dịch vụ: Việc gọi dịch vụ được thực hiện thông qua ủy nhiệm dịch vụ, kết quả là tạo ra được ứng dụng tra từ điển từ các dịch vụ mạng mà không cần biết cài đặt chi tiết của dịch vụ. 3.3 Thành phần đăng ký dịch vụ. Hiện trên thế giới có 2 nơi đăng ký dịch vụ công cộng do Microsoft ( ) và IBM ( ) quản lý. Khi nhà cung cấp dịch vụ đăng ký hay cập nhật dịch vụ tại một trong 2 nơi đăng ký thì thông tin về dịch vụ sẽ được cập nhật tới nơi đăng ký còn lại trong vòng 24 giờ. Chỉ có trong Windows 2003 (trừ bản Web Edition), Microsoft mới cho phép tích hợp nơi đăng ký dịch vụ riêng để sử dụng trong các mạng nội bộ, đó là dịch vụ UDDI (UDDI Services – thành phần này không được cài mặc định). Dịch vụ UDDI cho phép xuất bản, cập nhật và tìm kiếm các dịch vụ cũng như các nhà cung cấp dịch vụ. Giao diện của dịch vụ UDDI như sau: Hình 3.9: Giao diện dịch vụ UDDI 4. Các kết quả đạt được Ứng dụng từ điển được xây dựng từ 4 dịch vụ từ điển khác nhau là Anh – Việt, Việt – Anh, Pháp – Việt, Việt – Pháp. Giao diện của chương trình: Hình 3.10: Giao diện của chương trình Thông tin chi tiết về dịch vụ đang được sử dụng: Hình 3.11: Thông tin chi tiết về dịch vụ Khi thông tin về dịch vụ thay đổi (chẳng hạn vị trí của dịch vụ thay đổi) thì ứng dụng sẽ thực hiện việc truy vấn UDDI để cập nhật thông tin về dịch vụ mà không cần phải dịch lại chương trình. Hình 3.12: Dịch vụ thay đổi Truy vấn UDDI thành công, ứng dụng lại hoạt động như bình thường. Hình 3.13: Truy vấn thay đổi dịch vụ thành công Thông tin thay đổi về dịch vụ được thấy rõ khi xem thông tin chi tiết về dịch vụ (để ý rằng điểm truy cập của dịch vụ đã thay đổi): Hình 3.14: Thông tin về dịch vụ thay đổi 5. Đánh giá về ứng dụng 5.1. Ưu điểm Ứng dụng được xây dựng theo định hướng dịch vụ, tức là gồm có 3 thành phần: thành phần cung cấp dịch vụ (các dịch vụ từ điển), thành phần sử dụng dịch vụ (ứng dụng tra từ được xây dựng từ các dịch vụ từ điển) và thành phần đăng ký dịch vụ (dịch vụ UDDI của Windows 2003), do vậy, nó đã tách được phần giao diện ra khỏi phần cài đặt. Hơn nữa, nó được xây dựng theo cơ chế liên kết dịch vụ động nên đảm bảo tính linh hoạt khi dịch vụ thay đổi. Ứng dụng có giao diện sử dụng thân thiện, đã thể hiện được các tính chất căn bản cần có của một ứng dụng xây dựng theo kiến trúc hướng dịch vụ: Các dịch vụ có giao diện rõ ràng: Giao diện của dịch vụ được công bố trong UDDI, mô tả mọi thông tin cần thiết về chức năng cũng như các tham số đầu vào, đầu ra, điểm truy cập của dịch vụ, tạo ra giao ước sử dụng dịch vụ giữa thành phần sử dụng và thành phần cung cấp dịch vụ. Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có tính tự chứa đựng và mức độ đóng gói cao (coarse-grained): Các dịch vụ từ điển đều thực hiện được một chức năng hoàn chỉnh, đó là tra từ. Các dịch vụ độc lập có thể tích hợp lại với nhau trong cùng một ứng dụng để làm nên ứng dụng tổng thể (từ điển đa ngôn ngữ). Mỗi dịch vụ lại được cấu tạo từ nhiều lớp khác nhau: AvlNode, AvlTree, LoadDict, BASE64Converter, XMLGenerator. Một dịch vụ cần có khả năng được phát hiện ra một cách công khai bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên kết động tới dịch vụ: Điều này được thực hiện thông qua việc sử dụng dịch vụ UDDI. Các dịch vụ có tính liên thông: Do việc sử dụng dịch vụ chỉ cần biết đặc tả giao diện của dịch vụ là file WSDL tuân theo định dạng XML mà bất kỳ nền tảng nào cũng có thể hiểu được và không quan tâm tới cài đặt cụ thể của dịch vụ, việc truyền thông lại dùng giao thức phổ biến là HTTP nên các dịch vụ mạng được xây dựng có thể hoạt động và tương tác trên mọi nền tảng. Các dịch vụ không được gắn kết chặt chẽ: Thành phần sử dụng và thành phần cung cấp dịch vụ không gắn kết trực tiếp với nhau mà thông qua thành phần đăng ký dịch vụ là UDDI, điều này đảm bảo cho tính mềm dẻo và linh hoạt của dịch vụ. Các dịch vụ trong suốt về vị trí: Sự thay đổi vị trí của dịch vụ không làm ảnh hưởng tới thành phần sử dụng dịch vụ, do các thay đổi của dịch vụ đều được phản ánh trong UDDI, thành phần sử dụng dịch vụ chỉ truy vấn thông qua UDDI mà không liên kết trực tiếp tới dịch vụ. 5.2. Các điểm hạn chế Ứng dụng mới chỉ cung cấp chức năng cơ bản là tra từ. Chưa quan tâm tới vấn đề bảo mật cho dịch vụ mạng. KẾT LUẬN Khi độ phức tạp phần mềm tăng lên, các nhà nghiên cứu luôn tìm ra nhiều cách mới để khắc phục. Kiến trúc hướng dịch vụ, cùng với công nghệ dịch vụ mạng là câu trả lời cuối cùng cho vấn đề này. Trong khuôn khổ đồ án tốt nghiệp này, NVĐA đã trình bày những khái niệm về kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, cũng như việc áp dụng công nghệ dịch vụ mạng để xây dựng ứng dụng theo định hướng dịch vụ. Đây là một đề tài rất thú vị, không chỉ bởi tính thời sự của nó, mà còn bởi tư duy mới trong xây dựng phần mềm của nó. Việc nghiên cứu đề tài về kỹ thuật hướng dịch vụ đã giúp tôi có cái nhìn mới về phát triển phần mềm, các vấn đề của các kỹ thuật phát triển phần mềm hiện tại. Các kết quả đạt được: Nắm được bản chất của các mô hình phát triển phần mềm và sự tiến hóa của chúng. Nghiên cứu các bản chất, các yêu cầu và các thành phần của kiến trúc hướng dịch vụ. Hiểu được các lợi ích khi phát triển phần mềm theo kiến trúc hướng dịch vụ. Tìm hiểu về công nghệ dịch vụ mạng, tính liên thông giữa các dịch vụ mạng và các chuẩn cho phép thực hiện công nghệ dịch vụ mạng. Áp dụng thành công công nghệ dịch vụ mạng để xây dựng ứng dụng tra từ điển theo kiến trúc hướng dịch vụ. Các hạn chế: Do trình độ chuyên môn và thời gian hạn hẹp nên đồ án không tránh khỏi có nhiều thiếu sót: Chưa tìm hiểu sâu được về vấn đề bảo mật cho kiến trúc hướng dịch vụ. Chưa thử nghiệm được nhiều về tính liên thông giữa các dịch vụ. Chưa thật sự hoàn thiện chương trình ứng dụng. Chưa triển khai ứng dụng trên mạng Internet. Hướng phát triển tiếp theo của đề tài: Tìm hiểu các công nghệ khác áp dụng cho việc cài đặt kiến trúc hướng dịch vụ. Hoàn thiện giao diện và chức năng cho ứng dụng. Phát triển cơ chế bảo mật cho các dịch vụ. Việc nghiên cứu đề tài đã giúp tôi nắm được xu thế mới trong phát triển phần mềm - phát triển hướng dịch vụ, để từ đó áp dụng những lợi điểm của kỹ thuật phát triển này vào các sản phẩm trong tương lai của mình, cũng như khả năng tiếp cận và nắm bắt các công nghệ, công cụ mới hỗ trợ cho việc phát triển phần mềm theo kiến trúc hướng dịch vụ. Cuối cùng, một lần nữa tôi xin chân thành cảm ơn TS. Huỳnh Quyết Thắng, người đã định hướng cho tôi hướng nghiên cứu về đề tài này và là người hướng dẫn, giúp đỡ tôi rất nhiều trong quá trình thực hiện đề tài. Tôi cũng xin cảm ơn gia đình và bạn bè đã tạo điều kiện và giúp đỡ tôi trong suốt quá trình học tập cũng như thực hiện đề tài này. Danh mục tài liệu tham khảo [1]. Mark Endrei & others, Patterns: Service-Oriented Architecture and Web Services, IBM Press , 2004 [2]. Scott Short, Building XML Web Services for the Microsoft .NET Platform, Microsoft Press, 2002 [3]. David S. Linthicum, 12 Steps to implementing a Service-Oriented Architecture, 2004 [4]. Micheal S. Mimoso, A defining moment for SOA, 2004 [5]. Bernhard Borges & others, Delving into Service-Oriented Architecture and Web Services, [6]. Don Box, Four tenets to keep in mind when considering service orientation, 2004 [7]. Connecticut Object-Oriented User Group, Service-Oriented Architecture, 2003 [8]. Brent Carlson & Dmitry Tyomkin, Service-Oriented Architecture: Elements of good design, Business Integration, 2004 [9]. Sayed Hashimi, Service-Oriented Architecture Explained, 2003 [10]. Friedemann Lindermann, Service-Oriented Requirements Engineering and Verification, UTHH, 2004 [11]. Google, [12]. Vietnam Dictionary,