Luận văn Hệ thống quản lý đăng ký thuế sử dụng web service

nghĩa cấu trúc dữ liệu SOAP được đặt trong SOAP-ENC. 4. Giao thức truyền thông trong SOAP: Giao thức SOAP sử dụng hai kiểu truyền thông: • RPC (đã giới thiệu ở phần XML) • Document, đây là kiểu truyền thông hướng thông điệp, nó cung cấp giao tiếp ở mức trừu tượng thấp, khó hiểu và yêu cầu lập trình viên mất công sức hơn. Hai kiểu truyền thông này cung cấp các định dạng thông điệp, tham số, lời gọi đến các API khác nhau nên việc sử dụng chúng tùy thuộc vào thời gian và sự phù hợp với dịch vụ Web cần xây dựng. 5. Mã hóa trong SOAP: Giao thức SOAP không quan tâm đến loại ngôn ngữ lập trình được sử dụng nên các ứng dụng web có thể được viết bằng nhiều ngôn ngữ khác nhau. Giả sử dịch vụ yêu cầu và dịch vụ đáp ứng được phát triển bằng ngôn ngữ Java. Bởi vì định dạng cho Web Service chính là XML nên mã hóa SOAP sẽ chuyển đổi từ cấu trúc dữ liệu Java sang SOAP XML và ngược lại. Bất kỳ một môi trường thực thi SOAP nào cũng phải có một bảng chứa thông tin ánh xạ nhằm chuyển đổi từ ngôn ngữ Java sang XML và từ XML sang Java - bảng đó được gọi là SOAPMappingRegistry. Nếu một kiểu dữ liệu được sử dụng dưới một dạng mã hóa thì sẽ có một ánh xạ tồn tại trong bộ đăng ký của môi trường thực thi SOAP đó. 1.3.4. UDDI: 1. Giới thiệu về UDDI: Để có thể sử dụng được các dịch vụ web, đầu tiên client phải tìm kiếm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ. UDDI sẽ cho cung cấp các thông tin này lên mạng cho phép các client kích hoạt các ứng dụng để tìm kiếm thông tin của dịch vụ Web khác nhằm xác định xem dịch vụ nào sẽ cần đến nó. 19 UDDI là một nơi mà các nhà cung cấp cho phép khách hàng đăng kí dịch vụ để sử dụng các chức năng của web service. UDDI sẽ định vị các thông tin về các web service được cung cấp bởi các nhà cung cấp dịch vụ, danh sách các nhà cung cấp dịch vụ trên web service nào đó, chi tiết về kĩ thuật sử dụng (API) web service do mình đưa ra… UDDI cung cấp các chuẩn kỹ thuật để mô tả, khám phá và tập hợp các cài đặt dựa trên Internet. Các đặc tính kĩ thuật phát triển nhanh chóng vì nó nhận được phản hồi nhanh nhạy từ các cài đặt, những cài đặt này xác nhận các khái niệm và cung cấp nền tảng kinh nghiệm phong phú cho việc hoàn thiện các đặc tả sau này. Trong kinh doanh, nó giúp mở rộng và đơn giản hóa các giao dịch giữa các doanh nghiệp (B2B), tạo mối quan hệ giữa nhà sản xuất với các khách hàng khác nhau, mỗi khách hàng ứng với một tập các giao thức và các chuẩn hỗ trợ miêu tả dịch vụ rất linh hoạt sử dụng bất kỳ giao thức tương tác nào, lấy dữ liệu từ các nhà cung cấp khác trong cùng một lĩnh vực có liên quan, cung cấp "cửa hàng một cửa" cho việc tìm kiếm thông tin về dịch vụ điện tử và thương mại. UDDI dựa vào những chuẩn đã có như là ngôn ngữ đánh dấu mở rộng (XML) và giao thức truy cập đối tượng đơn giản SOAP để xây dựng nền tảng cho việc đăng ký, các đặc tính (như quan hệ kinh doanh), giải quyết những vấn đề quan trọng cho việc phát triển dịch vụ web như: bảo mật, tăng cường quốc tế hóa, khả năng tương tác nội bộ, và hàng loạt các cải tiến hàm API để cải tiến công cụ tốt hơn. 2. Nguyên tắc hoạt động: Bản ghi của UDDI bao gồm các thông tin: • Các mô tả của các doanh nghiệp có thể truy cập bằng các chương trình máy tính và các dịch vụ mà chúng hỗ trợ. • Các tham chiếu tới các đặc tả cụ thể mà một dịch vụ web có thể hỗ trợ, các định nghĩa phân loại (được sử dụng cho việc xếp loại kinh doanh và dịch vụ), và các hệ thống định danh (sử dụng để xác định các doanh nghiệp). • UDDI cung cấp một lược đồ và mô hình lập trình với định nghĩa luật giao tiếp với bản ghi. Tất cả các hàm API trong đặc tả UDDI được định nghĩa trong XML được gói trong một phong bì SOAP, và gửi bừng giao thức HTTP. 20 Hình 1.4 - Luồng thông báo UDDI giữa Client và Registry Hình 1.4 mô tả sự truyền thông báo UDDI, từ yêu cầu SOAP của máy khách thông qua giao thức HTTP đến một nốt bản ghi đăng ký và quay lại. Máy chủ SOAP tiếp nhận các thông điệp đăng ký UDDI SOAP, xử lý và trả lại một kết quả SOAP đến máy khách. Các yêu cầu từ máy khách phải là các giao dịch đảm bảo an ninh và được xác thực. Hình 1.5 - UDDI làm việc như thế nào Hình 1.5 mô tả cách tạo dữ liệu bản ghi UDDI và cách khách hàng khám phá, sử dụng thông tin: 21 Bước 1: Công bố thông tin hữu ích đến bản ghi khi các công ty và các cá nhân định nghĩa các đặc tả liên quan đến công nghiệp hay kinh doanh, mà họ đăng ký với UDDI. Đó là các mô hình kỹ thuật, hoặc thông dụng hơn là tModels. Bước 2: Các công ty đăng ký bản mô tả kinh doanh các dịch vụ của họ. Một bản ghi UDDI sẽ theo dõi bằng cách gán cho mỗi điểm một định danh duy nhất hay một khóa định danh phổ biến duy nhất (Unique Universal Identifier - UUID) Bước 3: Một khóa UUID được đảm bảo là duy nhất và không bao giờ thay đổi trong một bản ghi UDDI, là một chuỗi số thập lục phân ngẫu nhiên có định dạng (Ví dụ: C0B9FE13-179F-413D-8A5B-5004DB8E5BB2) được dùng để tham chiếu đến điểm mà chúng được gán vào và chỉ có ý nghĩa trong bản ghi đó. Bước 4: Các khách hàng khác, như: máy tìm kiếm, và ứng dụng thương mại… sử dụng một bản ghi UDDI để khám phá các dịch vụ mà chúng quan tâm. Bước 5: Các doanh nghiệp khác có thể yêu cầu và sử dụng các dịch vụ này. Dữ liệu trong một bản ghi UDDI có thể được phân chia vào bốn mục, mỗi điểm được gán cho một khóa UUID duy nhất có thể được định vị trong bản ghi UDDI đó: • BusinessEntity: mô hình hóa các thông tin kinh doanh như: địa chỉ, thông tin liên hệ, tên giao dịch… • BusinessService: mô tả một dịch vụ web như: tên dịch vụ, danh sách chức năng… • TModel: mô tả các đặc tả, phân lớp hoặc định danh, thông tin về loại dịch vụ. • BindingTemplate: chứa thông tin về cách thức và địa chỉ của một dịch vụ web, là một ánh xạ giữa một businessService và tập tModel mô tả dấu tay kỹ thuật của nó Thông tin đăng ký có thể chia thành ba loại: • Bản trắng (White pages): chứa các thông tin cơ bản của một doanh nghiệp (như tên, mô tả việc kinh doanh, thông tin liên lạc...) và các định dạng chính yếu của dịch vụ web cho phép các đối tượng khác xác định được dịch vụ. 22 • Bản vàng (Yellow pages): chứa thông tin mô tả dịch vụ Web theo những loại khác nhau để chọn loại phù hợp với đối tượng, thông tin mở rộng khả năng tìm kiếm một doanh nghiệp hoặc dịch vụ trong bản ghi nhờ hỗ trợ phân lớp sử dụng hệ thống phân loại, không chỉ với các doanh nghiệp và dịch vụ mà còn với tModels. • Bản xanh (Green pages): cung cấp các thông tin kỹ thuật mô tả các hành vi và chức năng của dịch vụ Web. Một bản ghi đặc biệt được cấu thành từ một tập các cài đặt UDDI có thể truy cập công cộng được được gọi là các nốt. Chúng chia sẻ dữ liệu và thành lập bản ghi doanh nghiệp UDDI. 3. Đặc tả UDDI: Các đặc tả UDDI: được cấu thành từ vài tài liệu khác nhau. Tài liệu đặc tả API mô tả các hàm API SOAP cho phép thực hiện các hoạt động tìm kiếm và quảng bá; xử lý lỗi, ngữ nghĩa của yêu cầu, kết quả; các thông tin thực tế về các quy ước và cách sử dụng cũng có sẵn. Các tài liệu bao gồm đặc tả cấu trúc dữ liệu và lược đồ API định nghĩa thông điệp và ngữ nghĩa của dữ liệu. Các hàm API của UDDI được chia thành hai nhóm: truy vấn và phát hành. Còn các API truy vấn chia thành ba mẫu truy vấn: • Các mẫu tìm kiếm thừa kế chức năng của toán tử tìm kiếm, cho phép duyệt các mục dữ liệu với những điều kiện khác nhau (hạng mục phân loại, các định danh, thông tin tên từng phần…) • Các mẫu tìm kiếm sâu: liên quan đến việc thu nhập thông tin chi tiết về một mục dữ liệu đã tìm thấy • Các mẫu tìm kiếm viện dẫn thông tin: là việc gọi các dịch vụ để sử dụng thông tin mẫu kèm theo thường được lưu tạm thời bởi các máy trạm để sử dụng lại mà không cần gửi lại bản ghi cho cùng một thông tin mà máy trạm cần. Nếu thông tin đính kèm thay đổi, máy trạm phải gửi lại bản ghi để cập nhật lại thông tin. 4. Một số đặc điểm của UDDI: Các cập nhật gắn với hỗ trợ nhằm giúp các tổ chức lớn mô hình hóa một cách hiệu quả các dịch vụ và công việc kinh doanh của họ. Khi các công ty muốn phân chia các lựa chọn web của họ theo vị trí địa lý, trình diễn chính các doanh nghiệp đó trên nền web một cách độc lập nhưng có liên quan đến nhau để dễ dàng quản lý, phát triển. 23 UDDI đưa ra nhiều phương pháp lựa chọn như: có thể duy trì các doanh nghiệp độc lập và không liên quan hoặc định nghĩa các mối quan hệ giữa các doanh nghiệp như mô hình cha con, đồng đẳng, và đồng nhất. Điều này tạo nên tính mềm dẻo để mô hình hóa một doanh nghiệp với nhiều chi nhánh, khách hàng bên ngoài, hoặc các quan hệ nội bộ khác nhau trong cùng công ty hoặc quan hệ giữa hai doanh nghiệp bất kỳ (được định nghĩa bởi các khóa duy nhất). Phân hạng mục của UDDI ngày mạnh hơn trong các phiên bản mới, góp phần cải tiến khả năng tìm kiếm thông tin. Phiên bản 1 đưa ra 3 cách phân loại: theo các hạng mục công nghiệp NAICS, hạng mục dịch vụ và dự án UNSPC, và phân loại địa lý ISO 3166-2. Các phân loại đều được kiểm tra bởi bản ghi UDDI; nếu cố gắng lưu trữ mã không hợp lệ sẽ bị từ chối. Phiên bản 2 bổ sung thêm khả năng định nghĩa cách phân hạng mục được kiểm tra nội tại, có thể đưa ra sử dụng công cộng trong UDDI. Khi các nhà cung cấp đồng ý cho sử dụng sẽ hỗ trợ một giá trị hợp lệ của dịch vụ web và làm cho nó có thể truy cập được đến bản ghi doanh nghiệp UDDI để hỗ trợ việc kiểm tra và xác nhận của các giá trị phân hạng mà các khách hàng mong muốn để liên kết với các bản ghi của họ. Điều này tạo nên tính mềm dẻo trong việc đảm bảo chỉ những giá trị phân hạng phù hợp được lưu trữ bởi khách hàng sử dụng cách phân hạng của họ. Các truy vấn cũng được cải tiến qua từng phiên bản để giải quyết các yêu cầu truy vấn phức tạp hơn. Ví dụ: cải tiến hàm truy vấn tìm kiếm bằng cách kết hợp thêm một số điều kiện lọc như: Bộ định tính combineCategoryBags cho phép gộp tất cả các dữ liệu phân loại được liên kết với một doanh nghiệp và tất cả các dịch vụ mà nó chứa (gồm cả các tham chiếu dịch vụ) vào một tập hợp đơn mà việc tìm kiếm sẽ thực hiện trên đó giúp giảm bớt các bước trong việc tìm kiếm một doanh nghiệp bằng cách rà soát trong các doanh nghiệp và các dịch vụ của chúng cùng lúc. Bộ lọc serviceSubset cho phép tìm kiếm các doanh nghiệp sử dụng điều kiện phân hạng mục. Chỉ kiểm trên các hạng mục được gắn kết với các dịch vụ của một công ty, còn các hạng mục gắn kết với bản thân doanh nghiệp không được gộp trong việc tìm kiếm. Bộ định tính orLikeKeys cho phép truy vấn phức tạp ảo. Tìm kiếm các doanh nghiệp mà được phân loại với các cấp độ khác nhau theo đặc trưng của chúng, trong khi cùng lúc cho phép một truy vấn đơn tham chiếu đến nhiều hạng mục khác nhau cùng lúc. 24 1.3.5. Ngôn ngữ mô tả dịch vụ web WSDL: 1. Giới thiệu về WSDL: WSDL (Web service Description Language) là một tài liệu XML mô tả những thông tin cần thiết để cho client hiểu biết về dịch vụ web. Các thông tin bao gồm: tên dịch vụ, giao thức truyền thông và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của dịch vụ Web, các thao tác, tham số, kiểu dữ liệu sử dụng trong truyền thông. Một tài liệu WSDL hợp lệ bao gồm hai thành phần được lưu trong hai tập tin XML, đó là tập tin giao diện dịch vụ và tập tin thi hành dịch vụ. Thành phần giao diện: đưa ra cách thức làm thế nào để giao tiếp với dịch vụ Web, giao thức liên kết, định dạng thông điệp để tương tác với dịch vụ Web, phương thức kết nối và giao thức truyền thông, địa chỉ dịch vụ web. Thành phần thi hành: mô tả các thông tin truy xuất CSDL. 2. Cấu trúc của một tài liệu WSDL: WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung cấp dịch vụ web qua Internet. Một client khi kết nối tới dịch vụ Web có thể đọc tài liệu WSDL để xác định những chức năng sẵn có trên server. Sau đó, client có thể sử dụng SOAP để lấy ra chức năng chính xác có trong WSDL. Một tài liệu WSDL được định nghĩa trong dịch vụ mạng bằng các thẻ sau: Types – mô tả các kiểu dữ liệu được trao đổi giữa client và server. * Trong đó, thẻ definitions chỉ rõ tên của tài liệu qua thuộc tính name, thuộc tính namespaces để phân biệt các thẻ và cho phép tài liệu wsdl có thể tham chiếu tới các đặc tả bên ngoài (WSDL, SOAP, XML Schema), thuộc tính targetNamespace là một quy tắc XML Schema cho phép tài liệu WSDL tham khảo tới chính nó. 25 <definitions name="StockQuote" targetNamespace="" xmlns:tns="" xmlns:xsd1="" xmlns:soap="" xmlns=""> Ví dụ: về thẻ Types: 26 Message: mô tả thông điệp được gửi giữa client và server. Nhiều thao tác có thể tham chiếu tới cùng một thông điệp. Thao tác và các thông điệp được mô tả riêng rẽ tạo nên sự linh hoạt và đơn giản hóa việc tái sử dụng lại. * * Ví dụ: về thẻ Message với hai dạng thông điệp yêu cầu và trả lời. Operation: mô tả một hoạt động của dịch vụ. Port Type: mô tả những hoạt động hỗ trợ bởi một hoặc nhiều thiết bị đầu cuối hay những hoạt động mà dịch vụ web cung cấp và những thông điệp liên quan. WSDL định nghĩa bốn kiểu thao tác mà một cổng có thể hỗ trợ. Kiểu one-way: cổng nhận một thông điệp, đó là thống điệp nhập. Kiểu request-response: cổng nhận một thông điệp, đó là thống điệp phản hồi. Kiểu solicit-response: cổng gửi một thông điệp và nhận về một thông điệp. Kiểu notification: cổng gửi một thông điệp, đó là thông điệp xuất. Mỗi kiểu thao tác có cú pháp biến đổi tùy theo: thứ tự của các thông điệp nhập, thông điệp xuất và thông điệp lỗi. 27 * Ví dụ: Thẻ Port Type: Binding: mô tả cách thức các dịch vụ web kết hợp với nhau. Một kết hợp gồm các nội dung: những giao thức mở rộng cho những giao tác và những message bao gồm thông tin URN và mã hóa cho SOAP; mỗi một kết hợp tham chiếu đến một loại cổng; một kiểu cổng (portType) có thể được sử dụng trong nhiều mối kết hợp. Tất cả các thao tác định nghĩa bên trong kiểu cổng phải nằm trong phạm vi mối kết hợp. 28 Ví dụ: Thẻ blinding <soap:binding transport="" style="rpc"/> <soap:operation soapAction=" orexml/SayHello"/> Port: một cổng đầu cuối, định nghĩa như một tập hợp của binding và một địa chỉ mạng Service: thực hiện những gì đã được định nghĩa trong tập tin giao diện và cách gọi web services theo thủ tục và phương thức nào: 29 Ví dụ: Thẻ Service: 3. Các bước xây dựng một Web Service: Có 4 giai đoạn chính để xây dựng một dịch vụ Web đó là: Giai đoạn xây dựng bao gồm: phát triển và chạy thử ứng dụng dịch vụ Web, xây dựng các chức năng và định nghĩa dịch vụ. Có hai phương pháp tiến hành: • Red- path-solod: xây dựng một dịch vụ Web mới từ trạng thái ban đầu hoặc với một dịch vụ đã có sẵn. Từ đó, xây dựng định nghĩa service (WSDL) với các đối tượng, hàm chức năng mà chúng ta mong muốn. • Blue-path-dashed: dịch vụ Web sẽ được xây dựng từ đầu hoặc từ một định nghĩa dịch vụ WSDL. Sử dụng WSDL này, xây dựng hoặc sửa đổi lại mã để thực hiện các yêu cầu mong muốn trong dịch vụ Web. Giai đoạn triển khai: mô tả định nghĩa dịch vụ, xây dựng WSDL và triển khai mã thực thi của dịch vụ Web phía server, sau đó sử dụng UDDI registry để công bố dịch vụ Web trên mạng Internet để các client có thể nhìn thấy. Giai đoạn tiến hành: tìm kiếm và gọi thực thi dịch vụ Web bởi những người dùng muốn sử dụng dịch vụ. Quản lý và quản trị dịch vụ: duy trì sự ổn định của dịch vụ, cập nhật thông tin mới, sửa lỗi xảy ra… Có 3 cách tiếp cận chủ yếu để xây dựng nên một dịch vụ Web: có thể từ một ứng dụng đã có (bottom-up); từ một định nghĩa dịch vụ, WSDL để phát sinh một ứng dụng mới (top-down) hoặc có thể từ một nhóm các dịch vụ Web hiện có, kết hợp lại với nhau để tạo nên các chức năng mới hoặc mở rộng thêm chức năng. 30 Hình 1.6 - Quy trình xây dựng một web service Hình 1.6 mô tả quy trình xây dựng một web service, gồm các bước sau: Bước 1: Định nghĩa và xây dựng các chức năng , các dịch vụ mà servive sẽ cung cấp Bước 2: Tạo WSDL cho service Bước 3: Xây dựng SOAP server cho service Bước 4: Đăng ký WSDL với UDDI registry để cho phép các client có thể tìm thấy và truy xuất Bước 5: Client nhận file WSDL và từ đó xây dựng SOAP client để có thể kết nối với SOAP server Bước 6: Xây dựng ứng dụng phía client và sau đó gọi thực hiện service thông qua việc kết nối tới SOAP server. 31 Chương 2. SỬ DỤNG WEB SERVICE VÀ VẤN ĐỀ AN TOÀN KHI SỬ DỤNG 2.1. Sử dụng Web Service: Web service mô tả cách thức chuẩn để tích hợp các ứng dụng dựa trên nền tảng web. Dịch vụ Web cho phép chạy các ứng dụng mà không yêu cầu bất cứ sự tương thích nào giữa hai hệ điều hành giữa hai máy tính và có thể xây dựng dựa trên việc kết hợp các mã nguồn mở và những công nghệ tiêu chuẩn sẵn có như XML, SOAP, WSDL, UDDI… Các tài liệu sau khi đóng gói đảm bảo các ứng dụng khác có thể dễ dàng nhìn thấy và truy cập đến những dịch vụ mà nó thực hiện và có thể yêu cầu thông tin từ các dịch vụ web khác. Như vậy các thông tin từ một Web Service có thể tái sử dụng dễ dàng bởi các trình ứng dụng khác nhau hoặc từ Web Service khác ngay cả khi không phải là ứng dụng web mà là những ứng dụng thông thường. Dịch vụ web kết hợp các máy tính cá nhân với các loại thiết bị khác nhau, các cơ sở dữ liệu và các mạng máy tính để tạo thành một mô hình tính toán ảo mà người sử dụng có thể làm việc thông qua các trình duyệt mạng. Các dịch vụ web sẽ chạy trên các máy phục vụ trên nền Internet nên có thể chuyển các chức nǎng từ máy tính cá nhân lên môi trường Internet. Vì thế người sử dụng có thể làm việc với các dịch vụ web thông qua bất kỳ loại thiết bị nào có hỗ trợ dịch vụ web và có khả năng truy cập Internet, kể cả các thiết bị cầm tay như các ứng dụng điện thoại di dộng của Smartphone, Packet PC... Dịch vụ web sẽ biến Internet thành một nơi làm việc chứ không phải chỉ là một thiết bị truyền tải nội dung đơn thuần. Các ứng dụng và cơ sở dữ liệu từ máy tính cá nhân được truyền tới các máy phục vụ của một nhà cung cấp dịch vụ web. Các máy phục vụ là một phần quan trọng của dịch vụ web, phải đảm bảo độ an toàn, độ riêng tư và khả nǎng truy nhập cho người sử dụng, hay các giao dịch giữa người sử dụng và các chương trình kinh doanh, các cơ sở dữ liệu quan trọng của một tổ chức nào đó… 32 Hình 2.1 - Mô tả 4 bước quá trình tham gia dịch vụ web Hình trên mô tả bốn bước mở rộng một quá trình tham gia dịch vụ web: Bước 1: Người yêu cầu và người cung cấp dịch vụ web phải biết về nhau, nghĩa là bên nào có hoạt động tương tác thì bên kia phải nhận thức được. Có hai trường hơp: Trường hợp điển hình, người yêu cầu sẽ là người khởi đầu, đánh thức dịch vụ cung cấp. Có hai cách để thực hiện điều này: các thực thể yêu cầu phải có được địa chỉ của các đại lý cung cấp dịch vụ thông qua các tổ chức cung cấp dịch vụ hoặc người yêu cầu có thể sử dụng các dịch vụ khám phá để tìm ra mô tả dịch vụ phù hợp (bao gồm các đường dẫn đến các đại lý cung cấp dịch vụ) thông qua việc mô tả các chức năng liên quan, phát hiện thủ công hoặc lựa chọn tự động. Trường hợp khác ít phổ biến hơn, bên đại lý cung cấp dịch vụ có thể trao đổi thông điệp với người yêu cầu. Trong trường hợp này, bên yêu cầu và bên cung cấp dịch vụ sẽ nhận biết được nhau. Các nhà cung cấp biết được địa chỉ của người yêu cầu dịch vụ bằng một số ứng dụng phụ thuộc như các bản đăng ký… Bước 2: Bên cung cấp và yêu cầu dịch vụ thống nhất về sự mô tả dịch vụ (tài liệu WSDL) và ngữ nghĩa để điều chỉnh tương tác giữa hai bên. Đó không nhất thiết là người yêu cầu và cung cấp dịch vụ phải giao tiếp hay thương lượng với nhau mà chỉ đơn giản là phải có cùng (hoặc tương thích) sự hiểu biết về mô tả dịch vụ và ngữ nghĩa và có ý định sẽ duy trì chúng, chẳng hạn như: 33 Người yêu cầu và bên cung cấp dịch vụ có thể giao tiếp trực tiếp với nhau, để thống nhất rõ ràng về mô tả dịch vụ và ngữ nghĩa. Bên cung cấp dịch vụ có thể công bố và cung cấp cả mô tả dịch vụ và ngữ nghĩa như một hợp đồng mà người yêu cầu buộc phải chấp nhận, không sửa chữa để được quyền sử dụng dịch vụ. Mô tả dịch vụ và ngữ nghĩa (trừ địa chỉ mạng của dịch vụ cụ thể) có thể được định nghĩa như là một tiêu chuẩn của một tổ chức công nghiệp. Trong trường hợp này, hành động của người yêu cầu và các tổ chức cung cấp dịch vụ phải thống nhất và phù hợp với các tiêu chuẩn được đưa ra. Hoăc một công ty lớn có thể yêu cầu hay đặt hàng với nhà cung cấp xây dựng một dịch vụ phù hợp với một mô tả dịch vụ và ngữ nghĩa. Tùy vào hoàn cảnh, diễn biến mà có thể thực hiện bước 2 trước bước 1. Bước 3: Thông tin mô tả dịch vụ và ngữ nghĩa là đầu vào hoặc biểu hiện bên trong của giao dịch giữa người yêu cầu và bên cung cấp dịch vụ. Có nhiều cách thực hiện và kiến trúc này không xác định hay quan tâm đến cái được sử dụng. Ví dụ như: một hệ thống đại lý có thể được mã hóa để thực hiên một mô tả dịch vụ, ngữ nghĩa cụ thể cố định; hoặc hệ thống đại lý có thể được mã hóa một cách tổng quát hơn, và đòi hỏi mô tả dịch vụ hoặc ngữ nghĩa có thể là đầu vảo tự động; hoặc một hệ thống đại lý được tạo ra trước, các mô tả dịch vụ hoặc ngữ nghĩa có thể tạo ra hoặc lấy từ các mã của đại lý. Bước 4: Bên yêu cầu và nhà cung cấp trao đổi thông điệp SOAP thay cho chủ sở hữu. Lưu ý đến sự đồng ý về mô tả thông tin và ngữ nghĩa, là sự thảo thuận, ràng buộc giữa hai bên cung cấp và yêu cầu (như ký hợp đồng) không như bước hai. Có hai lý do cần phải có sự đồng ý: người yêu cầu hoạt động theo quan điểm của đơn vị yêu cầu, trong khi người cung cấp lại thực hiên nó theo quan điểm của nhá cung cấp dịch vụ (ví dụ, đầu vảo của bên này là đầu ra cho bên khác) hoặc người yêu cầu và mô tả dịch vụ chỉ cần thực hiện những mô tả dịch vụ và ngữ nghĩa liên quan đến vài trò của mình. Tóm lại sự đồng ý chỉ đơn giản là một cái nhìn đồng nhất, không mâu thuẫn của mô tả dịch vụ và ngữ nghĩa của bên cung cấp và người yêu cầu dịch vụ. 2.2. An toàn Web Service: 2.2.1. Tại sao cần an toàn Web Service: Dịch vụ web ra đời đã mở ra hướng đi rất tích cực trong việc quản lý thông tin, kinh doanh và phục vụ đời sống, mang lại những lợi nhuận khổng lồ cho các doanh 34 nghiệp qua các hoạt động trên Internet và đưa ra phương pháp tiếp cận mới tốt hơn cho người sử dụng. Nhưng bên cạnh mặt tích cực của web service mang lại thì vẫn có những tồn tại những vấn đề khi áp dụng các dịch vụ này. Các mối đe dọa với các dịch vụ Web là sự đe dọa hệ thống máy chủ, ứng dụng và mạng lưới cơ sở hạ tầng. Một tổ chức phát triển một dịch vụ web, câu hỏi đầu tiên người dùng thường đặt ra là làm sao để chứng thực được dịch vụ web đó. Ví dụ như một khách hàng muốn kiểm tra số tiền trong tài khoản ngân hàng của mình qua một thiết bị điện tử thì họ phải cung cấp các thông tin đề nhận dạng tài khoản như tên, mật khẩu… Sau khi khách hàng đã nhập các thông tin cần thiết thì các thông tin đó sẽ được đóng gói và gửi đi đến máy chủ để xác nhận và trả về kết quả dịch vụ mà người dùng yêu cầu. Nhưng nếu trong quá trình truyền thông đó, thông điệp gửi đi bị chặn, bị sửa đổi hay rơi vào tay người khác thì khách hàng sẽ là người chịu thiệt thòi khi mà có thể tài khoản sẽ ăn cắp hoặc bị sử dụng trái phép… Trong hoạt động kinh doanh trên mạng hay các trao đổi thông tin, tài chính tiền tệ… sử dụng dịch vụ web nếu có sự sai sót trong truyền thông hoặc bảo vệ dữ liệu thì sẽ những không chỉ khách hàng mà cả nhà cung cấp dịch vụ sẽ phải chịu thiệt thòi. Chính vì thế các nhà cung cấp phải đáp ứng được nhu cầu an toàn đề người sử dụng tin tưởng sử dụng dịch vụ và tránh được những thiệt hại cho chính người cung cấp. Vì thế một loạt các cơ chế bảo mật được sử dụng để giải quyết vấn đề liên quan đến chứng thực, kiểm soát truy cập dựa trên vai trò, phân phối thực thi chính sách an ninh, tin nhắn lớp bảo mật thích ứng với sự hiện diện của các lớp trung gian. Có hai hình thức bảo mật chính, đó là bảo đảm an ninh ở mức chuyển tải và mức thông điệp: Thứ nhất là hình thức bảo đảm an ninh ở mức chuyển tải. Bằng cách sử dụng cơ chế an ninh điểm nối điểm (point to point), dùng trong nhận dạng và xác thực, bảo đảm tính tòan vẹn và bảo mật của thông điệp. HTTP là giao thức không an tòan, dữ liệu truyền đi ở dạng Text nên dễ bị lộ. Thay bằng giao thức HTTPs mà các thông điệp đều đã được mã hóa. Kỹ thuật HTTPS cho phép xác thực máy chủ, máy chủ phải xuất trình chứng thực cho trình khách để trình khách nhận dạng máy chủ, còn máy chủ không thể chứng thực được trình khách. Trên thực tế người ta thường dùng xác thực cơ sở HTTP kết hợp với HTTPS. Thứ hai là hình thức bảo đảm an ninh ở mức thông điệp, liên quan tới an ninh của thông điệp trong gói SOAP. Bảo đảm an ninh ở mức thông điệp đòi hỏi sự bảo vệ bằng tên người dùng, mật mã XML và chữ ký số. 35 Bảo mật dịch vụ Web (WS-Security) cung cấp an ninh ở mức thông điệp. Hai phương pháp này thường được sử dụng kết hợp với nhau. Có ba khái niệm cơ bản liên quan đến vấn đề an ninh: nguồn tài nguyên cần được bảo mật, cơ chế bảo mật và chính sách, là các tài liệu mô tả sự ràng buộc của các tài nguyên. Các chính sách được chia làm hai loại: chính sách bắt buộc và chính sách cho phép (quyền hạn). Chính sách cho phép liên quan tới các hoạt động, truy cập mà các bên được phép thực hiện, còn chính sách bắt buộc yêu cầu hành động mang tính nghĩa vụ mà các bên cần phải thực hiện. Một tài liệu có thể bao gồm cả hai loại chính sách trên, chúng liên quan chặt chẽ và phụ thuộc vào nhau nhưng không nhất quán và có cơ chế thực thi khác nhau. Chính sách cho phép có thể dùng khi xác minh hành động được yêu cầu hoặc truy cập được chấp nhận nhưng chính sách yêu cầu chỉ có thể xác minh khi một nghĩa vụ không được thực hiện. Ví dụ một mối đe dọa truy cập trái phép có thể được phát hiện bằng một cơ chế xác nhận danh tính của các đại lý khi người dùng muốn truy cập vào các nguồn tài nguyên kiểm soát và có thể vô hiệu hóa quyền truy cập. Một vai trò quan trọng của các đối tượng trung gian SOAP là có thể chuyển tiếp một thông điệp đi khi một chính sách an toàn bị vi phạm. Bảo mật thông tin khuyến khích mã hóa các thông điệp, không chỉ mã hóa thông điệp SOAP mà còn phải người gửi và nhận thông điệp. Các phương pháp bảo mật truyền thống như Transport Layer Security (SSL / TLS), Mạng riêng ảo (VPN), IPSec (Internet Protocol Security) và Secure Multipurpose Internet Mail Exchange (S / MIME) là công nghệ point-to-point nhưng chúng không đủ để bảo mật cho end-to-end, các dịch vụ web yêu cầu độ bảo mật cao hơn. Các dịch vụ Web sử dụng cách tiếp cận dựa trên thông điệp, cho phép các tương tác phức tạp. Một thông điệp có thể đi qua nhiều trung gian khác nhau trước khi đến đích nên mức độ bảo mật là quan trọng, trái ngược với point-to-point, cấp vận tải, an ninh. Hình 2.2 - Sơ đồ vận chuyển trung gian trong bảo mật End-to-End 36 Có nhiều cách để đe dọa an ninh của một dịch vụ web. Thông điệp thay đổi: các mối đe dọa ảnh hưởng đến tính toàn vẹn của thông điệp, có thể bị sửa đổi một phần (hoặc toàn bộ). Tính bảo mật: các tổ chức trái phép có được quyền truy cập vào thông tin có trong một tin nhắn hoặc các bộ phận tin nhắn, chẳng hạn như: một trung gian có được quyền truy cập vào thông tin thẻ tín dụng dành cho người nhận cuối cùng. Người trung gian: kẻ tấn công để thỏa hiệp với một trung gian SOAP và chặn các tin nhắn giữa người yêu cầu dịch vụ web và người nhận cuối mà hai bên vẫn nghĩ rằng họ đang giao tiếp với nhau, các kỹ thuật xác thực có thể làm giảm mối đe dọa khi kẻ tấn công muốn truy cập hay sửa chữa thông điệp. Spoofing (giả mạo): một cuộc tấn công phức tạp để khai thác các mối quan hệ dựa trên sự tin tưởng bằng cách giả danh một thực thể đáng tin cậy để phá hoại an ninh của các thực thể mục tiêu, thường là các tin nhắn giả mạo, cần phải có các kỹ thuật xác thực mạnh để ngăn chặn. Từ chối dịch vụ (DoS): ngăn chặn người sử dụng hợp pháp truy cập đến dịch vụ, cách này có thể gây ra thiệt hại đáng kể khi các đại lý bị gián đoạn hoạt động, bị ngắt kết nối với phần còn lại của thế giới. DoS dễ dàng thực hiện, khai thác điểm yếu trong kiến trúc của hệ thống bị tấn công, sử dụng các nguồn lực của nhiều hơn một máy tính để khởi động đồng bộ các cuộc tấn công DoS vào một tài nguyên và có thể khai thác từ các cơ chế bảo mật khác. Tấn công replay: chặn tin nhắn và sau đó replay lại cho đại lý mục tiêu, cần các kỹ thuật chứng thực thích hợp như đóng dấu thời gian và đánh số thứ tự các tin nhắn. An ninh cho dịch vụ web phải tạo ra một môi trường an toàn để hai bên yêu cầu và cung cấp dịch vụ có thế giao dịch với nhau và nội dung thông điệp được bảo toàn trong quá trình truyền tải bằng cách sử dụng nhiều cơ chế bảo mật. Cơ chế xác thực: dùng để xác minh của người yêu cầu và đại lý cung cấp dịch vụ hoặc uỷ quyền sử dụng chứng thực lẫn nhau. Một số phương pháp có thể được dùng trong cơ chế xác thực như: mật khẩu, thông qua một thời gian và chứng chỉ. Mật khẩu chứng thực phải là mật khẩu mạnh và nên kết hợp với các xác thực khác. Các giấy chứng nhận có thể là: Lightweight Directory Access Protocol (LDAP), Remote Authentication Dial-in User Service (RADIUS), Kerberos, Public Key Infrastructure (PKI). Cơ chế ủy quyền: sau khi xác thực, cơ chế ủy quyền kiểm soát các truy cập đến tài nguyên hệ thống , xác định quyền truy cập của người yêu cầu. Cơ chế toàn vẹn và bảo mật dữ liệu: đảm bảo rằng thông tin không bị thay đổi trong quá trình truyền mà không bị phát hiện, bằng cách sử dụng mã hóa dữ liệu và chữ ký số. Cơ chế toàn vẹn giao dịch và truyền thông: dùng để đảm bảo rằng quá trình nghiệp vụ đã được thực hiện đúng và các luồng giao tác được thực hiện chính xác. Cơ chế chống thoái thác là dịch vụ an ninh bảo vệ một bên trong một giao dịch chống lại sự từ chối sai về sự xuất hiện của giao dịch đó bởi 37 một bên còn lại, bằng cách sử dụng công nghệ cung cấp bằng chứng về sự xuất hiện của các giao dịch có thể được sử dụng bởi một bên thứ ba để giải quyết bất đồng. Cơ chế toàn vẹn end-to-end và bí mật của thông điệp: phải đảm bảo ngay cả khi có sự hiện diện của các trung gian. Cơ chế vết kiểm toán: dùng để theo hành vi của người dùng và bảo đảm tính toàn vẹn hệ thống thông qua xác minh, trong đó các đại lý đóng vai trò của một kiểm toán viên; phương pháp này thường không thể ngăn chặn các hành vi vi phạm nghĩa vụ nhưng nếu một kiểm toán phát hiện vi phạm chính sách, một số hình thức xử phải sẽ được sử dụng. Cơ chế bắt buộc phân phối chính sách an ninh: người thực hiện phải xác định một chính sách an ninh và thực thi nó trên nền tảng khác nhau với các đặc quyền khác nhau. 2.2.2. An toàn Web Service: 1. WS-Security: WS-Security là một chuẩn dùng để bảo mật cho dịch vụ Web. Mục tiêu của nó là đảm bảo an toàn cho ứng dụng trao đổi thông điệp bằng giao thức SOAP bằng cách cung cấp mật mã, hỗ trợ tính toàn vẹn, tính xác thực và tin cậy của thông điệp. Nó đư- ợc thiết kế dạng chuẩn mở nhằm hướng tới những mô hình an toàn khác bao gồm PKI, Kerberos, và SSL. WS-Security mô tả ba cơ chế chính, bao gồm: làm thế nào để ký thông điệp SOAP để đảm bảo tính toàn vẹn và đăng ký cung cấp các tin nhắn chống thoái thác; làm thế nào để mã hóa các thông điệp SOAP để đảm bảo bí mật; làm thế nào để đính kèm thẻ bảo mật. Các cơ chế này cho phép một loạt các khuôn dạng chữ ký, các cơ chế an toàn, các thuật toán mã hóa và các tên miền tin cậy, và mở ra các mô hình bảo mật thông báo: • Vé Kerberos: giao thức mật mã, dùng để xác thực trong các mạng máy tính hoạt động trên những đường truyền không an toàn • Chứng nhận UserID/Password • Các tùy chỉnh xác nhận thông báo. • Chứng thực theo chuẩn X.509 gồm các nội dung: số phiên bản, số serial, ID chữ ký, tên công bố, thời điểm có hiệu lực, định nghĩa chủ đề, phần mở rộng và chữ ký trên các trường trên. • SAML (Security Assertion Markup Language): một giao thức chuẩn dùng trong xác nhận và cấp phép sử dụng tài nguyên. 38 WS-Security tích hợp tính năng bảo mật trong phần header của một thông điệp SOAP, làm việc tại lớp ứng dụng. Các cơ chế không cung cấp một giải pháp an ninh hoàn toàn cho các dịch vụ Web. WS Security không cung cấp bất kỳ đảm bảo an ninh nào mà đó là một khối xây dựng có thể sử dụng để liên kết với phần mở rộng dịch vụ Web khác và giao thức ứng dụng cụ thể cấp cao hơn để chứa nhiều loại mô hình an ninh và công nghệ bảo mật. Tuy vậy vẫn còn rất nhiều yêu cầu an toàn khác của web service mà WS security chỉ là một lớp trong nhiều lớp của một giải pháp an toàn web service. 2. Chứng thực trong một ứng dụng: Cung cấp một giao diện thân thiện để người dùng dễ dàng định nghĩa chứng thực cho một ứng dụng web service. Trong một ứng dụng cụ thể, chứng thực cần thực hiện những công việc sau: Phía client: • Client cần cung cấp một dấu hiệu an toàn trong tập tin mô tả của client. Ví dụ: cung cấp username và password trong một SOAP message tới server. • Client cần chỉ rõ một callbackhandler trong tập tin mô tả của client. Một callback hander là một tập tin lớp trong đường dẫn của client dùng để lấy username và mật khẩu từ bộ mô tả triển khai và chèn chúng vào trong SOAP message. Phía server: • Để cấu hình server an toàn cần có một dấu hiệu an toàn hợp lệ. Nếu không có dấu hiệu an toàn, yêu cầu sẽ thất bại. • Server cần chỉ rõ một callbackhandler để đọc dấu hiệu an toàn trong yêu cầu và sau đó xác nhận nó. 39 Ví dụ 1: SOAP message không được bảo mật (không có username và password) <soapenv:Envelope xmlns:soapenc="" xmlns:soapenv="" xmlns:xsd="" xmlns:xsi=""> <soapenv:Body soapenc:encodingStyle=""> 2003-09- 05T07:00:00.000Z Ví dụ 2: SOAP message được bảo mật (có chứng thực username và password) <soapenv:Envelope xmlns:soapenc="" xmlns:soapenv="" xmlns:xsd="" xmlns:xsi=""> <wsse:Security xmlns:wsse="" soapenv:mustUnderstand="1"> stade2 PassWordHere 40 <soapenv:Body soapenc:encodingStyle=""> 2005-09- 05T07:00:00.000Z Ví dụ 3: SOAP message được bảo vệ toàn vẹn thông qua việc mã hóa <wsse:Security xmlns:wsse="" soapenv:mustUnderstand="1"> G+p3CZiiT/yYmkzORKt2m4KSEybc+dYEBUqbPUxA+L5epHSsy5FuxCW2XCJf ner5nov80OJdadyHCf0qfLI2Wzrx09JL0k4t+BtzgSY2B1tTIdgO770NcIIf Uq3uD9mAdVGuwKFqIofG0Kuh78ae1OjQk+Ty37FJqpVQCwxeSj0= <wsse:Reference 41 URI="#wssecurity_binary_security_token_id_3202627907101346821"> 3. Các bước để tạo an toàn thông tin trong ứng dụng: Để một ứng dụng được an toàn và tin cậy, client và server phải có tính toàn vẹn thông tin, nghĩa là phải bảo đảm rằng không ai có thể sửa đổi thông điệp trong khi nó đang được chuyển. Thực chất đó là việc tạo ra một chữ ký số hóa XML dựa vào nội dung của thông điệp. Nếu dữ liệu thông điệp bị thay đổi bất hợp pháp, nó sẽ không còn thích hợp với chữ ký số hóa XML. Một chữ ký được tạo ra dựa vào một khóa mà ngư- ời gửi thông điệp tạo ra. Người nhận chỉ nhận được thông điệp khi chữ ký và nội dung phù hợp. Nếu không phù hợp thì một thông báo lỗi sẽ trả về người gửi và yêu cầu gửi lại. Phía client: • Chỉ rõ những thành phần của message mà phải có chữ ký hay một dấu hiệu chứng thục nào đó. Những thành phần trong message có thể có chữ ký là phần thân. • Chỉ rõ một khóa trên hệ thống tập tin mà sẽ ký lên message. Chỉ những client đã được cấp quyền mới có quyền sở hữu khóa này. • Chỉ rõ những giải thuật sẽ được sử dụng bởi khóa để ký lên message. • Nếu một client chờ đợi một sự phản hồi từ server với thông tin cũng yêu cầu phải toàn vẹn, thì client phải được cấu hình để làm cho có hiệu lực tính toàn vẹn của message phản hồi. Phía server: 42 • Chỉ rõ những thành phần của message cần được ký. Nếu message đến không có một chữ ký hợp lệ, thì yêu cầu sẽ thất bại. • Chỉ rõ một khóa để duyệt chữ ký của message đến có hợp lệ hay không. • Chỉ rõ giải thuật mà khóa sử dụng làm cho có hiệu lực tínhš toàn vẹn của message gửi đến. • Nếu có message phản hồi lại thì message đó cũng phải được ký, và cung cấp thông tin chữ ký trong message phản hồi. 4. Những thành phần mở rộng của ws-security: Do WS-security chỉ là một lớp trong nhiều lớp của một giải pháp an toàn web service đầy đủ, nên cần một mô hình an toàn chung lớn hơn để có thể bao phủ tất cả các khía cạnh an toàn khác như đăng ký và không từ chối. Hình 2.3 - Mô hình an toàn đẩy đủ cho Web service Trong mô hình này các thành phần quan trọng bao gồm: • WS-SecureConversation Describes: quản lý và xác nhận thông điệp trao đổi giữa các phần bao gồm: ngữ cảnh an toàn, thiết lập, dẫn xuất ra các phiên làm việc. • WS-Authentication Describes: quản lý những dữ liệu cần chứng thực và chính sách chứng thực. • WS-Policy Describes: quản lý những ràng buộc của những chính sách an toàn ở các điểm trung gian và đầu cuối. • WS-Trust Describes: khung cho phép những web service an toàn trao đổi , tương tác với nhau. 43 Chương 3. XÂY DỰNG ỨNG DỤNG ĐĂNG KÝ THUẾ THU NHẬP CÁ NHÂN 3.1. Giới thiệu bài toán: Bài toán: Mỗi người công dân khi đi làm việc đều có nghĩa vụ phải đóng thuế thu nhập cá nhân cho các tổ chức thuế. Việc đăng ký thuế lấy mã số thuế cá nhân của người lao động do các tổ chức, đơn vị chủ quản tiến hành. Ứng dụng đăng ký thuế hỗ trợ cho các doanh nghiệp, tổ chức đăng ký thuế thu nhập cá nhân một cách đơn giản,nhanh chóng và chính xác. Yêu cầu của hệ thống: Xác thực người dùng đăng nhập vào hệ thống. Nếu người dùng đăng nhập thành công thì cho phép sử dụng các chức năng của hệ thống theo đúng quyền hạn người dùng. Các thông tin về tài khoản được lưu trong biến session. Khi người dùng thoát ra khỏi hệ thống thì phải xóa hết những thông tin bảo mật như: đăng nhập và mật khẩu. Có hai loại người dùng: Administrator dành cho các cơ quan thuế và User dành cho các các tổ chức muốn kê khai đăng ký thuế thu nhập cá nhân. Mỗi cơ quan, doanh nghiệp có một mã số thuế riêng, họ được cấp một tài khoản để sử dụng các chức năng của ứng dụng hoặc đăng ký một tài khoản và sau khi được cơ quan thuế xác nhận thì có thể đăng nhập xem thông tin va sử dụng các chức năng. Sau khi đăng nhập, Administrator có thể xem các thông tin của mình và có thể cập nhật lại thông tin đã cũ, không còn phù hợp. Có chức năng xem các thông tin về các cơ quan thuế trên địa bàn quản lý của mình bao gồm: thông tin của đơn vị đăng ký thuế, các hồ sơ của các nhân viên đã được đăng ký thuế hoặc đang chờ đăng ký thuế của mỗi đơn vị. Cơ quan thuế sẽ xem xét, xác nhận tính chính xác các thông tin nhận được, nếu có sai sót có thể xóa thông tin nhân viên đăng ký khỏi cơ sở dữ liệu và báo cho đơn vị được biết để gửi lại thông tin mới. User đã được cơ quan thuế xác nhận có thể xem thông tin về đơn vị của mình, bao gồm: thông tin của đơn vị, thông tin của nhân viên đã được đăng ký thuế hoặc đang chờ đăng ký thuế. Nếu nhân viên nào chưa được cơ quan thuế đánh dấu xử lý thì User có quyền cập nhật lại. Gửi các thông tin đăng ký thuế mới cho cơ quan thuế xem xét. Các user chưa được cơ quan thuế xác nhận sẽ không được cung cấp nội dung 44 3.2. Thiết kế hệ thống: 3.2.1. Sơ đồ phân rã chức năng: Hệ thống ứng dụng thuế cung cấp các chức năng chính sau: • Chức năng đăng nhập: xác thực người dùng đã được cấp tài khoản và quyền hạn người dùng để sử dụng các thông tin của hệ thống. • Chức năng thông tin người dùng: hiển thị các thông tin về người dùng và sửa các thông tin. • Chức năng quản lý: xem thông tin cần quản lý, cập nhật lại thông tin, gửi các thông tin mới • Chức năng đăng xuất: người dúng thoát khỏi hệ thống, các thông tin của người dùng được xóa khỏi biến session. Hình 3.1 - Sơ đồ phân rã chức năng 3.2.2. Thiết kế cơ sở dữ liệu: Hệ thống sẽ sử dụng ứng dụng login control trong Visual Studio 2008, xây dựng trên cơ sở dữ liệu: ASPNETDB gồm các bảng chứa các thông tin đăng nhập của người dùng để thực hiên việc truy cập vào ứng dụng Web. Ngoài các bảng mặc định trong cơ sở dữ liệu ASPNETDB, bao gồm: Tạo thêm các bảng sau: 45 - Bảng aspnet_info_donvi: lưu các thông tin thực tế của tổ chức đã có tài khoản gồm: mã số thuế của tổ chức, địa chỉ, số điện thoại, tên đơn vị, cơ quan quản lý thuế của đơn vị, ngày đăng ký, tên người dùng dạng int. Tên trường Kiểu dữ liệu Ràng buộc UserId uniqueidentifier Khóa ngoài Mst_Donvi nvarchar(14) Khóa chính Address_Donvi nvarchar(255) Không rỗng Phone_Donvi int Name_Donvi nvarchar(255) Không rỗng Cqt_Quanly nvarchar(50) Không rỗng city nvarchar(50) Không rỗng - Bảng aspnet_info_nv: lưu các thông tin của nhân viên: tên, năm sinh, giới tính, địa chỉ hộ khẩu, địa chỉ cư trú, số chứng minh thư nhân dân, nơi cấp CMT, thời gian cấp CMT. Email, số điện thoại, mã số thuế thu nhập cá nhân, mã số thuế đơn vị trực tiếp. Tên trường Kiểu dữ liệu Ràng buộc name nvarchar(256) Không rỗng brith datetime Không rỗng gender nvarchar(50) Không rỗng address1 nvarchar(256) Không rỗng address2 nvarchar(256) Không rỗng mst_donvi nvarchar(14) Khóa ngoài cmt bigint Khóa chính date_cmt datetime Không rỗng address_cmt nvarchar(256) Không rỗng 46 email nvarchar(256) phone nvarchar(16) mst_tncn nvarchar(14) check Int Sơ đồ quan hệ các bảng: Hình 3.2 - Sơ đồ quan hệ các bảng 3.2.3. Hoạt động chương trình: 1. Cài đặt hệ thống: Sử dụng bộ ngôn ngữ lập trình Visual Studio 2008 của Microsoft. Ngôn ngữ lập trình: asp và visual basic 47 2. Hoạt động: - Quản lý người dùng trực tuyến, tạo người dùng mới và cung cấp cho các đơn vị một tài khoản để truy cập ứng dụng - Trang chủ ứng dụng: - Phương thức đăng nhập: LogIn, cho phép nhập các thông tin tài khoản, bao gồm: username và password để đăng nhập vào hệ thống. Phương thức trên sẽ trả về một trang thông báo kết quả đăng nhập. Nếu thông tin đăng nhập đúng và chưa có ai đang đăng nhập trên cùng thiết bị thì sẽ có thông báo trả lại là: “Bạn đã đăng nhập với tên: (Username)”. Nếu thông tin đăng nhập sai hoặc đăng nhập bằng tài khoản khác khi chưa thoát tài khoản cũ thì sẽ có thông báo trả lại là: “Bạn đã nhập sau username hoặc password” 48 - Phương thức đăng xuất: LogOut: dùng để đăng xuất khỏi hệ thống. Nếu đang sử dụng một tài khoản nào đấy thì kết quả của phương thức Logout là thông báo “Bạn đã đăng xuát khỏi hệ thống”. Nếu chưa hiện tại không ở trạng thái đăng nhập thì sẽ trả về một trang thông báo khác. 49 - Phương thức online_hay_offline: để biết trạng thái hiện tại là online hay offline, xem có ai đang đăng nhập hệ thống trên thiết bị này không. Kết quả tương ứng trả về là True hoặc False. - Phương thức thongtin_nguoidung: cho biết tên tài khoản đang đăng nhập và loại tài khoản là Admintrator hay User. - Phương thức: thongtin_donvi_dangnhap: cho biết các thông tin về người dùng đang đăng nhập như: tên đơn vị, địa chỉ, điện thoại, mã số thuế, doanh nghiệp, email, cơ quan quản lý. 50 Các phương thức dành cho người dùng có quyền Administrator, đây là loại tài khoản dành cho các cơ quan quản lý thuế, thông tin được quản lý là các thông tin của các đơn vị có nhiệm vụ phải đóng thuế trên địa bàn mà cơ quan thuế này quản lý. Cơ quan thuế sẽ xem danh sách các đơn vị trên địa bàn mình quản lý, nếu đơn vị nào có nhân viên cần đăng ký thuế thì cơ quan thuế sẽ xem thông tin mà đơn vị cung cấp, sau đó xác thực xem thông tin đó đúng hay sai. Sau khi xác thực thông tin là đúng và đủ điều kiện cấp mã số thuế thì cơ quan thuế sẽ cập nhập mã số thuế cho nhân viên đó hoặc nếu thông tin không chính xác thì sẽ xóa nhân viên khỏi danh sách đăng ký thuế thu nhập cá nhân. Nếu các tài khoản không có quyền Administrator sử dụng các phương thức này thì kết quả trả về là một thông báo: “Bạn không có quyền truy cập chức năng này”: - Phương thức: admin_xem_thongtin_cac_donvi:xem thông tin của các đơn vị thuộc sự quản lý của chủ tài khoản, gồm các thông tin như: mã số thuế đơn vị, tên đơn vi, địa chỉ, điện thoại, mail - Phương thức: admin_xem_chitiet_nhanvien_cua_mot_donvi: xem danh sách và thông tin các nhân viên của nhân viên thuộc một đơn vị nào đó bằng cách nhập mã 51 số thuế của đơn vị (mst_donvi), thông tin có thể xem bằng phương thức admin_xem_thongtin_cac_donvi. Nếu chỉ muốn xem danh sách các nhân viên chưa đăng ký thuế thì nhập số 0 vào ô mst_tncn. - Phương thức: admin_tim_nhanvien_theo_cmt: khi cơ quan thuế xem xét một hồ sơ đăng ký mã số thuế nào đó thì sẽ so sánh nó với một số thông tin từ nguồn khác để xác thực xem thông tin đơn vị đăng ký có trùng khớp không. Khi đó để tìm hồ sơ đăng ký đó thì họ sẽ nhập số chứng mình thư trong hồ sơ xác thực vào ô cmt. Nếu trong cơ sở dữ liệu đã có thông tin đăng ký của số chứng mình thư này thì kết quả trả về là thông tin của người có số chứng minh thư trùng khớp, nếu sai thì trả về kết quả lỗi. - Phương thức: admin_xoa_nhanvien_theo_cmt: xóa thông tin đăng ký nào không khớp với hồ sơ xác thực, chỉ đúng với hồ sơ chưa có mã số thuế cá nhân. Thực hiện bằng cách nhập số chứng minh thư vào ô cmt. Nếu có số chứng minh thư đó trong cơ sớ dữ liệu và chưa cấp mã số thuế cá nhân thì trả về thông bào: “Bạn đã xóa thông 52 tin về số chứng minh thư: (cmt)”. Nếu số chứng minh thư chưa có trong cơ sở dữ liệu hoặc chưa nhập thông tin vào ô cmt hoặc số chứng mình thư nhập sai thì trả về thông báo: “Số chứng minh thư không tồn tại hoặc đã có mã số thuế”. - Phương thức: admin_cap_masothue:cập nhật mã số thuế cho một nhân viên đăng ký mà chưa có mã số thuế. Bằng cách nhập số chứng minh thư của nhân viên vào ô và nhập mã số thuế vào ô mst_tncn. Cập nhật mã thành công sẽ trả về thông báo: “Bạn đã nhập thành công mã số thuế của nhân viên có số chứng minh thư: (cmt), với mã số thuế là: (mst_tncn)”. Nếu nhân viên này đã có mã số thuế từ trước thì sẽ có thông báo:”Bạn đã đổi mã số thuế thu nhập cá nhân của nhân viên có số chứng minh thư: (cmt). Mã số thuế cũ là: (mst_tncn_cu) và mã số thuế mới là (mst_tncn)”. Nếu mã số thuế này đã tồn tại thì trả về thông báo: “Mã số thuế này đã có trong cơ sở dữ liệu”. 53 Các phương thức sau chỉ dành cho người dùng loại User, tức là các đơn vị hoạt động có nghĩa vụ nộp thuế sẽ đăng ký thuế cho nhân viên. Khi cần xem các thông tin thuế của nhân viên hoặc cập nhật hay xóa lại dữ liệu thuế sai, hoặc thêm một đăng ký mới cho nhân viên. Nếu người dùng không có quyền này khi sử dụng các phương thức sẽ nhận được thông báo “Bạn không có quyền truy cập chức năng này”: - Phương thức: donvi_xem_danhsach_nhanvien: xem danh sách và thông tin thuế của các nhân viên. Nếu muốn xem các nhân viên chưa có mã số thuế thu nhập cá nhân thì nhập số 0 vào ô mst_tncn. Nếu chỉ xem thông tin nhân viên đã có mã số thuế thu nhập cá nhân thì nhập số 1. Nếu xem tất cả nhân viên thì không cần quan tâm đến ô này. - Phương thức: donvi_tinhtrang_nhanvien: xem số lượng nhân viên đã có mã số thuế thu nhập cá nhận và chưa có mã số thuế thu nhập cá nhân của đơn vị. - Phương thức: donvi_capnhat_thongtin_nhanvien: khi xem xét một hồ sơ thuế đang chờ cấp mã số thuế mà có thông tin sai (name, address1, address2, gender, address_cmt, email, phone) thì có thể cập nhật lại thông tin bị sai đó bằng cách nhập: 54 số chứng mình thư của nhân viên cần sửa thông tin vào ô cmt, nhập trường thông tin cần sửa vào ô truong_sua, và nhập thông tin mới cần chèn vào ô noi_dung_moi. Nếu các thông tin chính xác thì trả về thông báo: “Bạn đã cập nhật thành công cho nhân viên có số chứng minh thư: (cmt), trường sửa là: (truong_sua), nội dung mới là: (noi_dung_moi), nội dung cũ là: (noi_dung_cu)”. Nếu bạn nhập thiếu hoặc sai trường nào đó hoặc số chứng minh thư không tồn tại thì chương trình sẽ trả lại kết quả: “Bạn chưa đủ hoặc nhập sai thông tin”. Nếu không muốn cập nhật hoặc nhân viên đó đã chuyển đi mà chưa có mã só thuế thì có thể sử dụng phương thức khác để xóa thông tin nhân viên khỏi cơ sở dữ liệu. Sau đó có thể thêm thông tin mới. - Phương thức: donvi_xoa_thongtin_nhanvien: dùng để xóa thông tin của một nhân viên chưa có mã số thuế cá nhân. Bằng cách nhập số chứng minh thư của nhân viên đó vào ô cmt. Nếu thông tin nhập đúng thì kết quả trả về là: “Bạn đã xóa thành công nhân viên có số chứng minh thư: (cmt)”. Nếu không có nhân viên nào có số chứng minh thư mà chưa có mã số thuế hoặc không tồn tại trong cơ sở dữ liệu của đơn vị bàn thì trả về thông báo“Bạn đã nhập sai thông tin”. 55 - Phương thức: donvi_chuyen_nhanvien: dùng khi một nhân viên nào đó chuyển đi khỏi đơn vị đó thì sẽ gửi thông tin cập nhật lại trạng thái. - Phương thức: donvi_dangky_nhanvien: dùng để thêm thông tin về một nhân viên chưa có mã số thuế thu nhập cá nhân vào cơ sở dữ liệu. Nếu các thông tin nhập vào các ô nhập liệu đúng quy cách thì kết quả tra về là thông báo ”Bạn đã thêm thành công thông tin đăng ký thuế của nhân viên có số chứng minh thư: (cmt)”. Nếu số chứng mình thư đã có trong cơ sở dữ liệu thì sẽ có thông báo: “Số chứng minh thư (cmt) đã có trong cơ sở dữ liệu” .Nếu thông tin nhập vào chưa đúng thì sẽ có thông báo: “Bạn chưa đủ hoặc đúng thông tin” 56 TÀI LIỆU THAM KHẢO [1] Web Services Architecture “” [2] Phạm Quang Hòa - Bảo mật trong ASP.NET Web Service “ trong-aspnet-web-service/” [3] XÂY DỰNG SEARCH ENGINE TÍCH HỢP WEB SERVICE CỦA GOOGLE %E1%BB%A8ng-d%E1%BB%A5ng-x%C3%A2y-d%E1%BB%B1ng-search-engine- t%C3%ADch-h%E1%BB%A3p-web-service-c%E1%BB%A7a-Google [4] Dịch vụ Web (Web service) [5] Tim hieu ngon ngu XML - Share-Book.com [6] Prentice Hall PTR. web services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More, Chapter 8. Universal Description, Discovery, and Integration (UDDI). [7] Wikipedia. Web service. “” [8] W3School. “”. [9] Web Services Architecture. “”