TÌM HIỂU VỀ WEB SERVICE VÀ XÂY DỰNG ỨNG DỤNG TRÊN ĐIỆN THOẠI DI ĐỘNG
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.64 MB, 84 trang )
<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">
<b><small>TRƯỜNG ĐẠI HỌC QUẢNG NAM KHOA CƠNG NGHỆ THƠNG TIN </small></b>
<small>------ </small>
<b>NGUYỄN QUANG SÁCH </b>
<b>TÌM HIỂU VỀ WEB SERVICE VÀ XÂY DỰNG ỨNG DỤNG TRÊN ĐIỆN THOẠI DI ĐỘNG </b>
<b>KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC </b>
<i>Quảng Nam, tháng 04 năm 2015</i>
</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2"><b>LỜI CẢM ƠN </b>
Tôi cũng xin chân thành cảm ơn quý Thầy, Cô khoa công nghệ thông tin trường Đại học Quảng Nam đã cùng tri thức và tâm huyết của mình để tận tình truyền đạt vốn kiến thức quý báu cho tôi trong suốt thời gian học tập tại trường. Với vốn kiến thức được tiếp thu trong quá trình học khơng chỉ là nền tảng cho q trình nghiên cứu khóa luận mà cịn là hành trang q báu để tôi bước vào đời một cách vững chắc và tự tin.
Tôi cũng thầm biết ơn sự ủng hộ của gia đình, bạn bè - những người thân yêu luôn ủng hộ và là chỗ dựa tinh thần vững chắc cho tơi.
Cuối cùng, tơi xin kính chúc q Thầy, Cơ và gia đình dồi dào sức khỏe và thành cơng trong sự nghiệp cao q.
Trong q trình làm bài khóa luận, khó tránh khỏi sai sót, rất mong các thầy, cơ bỏ qua. Đồng thời do trình độ lý luận cũng như kinh nghiệm thực tiễn còn hạn chế nên bài báo cáo không thể tránh khỏi những thiếu sót, em rất mong nhận được ý kiến đóng góp thầy, cơ để em học thêm được nhiều kinh nghiệm và sẽ hoàn thành tốt hơn bài báo cáo khóa luận sắp tới.
Em xin chân thành cảm ơn!
Quảng Nam, ngày 27 tháng 04 năm 2016 Sinh viên thực hiện
Nguyễn Quang Sách
</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3"><b>MỤC LỤC </b>
PHẦN 1. MỞ ĐẦU ... 11.1. Lý do chọn đề tài ... 1
1.2. Mục đích nguyên cứu ... 2
1.3. Đối tượng và phạm vi nghiên cứu ... 2
1.4. Phương pháp nghiên cứu ... 2
1.5. Đóng góp của đề tài ... 2
1.6. Cấu trúc đề tài ... 3
PHẦN 2. NỘI DUNG NGHIÊN CỨU... 4
CHƯƠNG 1: CƠ SỞ LÝ THUYẾT ... 4
1.1. Giới thiệu về Web service ... 4
1.1.1. Khái niệm Web service ... 4
1.1.2. Đặc điểm của Web service ... 4
1.1.3. Ưu và nhược điểm của Web service ... 5
1.1.4. Nền tảng của Web service ... 6
1.2. Các công nghệ và kiến trúc của Web service ... 7
1.2.1. Các công nghệ của Web service ... 7
1.2.1.1. Ngôn ngữ XML – RPC ... 7
1.2.1.2. Giao thức truyền thông điệp SOAP... 8
1.2.1.3. Ngôn ngữ mô tả Web service - WSDL ... 10
1.2.1.4. Đăng ký dịch vụ UDDI ... 12
1.2.2. Kiến trúc Web service ... 14
1.2.2.1. Cơ chế hoạt động của Web service ... 14
1.2.2.2. Kiến trúc phân tầng của Web service ... 16
1.2.3. Kiến trúc hướng dịch vụ SOA... 17
1.2.3.1. Khái niệm kiến trúc hướng dịch vụ SOA ... 17
1.2.3.2. Nguyên tắc thiết kế của SOA ... 18
1.3. Xây dựng một Web service ... 19
1.3.1. Qui trình xây dựng một Web service ... 19
1.3.2. Xây dựng Web service dùng API RESTful Service ... 19
</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">1.3.2.1. Giới thiệu về ASP.NET Web API ... 19
1.3.2.2. Giới thiệu cơ bản về RESTful Service ... 20
1.3.2.3. Nguyên tắc cơ bản để tạo ra RESTful Service ... 21
1.3.2.4. Xây dựng Web service ... 22
1.4. Bảo mật trong Web service ... 26
1.4.1. Tổng quan về an toàn Web service ... 26
1.4.2. Bảo mật Web service ... 27
1.4.2.1. Khái niệm ... 27
1.4.2.2. Chứng thực trong một ứng dụng ... 27
1.4.2.3. Những thành phần mở rộng của bảo mật Web service ... 27
1.4.3. Giới thiệu các kỹ thuật bảo mật Web service ... 28
1.4.3.1. eXtensible Access Control Markup Language (XACML) ... 28
1.4.3.2. Security Assertion Markup Language (SAML) ... 30
1.4.3.3. XML Key Management Specification (XKMS) ... 31
1.4.3.4. Web Services Policy Framework (WS-Policy) ... 32
1.4.3.5. eXentisble Rights Markup Language (XrML) ... 33
1.4.3.6. Giao thức bảo mật SSL ... 33
CHƯƠNG 2: TỔNG QUAN VỀ LẬP TRÌNH TRÊN DI ĐỘNG ... 35
2.1. Giới thiệu lập trình trên di động ... 35
2.2. Lập trình di động đa nền tảng Xamarin ... 37
2.2.1. Giới thiệu về Xamarin ... 37
2.2.2. Một số tính năng của Xamarin ... 38
2.3.3. Cài đặt Xamarin ... 38
2.3. Giới thiệu về Entity Framework Code First ... 42
2.3.1. Entity Framework Code First là gì? ... 42
2.3.2. Tạo cơ sở dữ liệu với Entity Framework Code First ... 43
2.4. Giới thiệu về Visual Studio 2015 ... 46
2.5. Giới thiệu về Microsoft SQL Server 2014 ... 48
<small>CHƯƠNG 3: PHÂN TÍCH VÀ XÂY DỰNG ỨNG DỤNG GHI CHÚ TRÊN DI ĐỘNG</small> .... 50
3.1. Phân tích chức năng ... 50
</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">3.2. Xây dựng ứng dụng ghi chú trên di động ... 57
3.2.1. Xây dựng Web service cho ứng dụng ghi chú ... 57
3.2.2. Xây dựng chức năng hiển thị danh sách các ghi chú ... 61
3.2.3. Xây dựng chức năng tìm kiếm các ghi chú ... 64
3.2.4. Xây dựng chức năng thêm mới ghi chú ... 67
3.2.5. Xây dựng chức năng sửa và xóa ghi chú ... 70
</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6"><b>DANH MỤC KÝ HIỆU VÀ TỪ VIẾT TẮT </b>
API Application Programming Interface B2B <b>Business To Business </b>
HTTP Hypertext Transfer Protocol HTML Hypertext Markup Language MVC Model View Controller
POP3 Post Office Protocol phiên bản 3 RPC Remote Procedure Call
SOAP Simple Object Access Protocol SOA Service Oriented Architecture SSL Security Sockets Layers
SAML Security Assertion Markup Language
</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">Sinhviênthựchiện:NguyễnQuangSáchviSMTP Simple Mail Transfer Protocol
TCP/IP Transmission Control Protocol/ Internet Protocol UDDI Universal Description Discovery and Integration URL Uniform Resource Locator
XML eXtensible Markup Language
XACML eXtensible Access Control Markup Language XKMS XML Key Management Specification
XrML eXentisble Rights Markup Language WSE Web Service Enhancement
WSDL Web Service Description Language
W3C World Wide Web Consortium
</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8"><b>DANH MỤC HÌNH ẢNH </b>
Hình 1.1: Mơ tả cấu trúc của một thơng điệp XML ... 8<small> </small>Hình 1.2: Mơ tả cấu trúc của một thơng điệp SOAP ... 9<small> </small>
Hình 1.3: Mơ tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP ... 10<small> </small>
Hình 1.4: Lược đồ XML UDDI định nghĩa bốn loại thơng tin ... 13<small> </small>
Hình 1.5: Mơ hình Web service ... 14<small> </small>
Hình 1.6: Web service technology stack ... 16<small> </small>
Hình 1.7: TCP/IP network model ... 16<small> </small>
Hình 1.8: Mơ hình phi trạng thái ... 21<small> </small>
Hình 1.9: Mơ hình trạng thái ... 21<small> </small>
Hình 1.10: Tạo project trong Visual Studio 2015 ... 22<small> </small>
Hình 1.11: Giao diện đặt tên cho project và cấu hình ... 23<small> </small>
Hình 1.12: Giao diện cấu hình cho project ... 23<small> </small>
Hình 1.13: Giao diện tạo thành cơng project để xử lý tiếp theo ... 24<small> </small>
Hình 1.14: Giao diện tạo một Controller mới ... 24<small> </small>
Hình 1.15: Giao diện chọn cấu hình cho Controller ... 25<small> </small>
Hình 1.16: Giao diện viết các chức năng Web service trong Controller ... 25<small> </small>
Hình 1.17: Giao diện Web service vừa tạo thành cơng ... 26<small> </small>
Hình 1.18: Mơ hình an tồn cho Web service ... 28<small> </small>
Hình 1.19: XACML Architecture ... 29<small> </small>
Hình 1.20: XKMS Services ... 31<small> </small>
Hình 1.21: Cấu trúc của SSL và giao thức SSL ... 34<small> </small>
Hình 2.1: Giới thiệu về Xamarin ... 37<small> </small>
Hình 2.2: Trang chủ của Xamarin để tải file cài đặt ... 39<small> </small>
Hình 2.3: Giao diện bắt đầu quá trình cài đặt Xamarin ... 39<small> </small>
Hình 2.4: Giao diện cài đặt Xamarin ... 40<small> </small>
Hình 2.5: Giao diện cài đặt các cộng cụ trong Xamarin ... 40<small> </small>
Hình 2.6: Giao diện cài Xamarin ... 41<small> </small>
Hình 2.7: Giao diện quá tải và cài đặt bộ các công cụ ... 41<small> </small>
Hình 2.8: Giao diện cài thành cơng Xamarin ... 42<small> </small>
</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">viiiHình 2.9: Thiết kế các lớp domain trước và sau đó tạo ra cơ sở dữ liệu. ... 42<small> </small>
Hình 2.10: Giao diện tạo project có tên EFCodeFirstExample ... 43<small> </small>
Hình 2.11: Thêm thư viện Entity Framework thơng qua nuget package ... 43<small> </small>
Hình 2.12: Cài đặt Entity Framework thơng qua Nuget Package Manager ... 44<small> </small>
Hình 2.13: Cài đặt thành cơng Entity Framework dưới dạng references ... 44<small> </small>
Hình 2.14: Giới thiệu Microsoft Visual Studio 2015 ... 46<small> </small>
Hình 3.1: Biểu đồ Use Case ... 51<small> </small>
Hình 3.2: Biểu đồ tuần tự UC tìm kiếm ... 51<small> </small>
Hình 3.3: Biểu đồ cộng tác UC tìm kiếm ... 52<small> </small>
Hình 3.4: Biểu đồ tuần tự UC thêm ghi chú ... 52<small> </small>
Hình 3.5: Biểu đồ cộng tác UC thêm ghi chú ... 53<small> </small>
Hình 3.6: Biểu đồ tuần tự UC sửa ghi chú ... 53<small> </small>
Hình 3.7: Biểu đồ cộng tác UC sửa ghi chú ... 54<small> </small>
Hình 3.8: Biểu đồ tuần tự UC xóa ghi chú ... 54<small> </small>
Hình 3.9: Biểu đồ cộng tác UC xóa ghi chú ... 55<small> </small>
Hình 3.10: Biểu đồ thành phần ... 56<small> </small>
Hình 3.11: Biểu đồ triển khai ... 57<small> </small>
Hình 3.12: Giao diện Web service ... 60<small> </small>
Hình 3.13: Giao diện Web service ... 60<small> </small>
Hình 3.14: Giao diện trang chính ứng dụng ... 61<small> </small>
Hình 3.15: Giao diện trang tìm kiếm ... 64<small> </small>
Hình 3.16: Giao diện trang thêm ghi chú mới ... 67<small> </small>
Hình 3.17: Giao diện trang xem chi tiết ghi chú ... 70<small> </small>
</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">Các tài nguyên Internet được xây dựng bằng nhiều công nghệ và ngôn ngữ khác nhau dẫn đến vấn đề là tài nguyên ngày càng nhiều nhưng không đồng bộ, các hệ thống không thể truy xuất hoặc cập nhật lẫn nhau. Các ứng dụng máy tính khơng có khả năng khai thác dữ liệu trực tiếp từ các website, website được viết bằng ngơn ngữ này cũng gặp khó khăn khi khai thác dữ liệu từ website được viết bằng ngôn ngữ khác. Từ đây sẽ nảy sinh một yêu cầu là cần có một tài nguyên thống nhất để tất cả mọi hệ thống có thể sử dụng ở mọi lúc mọi nơi. Để giải quyết yêu cầu trên, các nhà khoa học đã xây dựng Web service.
Web service ra đời được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt động của B2B (Business to Business) và B2C (Business to Customer). Giá trị cơ bản của Web service dựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đối với hệ thống đóng gói và hệ thống kế thừa. Các phần mềm được viết bởi những ngôn ngữ khác nhau có thể sử dụng Web service để chuyển đổi dữ liệu thông qua mạng Internet theo cách giao tiếp tương tự bên trong một máy tính. Tuy nhiên, cơng nghệ xây dựng Web service không nhất thiết phải là các cơng nghệ mới, nó có thể kết hợp với các cơng nghệ đã có như XML, SOAP, WSDL, UDDI… Với sự phát triển và lớn mạnh của Internet, Web service thật sự là một công nghệ đáng được quan tâm để giảm chi phí và độ phức tạp trong tích hợp hệ thống.
<b>Chính vì lý do này nên tơi chọn đề tài “Tìm hiểu về Web service và xây dựng </b>
<b>ứng dụng trên điện thoại di động”. </b>
</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11"><b>1.2. Mục đích nguyên cứu </b>
- Nắm vững các kiến thức về lý thuyết Web service - Tìm hiểu về lập trình di động đa nền tảng
- Triển khai ứng dụng Web service trên ứng dụng di động
<b>1.3. Đối tượng và phạm vi nghiên cứu </b>
- Đối tượng nghiên cứu của đề tài là lý thuyết kiến trúc Web service, lập trình di động đa nền tảng với Xamarin.
- Phạm vi nghiên cứu của đề tài được giới hạn trong các nội dung sau: về mặt lý thuyết, đó là kiến trúc Web service, nền tảng, mô hình kiến trúc, khả năng ứng dụng của Web service trong việc xây dựng các ứng dụng hướng dịch vụ (SOA), các chuẩn công nghệ hỗ trợ trong Web service: SOAP, XML, WSDL và UDDI,..., lý thuyết về lập trình đa nền tảng trên di động.
<b>1.4. Phương pháp nghiên cứu </b>
- Tiếp cập lý thuyết về Web service
- Thu thập thông tin, nghiên cứu tài liệu liên quan đến đề tài - Tham khảo sách, báo và từ Internet
- Với đề tài này tôi mong muốn cung cấp một tài liệu tham khảo cho các bạn sinh viên trong khoa khi tiếp cận và tìm hiểu về lập trình đa nền tảng trên di động và nhất là lĩnh vực mà tôi đang nghiên cứu.
</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12"><b>1.6. Cấu trúc đề tài </b>
Ngoài phần mở đầu và kết luận, phần nội dung khóa luận gồm ba chương: - Chương 1: Cơ sở lý thuyết về Web service, chương này giới thiệu tổng quan về khái niệm, đặc điểm nền tảng, kiến trúc của Web service và cách xây dựng triển khai một Web service.
- Chương 2: Giới thiệu về lập trình di động đa nền tảng, chương này giới thiệu về kĩ thuật lập trình di động đa nền Xamarin tảng trên di động và công cụ sử dụng liên quan.
- Chương 3: Phân tích và xây dựng ứng dụng trên di động, nội dung chương này bao gồm phân tích các chức năng của và xây dựng chức năng ứng dụng ghi chú trên di động.
</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">Trước hết, có thể nói rằng ứng dụng cơ bản của Web service là tích hợp các hệ thống và là một trong những hoạt động chính khi phát triển hệ thống. Trong hệ thống này, các ứng dụng cần được tích hợp với cơ sở dữ liệu (CSDL) và các ứng dụng khác, người sử dụng sẽ giao tiếp với CSDL để tiến hành phân tích và lấy dữ liệu. Trong thời gian gần đây, việc phát triển mạnh mẽ của thương mại điện tử và B2B cũng địi hỏi các hệ thống phải có khả năng tích hợp với CSDL của các đối tác kinh doanh (nghĩa là tương tác với hệ thống bên ngoài - bên cạnh tương tác với các thành phần bên trong của hệ thống trong doanh nghiệp).
<b>1.1.2. Đặc điểm của Web service </b>
Web service cho phép client và server tương tác được với nhau ngay cả trong những mơi trường khác nhau. Ví dụ, đặt Web server cho ứng dụng trên một máy chủ chạy hệ điều hành Linux trong khi người dùng sử dụng máy tính chạy hệ điều hành Windows, ứng dụng vẫn có thể chạy và xử lý bình thường mà không cần thêm yêu cầu đặc biệt để tương thích giữa hai hệ điều hành này.
Phần lớn kĩ thuật của Web service được xây dựng dựa trên mã nguồn mở và được phát triển từ các chuẩn đã được cơng nhận, ví dụ như XML.
</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">Sinhviênthựchiện:NguyễnQuangSách5 Là sự kết hợp của việc phát triển theo hướng từng thành phần với những lĩnh vực cụ thể và cơ sở hạ tầng Web, đưa ra những lợi ích cho cả doanh nghiệp, khách hàng, những nhà cung cấp khác và cả những cá nhân thông qua mạng Internet. Một ứng dụng khi được triển khai sẽ hoạt động theo mơ hình client-server. Nó có thể được triển khai bởi một phần mềm ứng dụng phía server ví dụ như PHP, Oracle Application server hay Microsoft.Net…
Ngày nay Web service đang rất phát triển, những lĩnh vực trong cuộc sống có thể áp dụng và tích hợp Web service là khá rộng lớn như dịch vụ chọn lọc và phân loại tin tức, ứng dụng cho các dịch vụ du lịch (cung cấp giá vé, thông tin về địa điểm…), các đại lý bán hàng qua mạng, thông tin thương mại như giá cả, tỷ giá hối đoái, đấu giá qua mạng, hay dịch vụ giao dịch trực tuyến như đặt vé máy bay, thông tin thuê xe…
<b>1.1.3. Ưu và nhược điểm của Web service </b>
Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán.
Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành dịch vụ, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của các doanh nghiệp khác.
Ở góc độ doanh nghiệp, Web service là một công nghệ phục vụ rất tốt trong việc quảng bá dịch vụ của mình cho đa dạng khách hàng.
</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">Sinhviênthựchiện:NguyễnQuangSách6 Nhược điểm
Có quá nhiều chuẩn cho Web service khiến người dùng khó nắm bắt cũng như gây khó khăn cho các nhà phát triển.
An tồn và bảo mật thơng tin là một vấn đề nan giải của Web service.
Có nhiều vấn đề về các tác vụ địi hỏi tiến trình xử lý (ví dụ như chuyển tiền qua lại giữa các ngân hàng) chưa được giải quyết hoàn chỉnh.
Tốc độ thực thi của Web service phụ thuộc rất nhiều vào tốc độ đường truyền Internet và nhìn chung các Web service thực thi chậm hơn các ứng dụng bình thường khác.
<b>1.1.4. Nền tảng của Web service </b>
Web service cũng có thể được nói một cách khác là các khối cơ bản được xây dựng để di chuyển trong hệ thống máy tính phân tán trên Internet. Các chuẩn mở và việc tập trung vào giao tiếp và làm việc cộng tác giữa con người và các ứng dụng đã tạo nên một môi trường nơi mà Web service đang trở thành nền tảng cho việc tích hợp ứng dụng. Các ứng dụng được xây dựng sử dụng các Web service các loại từ nhiều nguồn khác nhau làm việc cùng với nhau bất kể là chúng ở đâu hoặc chúng đã được triển khai như thế nào. Có thể có các định nghĩa khác nhau về Web service khi các công ty xây dựng chúng, nhưng hầu hết tất cả các định nghĩa đều có chung các điểm sau:
Thứ nhất, Web service đưa ra chức năng hữu dụng cho người sử dụng Web thông qua một giao thức chuẩn Web. Trong hầu hết các trường hợp, giao thức được sử dụng đó là SOAP.
Thứ hai, Web service đưa ra cách mô tả các giao diện của chúng một cách đủ chi tiết nhằm cho phép người sử dụng xây dựng một ứng dụng máy trạm để giao tiếp được với chúng. Mô tả này thường được cung cấp ở dạng một tài liệu XML gọi là một tài liệu về ngôn ngữ mô tả Web service - WSDL (Web service Description Language).
Thứ ba, Web service được đăng ký sao cho các khách hàng tiềm năng là người sử dụng có thể tìm thấy chúng một cách dễ dàng. Điều này được thực hiện với UDDI (Universal Discovery Description and Integration).
</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">Sinhviênthựchiện:NguyễnQuangSách7Web service như một dịch vụ phần mềm được trình bày trên Web thông qua giao thức SOAP, được mô tả bằng một tệp WSDL và được đăng ký trong UDDI. Các dịch vụ Web service là nguồn thông tin mà ta có thể dễ dàng kết hợp vào các ứng dụng. Dễ dàng nhận ra toàn bộ lớp ứng dụng có thể được xây dựng để phân tích và tích hợp thơng tin ta quan tâm và trình bày nó theo nhiều cách khác nhau.
<b>1.2. Các cơng nghệ và kiến trúc của Web service 1.2.1. Các công nghệ của Web service </b>
<b>1.2.1.1. Ngôn ngữ XML – RPC </b>
XML (Extensible Markup Language) - Ngôn ngữ đánh dấu dữ liệu.
RPC (Remote Procedure Call) - Thủ tục gọi từ xa. RPC cung cấp cho người phát triển kĩ thuật để định nghĩa ra một giao diện mà có thể được gọi từ xa thơng qua mơi trường mạng máy tính. Giao diện này có thể là một hàm đơn giản nhưng cũng có thể là một thư viện API khổng lồ.
XML - RPC là một hướng tiếp cận dễ và rõ ràng nhất cho Web service, nó cung cấp phương thức gọi một ứng dụng từ một máy tính local đến một máy tính từ xa thơng qua mơi trường mạng.
XML - RPC cho phép chương trình có khả năng tạo ra các hàm hoặc các thủ tục gọi hàm thơng qua mạng máy tính.
XML - RPC sử dụng giao thức HTTP để vận chuyển thông tin từ Client đến Server.
XML - RPC sử dụng ngôn ngữ XML để mô tả các thông điệp yêu cầu và các thông điệp đáp ứng gần gũi với ngôn ngữ tự nhiên.
XML - RPC client chỉ ra cụ thể các thông tin về tên thủ tục, các tham biến trong thông điệp XML request, và server trả về lỗi hoặc trả về thông điệp response trong thông điệp XML response.
Các tham số của XML - RPC đơn giản chỉ là kiểu dữ liệu và nội dung - tuy nhiên các cấu trúc dữ liệu phức tạp như struct, array cũng được hỗ trợ bởi XML - RPC.
</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17"><b>1.2.1.2. Giao thức truyền thông điệp SOAP </b>
SOAP viết tắt cho cụm từ - Simple Object Access Protocol. Trong kiến trúc phân tầng của Web service, SOAP nằm ở tầng Packaging, SOAP là một giao thức đóng gói cho các dữ liệu chia sẽ giữa các ứng dụng. Xét về cơ bản, SOAP là XML, chính vì thế SOAP là một ứng dụng cụ thể của XML. SOAP được xây dựng lên từ các chuẩn XML như XML Schema và XML Namespaces dùng cho việc định nghĩa SOAP và các chức năng của nó.
Các thành phần cơ bản của SOAP gồm có:
<b> Thơng điệp XML </b>
Thơng điệp XML đó là các tài liệu XML được dùng để trao đổi thông tin giữa các ứng dụng. Nó cung cấp tính mềm dẻo cho các ứng dụng trong quá trình giao tiếp với nhau và là một dạng cơ bản của SOAP.
Các thông điệp này có thể là bất cứ thứ gì: Hóa đơn thanh toán, yêu cầu về giá cổ phiếu, một truy vấn tới một cơng cụ tìm kiếm hoặc có thể là bất kì thơng tin nào có quan hệ tới từng thành phần của ứng dụng.
Hình 1.1: Mơ tả cấu trúc của một thơng điệp XML
Bởi vì XML không phụ thuộc vào một ứng dụng cụ thể, hệ điều hành hay ngơn ngữ lập trình nào, cho nên các thơng điệp XML có thể sử dụng trong tất cả các mơi trường. Một chương trình Windows Perl có thể tạo ra một thơng điệp XML, trình bày thơng điệp đó và gửi đến cho một chương trình cài đặt bằng ngôn ngữ Java được triển khai trên nền Unix.
<b> RPC và EDI </b>
Sử dụng thông điệp XML, đương nhiên SOAP có 2 ứng dụng liên quan: RPC và EDI. Thủ tục gọi hàm từ xa RPC - Remote Procedure Call là một dạng tính tốn phân tán cơ bản, mô tả cách thức để một chương trình tạo ra một thủ tục gọi hàm hoặc phương thức tới một máy tính khác, truyền đối số và lấy giá trị trả về. Trao đổi tài liệu điện tử EDI (Electronic Document Interchange) là một dạng tiến trình cơ bản cho quy
</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">Sinhviênthựchiện:NguyễnQuangSách9trình thương mại nó định nghĩa các chuẩn định dạng và thông dịch của các tài liệu, thông điệp tài chính và thương mại.
Nếu bạn sử dụng SOAP cho EDI, khi đó thơng điệp XML có thể là các hóa đơn thanh tốn, trả tiền thuế, hoặc các tài liệu tương tự. Nếu bản sử dụng SOAP cho RPC khi đó thơng điệp XML có thể trình bày các đối số hoặc các giá trị trả về.
<b> Thông điệp SOAP </b>
Thông điệp SOAP bao gồm phần tử gốc envelope bao trùm toàn bộ nôi dung thông điệp SOAP, và các phần tử header và body. Phần tử header chứa các khối thơng tin có liên quan đến cách thức các thơng điệp được xử lý như thế nào. Nó bao gồm việc định tuyến và các thiết lập cho việc phân phối các thơng điệp. Ngồi ra phần tử header cịn có thể chứa các thơng tin về việc thẩm định quyền, xác minh và các ngữ cảnh cho các transaction. Các dữ liệu thực sự được lưu trữ tại phần tử body. Bất cứ thứ gì có thể trình bày cú pháp XML đều nằm trong phần tử body của một thông điệp SOAP.
Hình 1.2: Mơ tả cấu trúc của một thơng điệp SOAP
Tất cả các phần tử envelope đều chứa chính xác một phần tử body. Phần tử body có thể chứa các nốt con theo yêu cầu. Nội dung của phần tử body là các thông điệp. Nếu phần tử envelope mà chứa phần tử header, nó chỉ chứa không nhiều hơn một phần tử header và phần tử header này bắt buộc phải là phần tử con đầu tiên của phần tử envelope. Mỗi một phần tử chứa header đều được gọi là header block. Mục đích của header block cung cấp giao tiếp các thơng tin theo ngữ cảnh có liên quan đến quy trình xử lý các thơng điệp SOAP.
</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19"><b> Vận chuyển SOAP </b>
SOAP được đặt ở tầng Packaging trong kiến trúc phân tầng của Web Service, SOAP đứng phía trên tầng Network và tầng Transport. Vì thế SOAP khơng quan tâm đến việc giao thức vận chuyển nào được sử dụng trong q trình trao đổi các thơng điệp, điều đó làm cho giao thức thực sự mềm dẻo tại bất kì mơi trường SOAP được triển khai nào.
Tính mềm dẻo của SOAP được thể hiện qua việc SOAP có thể sử dụng các giao thức vận chuyển khác nhau để trao đổi các thông điệp, như HTTP, FTP, SMTP, POP3.
Hiện nay, HTTP được sử dụng phổ biến trên Internet, chính vì tính phổ biến của nó, cho nên HTTP hiện tại đang là giao thức vận chuyển phổ biến nhất cho việc vận chuyển các thông điệp SOAP.
SOAP thông qua HTTP rất thuận tiện cho SOAP RPC trong việc gọi yêu cầu và nhận các thơng điệp đáp ứng bởi vì bản chất HTTP chính là giao thức dựa trên nền tảng gọi các yêu cầu và nhận các đáp ứng (request - response - base protocol). Các SOAP request được gửi tới HTTP server thông qua phương thức POST và HTTP Server trả lại giá trị SOAP response thơng qua các HTTP response.
Hình 1.3: Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP
<b>1.2.1.3. Ngôn ngữ mô tả Web service - WSDL </b>
</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20">Sinhviênthựchiện:NguyễnQuangSách11WSDL là ngôn ngữ cho việc mô tả các giao diện Web service dựa trên nền tảng XML. WSDL là ngôn ngữ mà UDDI sử dụng.
<i> Type: Thành phần type định nghĩa kiểu dữ liệu được sử dụng cho Web </i>
service Để đảm bảo tính khơng phụ thuộc vào nền tảng, WSDL sử dụng cấu trúc của lược đồ XML để định nghĩa kiểu dữ liệu.
<i> Message: Thành phần message dung để định nghĩa các thành phần dữ liệu và </i>
các thông điệp mà nó được gọi tới. Mỗi thơng điệp có thể bao gồm một hoặc nhiều phần, các thành phần này có thể so sánh với các câu lệnh của các lời gọi hàm trong các ngơn ngữ lập trình truyền thống.
<i> PortType: Đây là thành phần quan trọng nhất trong một tài liệu WSDL. Nó </i>
được sử dụng để mô tả Web service, các thao tác được thực thi và các lời gọi thông điệp. Thành phần port type có thể được so sánh với các thư viện hàm (hoặc các module, các lớp) trong các ngơn ngữ lập trình.
</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21">Sinhviênthựchiện:NguyễnQuangSách12Trong thành phần <portType>, ta thường gặp 4 kiểu thao tác được WSDL định nghĩa dưới đây:
<b>Kiểu thao tác Mô tả </b>
One-way Thao tác này thể hiện rằng nó chỉ nhận các lời gọi thơng điệpnhưng không trả lại thông điệp đáp ứng
Request-response Thao tác này bao gồm việc nhận các thông điệp yêu cầu và trả về các thông điệp đáp ứng
Solicit-response Thao tác này sẽ gửi đi các yêu cầu và đợi các đáp ứng
Notification Thao tác này sẽ gửi đi các yêu cầu nhưng không đợi để nhận các đáp ứng
Binding: Thành phần này định nghĩa các định dạng thông điệp, các mô tả cụ thể về các giao thức cho mỗi port.
Các thành phần của UDDI UDDI gồm 2 thành phần chính:
Phần đăng ký của tất cả các Web Service’s metadata, bao gồm cả việc trỏ đến tài liệu WSDL mô tả dịch vụ.
Phần thiết lập WSDLPort type định nghĩa cho các thao tác và tìm kiếm thơng tin đăng ký.
UDDI xây dựng dựa trên các giao thức chuẩn Internet được công bố bởi W3C và IETF như XML, HTTP, và DNS. UDDI sử dụng WSDL để mô tả giao diện của Web
</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">Sinhviênthựchiện:NguyễnQuangSách13service. Thêm nữa tính năng độc lập với nền tảng ngơn ngữ lập trình đã được điều hợp cùng với giao thức SOAP.
Mơ hình dữ liệu của UDDI
UDDI bao gồm lược đồ XML, mô tả bốn kiểu cấu trúc dữ liệu dưới đây:
Hình 1.4: Lược đồ XML UDDI định nghĩa bốn loại thông tin
<b>Cấu trúc dữ liệu businessEntity </b>
Cấu trúc dữ liệu businessEntity trình bày nhà cung cấp Web service. Cấu trúc này chứa các thông tin về công ty, bao gồm danh sách liên lạc, thông tin, phân biệt các tổ chức thương mại, và danh sách các nhà cung cấp Web service.
<b>Cấu trúc dữ liệu businessService </b>
Liên kết với mỗi business entity là một danh sách các business service cung cấp bởi business entity đó. Mỗi thành phần chứa thơng tin mơ tả về dịch vụ, về thông tin phân loại của dịch vụ và danh sách các binding template liên quan đến thông tin kỹ thuật của dịch vụ. Mỗi business service cần có ít nhất một binding template.
<b>Cấu trúc dữ liệu bindingTemplate </b>
BindingTemplate là kĩ thuật mô tả của Web service được trình bày bởi cấu trúc dữ liệu Business Service. Binding template trình bày sự hoạt động thực tế của Web service, mô tả công nghệ sử dụng để giao tiếp với Web service. Một Business Service có thể có thể có nhiều binding template, cho nên dịch vụ phải chỉ rõ các hành động cụ thể khác nhau trong cùng một dịch vụ.
</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23"><b>Cấu trúc dữ liệu tModel </b>
tModel là lõi trong cùng của kiểu dữ liệu, nhưng rất khó có khả năng để có thể nắm bắt được hết. tModel là chuẩn cho mơ hình kĩ thuật.
tModel là phương pháp để mô tả một vài quy trình thương mại, dịch vụ và các cấu trúc mẫu lưu trữ trong UDDI registry. Bất kì một khái niệm trừu tượng nào đều có thể được đăng ký trong UDDI như là một tModel. Ví dụ: chúng ta có thể định nghĩa ra một kiểu cổng (port type) WSDL mới, và đồng nghĩa với đó ta có thể định nghĩa ra một tModel mới mà trình bày kiểu cổng đó trong UDDI. Sau đó, ta có thể chỉ định ra dịch vụ thương mại mà thực thi kiểu cổng đó bằng việc kết hợp với tModel với một business service’s binding template.
<b>Cấu trúc dữ liệu publisherAssertion </b>
Đây là một cấu trúc dữ liệu quan hệ mà nó đặt sự kết hợp giữa hai hoặc nhiều cấu trúc dữ liệu businessEntity theo một kiểu quan hệ cụ thể, chẳng hạn như một cơng ty con hoặc một phịng ban.
<b>1.2.2. Kiến trúc Web service </b>
<b>1.2.2.1. Cơ chế hoạt động của Web service </b>
Cơ chế hoạt động của Web service yêu cầu phải có 3 thao tác đó là: Find, Public, Bind.
Hình 1.5: Mơ hình Web service
- Mơ hình Web service đơn giản định nghĩa cách thức tương tác giữa Service Requestor (bên sử dụng dịch vụ), Service Provider (bên cung cấp dịch vụ), Service Directory UDDI (bên trung gian).
</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24">Sinhviênthựchiện:NguyễnQuangSách15- Bên sử dụng dịch vụ tìm kiếm các dịch vụ trong một UDDI Service Directory. Chúng sẽ lấy thông tin mô tả WSDL của các Web service cung cấp bởi Service Providers từ trước thông qua Service Directory. Sau khi lấy được mô tả WSDL, bên yêu cầu dịch vụ kết nối đến nhà cung cấp dịch vụ bằng cách triệu gọi các dịch vụ thông qua giao thức SOAP.
- Một số cơ chế tương tác giữa các thành phần này:
Service: là cơ chế cho phép client xác đinh và triệu gọi các dịch vụ từ xa thông qua mạng mà không phụ thuộc vào vị trí địa lí, hệ điều hành sử dụng hay ngơn ngữ lập trình sử dụng.
Message: là phương tiện giao tiếp giao tiếp giữa bên cung cấp dịch vụ và bên sử dụng dịch vụ. Một message có thể là một yêu cầu từ bên sử dụng dịch vụ gửi đến bên cung cấp dich vụ hay là phản hồi từ bên cung cấp dịch vụ về cho bên sử dụng dịch vụ.
Dynamic discovery: là cơ chế được cài đặt dựa trên directory service. Về phía bên cung cấp, sẽ sử dụng direcrtory service để tự đăng kí những dịch vụ mà cung cấp. Cịn về phía sử dụng, sẽ truy vấn để tìm ra các dịch vụ theo nhu cầu từ directory service thông qua mạng. Điều này làm giảm sự lệ thuộc của bên sử dụng dịch vụ vào bên cung cấp dịch vụ.
Publish: để có thể truy cập được thì một Web service cần phải được công bố để các Service Request có thể tìm thấy nó. Việc cơng bố có thể khác nhau tùy thuộc vào từng ứng dụng cụ thể. Nhưng thông thường, một mô tả dịch vụ (service description) bao gồm các thông tin sau: các interface, các kiểu dữ liệu, các toán tử, các thơng tin kết nối, vị trí của dịch vụ có thể truy cập được trên mạng…
Find: trong thao tác tìm kiếm Service request sẽ lấy mô tả về dịch vụ đang được yêu cầu một cách trực tiếp hoặc thông qua Service Provider. Thao tác tìm kiếm này có thể diễn ra trong hai vịng: thiết kế xây dựng (lập trình viên cần biết mơ tả, interface của dịch vụ) và thực thi (xác định vị trí và tiến hành triệu gọi dịch vụ).
</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">Sinhviênthựchiện:NguyễnQuangSách16 Bind: để sử dụng được dịch vụ thì cần phải triệu gọi nó. Trong thao tác bind, Service Request khi thực thi sẽ gọi hoặc khởi tạo một luồng tương tác với dịch vụ dựa trên các thông tin trong mô tả dịch vụ mà nó thu được trước đó như: vị trí dịch vụ, các liên lạc và tương tác với dịch vụ …
<b>1.2.2.2. Kiến trúc phân tầng của Web service </b>
Hình 1.6: Web service technology stack
Mơ hình kiến trúc phân tầng của Web service tương tự với mơ hình TCP/IP được sử dụng để mơ tả kiến trúc Internet.
Hình 1.7: TCP/IP network model
Các tầng truyền thống như Packaging, Description, và Discovery trong mơ hình Web Service Stack là những tầng cung cấp khả năng tích hợp và cần thiết cho mơ hình ngơn ngữ lập trình trung lập.
<b> Tầng Discovery: Tầng Discovery cung cấp cơ chế cho người dùng khả năng </b>
lấy các thông tin mô tả về các Service Provider. Công nghệ được sử dụng tại tầng này đó chính là UDDI - Universal Description, Discovery and Integration.
</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26"><b> Tầng Description: Khi Web service được thực thi, nó cần phải đưa ra các </b>
quyết định về các giao thức trên các tầng Network, Transport, Packaging mà nó sẽ hỗ trợ trong quá trình thực thi. Các mơ tả về dịch vụ sẽ đưa ra phương pháp để làm thế nào mà các Service Consumer có thể liên kết và sử dụng các service đó. Tại tầng Description, cơng nghệ được sử dụng ở đây chính là WSDL. Ngồi ra, ít phổ biến hơn, chúng ta cịn có 2 ngơn ngữ khác được định nghĩa bởi tổ chức W3C đó là ngơn ngữ môt tả tài nguyên - W3C’s Resource Desciption Framework (RDF) và ngôn ngữ đánh dấu sự kiện DARPA.
<b> Tầng Packaging: Việc thực hiện vận chuyển các dữ liệu Web service được </b>
thực hiện bởi tầng Transport, tuy nhiên trước khi được vận chuyển, các dữ liệu cần phải được đóng gói lại theo các định dạng đã định trước để các thành phần tham gia vào mơ hình Web service có thể hiểu được, việc đóng gói dữ liệu được thi bởi tầng Packaging. Việc đóng gói dữ liệu bao gồm các cơng việc định dạng dữ liệu, mã hóa các giá trị đi kèm dữ liệu đó và các cơng việc khác. SOAP là cơng nghệ chủ yếu được sử dụng tại tầng này, nó là một giao thức đóng gói dữ liệu phổ biến dựa trên nền tảng XML.
<b> Tầng Transport: Tầng Transport có vai trị đảm nhiệm việc vận chuyển các </b>
Web Service Message, tại đây bao gồm một vài dạng công nghệ khác nhau cho phép các giao tiếp trực tiếp giữa các Application - to - Application dựa trên tầng Network. Mỗi công nghệ bao gồm các giao thức như TCP, HTTP, SMTP….Việc lựa chọn giao thức vận chuyển được dựa trên mỗi nhu cầu giao tiếp của các Web service.
<b> Tầng Network: Tầng Network trong công nghệ Web Service chính xác giống </b>
tầng Network trong mơ hình giao thức TCP/IP. Nó cung cấp khả năng giao tiếp cơ bản, định địa chỉ và định tuyến.
<b>1.2.3. Kiến trúc hướng dịch vụ SOA </b>
<b>1.2.3.1. Khái niệm kiến trúc hướng dịch vụ SOA </b>
SOA - viết tắt của thuật ngữ Service Oriented Architecture (kiến trúc hướng dịch vụ) là khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch vụ.
</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">Sinhviênthựchiện:NguyễnQuangSách18Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức năng (module phần mềm) thực hiện quy trình nghiệp vụ nào đó, một cách cơ bản, SOA là tập hợp các dịch vụ kết nối mềm dẻo với nhau (nghĩa là một ứng dụng có thể nói chuyện với một ứng dụng khác mà không cần biết các chi tiết kĩ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp của kĩ thuật bên dưới.
Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách sử dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ có tính linh hoạt có thể triển khai và tái sử dụng trong tồn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà khơng làm ảnh hưởng đến client sử dụng dịch vụ.
Thực ra khái niệm SOA khơng hồn tồn mới, DCOM và CORBA cũng có kiến trúc tương tự. Tuy nhiên các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví dụ các ứng dụng phân tán muốn làm việc với nhau phải đạt đuợc thoả thuận về chi tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay đổi tương ứng đối với mã lệnh truy cập thành phần COM này.
Ưu điểm quan trọng nhất của SOA là khả năng kết nối mềm dẻo (nhờ sự chuẩn hoá giao tiếp) và tái sử dụng. Các dịch vụ có thể được sử dụng với trình Client chạy trên nền tảng bất kì và được viết bởi ngơn ngữ bất kì.
<b>1.2.3.2. Nguyên tắc thiết kế của SOA </b>
SOA dựa trên hai nguyên tắc thiết kế quan trọng:
Mơ-đun: đó là tách các vấn đề lớn thành nhiều vấn đề nhỏ hơn.
Đóng gói: Che đi dữ liệu và lô-gic trong từng mô-đun đối với các truy cập từ bên ngồi.
Hai tính chất này sẽ dẫn đến đặc điểm thiết kế của kiến trúc SOA đó là các dịch vụ tương tác với nhau qua các thành phần giao tiếp, tuy nhiên các dịch vụ đó vẫn hoạt
</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28">Sinhviênthựchiện:NguyễnQuangSách19động độc lập với nhau, chia sẻ các lược đồ dữ liệu cho nhau và tuân thủ các chính sách của kiến trúc chung nhất.
<b>1.3. Xây dựng một Web service </b>
<b>1.3.1. Qui trình xây dựng một Web service </b>
Qui trình xây dựng một Web service bao gồm các bước sau:
- Định nghĩa và xây dựng các chức năng, các dịch vụ mà dịch vụ sẽ cung cấp. - Tạo WSDL cho dịch vụ.
- Xây dựng SOAP server.
- Đăng ký WSDL với UDDI registry để cho phép các client có thể tìm thấy và truy xuất.
- Client nhận file WSDL và từ đó xây dựng SOAP client để có thể kết nối với SOAP server.
- Xây dựng ứng dụng phía client và sau đó gọi thực hiện dịch vụ thơng qua việc kết nối tới SOAP server.
- Lựa chọn một ngơn ngữ, xây dựng các tiến trình nghiệp vụ và chúng ta bắt đầu tạo nên một Web service như ý muốn. Sau đó là cung cấp Web service này trên Internet.
<b>1.3.2. Xây dựng Web service dùng API RESTful Service 1.3.2.1. Giới thiệu về ASP.NET Web API </b>
<b>Là nền tảng lập trình giúp chúng ta tạo ra các Web API - API trên nền Web. Web </b>
API là web service được xây dựng dựa trên HTTP sử dụng mơ hình lập trình convention (như ASP.NET MVC).
<b> Đă ̣c điểm Web API (.NET 4.0 trở lên) </b>
Giúp cho việc xây dựng các HTTP service rất đơn giản, nhanh chóng. Mã ng̀n mở và có thể được sử dụng bởi bất kì client hỗ trợ XML, JSON. Hỗ trợ đầy đủ các thành phần HTTP: URI, request/response headers, caching, versioning, content formats.
Có thể host trong ứng dụng hoặc trên IIS
Kiến trúc lý tưởng cho các thiết bị có băng thơng giới hạn như các thiết bị di đô ̣ng.
</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">Sinhviênthựchiện:NguyễnQuangSách20 Định dạng dữ liệu có thể là JSON, XML hoặc một kiểu dữ liệu bất kỳ
Làm mới và hiện đại hóa các mẫu dự án mặc định Nhiều tính năng mới để hỗ trợ các ứng dụng di động Tùy chỉnh sinh mã (code)
Tăng cường hỗ trợ cho các phương pháp bất đồng bộ
<b> Ưu điểm của Web API </b>
Hiê ̣u suất (performance) cao Hỗ trơ ̣ RESTfull đầy đủ
Hỗ trơ ̣ đầy đủ các thành phần MVC như: routing, controller, action result, filter, model binder, IoC container, dependency injection, unit test, …
<b>1.3.2.2. Giới thiệu cơ bản về RESTful Service </b>
REST định nghĩa các quy tắc kiến trúc để thiết kế Web service chú trọng vào tài nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng như thế nào và được chuyển tải qua HTTP thông qua số lượng lớn người dùng và được viết bởi những ngơn ngữ khác nhau. Nếu tính theo số dịch vụ mạng sử dụng, REST đã nổi lên trong vài năm qua như là một mơ hình thiết kế dịch vụ chiếm ưu thế. Trong thực tế, REST đã có những ảnh hưởng lớn và gần như thay thế SOAP và WSDL vì nó đơn giản và dễ sử dụng hơn rất nhiều.
REST không thu hút được nhiều sự chú ý khi lần đầu tiên giới thiệu vào năm 2000 bởi Roy Fielding trong luận án của ông "Architectural Styles and the Design of Network-based Software Architectures" (phong cách kiến trúc và thiết kế kiến trúc phần mềm dựa trên mạng) tại Đại học California. Luận án đã phân tích một loạt các nguyên tắc kiến trúc phần mềm sử dụng Web như là một nền tảng tính tốn phân tán.
- RESTfull tuân thủ theo 4 nguyên tắc thiết kế cơ bản sau: Sử dụng các phương thức HTTP một cách rõ ràng Phi trạng thái
Hiển thị cấu trúc thư mục như URls
Chuyển đổi linh hoạt JavaScript Object Notation (JSON) và XML hoặc cả hai
</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30"><b>1.3.2.3. Nguyên tắc cơ bản để tạo ra RESTful Service </b>
- Có 4 nguyên tắc thiết kế cơ bản sau:
Nguyên tắc 1: Sử dụng các phương thức HTTP một cách rõ ràng
Thiết lập một ánh xạ 1-1 giữa các hành động: tạo, đọc, cập nhật và xố các q trình vận hành và các phương thức HTTP:
POST (HttpPost) - Tạo một tài nguyên trên máy chủ GET (HttpGet) - Truy xuất một tài nguyên
PUT (HttpPut) - Thay đổi trạng thái một tài nguyên hoặc để cập nhật nó DELETE (HttpDelete) - Huỷ bỏ hoặc xoá một tài nguyên
Nguyên tắc 2: Phi trạng thái
Ta xem mơ hình giữa trạng thái và phi trạng thái để dễ so sánh: Mơ hình phi trạng thái:
Hình 1.8: Mơ hình phi trạng thái Mơ hình trạng thái:
Hình 1.9: Mơ hình trạng thái Ngun tắc 3: Hiển thị cấu trúc thư mục như URls
Cấu trúc địa chỉ của RESTful service:
Giấu các đuôi tài liệu mở rộng của bản gốc trong máy chủ (.jsp, .php, .asp). Để mọi thứ là chữ thường (thực ra là không phân biệt).
</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31">Sinhviênthựchiện:NguyễnQuangSách22 Thay thế các khoảng trống bằng gạch chân hoặc gạch nối
Tránh các chuỗi yêu cầu
Thay vì sử dụng mã (404 Not Found) khi yêu cầu địa chỉ cho một phần đường dẫn thı̀ luôn luôn cung cấp một trang mặc định hoặc tài nguyên như một phản hồi.
Nguyên tắc 4: Chuyển đổi JavaScript Object Notation (JSON) và XML.
Là mô ̣t bản tóm tắt các thuô ̣c tı́nh của những thứ trong mô hı̀nh dữ liê ̣u hê ̣ thống.
Định da ̣ng dữ liê ̣u mà ứng du ̣ng và trao đổi di ̣ch vu ̣ trong mức đáp ứng yêu cầu/ phản hồi hoă ̣c trong phần thân của HTTP.
Các chủ thể trong mô hı̀nh dữ liê ̣u có liên quan với nhau.
Cấu trúc di ̣ch vu ̣ sao cho nó tâ ̣n du ̣ng được phần đầu chấp nhâ ̣n HTTP có sẵn bên trong - mô ̣t loa ̣i MIME.
<b>1.3.2.4. Xây dựng Web service </b>
<b> Bước 1: Tạo cơ sở dữ liệu tên “Ghichu”, có một bảng “Ghichus”. Bước 2: Khởi đô ̣ng Visual Studio → tạo một project ASP.NET Web </b>
Application và chọn template Web API.
Từ Visual Studio 2015 vào menu File/chọn new/ chọn project:
<b>Hình 1.10: Tạo project trong Visual Studio 2015 </b>
</div><span class="text_page_counter">Trang 32</span><div class="page_container" data-page="32">Sinhviênthựchiện:NguyễnQuangSách23 Sau khi chọn project, màn hình sau xuất hiện:
Hình 1.11: Giao diện đặt tên cho project và cấu hình
Chọn các cấu hình như trên, đặt tên project là Khoaluan rồi nhấn OK. Sau đó
<b>chọn tiếp tục chọn như sau: </b>
Hình 1.12: Giao diện cấu hình cho project Nhấp OK và chờ Visual Studio tạo các file mẫu cho project
</div><span class="text_page_counter">Trang 33</span><div class="page_container" data-page="33">Sinhviênthựchiện:NguyễnQuangSách24 Visual Studio tạo ra projetc có mẫu như hình sau:
Hình 1.13: Giao diện tạo thành cơng project để xử lý tiếp theo
Giờ ta tiến hành tạo CSDL Ghichu bằng Entity framework code first trong
</div><span class="text_page_counter">Trang 34</span><div class="page_container" data-page="34">Sinhviênthựchiện:NguyễnQuangSách25 Chọn web API 2 Controller with actions, using Entity Framework như sau:
Hình 1.15: Giao diện chọn cấu hình cho Controller ApiController vừa tạo được như sau:
Hình 1.16: Giao diện viết các chức năng Web service trong Controller
</div><span class="text_page_counter">Trang 35</span><div class="page_container" data-page="35">Sinhviênthựchiện:NguyễnQuangSách26 Cuối cùng F5 để chạy project:
Hình 1.17: Giao diện Web service vừa tạo thành công
<b>1.4. Bảo mật trong Web service </b>
<b>1.4.1. Tổng quan về an toàn Web service </b>
Từ những giai đoạn đầu tiên của Internet, các doanh nghiệp luôn đòi hỏi rất khắt khe về vấn đề bảo mật trong thương mại điện tử. Những hạn chế của tường lửa như việc giám sát các gói tin được truyền tải dựa trên giao thức HTTP là chưa có, điều này có thể khiến cho máy chủ có nguy cơ bị những cuộc tấn công không hề biết được biết trước. Đã có rất nhiều các thuật tốn đưa ra cơ chế và những chuẩn về bảo mật như sự mã hố khố thơng tin, chữ ký số… nhưng hầu hết chỉ tập trung vào việc đưa ra các định dạng bảo về dữ liệu trong quá trình trao đổi, không quan tâm đến việc xác định các nghi thức mà các bên cần thực hiện khi tương tác với nhau.
Ngoài ra, những chuẩn chung về việc chỉ ra nghi thức giao tiếp giữa Web service là chưa có, đã khiến cho các sản phẩm hỗ trợ bảo mật của Web service khơng thể tích hợp với nhau, mặc dù các sản phầm này đều được thiết kế dựa trên chuẩn về bảo mật cho Web service.
Một chuẩn an toàn chung cho các hệ thống giao dịch trên mạng thường phải tập trung vào những điều sau:
Identification: định danh được những ai truy cập tài nguyên hệ thống.
</div><span class="text_page_counter">Trang 36</span><div class="page_container" data-page="36">Sinhviênthựchiện:NguyễnQuangSách27 Authentication: chứng thực truy cập tài nguyên của người muốn sử dụng. Authorization: cho phép giao dịch khi đã xác nhận định danh người truy cập. Integrity: tồn vẹn thơng tin trên đường truyền.
Confidentiality: độ an tồn, khơng ai có thể đọc thơng tin trên đường đi. Auditing: kiểm tra, tất cả các giao dịch đều được lưu lại để kiểm tra.
Non-repudiation: độ mềm dẻo, cho phép chứng thực hợp tính hợp pháp hóa của thơng tin đến từ một phía thứ ba ngồi hai phía là người gửi và người nhận.
<b>1.4.2. Bảo mật Web service 1.4.2.1. Khái niệm </b>
Bảo mật Web service là một chuẩn an toàn cho SOAP và cả những phần mở rộng của SOAP, nó được dùng khi muốn xây dựng những Web service toàn vẹn và tin cậy. Bảo mật Web service đảm bảo cho tính an tồn, sự tồn vẹn thơng điệp và tính tin cậy của thơng điệp.
<b>1.4.2.2. Chứng thực trong một ứng dụng </b>
Phía máy khách
Máy khách sẽ cung cấp một dấu hiệu an toàn trong tập tin mô tả cũng như phải chỉ rõ một Callback handler để lấy tài khoản và mật khẩu trong thông điệp SOAP và gửi tới máy chủ.
Phía máy chủ
Để cấu hình máy chủ an tồn cần có một dấu hiệu an tồn hợp lệ cũng như phải chỉ rõ một Callback handler để đọc dấu hiệu an toàn trong SOAP máy khách và xác nhận nó.
<b>1.4.2.3. Những thành phần mở rộng của bảo mật Web service </b>
Do bảo mật Web service chỉ là một lớp trong nhiều lớp của giải pháp an toàn đầy đủ, nên cần một mơ hình an tồn chung lớn hơn để có thể bao phủ tất cả các khía cạnh an tồn khác như đăng ký (logging) và khơng từ chối (non-repudiation).
</div><span class="text_page_counter">Trang 37</span><div class="page_container" data-page="37">Sinhviênthựchiện:NguyễnQuangSách28Hình 1.18: Mơ hình an tồn cho Web service
Trong mơ hình này các thành phần quan trọng bao gồm:
WS-SecureConversation Describes: thông điệp trao đổi giữa các phần, bao gồm sự trao đổi ngữ cảnh, thiết lập, dẫn xuất ra những phiên.
WS-Authentication Describes: quản lý những dữ liệu, chính sách cần 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: cho phép Web service an toàn trao đổi, tương tác với nhau.
<b>1.4.3. Giới thiệu các kỹ thuật bảo mật Web service </b>
<b>1.4.3.1. eXtensible Access Control Markup Language (XACML) </b>
Tổng quan XACML
Trong một mơi trường phân phối, ví dụ như thiết lập một Web service, thực hiện các chính sách điều khiển truy cập bằng cách cấu hình chúng tại mỗi điểm, khiến cho các chính sách trở nên đắt tiền và khơng đáng tin cậy. Hơn nữa, các chính sách điều khiển truy cập thường được thể hiện thông qua các ngôn ngữ độc quyền và khác nhau. XACML được hình thành để giải quyết vấn đè này, bằng cách cung cấp một tiêu chuẩn, ngôn ngữ duy nhất để xác định các chính sách điều khiển truy cập. XACML phiên bản 2.0 đã được chấp nhận như một tiêu chuẩn OASIS cùng với sáu cấu hình của XACML: SAML 2.0, XML Digital Signature, Privacy Policy (chính sách bảo mật), Hierarchical Resource (phân cấp tài nguyên) và RBAC (Role-Based Access Control).
</div><span class="text_page_counter">Trang 38</span><div class="page_container" data-page="38">Sinhviênthựchiện:NguyễnQuangSách29 Mơ hình của XACML
Hình 1.19: XACML Architecture
PEP (Policy Enforcement Point): Thực hiện kiểm soát truy cập bằng cách yêu cầu quyết định và thực thi các quyết định ủy quyền.
PAP (Policy Administration Point): Tạo và lưu trữ chính sách bảo mật.
PDP (The Policy Decision Point): Nhận, xem xét yêu cầu. Sau đó áp dụng các chính sách cùng với việc đánh giá các chính sách đó rồi trả về PEP
PIP (Policy Information Point): Là nguồn gốc của các giá trị thuộc tính hoặc các dữ liệu cần thiết để đánh giá chính sách.
Context Handler: Xác định để chuyển đổi các yêu cầu theo định dạng gốc của nó với hình thức XACML và chuyển đổi các quyết định ủy quyền theo hình thức XACML sang định dạng gốc.
Các chính sách XACML sẽ được nạp vào PAP, tại đây các chính sách sẽ được gửi tiếp tới PDP. PDP là điểm quyết định sẽ sử dụng chính sách nào cho các yêu cầu truy cập. Khi có một yêu cầu truy cập được gửi tới PEP, nó sẽ tiếp nhận các yêu cầu và thực hiện chúng bằng cách yêu cầu tới các văn bản xử lý. Các văn bản này lại được gửi yêu cầu tới PDP, tại đây các yêu cầu được xử lý và sau đó được gửi phản hồi lại cho
</div><span class="text_page_counter">Trang 39</span><div class="page_container" data-page="39">Sinhviênthựchiện:NguyễnQuangSách30Context Handler. Và tiếp tục gửi lại cho PEP - nơi thực hiện các chính sách sau khi đã qua q trình xử lý và thực hiện tại PDP. Sau khi thực thi các chính sách PEP sẽ gửi các chính sách tới các Máy chủ chứng thực và tạo ra các tài nguyên để chia sẻ. Các tài nguyên này kết hợp cùng với PIP được lưu trữ trở lại cho Context Handler phục vụ cho những yêu cầu lần sau.
<b>1.4.3.2. Security Assertion Markup Language (SAML) </b>
Tổng quan SAML
SAML là sự kết hợp giữa S2ML và AuthML, được phát triển thông qua OASIS. SAML là một tiêu chuẩn dựa trên XML, được hình thành như một khn khổ cho việc trao đổi thông tin liên quan đến an ninh, thể hiện dưới các xác nhận và sự tin tưởng giữa các bên tham gia trao đổi, nhằm xác thực giao tiếp người dùng, quyền lợi và các thuộc tính thơng tin.
Hoạt động của SAML
Hỗ trợ việc khẳng định các chứng thực gốc duy nhất giữa các domain với nhau. Việc khẳng định có thể truyền đạt thơng tin về các thuộc tính của đối tượng và có thể quyết định ủy quyền cho đối tượng được phép truy cập tài nguyên nhất định.
Xác thực tin tưởng
Chứng thực các vấn đề liên Domain Tập trung các vấn đề xác thực liên SAML hỗ trợ ba loại hình xác nhận:
Xác thực: Các đối tượng quy định được chứng thực tại thời điểm cụ thể. Thuộc tính: Các đối tượng quy định có liên quan tới thuộc tính được cung cấp.
Quyết định ủy quyền: một yêu cầu cho phép đối tượng quy định để truy cập vào tài nguyên quy định đã được cấp hoặc từ chối.
Đặc điểm của SAML
Một SAML duy nhất khẳng định có thể chứa một số báo cáo khẳng định về chứng thực, ủy quyền và các thuộc tính. Khẳng định là do cơ quan SAML, cụ thể là cơ quan thẩm định, cơ quan thuộc tính, hoặc là một điểm quyết định chính sách. Tuy nhiên, nó khơng cung cấp cơ chế để kiểm tra, thu hồi chứng chỉ. SAML cung cấp bối cảnh
</div><span class="text_page_counter">Trang 40</span><div class="page_container" data-page="40">Sinhviênthựchiện:NguyễnQuangSách31chứng thực, được truyền đạt (hoặc tham chiếu) một sự khẳng định của chứng thực đó. Khn khổ quy định của SAML là nhằm hỗ trợ nhiều tình huống kinh doanh thực trên thế giới, từ những người mà trong đó khách hàng là một trình duyệt để thêm những phần phức tạp nơi mà Web service có liên quan.
Bảo mật thơng tin SOAP, khẳng định SAML có thể được sử dụng trong thơng điệp SOAP để thực hiện vấn đề an ninh và nhận dạng thông tin giữa các hành động.
<b>1.4.3.3. XML Key Management Specification (XKMS) </b>
Bảo mật Web service xác định các cơ chế cơ bản cho việc cung cấp thông điệp an tồn, thơng điệp SOAP được bảo vệ bởi bảo mật Web service trình bày ba vấn đề chính đó là: tính khơng tương thích định dạng bảo mật thẻ, sự khác biệt không gian tên và sự tin cậy an ninh thẻ. Để khắc phục những vấn đề trên, cần thiết phải xác định tiêu chuẩn mở rộng để bảo mật Web service cung cấp các phương pháp nhằm đưa ra, đổi mới và xác nhận thẻ bảo mật và để thiết lập và đánh giá sự xuất hiện, mối quan hệ tin tưởng lẫn nhau. XKMS là một giao thức được phát triển bởi W3C để mô tả sự phân phối và đăng ký khóa cơng cộng, nó làm giảm các ứng dụng phức tạp cú pháp của nền tảng được sử dụng để thiết lập các mối quan hệ tin tưởng.
Trong hình vẽ sau, một dịch vụ X-KISS cung cấp cho khách hàng hai chức năng và có thể thực hiện bởi chính các dịch vụ X-KISS hoặc của một khóa cơ sở cơ bản. Đó là chức năng: xác định ví trí và tính xác thực. Đối với mục đích mã hóa, các chức năng cho phép một người gửi khơng cần biết chính xác liên kết với người nhận để có được thơng điệp đó. Các dịch vụ X-KISS không thực hiện bất kỳ sự khẳng định về tính hợp lệ của các liên kết giữa dữ liệu và khóa.
Hình 1.20: XKMS Services
</div>
