Tài liệu Nghiên cứu công nghệ SOA và bảo mật xác thực Xauth áp dụng xây dựng giải pháp quản lý sự cố mạng viễn thông

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ BÙI ĐỨC HIẾU NGHIÊN CỨU CÔNG NGHỆ SOA VÀ BẢO MẬT XÁC THỰC XAUTH ÁP DỤNG XÂY DỰNG GIẢI PHÁP QUẢN LÝ MẠNG VIỄN THÔNG Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SỸ NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. TRƯƠNG NINH THUẬN NGƯỜI ĐỒNG HƯỚNG DẪN: TS. TRỊNH THANH BÌNH Hà Nội - 2014 2 Lời mở đầu Với những dòng chữ tiên này, tôi xin dành để gửi lời cảm ơn chân thành và sâu sắc nhất tới thầy giáo, tiến sỹ Trương Ninh Thuận, tiến sỹ Trịnh Thanh Bình - người đã tận tình hướng dẫn, chỉ bảo và tạo cho tôi những điều kiện tốt nhất từ khi bắt đầu cho tới khi hoàn thành luận văn của mình. Đồng thời, xin trân trọng gửi lời cảm ơn tới tập thể các thầy giáo - Bộ môn Công Nghệ Phần Mềm - trường Đại học Công nghệ - Đại học Quốc gia Hà Nội đã tạo cho tôi một môi trường làm việc đầy đủ và thuận tiện. Xin cảm ơn tất cả những người thân yêu trong gia đình tôi cùng toàn thể bạn bè, những người đã luôn mỉm cười và động viên tôi mỗi khi vấp phải những khó khăn, bế tắc. Cuối cùng, xin chân thành cảm ơn ông Shakti (công ty Katjaksys), anh Nguyễn Minh Quân (công ty điện toán VDC), những người đã đem đến cho tôi những lời khuyên vô cùng bổ ích để giúp tháo gỡ những khó khăn, vướng mắc trong quá trình làm luận văn. 3 Mục lục Lời mở đầu ............................................................................................................ 3 Mục lục .................................................................................................................. 4 Danh sách hình vẽ ................................................................................................. 6 Bảng từ viết tắt ...................................................................................................... 8 Mở đầu................................................................................................................... 9 CHƯƠNG 1: TỔNG QUAN CÁC CÔNG NGHỆ PHÂN TÁN........................ 11 1.1. Hoàn cảnh ra đời .....................................................................................11 1.2. Một số mô hình trong hệ thống phân tán..............................................11 1.2.1. CORBA - Common Object Request Broker Architecture......... 12 1.2.2. DCOM – Distributed Component Object Model....................... 13 1.2.3. EJB – Enterprise Java Bean ....................................................... 13 1.3. Kết luận chương 1 ...................................................................................14 CHƯƠNG 2: KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ CÔNG NGHỆ WCF ....... 16 2.1. Giới thiệu kiến trúc hướng dich vụ SOA ..............................................16 2.1.1. Tổng quan .................................................................................. 16 2.1.2. Các nguyên tắc chính của hệ thống SOA .................................. 17 2.1.3. Các tính chất của hệ thống SOA ................................................ 18 2.1.4. Lợi ích của SOA......................................................................... 22 2.1.5. Kiến trúc phân tầng chi tiết của SOA ........................................ 23 2.1.6. Một số mô hình triển khai SOA ................................................. 26 2.1.7. Các phương pháp xây dựng hệ thống SOA ............................... 26 2.1.8. Chu trình phát triển của SOA: ................................................... 26 2.2. Tổng quan công nghệ WCF....................................................................28 2.2.1. Giới thiệu ................................................................................... 28 2.2.2. Ưu điểm của WCF ..................................................................... 29 2.2.3. Kiến trúc WCF ........................................................................... 30 2.3. Kết luận chương 2 ...................................................................................30 CHƯƠNG 3 NGHIÊN CỨU XÂY DỰNG GIẢI PHÁP CHO BÀI TOÁN QUẢN LÝ SỰ CỐ BTS ...................................................................................... 32 3.1. Xây dựng giải pháp .................................................................................32 3.1.1. Khảo sát bài toán ........................................................................ 32 4 3.1.2. Phân tích bài toán ....................................................................... 34 3.1.3. Xây dựng giải pháp .................................................................... 37 3.2.1. Xây dựng cơ sở dữ liệu lưu trữ .................................................. 40 3.3. Kết quả xây dựng và thử nghiệm phần mềm .......................................42 3.3.1. 3.4. Một số hình ảnh hoạt động của phần mềm: ............................... 42 Kết luận chương 3 ...................................................................................44 CHƯƠNG 4 NGHIÊN CỨU XÂY DỰNG GIẢI PHÁP XÁC THỰC BẢO MẬT DỊCH VỤ WEB VỚI OAUTH và XAUTH ............................................. 46 4.1. Tổng quan ................................................................................................46 4.2. Các vấn đề gặp phải ................................................................................46 4.3. Dịch vụ chia sẻ định danh mở OpenID .................................................47 4.4. Dịch vụ xác thực ủy quyền chia sẻ tài nguyên Oauth ..........................48 4.5. Cơ chế xác thực Oauth đề xuất cho bài toán ........................................51 4.6. Những vấn đề phát sinh của Oauth trên môi trường thiết bị di động52 4.7. Giải pháp XAuth và Service Authorization manager..........................53 4.8. Xây dựng xử lý xác thực .........................................................................54 4.9. Kết luận chương 4 ...................................................................................57 KẾT LUẬN ......................................................................................................... 58 Tài liệu tham khảo ............................................................................................... 59 5 Danh sách hình vẽ Hình 1: Mô hình tương tác của các đối tượng trong kiến trúc CORBA [1] ....... 12 Hình 2: Mô hình tương tác của các đối tượng trong kiến trúc DCOM ............... 13 Hình 3: Mô hình kiến trúc EJB ........................................................................... 14 Hình 4: Sơ đồ cộng tác trong SOA hiện nay ....................................................... 16 Hình 5: Cơ chế dò tìm dịch vụ động ................................................................... 20 Hình 6: Cơ chế phát hiện một dịch vụ khi dịch vụ đó Online ............................ 21 Hình 7: Kiến trúc phân tầng của SOA ................................................................ 24 Hình 8: Chu trình phát triển SOA ....................................................................... 27 Hình 9: Mô hình hoạt động của WCF tương tác với các thành phần client (Nguồn: Microsoft) ............................................................................................. 29 Hình 10: Kiến trúc của WCF (Nguồn: Microsoft) .............................................. 30 Hình 11:Mô hình hệ thống các phần mềm hỗ trợ điều hành mạng viễn thông... 32 Hình 12: Mô hình chức năng của hệ thống ......................................................... 34 Hình 13: Sơ đồ quy trình nghiệp vụ tổng thể ...................................................... 35 Hình 14: Sơ đồ quy trình nghiệp vụ quy trình quản lý danh sách BTS bị sự cố 36 Hình 15: Sơ đồ quy trình quản lý sự cố .............................................................. 36 Hình 16: Mô hình ứng dụng ................................................................................ 37 Hình 17: Mô hình triển khai hệ thống ................................................................. 38 Hình 18: Mô hình cơ sở dữ liệu phân hệ Hệ thống ............................................. 40 Hình 19: Mô hình cơ sở dữ liệu phân hệ Quản lý sự cố BTS ............................. 41 Hình 20: Quy trình xử lý xác thực định danh OpenId ........................................ 47 Hình 21: Quy trình xử lý xác thực, ủy quyền khai thác tài nguyên dịch vụ (Nguồn: Oauth.net).............................................................................................. 49 Hình 22: Quy trình xử lý xác thực, ủy quyền truy xuất tài nguyên đề xuất với bài toán hiện tại ......................................................................................................... 51 Hình 23: Xử lý xác thực theo cơ chế XAuth [4] ................................................. 54 Hình 24:Cơ chế làm việc của AuthorizationManager [4] ................................... 54 Hình 25: Khai báo AuthorizationManager.......................................................... 55 Hình 26: Đăng ký MyServiceAuthorizationManager với Web server ............... 56 Hình 27: Trạng thái đã xác thực thành công ....................................................... 56 Hình 28: Trạng thái xác thực thất bại.................................................................. 57 6 7 Bảng từ viết tắt Từ viết tắt Giải nghĩa SOA Service-oriented architecture WCF Windows Communication Foundation OAuth Open standard for authorization BTS Base transceiver station RESTful Representational State Transfer SOAP Simple Object Access Protocol JAXM Java API for XML Messaging CORBA Common Object Request Broker Architecture XSLT Extensible Stylesheet Language Transformations OAUTH Open standard for Authorization DCOM Distributed Component Object Model EJB Enterprise JavaBeans ORB Object Request Broker WSDL Web Services Description Language PDA Personal Digital Assistant BVT Ban Viễn Thông 8 Mở đầu Hiện nay, trên thế giới nói chung và Việt Nam nói riêng, việc ứng dụng các sản phẩm phần mềm vào quản lý doanh nghiệp, xử lý các nghiệp vụ của doanh nghiệp là nhu cầu tất yếu. Từ các ứng dụng đơn lẻ như: quản lý nhân sự tiền lương, quản lý công nợ, quản lý tài chính, quản lý và chăm sóc khách hàng, vv… đến một giải pháp tổng thể như HRM (Human Resource Management) hay ERP (Enterprise Resource Planning), tất cả đã và đang mang lại cho doanh nghiệp nhiều lợi ích thiết thực. Tập đoàn bưu chính viễn thông Việt Nam - VNPT là một tập đoàn lớn với nhiều tổng công ty, công ty thành viên, hoạt động triên nhiễu lĩnh vực khác nhau trong đó có công ty Viễn thông Vinaphone. Với đặc thù hoạt động của mình, công ty phải sử dụng hệ thống phần mềm hỗ trợ quản lý điều hành viễn thông để phục vụ công tác quản lý điều hành công ty. Quá trình hoạt động và phát triển của công ty đòi hỏi thường xuyên phải nâng cấp hệ thống phần mềm cũ đồng thời xây dựng các hệ thống phần mềm mới nhằm đáp ứng được yêu cầu ngày càng cao trong công tác quản lý, báo cáo, giám sát hoạt động của công ty trong thời kỳ mới. Hệ thống phần mềm hỗ trợ quản lý và điều hành viễn thông là một hệ thống bao gồm nhiều module như Phát triển thuê bao, Quản lý mạng cáp ngoại vi, Giao tiếp với các thiết bị tổng đài, Quản lý sự cố, Quản lý đánh số, … đa phần được xây dựng trên nền tảng cũ (mô hình Client Server, ngôn ngữ lập trình Visual basic và CSDL Oracle, …) vì vậy độ phức tạp lớn dẫn đến chi phí phát triển và bảo trì cao. Bên cạnh đó, hệ thống còn phải đối mặt với các khó khăn trong xu thế mới như vấn đề an ninh bảo mật, vấn đề tái sử dụng và mở rộng các hệ thống sẵn có, vấn đề về sự không tương thích giữa hệ thống BVT với các hệ thống phần mềm chạy trên các nền tảng khác của các đơn vị được phối hợp triển khai như kết nối với Hệ thống tính cước của các đơn vị Viễn thông tỉnh thành, Hệ thống xác thực Visa của công ty Điện toán và Truyền số liệu (VDC), Hệ thống MyTV Portal của công ty Phần mềm và truyền thông VASC, … Để khắc phục các nhược điểm trên, các thành viên trong đội ngũ phát triển TOS cũng như cá nhân tôi luôn trăn trở tìm kiếm các giải pháp mới để áp dụng. Hiện nay, 9 một giải pháp mới đang được cộng đồng công nghệ thông tin rất quan tâm, đó là “Kiến trúc hướng dịch vụ” (Service-oriented Architecture - SOA). Giải pháp này được kỳ vọng là chìa khóa giải quyết được các vấn đề phức tạp và sẽ là “xu thế trong tương lai”. Ngoài phần giới thiệu, kết luận và phụ lục. Luận văn được chia thành 4 chương trình: Chương 1 – Tổng quan các công nghệ phân tán. Chương này giới thiệu một cách tổng quan những công nghệ chính được sử dụng để phát triển các hệ thống phân tán, so sánh ưu và nhược điểm của các công nghệ cũng như tiền đề để lựa chọn giải pháp cho bài toán đang nghiên cứu tìm hiểu. Chương 2 – Kiến trúc hướng dịch vu (SOA) và công nghệ WCF. Chương này đi tìm hiểu về kiến trúc SOA như một giải pháp cho hệ thống phân tán, cơ chế hoạt động, các tính chất đặc điểm của kiến trúc SOA. Tìm hiểu công nghệ dịch vụ Web WCF của Microsoft để lý giải cho việc lựa chọn công nghệ này là giải pháp cho bài toán đã đặt ra. Chương 3 – Nghiên cứu và xây dựng giải pháp cho bài toán quản lý sự cố trạm BTS. Ở chương này, ta tiến hành khảo sát và phân tích bài toán Quản lý sự cố BTS – một trong 9 bài toán của hệ thống phần mềm quản lý mạng viễn thông. Từ đó áp dụng kiến trúc và công nghệ đã nghiên cứu ở các chương trước cho bài toán. Chương 4 – Nghiên cứu xây dựng giải pháp xác thực bảo mật dịch vụ web với Oauth và Xauth. Ở chương này luận văn tìm hiểu một số giải pháp xác thực bảo mật từ đó đề xuất xây dựng giải pháp bảo mật xác thực, ủy quyền truy xuất tài nguyên Oauth, đồng thời cải tiến phương pháp xác thực Xauth phục vụ việc xác thực tài khoản người dùng với phần mềm trên các môi trường thiết bị di động. 10 CHƯƠNG 1: TỔNG QUAN CÁC CÔNG NGHỆ PHÂN TÁN 1.1. Hoàn cảnh ra đời Tập đoàn bưu chính viễn thông Việt Nam (VNPT) là một tập đoàn viễn thông lớn với nhiều tổng công ty, công ty thành viên hoạt động trên nhiều lĩnh vực khác nhau: Bưu chính, viễn thông, kỹ thuật, dịch vụ, thiết bị, vv.. Trong thời gian gần đây, tập đoàn có nhiều sự thay đổi trong quy trình quản lý, điều hành các công ty thành viên, cùng với yêu cầu ngày càng cao trong công tác giám sát điều hành Hiện tại trong nội bộ các công ty trực thuộc tập đoàn đang sử dụng rất nhiều phần mềm hỗ trợ các công tác quản lý. Các phần mềm này có tính chất phức tạp và không đồng nhất về nền tảng công nghệ. Việc xây dựng hệ thống quản lý điều hành viễn thông mới phải thực hiện song song với việc tái sử dụng lại các thành phần của hệ thống cũ. Điều này nảy sinh khó khăn trong việc giao tiếp giữa các hệ thống khác nhau chưa được đáp ứng. Bên cạnh đó, việc phát triển quy mô của các doanh nghiệp, triển khai với nhiều chi nhánh cũng gặp nhiều khó khăn do các phần mềm chưa đáp ứng được yêu cầu bảo mật khi trao đổi thông tin qua môi trường Internet. Với đặc thù các chi nhánh áp dụng phần mềm quản lý phân bố rải rác trong cả nước dẫn đến chi phí phát sinh khi triển khai, nâng cấp và bảo trì hệ thống tốn kém thời gian và công sức. Hiện trạng của hệ thống hệ thống cũ đòi hỏi việc xây dựng được giải pháp cho hệ thống mới nhằm khắc phục những khó khăn và hạn chế đang tồn tại. Việc lựa chọn công nghệ phù hợp và đánh giá chất lượng của hệ thống là rất quan trọng cho tập đoàn trong việc quản lý và điều hành doanh nghiệp. Do vậy các tiêu chí được đặt ra đối với công nghệ sử dụng cho hệ thống mới: - Tối ưu hóa việc tái sử dụng lại các hệ thống hiện có mà chưa thể thay thế được Tạo môi trường đồng nhất cho nhu cầu chia sẻ, tương tác trao đổi của các hệ thống hiện có Đảm bảo an toàn, bảo mật thông tin giữa các hệ thống trên Internet. Giảm thiểu chi phí cài đặt, nâng cấp, bảo trì hệ thống tại các chi nhánh Dựa trên các tiêu chí đã đặt ra có thể thấy kiến trúc phù hợp với yêu cầu hệ thống mới là kiến trúc phân tán. Ta sẽ tìm hiểu các công nghệ hỗ trợ kiến trúc này và tìm giải pháp công nghệ phù hợp nhất cho bài toán. 1.2. Một số mô hình trong hệ thống phân tán Ba kiến trúc phân tán phổ biến nhất hiện nay là DCOM, CORBA và EJB. Các kiến trúc này là sự mở rộng của hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng. Đối tượng đó có thể không nằm trong vùng không 11 gian ứng dụng, hoặc nằm trên một máy khác không chứa ứng dụng nhưng vẫn được tham chiếu sử dụng như một phần ứng dụng. 1.2.1. CORBA - Common Object Request Broker Architecture CORBA là một tiêu chuẩn được định nghĩa bởi Object Managerment Group (OMG). Nó thiết kế nhằm mục đích để tạo thuận lợi cho việc giao tiếp giữa các hệ thống được triển khai trên các nền tảng khác nhau [1]. Đây là một kiểu kiến trúc phân tán mang đặc tính: mở, độc lập với nền tảng và không phụ thuộc vào ngôn ngữ lập trình. Hình 1: Mô hình tương tác của các đối tượng trong kiến trúc CORBA [1] CORBA cho phép các ứng dụng giao tiếp nhau mà không cần biết vị trí và ai đã tạo ra. ORB là thành phần trung gian phục vụ việc trao đổi giữa Client/ Server thông qua các Object. Với ORB, client có thể triệu gọi một phương thức trên object server một cách thông suốt mà object đó có thể nằm trên cùng một máy hay mạng máy tính. ORB có trách nhiệm tìm kiếm object mà có thể hiện thực các yêu cầu, truyền thông số, gọi phương thức của nó và trả về kết quả. Client không cần phải biết vị trí của object, ngôn ngữ lập trình, hệ điều hành hay bất kỳ khía mà nó không phải là thành phần của giao diện object. Trong mô hình client/server, những nhà phát triển có thể sửa dụng những phương pháp thiết kế hay những chuẩn riêng của mình để phát triển các ứng dụng. Với ORB, 12 giao thức được định nghĩa với những giao diện ứng dụng thông qua việc đặc tả không phụ thuộc ngôn ngữ mô tả, IDL. Ưu điểm của CORBA: có thể thoả mãn mọi ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển CORBA. Nhược điểm: là ngôn ngữ lập trình cấp thấp, khó học và cần đội ngũ phát triển có kinh nghiệm. Các đối tượng CORBA khó có thể tái sử dụng. 1.2.2. DCOM – Distributed Component Object Model Kiến trúc DCOM được phát triển xoay quanh mục tiêu thúc đẩy khả năng tương tác giữa các phần mềm. Kiến trúc này hỗ trợ một dạng “Software Bus”, ở đó các thành phần của phần mềm có thể được tái sử dụng và được hợp nhất với các thành phần khác tương đồng [2]. Hình 2: Mô hình tương tác của các đối tượng trong kiến trúc DCOM Ưu điểm: - Kiến trúc DCOM mang tính ổn định, hoạt động không phụ thuộc vào vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng. Kiến trúc này phù hợp với các doanh nghiệp sử dụng các ứng dụng cùng chạy trên nền Windows. Nhược điểm: Các công nghệ trong kiến trúc DCOM chỉ chạy được trên nền windows. 1.2.3. EJB – Enterprise Java Bean 13 Kiến trúc Java Bean định nghĩa một thành phần Java ở server-side và một giao diện lập trình cho các ứng dụng server. Các nhà phát triển sẽ xây dựng các thành phần, được gọi là enterprise beans, thành phần này chứa lớp Bussiness Logic của doanh nghiệp. Enterprise beans chạy trên server EJB để cung cấp các dịch vụ giao dịch và bảo mật cho beans. Các nhà phát triển sẽ không phải lo lắng về việc phải lập trình cấp thấp hay các dịch vụ phức tạp mà chỉ cần tập trung vào giải quyết các vấn đề ở tầng cao hơn.[3] EJB bao gồm 3 tầng: tầng trình diễn, tầng xử lý nghiệp vụ, tầng thứ 3 là các tài nguyên như cơ sở dữ liệu máy chủ. Do EJB là một kiến trúc độc lập nền tảng nên nó phù hợp với những hệ thống đòi hỏi khả năng tích hợp từ nhiều ứng dụng. Tuy nhiên, EJB không phải là một chuẩn mở dẫn đến kiến trúc này hạn chế trong khả năng giao tiếp với các chuẩn khác. Hình 3: Mô hình kiến trúc EJB 1.3. Kết luận chương 1 Tóm lại, các kiến trúc trên đều hướng đến vấn đề xây dựng kiến trúc hướng dịch vụ nhưng chúng còn gặp phải một số vấn đề như: - Tight coupling (tính ăn khớp): kiến trúc triển khai cài đặt phía nhà cung cấp và phía sử dụng dịch vụ phải giống nhau. - Những chuẩn trên đa phần là những chuẩn đóng. Ví dụ: đối tượng Java trong mô hình EJB chỉ trao đổi được với các đối tượng cùng mô hình và không thể trao đổi được với các đối tượng DCOM. 14 - Lượng thông tin trong mỗi lần giao dịch là ít, được thực hiện nhiều lần vì vậy dẫn đến chiếm dụng băng thông sử dụng và thời gian đáp trả dữ liệu nhanh. - Một vấn đề đặt ra là làm thế nào để các hệ thống phân tán phát triển trên các công nghệ khác nhau có thể giao tiếp được với nhau? Cách tiếp cận mới này đáp ứng được yêu cầu đó. Đó là cách tiếp cận theo kiểu “kiến trúc hướng dịch vụ.” 15 CHƯƠNG 2: KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ CÔNG NGHỆ WCF 2.1. Giới thiệu kiến trúc hướng dich vụ SOA 2.1.1. Tổng quan Hơn 40 năm qua hệ thống CNTT đã phát triển theo cấp số nhân, trong quá trình phát triển đó, các công ty phần mềm đã tạo ra nhiều kiến trúc xử lý phức tạp. Khả năng xử lý của các kiến trúc truyền thống đã đạt tới giới hạn của mình, trong khi nhu cầu về năng lực xử lý ngày càng tăng cao. Đòi hỏi công nghệ phần mềm phải đưa ra được kiến trúc có thể đáp ứng những nhu cầu đó từ phía doanh nghiệp. Ngoài ra các kiến trúc này phải thỏa mãn những yêu cầu về giảm chi phí, tăng khả năng tích hợp với các hệ thống của đối tác và khách hàng [4]. Kiến trúc hướng dịch vụ (Service Oriented Architecture) là một phương pháp thiết kế và tích hợp các phần mềm, chức năng hệ thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch vụ có tính loose coupling” và có khả năng truy cập thông qua môi trường mạng. Một cách đơn giản thì một hệ thống SOA là tập hợp các dịch vụ được chuẩn hoá trên mạng, trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ. SOA có ba đối tượng chính minh hoạ trong hình sau: SOAP data Service Consume r http://hostname/service. wsdll W S D L Service Provider Service Registry find publish UDD Hình 4: Sơ đồ cộng tác trong SOA hiện nay  Service Provider: Cung cấp stateless service phục vụ cho một nhu cầu nào đó. User (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động.  Serive Consumer: User sử dụng service được cung cấp bởi Service Provider. 16  Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider khác nhau, Service Consumer dựa trên những thông tin này để tìm kiếm và lựa chọn Service Provider phù hợp. SOA cung cấp các giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triến khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là điều kiện cơ sở, nền tảng để tích hợp, tái sử dụng những tài nguyên hiện có. Tư tưởng về một kiến trúc phần mềm hướng dịch vụ đã có từ các mô hình CORBA, DCOM (mô hình của Microsoft), EJB (mô hình của java) tuy nhiên những cách tiếp cận này còn gặp nhiều hạn chế (như luận văn đã phân tích ở trên). Kiến trúc SOA không chỉ cải tiến đáng kể mà còn đem đến nhiều ưu điểm nổi trội hơn các mô hình cũ. 2.1.2. Các nguyên tắc chính của hệ thống SOA Một hệ thống SOA phải đảm bảo đủ 4 nguyên tắc chính sau: - Sự phân định rạch ròi giữa các dịch vụ Do có sự tách biệt giữa thành phần giao tiếp và thành phần thực hiện dịch vụ trong kiến trúc hướng dịch vụ. Các dịch vụ này sẽ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp. Thành phần này sẽ quy định những dạng thông điệp trong quá trình trao đổi: thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý. Và đây chính là cách duy nhất để các đối tượng bên ngoài có thể truy cập vào thông tin và chức năng của dịch vụ. ta chỉ cần gửi thông điệp được định dạng đến trước để yêu cầu dịch vụ mà không cần biết thông điệp đó sẽ được xử lý như thế nào. - Các dịch vụ tự hoạt động Các dịch vụ cần được triển khai và hoạt động như một thực thể độc lập mà không phụ thuộc vào các dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó không bị sụp đổ khi có sự cố. Để thực hiện điều này, các dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong trường hợp dịch vụ cộng tác của nó bị hỏng, đồng thời sử dụng các biện pháp bảo mật để tránh các cuộc tấn công ồ ạt từ bên ngoài vào như gửi thông điệp lỗi hoặc thông điệp ồ ạt. - Các dịch vụ chia sẻ lược đồ 17 Các dịch vụ nên cung cấp thành phần giao tiếp (Interface) của nó ra bên ngoài và hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ liệu (Schema) chuẩn. Như thế hệ thống sẽ có tính dễ liên kết và dễ dàng mở rộng - Tính tương thích của các dịch vụ dựa trên chính sách Một dịch vụ muốn tương tác với các dịch vụ khác thì phải thoả mãn các chính sách (Policy), các yêu cầu (Requirements) của dịch vụ đó như: mã hoá, bảo mật. Mỗi dịch vụ phải cung cấp công khai các chính sách và các yêu cầu bảo mật của mình. 2.1.3. Các tính chất của hệ thống SOA - Loose coupling Có 2 dạng đặc tính mô tả mối kết hợp giữa các modul trong kiến trúc phần mềm: loose (rời) và tigh (chặt). Trong đó các mối kết hợp mang đặc tính loose có các ràng buộc được mô tả một cách rõ ràng. Ngược lại, với đặc tính tigh, các ràng buộc của mối kết hợp không được mô tả trước. Các ứng dụng hiện nay đều hướng tới đặc tính loose coupling nhằm tăng tính tường minh và khả năng kết nối giữa các thành phần. SOA thể hiện tính loose coupling thông qua việc sử dụng Contract and Binding (Hợp đồng và ràng buộc). Khi bắt đầu sử dụng dịch vụ, người dùng sẽ gửi yêu cầu tới đối tượng Registry để yêu cầu các thông tin của dịch vụ. Lúc này Registry trả lại thông tin của các dịch vụ thỏa mãn tìm kiếm. Bên sử dụng dịch vụ sẽ lựa chọn dịch vụ cần sử dụng và tiến hành thực thi các nhiệm vụ theo mô tả của dịch vụ đó. Việc sử dụng dịch vụ trong SOA không phụ thuộc vào tập tin cài đặt mà dựa vào hợp đồng và các ràng buộc sử dụng dịch vụ. Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệ thống đầu cuối. Mỗi hệ thống có thể tự quản lý độc lập làm tăng hiệu suất, khả năng mở rộng và khả năng đáp ứng cao. Loose coupling làm tách biệt giữa bên cung cấp và bên sử dụng, nhưng nó đòi hỏi các interface phải theo một chuẩn và cần một thành phần trung gian quản lý để trung chuyển yêu cầu giữa các hệ thống đầu cuối - Tái sử dụng dịch vụ Do SOA chạy trên môi trường mạng, các dịch vụ được đăng ký trên Internet giúp việc tìm kiếm, chia sẻ và tài sử dụng được thực hiện dễ dàng. Một số dịch vụ trong hệ thống SOA không cần tái sử dụng, những dịch vụ này sẽ không cần Interface mô tả. Việc tái sử dụng trong SOA còn được thực hiện bằng cách kết hợp nhiều dịch vụ để thực hiện các nhiệm vụ khác nhau. 18 Tái sử dụng trong SOA còn giúp loại bỏ bớt các thành phần trùng lặp trong hệ thống, tối giản hóa việc cài đặt và đơn giản hóa quản trị hệ thống. Những dịch vụ dùng chung bởi tất cả các ứng dụng của hệ thống SOA gọi là những shared infrastructure service - Sử dụng dịch vụ bất đồng bộ Trong kiến trúc SOA, phương thức triệu gọi bất đồng bộ hoạt động theo cơ chế sau: Ban đầu, bên yêu cầu sẽ gửi một thông điệp với đầy đủ ngữ cảnh tới bên nhận. Bên tiếp nhận yêu cầu sẽ thiết lập một “kênh thông điệp” để trả kết quả sau khi đã xử lý. Trong quá trình xử lý của bên nhận yêu cầu, bên gửi yêu cầu không phải chờ yêu cầu được xử lý xong, các yêu cầu tiếp theo sẽ được đưa vào 1 queue để xử lý lần lượt. Do bên gọi không phải chờ đợi cho đến khi yêu cầu được xử lý xong và trả về nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ. Trên lý thuyết một hệ thống SOA có thể hổ trợ gửi và nhận cả thông điệp đồngbộ và bất đồng bộ - Quản lý các Policy (chính sách) Mỗi một nhà cung cấp dịch vụ trên Internet đối với các dịch vụ cung cấp cho khách hàng sẽ có một luật kết hợp riêng gọi là các Policy. Các Policy tạo ra sự thống nhất trong việc tái sử dụng dịch vụ vì các Policy được thiết kế tách biệt và tuỳ vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm đồng thời có thể chia các nhóm làm việc mà không cần phụ thuộc vào nhau (nhóm phát triển phần mềm và nhóm điều hành,nhóm hỗ trợ). - Khả năng cộng tác Một trong những đặc tính nổi bật và quan trọng nhất trong kiến trúc SOA là khả năng cộng tác (interoperability), khả năng này giúp cho các ứng dụng được phát triển trên các nền tảng và ngôn ngữ khác nhau có thể giao tiếp được với nhau. Để làm được điều này, mỗi dịch vụ phải đưa ra một giao diện tích hợp (Interface) có thể triệu gọi tới thông qua một kết nối. Kết nối này được gọi là interoperable. Interoperable chứa một dạng giao thức và cấu trúc sao cho các client kết nối tới nó đều có thể hiểu được. Do vậy, interoperability hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và client. Các định dạng dữ liệu này có thể được ánh xạ thông qua một ngôn ngữ đặc tả trung gian. Đặc tả này sẽ chịu trách nhiệm ánh xạ giữa định dạng dữ liệu khả kết (interoperable) đến định dạng của dữ liệu tuỳ thuộc vào hệ thống. Ví dụ Wrb Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống JAX-RPC, JAXM chuyển các đối tượng dạng Java thành SOAP. - Tự động dò tìm và ràng buộc động 19 SOA hỗ trợ cơ chế dò tìm dịch vụ (Service discovery). Khi một client cần sử dụng một dịch vụ nào đó, SOA có thể tìm kiếm dịch vụ theo những tiêu chuẩn khi cần. Client chỉ cần đơn giản hỏi một Registry về dịch vụ thoả mãn yêu cầu. Hình 5: Cơ chế dò tìm dịch vụ động Khi một khách hàng (hoặc đôi khi là một dịch vụ hoặc những người cần gọi dịch vụ khác) cần phải kết nối với một dịch vụ đích , nó trước hết sẽ yêu cầu dịch vụ phát hiện thông qua "Probe " kèm theo các tiêu chí của dịch vụ. Thông thường các tiêu chí này chứa tên loại hợp đồng dịch vụ đích . Sau đó, các dịch vụ dò tìm sẽ tìm kiếm trong kho lưu trữ của mình theo các tiêu chí . Kho lưu trữ có thể là một cơ sở dữ liệu , một bộ nhớ cache phân phối hoặc một tập tin XML. Nếu nó phù hợp, dịch vụ phát hiện sẽ lấy các thông tin của Endpoint (người dùng đầu cuối), nó được gọi là siêu dữ liệu Endpoint và gửi lại . Và điều này được gọi là "Probe" (thăm dò). Cuối cùng là client nhận được các siêu dữ liệu phát hiện Endpoint và sẽ sử dụng các Endpoint này để kết nối với dịch vụ đích . Bên cạnh đó thăm dò , dịch vụ phát hiện nên chịu trách nhiệm cho biết có một dịch vụ mới có sẵn khi nó trực tuyến , cũng như dừng lại khi nó đi offline .Tính năng này 20 được đặt tên là "Announcement" (thông báo). Khi một dịch vụ bắt đầu và dừng lại, nó sẽ thông báo cho các dịch vụ dò tìm. Hình 6: Cơ chế phát hiện một dịch vụ khi dịch vụ đó Online - Đặc tính Self – healing (tự hồi phục) Đặc tính này cho phép một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần đến sự can thiệp của con người. Đây là một yếu tố quan trọng trong các ứng dụng hệ thống phân tán. Trong SOA, có thể có nhiều dịch vụ được tích hợp với nhau để thực hiện một công việc, mỗi dịch vụ trong hệ thống đó luôn tiềm ẩn nguy cơ ngừng bất cứ lúc nào, nhất là những ứng dụng tổ hợp của nhiều dịch vụ được phát triển bởi nhiều nhà cung cấp khác nhau. Điều này làm cho độ tin cậy của hệ thống giảm sút, điều này đòi hỏi các dịch vụ phải có khả năng phục hồi của sau khi gặp lỗi. Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một kiến trúc hỗ trợ kết nối và thực thi động như thế sẽ có khả năng tự phục hồi cao hơn kiến trúc không hỗ trợ tính năng này. Một tính chất cơ bản khác của hệ thống hướng dịch vụ là: có sự tách biệt giữa interface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho một interface. Nếu một thể hiện dịch vụ nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho 21