Luận văn: Tìm hiểu RESTful Web Services và ứng dụng xây dựng SMSGateway

Luận văn thạc sĩ: Nghiên cứu dịch vụ Web RESTful & ứng dụng xây dựng hệ thống SMS Gateway. Tìm hiểu kiến trúc, ưu điểm & triển khai thực tế.

• Tác giả: Nguyễn Thái Sơn
• Người hướng dẫn: TS. Võ Đình Hiếu
• Trường học: Trường Đại Học Công Nghệ - Đại Học Quốc Gia Hà Nội
• Chuyên ngành: Công Nghệ Thông Tin
• Đề tài: Tìm Hiểu Dịch Vụ Web Restful Và Ứng Dụng Trong Xây Dựng Hệ Thống Smsgateway
• Loại tài liệu: Luận Văn Thạc Sĩ
• Năm xuất bản: 2014
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI CẢM ƠN
• LỜI CAM ĐOAN
• Mục lục
• Danh mục các ký hiệu và chữ viết tắt
• MỞ ĐẦU
• Các hệ thống dựa trên dịch vụ web ngày nay
• Bố cục luận văn
• 1. Chƣơng 1: Dịch vụ Web và REST
• 1.1. Tổng quan về dịch vụ web
• 1.2. Kiến trúc và các thành phần của dịch vụ Web
• 1.3. Nguyên tắc của REST
• 1.3.1. Khả năng đánh địa chỉ
• 1.3.2. Phi trạng thái
• 1.3.3. Giao diện đồng nhất
• 1.3.4. Khả năng lưu cache
• 1.4. Tại sao lại chọn REST
• 1.5. Dịch vụ web RESTful
• 2. Chƣơng 2- Thƣ viện JAX-RS
• 2.1. Sử dụng thư viện JAX-RS
• 2.1.1. Tạo mới một customer
• 2.1.2. Nhận thông tin customer
• 2.1.3. Cập nhật customer
• 2.2. Các toán tử HTTP và ánh xạ URI
• 2.2.1. Các toán tử ràng buộc của HTTP
• 2.2.2. Ký hiệu @Path và tùy chọn mở rộng
• 2.3. Ánh xạ JAX-RS
• 2.3.1. Các ký hiệu ánh xạ lấy thông tin cơ bản
• 3. Chƣơng 3: Bảo mật với dịch vụ RESTful
• 3.1. Kiểu kiến trúc REST phù hợp với bộ đệm web
• 3.2. Khóa mã hóa nội dung đối xứng
• 3.3. Thảo luận về giải pháp
• 3.4. Áp dụng bảo mật dịch vụ web RESTful
• 3.4.1. Bảo mật dịch vụ web RESTful bằng cách cấu hình web
• 3.4.2. Bảo mật dịch vụ web RESTful bằng cách sử dụng SecurityContext
• 3.4.3. Bảo mật dịch vụ web RESTful bằng cách sử dụng ký hiệu
• 4. Chƣơng 4- Thiết kế và hiện thực hệ thống SMSGateway
• 4.1. Giới thiệu hệ thống
• 4.2. Nguyên tắc hoạt động
• 4.3. Hệ thống SMSGateway
• 4.4. Mục tiêu áp dụng REST
• 4.5. Đánh địa chỉ
• 4.6. Phi trạng thái
• 4.7. Liên kết với nhau
• 4.8. Giao diện đồng nhất
• 4.9. Khả năng cache
• 4.10. Cấu trúc REST API
• 4.11. Các lược đồ tuần tự
• 4.11.1. Lấy danh sách MO bằng thao tác GET
• 4.11.2. Lấy một MO bằng thao tác GET
• 4.11.3. Tạo mới một MO bằng thao tác POST
• 4.11.4. Update một MO bằng thao tác PUT
• 4.11.5. Xóa MO bằng thao tác DELETE
• 5. Chƣơng 5- Prototype
• 5.1. Một số đoạn code mô tả thực thi API
• 5.2. Test API với Google Chrome
• 5.3. Test API với giao diện ứng dụng
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng Quan về RESTful Web Services SMSGateway CNTT

Hệ thống dựa trên nền web cho phép truy cập ứng dụng hoặc dịch vụ từ bất cứ đâu thông qua trình duyệt web. Giao dịch được coi là đơn vị công việc duy nhất, cần được ghi log lại vào dữ liệu hệ thống dù thành công hay thất bại. Các hệ thống này đòi hỏi khả năng tồn tại 100%, xử lý lượng lớn giao dịch và sử dụng giao thức truyền thông tiêu chuẩn. Hầu hết các hệ thống web hiện nay dùng XML-RPC, API cho máy và người. Điều này gây ra vấn đề vì nhiều dịch vụ tương tự được cung cấp bởi cả hai API, làm tăng gấp đôi công việc phát triển và bảo trì. Vì vậy, cần một kiến trúc mới. REST (Representational State Transfer) là một giải pháp thích hợp cho vấn đề này. Thiết kế web service theo kiến trúc REST cần: Hiểu nguyên tắc của REST. Hiểu loại dữ liệu được điều khiển bởi các hệ thống web. Đưa ra phương pháp xây dựng cách thức truy cập dữ liệu sử dụng API REST. Cài đặt API RESTful. Chứng minh API có thể dùng chung cho cả người và máy. Theo tài liệu gốc, "Nhiều cuộc điều tra về một loại kiến trúc có tên là REST [7,15] đã được thực hiện và kết quả cho thấy REST là một giải pháp thích hợp cho vấn đề này."

