TIỂU LUẬN MÔ HÌNH TÍNH TOÁN HƯỚNG DỊCH VỤ

MÔ HÌNH TÍNH TOÁN HƯỚNG DỊCH VỤ TIỂU LUẬN ĐỀ TÀI: MÔ HÌNH TÍNH TOÁN HƯỚNG DỊCH VỤ (SERVICEORIENTED COMPUTING Công nghệ thông tin đang ngày càng phát triển, trở thành ngành mũi nhọn trong chiến lược phát triển kinh tế của mỗi quốc gia. Đối tượng phục vụ chủ yếu hiện nay của CNTT là các tổ chức, các cơ sở doanh nghiệp.

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG =====o0o===== TIỂU LUẬN ĐỀ TÀI: MÔ HÌNH TÍNH TOÁN HƯỚNG DỊCH VỤ (SERVICE-ORIENTED COMPUTING) NHÓM 09 Giáo viên giảng dạy: TS. Vũ Thị Hương Giang Sinh viên thực hiện: Vũ Thị Thùy Như Phạm Thị Nhung Nguyễn Thị Thi Lớp: 12BCNTT2 Hà Nội, tháng 1/2013 MỤC LỤC 1. Tổng quan mô hình tính toán hướng dịch vụ 1.1 Các khái niệm và đặc trưng 1.1.1 Khái niệm Công nghệ thông tin đang ngày càng phát triển, trở thành ngành mũi nhọn trong chiến lược phát triển kinh tế của mỗi quốc gia. Đối tượng phục vụ chủ yếu hiện nay của CNTT là các tổ chức, các cơ sở doanh nghiệp. Với sự phát triển của Internet và với xu thế hội nhập chung của toàn thế giới, các tổ chức, doanh nghiệp cần bắt tay, phối hợp hoạt động và chia sẻ tài nguyên với nhau để nâng cao hiệu quả hoạt động. Khi đó các sản phẩm sẽ ngày càng phức tạp, kéo theo chi phí sản xuất, quản lý và bảo trì. Đặc biệt, ngành công nghệ phần mềm còn đối mặt với vấn đề hóc búa là bảo mật, và tái sử dụng lại các hệ thống sẵn có, vấn đề không tương thích về hệ thống giữa các tổ chức hợp tác với nhau. Để giải quyết vấn đề trên người ta đã đưa ra nhiều giải pháp và hiện nay, một giải pháp đang được quan tâm là kiến trúc hướng dịch vụ (Service Oriented Architecture – SOA). Tính toán hướng dịch vụ (SOC) dùng để chỉ tập hợp các khái niệm, nguyên lý và các phương thức dùng để tính toán trong mô hình kiến trúc hướng dịch vụ (SOA) với các phần mềm ứng dụng được xây dựng dựa trên các thành phần độc lập với một chuẩn giao diện. SOC phát triển phần mềm thành 3 phần độc lập: người xây dựng ứng dụng (Service providers), người cung cấp ứng dụng (Application builders), kết nối ứng dụng (Service brokers) Người cung cấp ứng dụng: Họ sử dụng các ngôn ngữ lập trình như Java, C#, … để viết chương trình. Các thành phần sẽ được tính hợp với nhau theo một giao diện chuẩn, gọi là dịch vụ hay mạng dịch vụ nếu các dịch vụ sử dụng trên internet. Kết nối ứng dụng: các dịch vụ có thể đăng ký và công bố cho việc truy nhập chung, giúp người xây dựng ứng dụng tìm hiểu các dịch vụ mà họ cần. Người xây dựng ứng dụng: thay vì xây dựng phần mềm từ đầu bởi các ngôn ngữ lập trình cơ bản, người xây dựng ứng dụng đại diện cho người sử dụng cuối để xác định ứng dụng logic của ứng dụng, sử dụng các dịch vụ chuẩn như là các thành phần. 3 1.1.2 Đặc trưng và lợi ích SOC được sử dụng bởi những người dùng lớn như ngân hàng (web dịch vụ của ngân hàng). Hàng không (web dịch vụ của hàng không), cơ quan du lịch (web dịch vụ hỗn hợp liên kết với dịch vụ hàng không, khách sạn, tàu xe…) SOC tạo điều kiện cho các doanh nghiệp làm việc cùng nhau: các công việc trong quá trình kinh doanh hoặc cung cấp sản phẩm sẽ dễ dàng hơn với các nhà cung cấp ở bên ngoài. Mục tiêu hàng đầu của SOC là tạo sự liên kết của việc truy nhập dịch vụ phần mềm thông qua giao thức chuẩn, các chức năng có thể tự động cập nhật và tích hợp vào ứng dụng hoặc được tích hợp vào các dịch vụ phức tạp hơn. Lợi ích của việc sử dụng tính toán hướng dịch vụ với mô hình tính toán đối tượng Tính năng Object-Oriented Computing Service-Oriented Computing Phương pháp ứng dụng được xây dựng bởi các lớp, kiến trúc ứng dụng là sự phân cấp và sự kế thừa Ứng dụng được xây dựng bởi các dịch vụ lỏng lẻo và tạo thành các ứng dụng thực thi Trừu tượng hóa và liên kết Việc phát triển ứng dụng là một đội chịu trách nhiệm cho toàn bộ vòng đời của ứng dụng. các nhà phát triển phải có kiến thức về các lĩnh vực ứng dụng và lập trình Việc phát triển ứng dụng được chia ra làm 3 phần độc lập: người xây dựng ứng dụng, nhà cung cấp dịch vụ, kết nối ứng dụng. Người xây dựng ứng dụng phải hiểu biết về ứng dụng và không cần biết các dịch vụ sẽ được thực hiện như thế nào. Các nhà cung cấp dịch vụ có thể lập trình nhưng không cần hiểu rõ về ứng dụng sẽ sử dụng dịch vụ nào Chia sẻ code và tái sử dụng Tái sử dụng code được thể hiện ở tính kế thừa giữa các lớp thông qua hàm thư viện. các hàm thư viện sẽ được cập nhập lại trong quá trình biên dịch và có nền tảng phụ thuộc Tái sử dụng code là ở các mức dịch vụ. các dịch vụ có giao diện chuẩn và được công bố trên các kho lưu trữ internet. Đó là các nên tảng độc lập có thể được tìm kiếm và truy nhập từ xa. Các dịch vụ môi giới cho phép chia sẻ hệ thống dịch vụ Liên kết động Ta phải gắn tên cho một Liên kết một dịch vụ là yêu 4 và tái cấu hình phương thức trong quá trình chạy. các phương thức phải liên kết đến mã thực thi trước khi ứng dụng được tích hợp cầu dịch vụ đó trong thời gian chạy. Các dịch vụ có thể được tìm thấy sau khi ứng dụng đã được tích hợp. tính này cho phép một ứng dụng có thể được tích hợp lại trong thời gian chạy Bảo trì hệ thống Người dùng phải thường xuyên nâng cấp phần mềm. ứng dụng phải dừng khi ta tiến hành nâng cấp Các mã dịch vụ ở thuộc tính dịch vụ của các nhà cung cấp. Dịch vụ có thể được cập nhật mà không cần sự tham gia của người sử dụng 1.2. Các nguyên lý của mô hình tính toán hướng dịch vụ 1.2.1 Tình huống sử dụng (Use Cases) Tính toán hướng dịch vụ cung cấp các công cụ để mô hình hóa thông tin và sự liên hệ giữa các mô hình, xây dựng quy trình hệ thống, bảo đảm các giao dịch, thêm các quyết định hỗ trợ, quan hệ giữa các chức năng của thành phần phần mềm đến các tổ chức mà họ đại diện. Tính toán theo định hướng dịch vụ cho phép chỉnh sửa các ứng dụng mới bằng cách cung cấp một giao diện dịch vụ Web loại bỏ vấn đề tin nhắn và cung cấp một cơ sở ngữ nghĩa để tùy chỉnh các chức năng của ứng dụng. Tính toán hướng dịch vụ có thể cho phép tự do lựa chọn các đối tác kinh doanh dưa trên các tiêu chi chuẩn chất lượng của mỗi dịch vụ mà mỗi bên có thể tùy chỉnh nó. Tính toán theo định hướng dịch vụ cung cấp hỗ trợ lựa chọn động của các đối tác như trừu tượng hóa, các trạng thái giao dịch sẽ được ghi và thao tác linh hoạt, theo cách này, lựa chọn động được khai thác để mang lại khả năng chịu lỗi cấp ứng dụng Tính toán theo định hướng dịch vụ cho phép sử dụng hiệu quả các nguồn tài nguyên lưới. Tính toán theo hướng dịch vụ tạo điều kiện cho Utility Computing, đặc biệt server dự phòng được sử dụng để đạt được khả năng chịu lỗi. Tính toán hướng dịch vụ cung cấp một mô hình ngữ nghĩa phong phú và linh hoạt tính toán đơn giản hoá việc phát triển phần mềm. 5 1.2.2 Mô hình kiến trúc hướng dịch vụ (SOA) Kiến trúc hướng dịch vụ (Service Oriented Architecture) là một hướng tiếp cận với việc 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: Hình 1: Sơ đồ cộng tác trong SOA hiện nay Nhà cung cấp dịch vụ (Service Provider) cần cung cấp thông tin về những dịch vụ của mình trong một dịch vụ lưu trữ thông tin dịch vụ (Service Registry). Người sử dụng (Service Consumer) tìm kiếm thông tin về dịch vụ cần thiết trong Service Regisstry sau đó xây dựng kênh giao tiếp với nhà cung cấ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ó. Thật ra, tư tưởng về một kiến trúc hướng dịch vụ không phải là mới mà CORBA, DCOM (mô hình của Microsoft), EJB (mô hình của java) đã thực hiện từ lâu, tuy nhiên cách tiếp cận này còn gặp nhiều hạn chế (như đã nói ở trên). 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. 6 2. Lộ trình nghiên cứu mô hình tính toán hướng dịch vụ 2.1. Tổng quan về lộ trình nghiên cứu mô hình tính toán hướng dịch vụ Lộ trình nghiên cứu mô hình tính toán hướng dịch vụ đưa ra một kiến trúc dựa trên dịch vụ được phân tầng logic, để tạo ra một môi trường IT có khả năng tương tác và thích nghi. Môi trường này có khả năng biểu diễn các chính sách nghiệp vụ được chi tiết hóa và các luật trừu tượng hóa. Mục đích của nó là cung cấp tính năng để bảo đảm tính nhất quán trong tổ chức, tính sẵn sàng cao của dịch vụ, bảo mật các dịch vụ và thông tin không công khai, kết hợp nhiều dịch vụ như là một phần của ứng dụng phức hợp. Sơ đồ trong hình dưới đây chỉ ra các hướng nghiên cứu SOC. Hình 2: Các hướng nghiên cứu SOC Về cơ bản, lộ trình nghiên cứu được chỉ ra trên 3 mức: - Thiết lập dịch vụ (service foundation): là mức thấp nhất sử dụng các service middleware cơ bản và thành phần kiến trúc (architectural constructs and functionality) để mô tả, xuất bản, và khám phá (discover) dịch vụ. - Tích hợp dịch vụ (service composition): tích hợp nhiều service nhỏ riêng lẻ để xây dựng service phức hợp. Các service phức hợp này lại có thể được sử dụng như một ứng dụng hoàn thiện, hay góp phần xây dựng nên các service phức hợp mức cao hơn. 7 - Quản lý và giám sát dịch vụ (service management and monitoring): quản lý và giám sát ứng dụng SOA trong suốt vòng đời của nó, bao gồm từ cài đặt, cấu hình, cho tới thu thập thông tin hoạt động và tối ưu hóa dịch vụ. - Thiết kế và phát triển dịch vụ (service-oriented engineering): quá trình thiết kế và phát triển ứng dụng SOC. 2.2. Các hướng cụ thể trên lộ trình nghiên cứu mô hình tính toán hướng dịch vụ 2.2.1 Thiết lập dịch vụ Lớp dưới cùng của mô hình phát triển ứng dụng SOC là bước thiết lập dịch vụ (service foundation) nhằm cung cấp hạ tầng middleware hướng dịch vụ có khả năng kết nối các thành phần và hệ thống không đồng nhất, đồng thời cho phép cung cấp dịch vụ trên nhiều kênh truy nhập như thiết bị di động, thiết bị cầm tay, qua mạng Internet, mạng di động, và các hạ tầng mạng khác. Kết quả nghiên cứu hiện tại Hạ tầng cho Web service và SOC được xây dựng dựa trên khái niệm Enterprise Service Bus (ESB) với hai ý tưởng chính: kết nối lỏng lẻo (loosely couple) các hệ thống tham gia cung cấp dịch vụ, và phân rã hệ thống thành các thành phần đơn lập dễ quản trị. Hình 3: Enterprise Service Bus kết nối nhiều ứng dụng và công nghệ khác nhau ESB là một mạng trao đổi thông điệp (message backbone) được thiết kế dựa trên các chuẩn mở nhằm cho phép cài đặt, triển khai, và quản trị các hệ thống SOA. Một mô hình khá thích hợp và thành công cho ESB là mô hình container. Với mô hình này, việc cài đặt dịch vụ được thực hiện dựa trên các container đảm nhận: - Tạo kết nối và quy cách trao đổi thông điệp (Message Exchange Patterns). - Hỗ trợ quản lý giao dịch, bảo mật, đo lường hiệu năng. - Hỗ trợ cấu hình động. 8 - Giám sát hoạt động và trạng thái bên trong của hệ thống. - Thực hiện chuyển đổi giao thức và dữ liệu. - Hỗ trợ khai phá dịch vụ. Các thách thức và vấn đề cần nghiên cứu o Cấu hình động cho kiến trúc thực thi (run-time architecture) o Khả năng kết nối động o Định tuyến dựa trên chủ đề và nội dung o Giải pháp bảo mật end-to-end o Hỗ trợ tích hợp tiến trình, thông tin, và ứng dụng o Cơ chế khai phá dịch vụ 2.2.2 Tích hợp dịch vụ Lớp tích hợp dịch vụ là lớp đảm nhận việc tích hợp nhiều dịch vụ riêng rẽ thành một dịch vụ phức hợp. Thành phần thực hiện công việc này gọi là bộ tích hợp dịch vụ. Một mặt nó hấp thụ, sử dụng các dịch vụ đã được phát triển và cung cấp sẵn. Mặt khác, nó cũng trở thành thành phần cung cấp dịch vụ bằng cách xuất bản mô tả dịch vụ của các dịch vụ phức hợp nó tạo ra. Kết quả nghiên cứu hiện tại Hiện đã có một số dự án xây dựng đặc tả cho việc mô tả tiến trình nghiệp vụ, nhằm định nghĩa và quản lý các tiến trình và tương tác nghiệp vụ, còn được gọi là “orchestration”. Orchestration mô tả các thức các dịch vụ tương tác với nhau ở mức thông điệp và thứ tự thực hiện tương tác dưới các góc nhìn khác nhau. Các thách thức và vấn đề cần nghiên cứu - Phân tích khả năng có thể phối hợp của các service - Khả năng tự phối hợp các dịch vụ - Phối hợp dịch vụ có quan tâm tới QoS - Phối hợp dịch vụ hướng nghiệp vụ - Phối hợp tài nguyên, nhân lực, và tổ chức dưới dạng dịch vụ 2.2.3 Quản lý và giám sát dịch vụ Quản lý các dịch vụ được liên kết lỏng lẻo với nhau trong SOA là một yêu cầu rất quan trọng. Quá trình phát triển các dịch vụ phức hợp yêu cầu cho phép theo dõi “sức khỏe” của các dịch vụ thành phần, tránh trường hợp một thành phần bị lối hoặc thay đổi dẫn đến gián đoạn hoạt động của một loạt dịch vụ liên quan. Quản lý và giám sát dịch vụ SOA bao gồm một loạt hoạt động như cài đặt và cấu hình dịch vụ, cho tới thu thập các tham số đánh giá hiệu năng và tối ưu hóa hệ thống để đảm bảo cung cấp dịch vụ với tốc độ đáp ứng yêu cầu. Kết quả nghiên cứu hiện tại 9 Hình 4 mô tả một mô hình kiến trúc quản lý, kết hợp quản lý dịch vụ với một kênh ứng dụng theo SOA. Kiến trúc này cung cấp kết nối liên tục giữa kênh ứng dụng Web service và chuyển hướng nó tới kênh quản lý. Ví dụ về ứng dụng quản lý bao gồm quản lý tính sẵn sàng và hiệu năng, quản lý cấu hình, lập kế hoạch dung lượng, quản lý job, phát hiện lỗi. Hình 4: Kiến trúc quản lý Web service Trên hình 4, các tài nguyên có thể quản lý bao gồm phần mềm và phần cứng, như phần mềm ứng dụng, thiết bị phần cứng, server,… cài đặt các giao diện quản lý và được mô tả bằng đặc tả Web Service Distributed Management (WSDM). Các thách thức và vấn đề cần nghiên cứu - Khả năng tự quản lý: Dịch vụ quản lý có khả năng tự cấu hình để thích nghi với các môi trường khác nhau mà nó được cài đặt. - Khả năng tự thích nghi: Dịch vụ quản lý có thể tự thích nghi theo sự thay đổi của môi trường, tuân theo các policy định trước. - Khả năng tự sửa lỗi: Dịch vụ quản lý có thể tự tìm, phân tích và phản ứng với các lỗi hệ thống bằng cách thực hiện các hoạt động sửa lỗi theo policy đã định mà không làm gián đoạn dịch vụ. - Khả năng tự tối ưu hóa: dịch vụ có thể tự giám sát và tối ưu hóa việc sử dụng tài nguyên hệ thống. - Khả năng tự bảo vệ: dịch vụ có thể tự phát hiện, tìm kiếm, và bảo vệ trước các nguy cơ tiềm tàng. 2.2.4 Thiết kế và phát triển dịch vụ Phương pháp luận thiết kế dịch vụ SOA là rất cần thiết để thiết kế ứng dụng SOA phù hợp với nghiệp vụ của doanh nghiệp. Nghiên cứu hiện tại 10 [...]... - Phát triển hướng thành phần (component-based development) Các thách thức và vấn đề cần nghiên cứu - Thách thức o nguyên lý thiết kế ứng dụng hướng dịch vụ o các phương pháp gap analysis linh hoạt o cơ chế quản lý (governance) dịch vụ o nguyên lý thiết kế cho thích ứng hóa dịch vụ - 3 Xây dựng ứng dụng mô hình tính toán hướng dịch vụ 3.1 Vấn đề khi xây dựng mô hình tính toán hướng dịch vụ 3.1.1 Các... Ngoài ra khi xây dựng mô hình tính toán hướng dịch vụ cần quan tâm tới chất lượng dịch vụ (Quality of Service -QoS) 11 3.1.2 Chất lượng dịch vụ Chất lượng dịch vụ được đánh giá thông qua các tiêu chí sau: - Tính sẵn sàng: là sẵn sàng để sử dụng ngay lập tức hoặc sẵn sàng khi nó - cần thiết Khả năng truy cập: là khả năng dịch vụ trả lời một yêu cầu tại một thời - điểm nhất định Tính toàn vẹn: đề cập... Cooperation) và tính đa dạng với độ phức tạp Để xây dựng một Agent hoặc một hệ thống Multiagent cách đơn giản nhất là sử dụng một môi trường phát triển có sẵn như: Jade, Zeus, FIPA-OS, và CoABS 3.1.6 Làm thế nào để thiết lập dịch vụ Việc xây dựng một ứng dụng bằng cách thiết lập dịch vụ đầu tiên đòi hỏi phải tồn tại dịch vụ, các chức năng dịch vụ cung cấp, được định nghĩa Khi các dịch vụ thiết yêu bị... điểm: không hỗ trợ năng động * Mô hình eAuction - Mô hình: áp dụng mọi tình huống, nơi có biến động của cung và cầu Mục tiêu: tăng hiệu quả, giảm chất thải và giảm thiểu chi phí tổng thể Nhược điểm: khi có các nhà cung cấp trung gian thì mô hình này không đáp ứng được Cả 3 mô hình trên đều bộc lộ những hạn chế, một mô hình quan trọng và đầy hứa hẹn là eMarketplace - Mô hình: hỗ trợ tích hợp chuỗi giá... toàn cầu, thường không kiểm soát toàn cầu rõ 14 ràng Điều này đòi hỏi một phương tiện để xác định mục tiêu chia sẻ, xác định nhiệm vụ phổ biến trên dịch vụ, và tránh những xung đột không cần thiết Kết quả là một sự hợp tác 3.1.7 Xử lý ngoại lệ Vì mô hình tính toán hướng dịch vụ rất đa dạng, phân phối và có các thành phần tự trị nên có thể xảy ra các trường hợp ngoại lệ Nó sẽ là tốt nếu các trường hợp... thực: chất lượng dịch vụ phải tương ứng với chất lượng quảng cáo Giá: bao gồm giá đăng ký sử dụng dịch vụ, duy trì dịch vụ, sửa đổi và cập nhật 3.1.3 Xây dựng Ontology Ontology là một mô hình dữ liệu biểu diễn một lĩnh vực và được sử dụng để suy luận về các đối tượng trong lĩnh vực đó và mối quan hệ giữa chúng Ontology cung cấp một bộ từ vựng chung bao gồm các khái niệm, các thuộc tính quan trọng và... sáu nguyên tắc thiết kế quan trọng khi hệ thống hướng dịch vụ được xây dựng và triển khai - Vai trò: Mỗi dịch vụ phải tương ứng với một vai trò thương mại và phải - gói gọn các khả năng của vai trò đó Khả năng: Các chức năng được hỗ trợ bởi các dịch vụ phải tương ứng với - khả năng của các vai trò mà nó thực hiện Tương tác: nó là tương tác giữa dịch vụ và người sử dụng, tương tác thẳng có tác dụng:... Applications 3.2.1 Mô hình cho ứng dụng thương mại điện tử * Mô hình eShop - Mô hình: một cửa hàng tự phục vụ cho khách hàng bằng cách hiển thị danh mục sản phẩm của công ty và cung cấp sản phẩm trên một trang web - Mục tiêu: giảm chi phí bán hàng - Nhược điểm: khách hàng không thể so sánh các sản phẩm của các nhà cung cấp khác nhau * Mô hình eProcurement - Mô hình: tập trung vào khía cạnh mua của doanh nghiệp,... lập kế hoạch, hoặc chỉ định sự kết hợp mong muốn của các dịch vụ. Các thành phần của dịch vụ được thực hiện và giám sát cho sự thành công hoặc lỗi Để thể hiện các thủ tục của thiết lập dịch vụ ta xây dựng đồ thị luồng công việc miêu tả từng bước một cách đơn giản Thiết lập dịch vụ này đòi hỏi sự trừu tượng hóa và có công cụ miêu tả các thuộc tính cần thiết khi có các yêu cầu, nó sẽ được đánh dấu khả... phát triển một trong các bên mà không ảnh hưởng đến bên kia + Cải thiện hiệu suất của toàn hệ thống - Cấu hình lại: khi thiết kế phải chú ý đến việc phân bổ tài nguyên để khi di dời 1 dịch vụ thì không phải cấu hình lại hệ thống đảm bảo tính trong - suốt về vị trí Chú ý: Dịch vụ được triển khai trong mô trường mở nên phải đối phó với nhiều mối đe dọa Điều này đỏi hỏi khi thiết kế SOC phải chú ý đến vấn