1.1. Dịch Vụ Web và Bài Toán Tích Hợp Dữ Liệu Liên Nền Tảng

Dịch vụ web cho phép trao đổi và tương tác thông tin, chức năng, dữ liệu giữa các ứng dụng dễ dàng, bất kể môi trường phát triển hoặc ngôn ngữ lập trình. Theo W3C, dịch vụ web là hệ thống phần mềm có sẵn các tính năng hỗ trợ tương tác giữa máy tính và máy tính, giữa người và máy tính. Dịch vụ web cung cấp API mô tả theo WSDL. Người dùng tương tác thông qua giao thức SOAP, sử dụng HTTP kết hợp với XML. Bản chất của dịch vụ web là tập hợp các đối tượng, phương thức được thực thi và công bố lên mạng để triệu gọi từ xa. Công nghệ dịch vụ web kết hợp các ứng dụng dựa trên web, sử dụng các chuẩn mở như XML, SOAP, WSDL, UDDI. XML mô tả dữ liệu, SOAP truyền tải dữ liệu, WSDL mô tả dịch vụ web, UDDI cung cấp danh sách dịch vụ web hoạt động. XML giải quyết vấn đề tương thích, cho phép trao đổi thông tin và mô tả giao thức. SOAP là giao thức truy xuất thông tin từ dịch vụ web thông qua thông điệp chung. WSDL là tài liệu đặc tả dựa trên XML để mô tả dịch vụ web, cung cấp tài liệu cho hệ thống phân tán, mô tả chức năng, cách thức tương tác. UDDI cung cấp khả năng công bố, tổng hợp và tìm kiếm các dịch vụ web.

1.2. XML RPC Giới Hạn và Sự Ra Đời của RESTful Web Services

XML-RPC kế thừa từ RPC và World Wide Web, hỗ trợ giao tiếp giữa các chương trình trên máy tính. Web là công cụ giao tiếp giữa người và người, sau đó tiến hóa thành công cụ giao tiếp giữa người và máy tính, cuối cùng chuyển sang dạng truyền thông phức tạp giữa máy tính và máy tính. HTML thành công trong việc hiển thị thông tin cho con người. W3C phát triển XML (eXtensible Markup Language), ngôn ngữ đánh dấu cung cấp linh hoạt hơn HTML về việc giao tiếp giữa các chương trình. XML được truyền giữa các máy tính sử dụng giao thức HTTP thông qua RPC. HTTP yêu cầu đồng bộ và phi trạng thái. Yêu cầu XML-RPC luôn có một trả lời XML-RPC tương ứng. XML cũng có khả năng thực thi hệ thống không đồng bộ. Phi trạng thái có nghĩa là không có nội dung được hiểu từ yêu cầu này đến yêu cầu tiếp theo. Tuy nhiên, XML-RPC có các nhược điểm: Yêu cầu XML-RPC bao gồm hành động và các tham số. API XML-RPC cần định nghĩa mã lỗi riêng. Chức năng xác thực và cache bên phía máy khách không thể thực hiện được. Dịch vụ RESTful là một giải pháp mới có thể thay thế XML-RPC để khắc phục các nhược điểm này.

II. RESTful Kiến Trúc Nguyên Tắc Ứng Dụng Trong CNTT

REST (Representational State Transfer) là kiểu kiến trúc được định nghĩa bởi Roy Fielding. Mục đích của REST là thiết kế các ứng dụng mạng phân tán sử dụng HTTP như giao thức tầng ứng dụng và là mô hình kiến trúc thực sự cho web. Web dựa vào tài nguyên, URI và liên kết, HTTP và các tính năng của nó. Các dịch vụ web lớn không nhận ra lợi ích từ dịch vụ web hướng tài nguyên. Chúng không có khả năng đánh địa chỉ, không cache, kết nối không tốt, không cần giao diện đồng nhất, không rõ ràng. REST là một kiểu kiến trúc cho hệ thống phân tán như World Wide Web. Để thực thi kiến trúc RESTful, cần tuân thủ theo kiến trúc hướng tài nguyên (ROA), cho phép thiết kế dịch vụ RESTful. Kiến trúc REST dựa vào các nguyên tắc: Tài nguyên (Resources), Khả năng đánh địa chỉ (Addressability), Phi trạng thái (Statelessness), Kết nối (Connectedness), Giao diện đồng nhất (Uniform Interface), Khả năng lưu cache (Cacheability).

2.1. Sáu Nguyên Tắc Vàng Của Kiến Trúc RESTful Trong CNTT

Mọi thứ mà dịch vụ cung cấp đều là tài nguyên. Tài nguyên có thể là đối tượng vật lý hoặc khái niệm trừu tượng. Mọi tài nguyên có duy nhất một URI. Thông tin nào đó không có URI thì không phải là tài nguyên. Hai tài nguyên không thể có cùng một URI, nhưng hai URI có thể trỏ vào cùng một tài nguyên vào cùng một thời điểm. Khả năng đánh địa chỉ: Mọi tài nguyên đều được đánh địa chỉ, có đủ URI để đánh địa chỉ cho mọi tài nguyên. Cho phép lưu lại các trang thông tin cần thiết, gửi URI này tới người khác như một tài nguyên. Với khả năng lưu cache, tài nguyên được lưu ở máy khách sau lần truy cập đầu tiên. Phi trạng thái: Mọi yêu cầu HTTP đều hoàn thành riêng biệt nhau. Thông tin trong yêu cầu phải được đệ trình lên máy chủ. Dịch vụ không dựa vào thông tin của các yêu cầu trước. Nếu máy chủ yêu cầu dữ liệu của yêu cầu trước, máy khách phải gửi lại thông tin đó xem như là một yêu cầu mới. Máy chủ không giữ bất kỳ thông tin gì của máy khách. Điều này làm cho hệ thống đáng tin cậy, đơn giản và khả năng mở rộng lớn hơn. Kết nối: Dịch vụ RESTful cho phép máy khách chuyển từ trạng thái này sang trạng thái khác bằng cách gửi các liên kết trong các đại diện với nhau. Tất cả các tài nguyên nên kết nối và liên kết với nhau, cho phép máy khách biết được nhau bằng cách duyệt các siêu liên kết trong các đại diện tài nguyên. Giao diện đồng nhất: Máy khách tương tác với hệ thống thông qua các phương thức của HTTP: GET, POST, PUT, DELETE. Các phương thức này định nghĩa những thứ có thể làm với một tài nguyên. Khả năng lưu cache: Tài nguyên nên được cache lại trên máy khách với một điều kiện và một khoảng thời gian. Giúp người dùng tải tài nguyên tốt hơn, nhanh hơn, giảm tải cho máy chủ về thời gian và lưu lượng.

2.2. Phương Thức HTTP GET POST PUT DELETE Trong RESTful API

HTTP GET: Nhận thông tin. An toàn và không thay đổi. Không làm thay đổi trạng thái của máy chủ. Có thể nhiều yêu cầu giống hệt nhau mà cho kết quả như nhau. Nếu yêu cầu thành công và kết quả là một tài nguyên được trả về thì thông điệp trạng thái trả về phù hợp với yêu cầu đó là 200 (thành công). Nếu tài nguyên không tồn tại thì trạng thái trả về là 404 (không thành công, tài nguyên không tìm thấy). HTTP POST: Yêu cầu tạo tài nguyên mới với dữ liệu đính kèm theo yêu cầu. Nếu yêu cầu POST mà không trả về kết quả, tài nguyên có thể được xác định bởi URI, trạng thái trả về nếu thành công là 200 (thành công). Nếu tạo tài nguyên mới thì trạng thái trả về là 201 (tạo tài nguyên mới) và chứa đựng thông tin mô tả trạng thái của yêu cầu và tham chiếu tới tài nguyên mới ở phần header của thông tin. HTTP PUT: Yêu cầu thực thể đính kèm được cung cấp theo cùng yêu cầu URI. Nếu URI tham chiếu tới tài nguyên đã tồn tại thì thực thể kèm theo sẽ được xem xét thay đổi ở trên máy chủ. Nếu tài nguyên đó chưa tồn tại thì có khả năng URI đó yêu cầu một tài nguyên mới, máy chủ sẽ phải tạo một tài nguyên mới với URI đó, nếu tài nguyên mới được tạo thì trạng thái trả về là 201, nếu tài nguyên đã tồn tại tức là thay đổi tài nguyên thì trạng thái trả về là 200. PUT và POST khác nhau về ý nghĩa, trong phương thức PUT thì URI định nghĩa các thực thể đính kèm với yêu cầu. Ngược lại trong phương thức POST trong URI yêu cầu định nghĩa tài nguyên mà sẽ điều khiển thực thể kèm theo. HTTP DELETE: Yêu cầu máy chủ xóa tài nguyên được xác định trong yêu cầu. Nếu xóa thành công thì mã trạng thái 200 (thành công) sẽ được trả về.

III. Vì Sao Chọn RESTful Web Services Cho Ứng Dụng CNTT

Các lý do chọn REST: Mỗi đối tượng vật lý hoặc khái niệm trừu tượng đều có thể xem như một tài nguyên duy nhất, được truy cập nhanh chỉ với một yêu cầu duy nhất. Với nguyên tắc phi trạng thái, REST làm cho hệ thống linh động tốt hơn khi máy chủ không bắt được thông tin của máy khách. Các máy chủ được kết nối với hệ thống đều có thể nhận bất kỳ yêu cầu nào từ máy khách và trả lời máy khách một cách phù hợp. Nếu dịch vụ không theo RESTful, các dịch vụ rất khó liên kết với nhau vì các tài nguyên không có khả năng đánh địa chỉ, không kết nối được với nhau, các phương thức của HTTP sử dụng trong mỗi yêu cầu không theo một mẫu chuẩn. Theo kiểu kiến trúc REST, máy khách có thể đoán được giao diện tương tác được thiết kế như thế nào và kết nối trực tiếp với thông tin cần thiết sử dụng URI chỉ định hoặc điều hướng qua đại diện sử dụng các liên kết. Khả năng lưu cache có thể dễ dàng sử dụng, làm giảm tải cho máy chủ và cải thiện thời gian cho máy khách. Dịch vụ RESTful là dịch vụ web áp dụng các nguyên tắc của REST để thiết kế và phát triển. REST là kiểu kiến trúc tầng dưới của web, áp dụng các nguyên tắc REST có nghĩa là sẽ tích hợp trực tiếp vào web hơn là tập trung vào các chức năng.

3.1. Ưu Điểm Vượt Trội Của RESTful So Với Các Kiến Trúc Khác

Dịch vụ RESTful sử dụng tài nguyên web như các khái niệm trừu tượng chính. Có rất nhiều lợi thế mà web đã đưa ra: Các kiểu dữ liệu chuẩn và phổ biến được sử dụng để mô tả dữ liệu, các loại dữ liệu này cũng được dùng để mô tả tài nguyên ở phía máy khách tùy theo yêu cầu của máy khách. Giao diện đồng nhất được cung cấp từ khi phương thức HTTP chuẩn được sử dụng. Thực sự độc lập ngôn ngữ. Khi sử dụng HTTP thì vượt qua tường lửa không phải là vấn đề. Lưu cache có thể làm tăng khả năng thực hiện. HTTP được sử dụng trong tầng ứng dụng, bởi vậy tất cả các tính năng chuẩn của HTTP được kết thừa vào trong dịch vụ RESTful, các tính năng quan trọng như mã hóa, xác thực và cache. Các vấn đề thuận lợi này được cung cấp phổ biến trong dịch vụ web 2.0 để phát triển dịch vụ RESTful như Yahoo, Amazon, Flickr.

3.2. Khi Nào Nên Và Không Nên Sử Dụng Kiến Trúc RESTful

Kiến trúc RESTful phù hợp khi cần tính linh hoạt, khả năng mở rộng cao, dễ dàng tích hợp với các hệ thống khác và tận dụng các tính năng của giao thức HTTP. RESTful đặc biệt hữu ích cho các ứng dụng web, ứng dụng di động và các API công khai. Tuy nhiên, RESTful có thể không phù hợp khi cần tính bảo mật cao, xử lý giao dịch phức tạp hoặc yêu cầu hiệu suất cực cao. Trong những trường hợp này, các kiến trúc khác như SOAP hoặc gRPC có thể là lựa chọn tốt hơn.

IV. Thư Viện JAX RS Xây Dựng RESTful Web Services Trên Java

Trong vài năm gần đây, việc xây dựng dịch vụ RESTful trong java gắn liền với các servlet API. Servlet mang đến cho bạn một giao thức HTTP rất gần gũi, tất nhiên là yêu cầu rất nhiều mã lập trình trong quá trình phát triển để chuyển đổi các thông tin từ một yêu cầu HTTP. Năm 2008, đặc tả mới JAX-RS được định nghĩa và hỗ trợ thực thi các dịch vụ RESTful. JAX-RS là framework tập trung vào ánh xạ các ký hiệu java với các đối tượng java rõ ràng. Có các ký hiệu để ràng buộc các mẫu URI cụ thể và các toán tử HTTP tới các phương thức riêng của lớp java. Cũng có các ký hiệu ánh xạ tham số giúp dễ dàng lấy các thông tin từ yêu cầu HTTP. Có phần thân thông điệp như reader và writer cho phép tách riêng các định dạng dữ liệu từ các đối tượng dữ liệu java. Có cơ chế ánh xạ lỗi với các mã lỗi của HTTP. Cuối cùng là cơ chế phù hợp với sự điều chỉnh nội dung của HTTP.

4.1. Ký Hiệu JAX RS và Ánh Xạ Request HTTP Vào Java Code

Ký hiệu @javax.Path được đặt ở đầu lớp CustomerResource cho ta biết đang sử dụng dịch vụ JAX-RS. Ký hiệu @Path có giá trị là /customers, cho biết đây là đường dẫn gốc của dịch vụ customers. Ký hiệu @javax.POST sẽ ràng buộc yêu cầu HTTP POST đối với phương thức createCustomer(). Ký hiệu @Consumes chỉ ra kiểu dữ liệu cần tạo để trả lại cho người dùng theo yêu cầu. Ký hiệu @javax.GET để ràng buộc toán tử GET của HTTP với phương thức java. Chúng ta sử dụng thêm ký hiệu @Path để xác định URI ràng buộc với phương thức này. Giá trị của ký hiệu này sẽ được nối với giá trị của ký hiệu @Path. Ký hiệu @javax.Produces đối với phương thức getCustomer() để chỉ cho JAX-RS biết kiểu dữ liệu trả về cho máy khách là application/xml. Ký hiệu @PathParam sẽ thông báo cho JAX-RS biết rằng tham số id được truyền từ URI vào. Ký hiệu @javax.PUT để ràng buộc yêu cầu HTTP PUT với phương thức updateCustomer().

4.2. Khai Thác Sức Mạnh Ánh Xạ URI với PathParam QueryParam FormParam

JAX-RS định nghĩa rất nhiều ký hiệu để lấy thông tin từ yêu cầu HTTP và ánh xạ nó vào các phương thức java. Các ký hiệu ánh xạ lấy thông tin cơ bản: @javax.PathParam: Cho phép trích lọc các giá trị từ các tham số tạm đưa vào từ URI. @QueryParam: Cho phép trích lọc các giá trị từ các tham số truy vấn vào từ URI. @FormParam: Cho phép trích lọc các giá trị từ dữ liệu trên form gửi vào. @MatrixParam: Cho phép trích lọc các giá trị từ các tham số dạng ma trận vào từ URI. @HeaderParam: Cho phép trích lọc các giá trị từ phần header của yêu cầu HTTP. @CookieParam: Cho phép trích lọc các giá trị từ cookie của HTTP được gửi bởi máy khách. Các ký hiệu này thường được sử dụng trong các tham số của phương thức truy cập tài nguyên. Khi JAX-RS nhận yêu cầu HTTP nó sẽ tìm ra phương thức java mà phục vụ yêu cầu này. Nếu phương thức java có tham số thì chúng sẽ được khai báo ngay phía sau các ký hiệu tương ứng, từ đó các ký hiệu này sẽ có nhiệm vụ trích lọc thông tin từ HTTP ánh xạ vào các tham số thực để cho các phương thức java sử dụng.

V. Bảo Mật RESTful Web Services Giải Pháp Cho Ứng Dụng CNTT

Các phương pháp bảo mật cơ bản gồm xác thực người dùng và bảo mật tầng vận chuyển về việc bảo mật phiên làm việc qua mạng. Cơ chế bảo mật các URL qua mạng bằng cách xác nhận cho các máy chủ. Cookies của web được sử dụng để truyền thông tin và thực hiện các thông tin bảo mật trong yêu cầu HTTP trong suốt phiên làm việc. Có nhiều cách để thiết kế và thực thi ứng dụng web. Một trong các mô hình có thể đáp ứng được vấn đề này đó chính là REST. URI có thể được tham chiếu đến sau phiên làm việc, đây cũng là điều mà các mô hình ứng dụng khác khó có thể đạt được. Kiến trúc bảo mật web có thể liên kết tốt hơn với kiểu kiến trúc REST, làm cho tất cả lợi thế về khả năng mở rộng bộ đệm của kiểu kiến trúc REST. Cần đưa ra phương pháp bảo mật phù hợp với kiến trúc REST, sử dụng khóa bảo mật nội dung, chia sẻ thời gian sống của nội dung được lưu bộ nhớ và chuyển tới máy khách qua HTTP bảo mật sau khi người dùng được xác thực thích hợp.

5.1. Xác Thực Cấp Quyền Mã Hóa Dữ Liệu Trong RESTful

Giải pháp bảo mật RESTful: Cần thiết phải mã hóa cùng một nội dung qua nhiều phiên làm việc. Máy chủ cần có cơ chế nội dung một lần duy nhất trong suốt thời gian ở bộ đệm. Khóa bảo mật nội dung trong đó chia sẻ thời gian sống của nội dung được lưu bộ nhớ và chuyển tới máy khách qua HTTP bảo mật sau khi người dùng được xác thực thích hợp. Với công nghệ java OAuth cần yêu cầu sử dụng các thành phần sau đây: Project Jersey, thư viện mã nguồn mở của SUN thực thi đặc tả JAX-RS cho dịch vụ web REST thông qua các thành phần mở rộng jersey hỗ trợ OAuth. OpenSSO, thư viện mã nguồn mở của SUN thực thi trình quản lý truy cập định danh cho doanh nghiệp, hỗ trợ dịch vụ OAuth Token thông qua các thành phần mở rộng. Yêu cầu đối với đối tượng dùng dịch vụ: Bộ lọc máy khách Jersey OAuth(Jersey OAuth Client Filter), thêm các yếu tố bảo mật cần thiết một cách tự động để yêu cầu máy khách gửi đi. Thư viện chữ ký Jersey OAuth(Jersey OAuth Signature Library), API mà bộ lọc máy khách sử dụng. Yêu cầu đối với đối tượng cung cấp dịch vụ: nhà cung cấp dịch vụ REST dựa vào jersey yêu cầu các thành phần: Jersey OAuth Signature Library, API được sử dụng bởi bộ lọc máy và các thành phần khác để xác nhận các yêu cầu ở máy chủ. OpenSSO OAuth Filter, thành phần nhà cung cấp dịch vụ mà cung cấp xác nhận sự xác thực và cấp quyền. OpenSSO Server, cung cấp dịch vụ xác thực và cấp quyền. Token Service, dịch vụ mở rộng cho vấn đề token OAuth.

5.2. Bảo Vệ API Web.xml SecurityContext và Ký Hiệu Bảo Mật JAX RS

Để bảo mật dịch vụ web RESTful theo giải pháp đã đưa ra, cần thực hiện theo một trong các phương pháp xác thực, cấp quyền, hoặc mã hóa. Trong mô tả web.xml của ứng dụng web chứa dịch vụ RESTful, cần đưa vào các mô tả, hay các thẻ mô tả để có thể ứng dụng được chức năng bảo mật, cần làm các việc như sau: Định nghĩa một thẻ cho mỗi tập tài nguyên (các URI) mà ta có kế hoạch bảo mật. Sử dụng thẻ để định nghĩa kiểu xác nhận mà ta muốn sử dụng và các realm bảo mật mà các ràng buộc trong đó sẽ được áp dụng. Định nghĩa một hoặc nhiều tập quyền sử dụng thẻ và ánh xạ chúng vào vào các ràng buộc bảo mật định nghĩa trong bước một. Để mã hóa cần thêm thẻ và thêm vào thẻ này một thẻ con với giá trị CONFIDENTIAL. Trong RESTful, gói giao diện javax.SecurityContext cung cấp thông tin bảo mật liên quan đến yêu cầu người dùng. Truy cập đối tượng SecurityContext thêm thể hiện vào các trường của lớp như phương thức setter hoặc các tham số của phương thức sử dụng đối tượng javax. Gói javax.security cung cấp cho chúng ta các ký hiệu để có thể giúp RESTful Web service bảo mật hơn: @DeclareRoles, được sử dụng bởi ứng dụng để khai báo các quyền. @DenyAll, chỉ ra rằng không có quyền bảo mật nào được phép yêu cầu xác định tài nguyên chỉ đỉnh. @PermitAll, chỉ ra rằng tất cả các quyền bảo mật được phép truy cập tài nguyên được chỉ định. @RolesAllowed, chỉ ra danh sách các quyền được phép truy cập vào tài nguyên của ứng dụng. @RunAs, định nghĩa định danh ứng dụng trong suốt quá trình thực thi trong trình chứa J2EE.

VI. SMS Gateway với RESTful API Thiết Kế Hiện Thực Hệ Thống

Chương này giới thiệu tổng quan về hệ thống cũng như lược đồ, cấu trúc của hệ thống SMSGateway và các công nghệ quan trọng được sử dụng trong hệ thống, cũng trong chương này sẽ mô tả quá trình thiết kế REST API, mô tả cấu trúc REST API sẽ xây dựng, nó được xây dựng như thế nào, môđun nào sẽ được làm và với mỗi môđun như vậy nó làm gì và tương tác với môđun khác như thế nào, hơn nữa sẽ giải thích nguyên tắc REST áp dụng vào hệ thống như thế nào, ngoài ra còn mô tả lược đồ use case chính được sử dụng. Hệ thống SMSGateway là cổng tin nhắn SMS cung cấp cho các khách hàng có nhu cầu gửi tin nhắn SMS qua các đầu số ngắn. Hỗ trợ nhiều loại nội dung, như: text, logo, picture, java game, hình ảnh, nhạc chuông, wap push,... SMSGateway được xây dựng dành cho các khách hàng lớn có lượng tin nhắn hàng ngày rất lớn và có nhiều loại tin nhắn khác nhau như các ngân hàng, công ty bảo hiểm, công ty chứng khoán, các sàn giao dịch, các doanh nghiệp cung cấp dịch vụ.

6.1. Kiến Trúc và Nguyên Tắc Hoạt Động Của SMS Gateway

Nguyên tắc hoạt động: Khách hàng nhắn tin, với nội dung theo cú pháp nhất định, và gửi đến đầu số điện thoại. Telco tiếp nhận tin nhắn, phân tích và gửi đến hệ thống tương ứng. SMSGateway tiếp nhận xử lý tin nhắn, sau khi xử lý xong sẽ gửi lại cho khách hàng một tin nhắn. Hệ thống SMSGateway được viết trong ngôn ngữ java. Java được chọn vì: Hoạt động trên bất kỳ HĐH nào, hỗ trợ nhiều loại database, cơ chế QUEUE, STORE & FORWARD, tự động điều chỉnh tốc độ gửi tin nhắn, kết hợp lưu trữ database và file để đảm bảo không bị mất dữ liệu, tự động phát hiện mất kết nối và tự động kết nối lại, cơ chế cảnh báo khi có sự cố, hỗ trợ nhiều loại nội dung, giao diện đơn giản, dễ thao tác, phù hợp với việc triển khai ở Việt Nam, hoạt động ổn định 24/24. Hệ thống SMSGateway cung cấp hai API, một cái được sử dụng để giao tiếp giữa máy tính và máy tính, và một cái được dùng để giao tiếp giữa người và máy tính.

6.2. Thiết Kế RESTful API Cho SMS Gateway Bài Toán Thực Tế

Hệ thống gồm ba tầng chính: tầng lưu trữ dữ liệu, tầng nghiệp vụ chứa hầu hết các nghiệp vụ logic, tầng thứ ba cũng là tầng trên cùng chứa một vài nghiệm vụ logic và API của GUI và XML-RPC. Nhiều dịch vụ được cung cấp bởi cả hai API và lượng công việc và lượng code sẽ tăng gấp đôi nếu tái sử dụng hoặc nâng cấp các dịch vụ trên, hơn nữa mỗi API đều có nhược điểm của nó: nhược điểm của XML-RPC, nhược điểm của GUI. Cần thay thế API cũ bằng RESTful API để tận dụng các ưu điểm của REST. Thiết kế RESTful API cho phép máy khách tương tác với hệ thống SMSGateway thông qua các phương thức của HTTP: GET, POST, PUT, DELETE. Các phương thức này định nghĩa những thứ có thể làm với một tài nguyên SMS, cho phép máy khách dễ dàng truy vấn, tạo mới, cập nhật và xóa tin nhắn SMS.

Trích đoạn nội dung tài liệu

Chương 1: Giới thiệu chung về dịch vụ web, kiến trúc và các thành phần cơ bản của dịch vụ web như XML, SOAP, WSDL và UDDI từ đó đưa ra mục tiêu phát triển luận văn, cũng trong chương này sẽ giới thiệu về REST, mô tả từ khóa REST ngày nay rất phù hợp với nền tảng cơ bản với dịch vụ web, đưa ra lý do tại sao chọn REST để phát triển dịch vụ web, và phần giới thiệu hệ thống mà sau này tác giả có ý định phát triển dịch vụ RESTful cũng được giới thiệu trong phần này. Chương 2: Giới thiệu thư viện JAX-RS và cách sử dụng thư viện vào việc lập trình phát triển dịch vụ web, các tính năng cũng như các toán tử của thư viện JAX-RS cũng sẽ được trình bày ở chương này. Chương 3: Chương này giới thiệu các phương pháp bảo mật cơ bản cũng như cách thực hiện và áp dụng vào hệ thống sẽ được tác giả trình bày trong chương này. Chương 4: Chương này sẽ giới thiệu chi tiết về hệ thống SMSGateway, nguyên tắc hoạt động của hệ thống cũng như mục tiêu mà hệ thống cần đạt được, áp dụng các nguyên tắc của REST và sử dụng thư viện JAX-RS để thiết kế các dịch vụ web RESTful ứng dụng vào hệ thống SMSGateway, ngoài ra các lược đồ tuần tự ở cấp độ cao sẽ được thiết kế và chỉ ra trong chương này để ta có thể thấy được REST API phân biệt các môđun khác nhau như thế nào và tương tác như làm sao.

Chương 5: Chương này sẽ giới thiệu các đoạn code mô tả các tiến trình phát triển ứng dụng và cung cấp một một vài tool để có thể kiểm chứng ứng dụng thực hiện các yêu cầu REST API. 6 TIEU LUAN MOI download : [e-mail] Chƣơng 1: Dịch vụ Web và REST Chương này sẽ giới thiệu tổng quan về dịch vụ web, kiến trúc, thành phần cơ bản, cũng trong chương này chúng ta sẽ tìm hiểu nguồn gốc từ REST và ý nghĩa của nó, tại sao chúng ta lựa chọn REST thay thế mà không phải là cái khác, giới thiệu những ý tưởng cơ bản của REST, các đặc điểm chính và lý do tại sao chúng ta lại sử dụng REST 1.1 Tổng quan về dịch vụ web Theo định nghĩa của W3C (World Wide Web Consortium) [8] thì một dịch vụ web là một hệ thống phần mềm được xây dựng sẵn các tính năng cần thiết, hay còn gọi là các phương thức theo chuẩn để hỗ trợ sự tương tác giữa máy tính và máy tính, giữa người và máy tính. Dịch vụ web cung cấp một API được mô tả theo một định dạng chung gọi là ngôn ngữ mô tả dịch vụ web (Web Service Description Language) viết tắt là WSDL [11]. Người dùng hoặc máy tính thực hiện tương tác với dịch vụ web thông qua giao thức SOAP (Simple Object Access Protocol) [10].

Đây là một trong các giao thức được sử dụng để trao đổi thông tin trên mạng phổ biến nhất hiện nay sử dụng HTTP (Hypertext Transfer Protocol) [2,3,4] kết hợp với việc sử dụng XML cùng với một số chuẩn khác. Như vậy ta thấy mục đính chính của dịch vụ web là cho phép trao đổi và tương tác thông tin, các chức năng, dữ liệu giữa các ứng dụng một cách dễ dàng mà không cần quan tâm đến môi trường phát triển cũng như ngôn ngữ lập trình bởi tất cả đã cả được quy về một định dạng chung. Ngoài ra bản chất của dịch vụ web là một tập hợp các đối tượng, các phương thức được thực thi và công bố lên mạng để có thể triệu gọi được từ xa thông qua các ứng dụng khác nhau.2 Kiến trúc và các thành phần của dịch vụ Web Công nghệ dịch vụ web không phải là một công nghệ mới, mà công nghệ này ra đời dựa trên các nền tảng công nghệ sẵn có trước đó. Công nghệ này là sự kết hợp các ứng dụng dựa trên nền web sử dụng các chuẩn mở như XML, SOAP, WSDL, UDDI [8].

Trong đó XML được sử dụng để mô tả dữ liệu, SOAP đóng vai trò giao thức truyền tải dữ liệu, WSDL đóng vài trò mô tả cho dịch vụ web còn UDDI đóng vai trò cung cấp danh sách các dịch vụ web đang hoạt động. Chi tiết về các chuẩn mở này chúng ta sẽ bàn chi tiết trong phần sau, phần các thành phần cơ bản của dịch vụ web. 7 TIEU LUAN MOI download : skknchat@gmail.1: Mô hình kiến trúc dịch vụ web 1.1 XML XML (Extensible Markup Langguage) là một chuẩn do W3C đề ra và được phát triển từ SGML, XML là một ngôn ngữ đánh dấu mở rộng với cấu trúc do lập trình viên phát triển dịch vụ tự định nghĩa. Về hình thức thì XML hoàn toàn có cấu trúc thẻ giống như HTML, nhưng HTML định nghĩa thành phần được hiện thị như thế nào thì XML lại định nghĩa những thành phần đó chứa những cái gì.

Hay nói cách khác XML có cú pháp tương tự HTML nhưng không tuân theo một đặc tả quy ước như HTML. Người sử dụng hoặc các chương trình có thể quy ước định dạng các thẻ XML. Dịch vụ web là sự kết hợp của nhiều thành phần khác nhau, và dịch vụ này hỗ trợ tương tác giữa các hệ thống được cài đặt trên môi trường khác nhau. Do đó cần phải sử dụng một loại tài liệu đồng nhất giúp giải quyết được vấn đề tương thích và XML hoàn toàn phù hợp với yêu cầu trên.

XML đã trở thành nền tảng cho việc xây dựng các dịch vụ web và XML có hai chức năng chính:  Trao đổi thông tin dữ liệu trong hệ thống sử dụng dịch vụ web  Mô tả các giao thức sử dụng trong dịch vụ web 1.2 SOAP SOAP (Simple Object Access Protocol) là một giao thức dùng để truy xuất các thông tin từ dịch vụ web thông qua một thông điệp chung. SOAP được Microsoft đề xuất vào năm 1998, hiện nay SOAP thuộc quyền quản lý và cải tiến của tổ chức W3C. SOAP là một giao thức dựa trên nền tảng XML, mô tả cách định dạng, đóng gói thông tin của các 8 TIEU LUAN MOI download : [e-mail] thông điệp và trao đổi chúng thông qua mạng mà không phụ thuộc bất kỳ môi trường thực thi hay ngôn ngữ lập trình nào. Đơn vị trao đổi thông tin cơ bản của SOAP là thông điệp SOAP (SOAP Message).

Mỗi thông điệp SOAP sẽ được dùng bởi một thẻ gốc là <Envelope> trong đó chứa 2 thẻ thành phần là SOAP Header và SOAP Body. SOAP Header chứa các thông tin cần thiết cho việc thực hiện chuyển thông điệp hay cơ chế định danh, bảo mật. SOAP Body chứa dữ liệu ứng dụng. Cấu trúc của một thông điệp SOAP như hình sau: Hình 1.2: Cấu trúc của một thông điệp SOAP 1.3 WSDL WSDL (Web Service Description Langguage) là một tài liệu đặc tả dựa trên chuẩn ngôn ngữ XML để mô tả các dịch vụ web.

Ban đầu WSDL được Microsoft và Ariba đề xuất, nhưng hiện nay WSDL được quản lý và phát triển bởi W3C. Mỗi một đặc tả WSDL sẽ cung cấp tài liệu cho các hệ thống phân tán cũng như mô tả chức năng của một dịch vụ web, cách thức tương tác, các thông điệp tương tác cho các yêu cầu theo request hay response. Sau đây là cấu trúc cơ bản của một tài liệu: 9 TIEU LUAN MOI download : skknchat@gmail.3:Cấu trúc của WSDL Một đặc tả WSDL bao gồm 2 phần chính: phần trừu tượng (Abstract definitions) và phần cụ thể (Concrete definitions), phần trừu tượng bao gồm các thông tin được chứa trong các thẻ types, message và portypes. Phần cụ thể bao gồm các thông tin được chứa trong các thẻ bindings và ports.

Mỗi thành phần sẽ có một tham chiếu đến một thành phần khác được mô tả như hình sau: Hình 1.4:Các thành phần của WSDL 10 TIEU LUAN MOI download : [e-mail] Mỗi một thành phần có một chức năng riêng, cụ thể như sau:  Types: chỉ ra kiểu dữ liệu cho các thông điệp gửi và nhận  Messages: là một thành phần trừu tượng mô tả cách thức giao tiếp giữa máy khách và máy chủ.  Porttypes: mô tả ánh xạ giữa các thông điệp, được mô tả trong phần tử messages và các phương thức (operations).  Binding: xác định giao thức nào được sử dụng khi giao tiếp với dịch vụ web, định nghĩa kiểu binding và giao thức vận chuyển binding cũng định nghĩa các operations.  Port: chỉ định địa chỉ và cổng kết nối tới dịch vụ web, thường là một địa chỉ URL đơn giản.4 UDDI UDDI (Universal Description, Discovery và Integration) cũng được Microsoft, IBM và Ariba đề xuất năm 2000.

Ngày nay UDDI thuộc quyền sở hữu và phát triển của tổ chức OASIS (Organization for the Advancement of Structured Information Standards). UDDI được xây dựng nhằm mục đính cung cấp khả năng cho phép công bố, tổng hợp và tìm kiếm các dịch vụ web. UDDI đưa ra một tập hợp các hàm API được chia làm 2 phần: Inquiry API, dùng để tìm kiếm và truy xuất các dịch vụ web đã đăng ký và Publisher „s API, dùng để công bố các dịch vụ web muốn đăng ký. Thông tin tổ chức trong UDDI được chia làm 3 phần:  White pages: liệt kê thông tin của các nhà cung cấp dịch vụ web, bao gồm địa chỉ, thông tin liên lạc và định danh.

 Yellow pages: phân loại dịch vụ theo tổ chức hay nhóm dịch vụ hoặc địa điểm đặt các dịch vụ.  Green pages: cung cấp thông tin về các dịch vụ web, cách thức truy cập cũng như tương tác với các dịch vụ web đó. 11 TIEU LUAN MOI download : skknchat@gmail.3 XML-RPC XML-RPC được kế thừa từ RPC và World Wide Web, sử dụng lại ý tưởng và nền tảng về việc tạo ra sự giao tiếp giữa con người với nhau để hỗ trợ việc giao tiếp giữa các chương trình trên máy tính. Mặc dù web là công cụ giao tiếp giữa con người với con người, sau đó được tiến hóa một cách tinh tế để làm công cụ giao tiếp giữa con người và máy tính, cuối cùng chuyển sang dạng truyền thông phức tạp giữa máy tính và máy tính HTML thực sự đã rất thành công, nhưng thực tế mới chỉ hữu ích cho các giao dịch hiển thị thông tin cho con người.

Vì lý do đó, W3C tổ chức phát triển eXtensible Markup Language (XML), một ngôn ngữ đánh dấu cung cấp linh hoạt hơn HTML về việc giao tiếp giữa các chương trình. XML được truyền giữa các máy tính sử dụng giao thức HTTP thông qua RPC, sử dụng HTTP có nghĩa là các yêu cầu XML-RPC phải được đồng bộ và phi trạng thái, một yêu cầu XML-RPC luôn luôn có một trả lời XML-RPC tương ứng, bởi vì yêu cầu và trả lời đều phải xảy ra trên cùng một kết nối HTTP.