›
›

Luận văn Nghiên cứu kiến trúc hướng dịch vụ (service - Oriented architecture) và ứng dụng

pdf 266 trang vanle 2150
Download
Bạn đang xem 20 trang mẫu của tài liệu "Luận văn Nghiên cứu kiến trúc hướng dịch vụ (service - Oriented architecture) và ứng dụng", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfluan_van_nghien_cuu_kien_truc_huong_dich_vu_service_oriented.pdf

Nội dung text: Luận văn Nghiên cứu kiến trúc hướng dịch vụ (service - Oriented architecture) và ứng dụng

  1. ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN HỒ BẢO THANH 0112030 NGUYỄN HOÀNG LONG 0112141 NGHIÊN CỨU KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED ARCHITECTURE) VÀ ỨNG DỤNG LUẬN VĂN CỬ NHÂN TIN HỌC GIÁO VIÊN HƯỚNG DẪN TH.S TRẦN MINH TRIẾT Thành phố Hồ Chí Minh - 2005
  2. ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN HỒ BẢO THANH 0112030 NGUYỄN HOÀNG LONG 0112141 NGHIÊN CỨU KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED ARCHITECTURE) VÀ ỨNG DỤNG Chuyên ngành: CÔNG NGHỆ PHẦN MỀM LUẬN VĂN CỬ NHÂN TIN HỌC GIÁO VIÊN HƯỚNG DẪN: TH.S TRẦN MINH TRIẾT Thành phố Hồ Chí Minh - 2005
  3. NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN
  4. NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN
  5. Lời cảm ơn Chúng em chân thành cám ơn Khoa Công Nghệ Thông Tin, trường Đại Học Khoa Học Tự Nhiên, Đại học Quốc gia Tp. Hồ Chí Minh đã tạo điều kiện thuận lợi cho chúng em trong quá trình học tập và thực hiện đề tài tốt nghiệp. Chúng em xin nói lên lòng biết ơn sâu sắc đối với Th.S Trần Minh Triết. Chúng em xin chân thành cám ơn Thầy đã luôn quan tâm, tận tình hướng dẫn chúng em trong quá trình học tập, nghiên cứu và thực hiện đề tài. Chúng em xin chân thành cám ơn quý Thầy Cô trong Khoa Công Nghệ Thông Tin đã tận tình giảng dạy, trang bị cho em những kiến thức quý báu trong suốt quá trình học tập và thực hiện đề tài. Chúng em cũng xin gửi lòng biết ơn đến thầy cô và bạn bè trong lớp đã giúp đỡ, động viên tinh thần chúng em rất nhiều trong suốt quá trình thực hiện luận văn này. Chúng em nhớ mãi công ơn gia đình đã chăm sóc, động viên và tạo mọi điều kiện thuận lợi cho chúng em hoàn thành tốt luận văn này. Mặc dù đã cố gắng hoàn thành luận văn trong phạm vi và khả năng cho phép nhưng chắc chắn sẽ không tránh khỏi những thiếu sót, kính mong nhận được sự góp ý và tận tình chỉ bảo của quý Thầy Cô và các bạn. Một lần nữa, xin chân thành cám ơn và mong luôn nhận được những tình cảm chân thành của tất cả mọi người. Tp. Hồ Chí Minh, tháng 7 năm 2005 Hồ Bảo Thanh - Nguyễn Hoàng Long
  6. Trang i Mục lục ChTU ương 1 TỔNG QUANUT 1 1.1TU UT ThTU ực trạng hiện tạiUT 1 1.2TU UT PhânTU tích, đánh giá một số mô hình kiến trúc phân tán hiện tạiUT 3 1.3TU UT CácTU vấn đề phát sinh, nguyên nhân và biện pháp khắc phụcUT 6 ChTU ương 2 GIỚI THIỆU VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE- ORIENTED ARCHITECTURE)UT 10 2.1TU UT KiTU ến trúc hướng dịch vụ là gì ?UT 10 2.2TU UT BTU ốn nguyên tắc chính của hệ thống SOAUT 11 2.2.1TU UT STU ự phân định ranh giới rạch ròi giữa các dịch vụUT 11 2.2.2TU UT CácTU dịch vụ tự hoạt độngUT 12 2.2.3TU UT CácTU dịch vụ chia sẻ lược đồUT 12 2.2.4TU UT TínhTU tương thích của dịch vụ dựa trên chính sáchUT 12 2.3TU UT CácTU tính chất của một hệ thống SOAUT 12 2.3.1TU UT LooseTU couplingUT 12 2.3.2TU UT STU ử dụng lại dịch vụUT 14 2.3.3TU UT STU ử dụng dịch vụ bất đồng bộUT 14 2.3.4TU UT QuTU ản lý các chính sáchUT 14 2.3.5TU UT CoarseTU granularityUT 15 2.3.6TU UT KhTU ả năng cộng tácUT 17 2.3.7TU UT TTU ự động dò tìm và ràng buộc độngUT 17 2.3.8TU UT TTU ự hồi phụcUT 18 2.4TU UT LTU ợi ích của SOAUT 19 2.5TU UT MTU ột số mô hình triển khai SOAUT 23 2.6TU UT KiTU ến trúc phân tầng chi tiết của SOAUT 26 2.6.1TU UT TTU ầng kết nốiUT 26 2.6.2TU UT TTU ầng orchestrationUT 27 2.6.3TU UT TTU ầng ứng dụng tổng hợpUT 28 ChTU ương 3 XÂY DỰNG HỆ THỐNG SOAUT 31 3.1TU UT NhTU ững thách thức khi xây dựng hệ thống SOAUT 31 3.2TU UT XâyTU dựng hệ thống SOAUT 34 3.2.1TU UT GiTU ới thiệu bài toánUT 34 3.2.2TU UT MTU ột số khái niệmUT 35 3.2.3TU UT CácTU bước xây dựng hệ thống SOAUT 38 3.3TU UT TriTU ển khai SOA trong thực tếUT 46 3.3.1TU UT CácTU đặc trưng chính về kinh doanhUT 47 3.3.2TU UT CácTU đặc trưng chính về công nghệUT 48 3.3.3TU UT CácTU chuẩn mở UT 50 3.3.4TU UT KiTU ến trúc hướng dịch vụ và Thương mại điện tử theo yêu cầuUT 50
  7. Trang ii ChTU ương 4 SOA VÀ VẤN ĐỀ BẢO MẬTUT 52 4.1TU UT CácTU thách thức về bảo mật trong hệ thống SOAUT 52 4.1.1TU UT ĐặTU t vấn đềUT 52 4.1.2TU UT CácTU vấn đề bảo mật liên quan cần quan tâmUT 53 4.2TU UT GiTU ới thiệu về kiến trúc bảo mật hướng dịch vụUT 55 4.2.1TU UT MTU ột số yêu cầu đặt ra của kiến trúcUT 55 4.2.2TU UT KháiTU niệm về kiến trúc bảo mật hướng dịch vụ SOSA (service-oriented security architecture)UT 58 4.2.3TU UT KiTU ến trúc bảo mật hướng dịch vụ SOSAUT 60 4.3TU UT GiTU ới thiệu một số chuẩn về bảo mật trong XMLUT 65 4.3.1TU UT WS-SecurityTU UT 66 4.3.2TU UT XML-SignatureTU UT 67 4.3.3TU UT XML-EncryptionTU UT 67 4.3.4TU UT XMLTU Key Management Specification:UT 67 4.3.5TU UT SecurityTU Assertion Markup Language (SAML)UT 67 4.4TU UT KhaiTU thác tính năng bảo mật web service của bộ thư viện WSE (Web Services Enhancements)UT 68 4.4.1TU UT NhTU ững tính năng chính của bộ thư viện WSEUT 68 4.4.2TU UT KiTU ến trúc của WSEUT 71 ChTU ương 5 SOA VÀ VẤN ĐỀ TÍCH HỢPUT 73 5.1TU UT GiTU ới thiệu về Enterprise Application IntegrationUT 73 5.1.1TU UT HiTU ện trạngUT 73 5.1.2TU UT MTU ột số lý do khiến các tổ chức doanh nghiệp phải quan tâm đến vấn đề tích hợp (xét về mặt nghiệp vụ)UT 74 5.1.3TU UT CácTU vấn đề kỹ thuật gặp phải trong tích hợp hệ thốngUT 75 5.1.4TU UT CácTU yêu cầu cho một giải pháp tích hợpUT 76 5.1.5TU UT ViTU ệc tích hợp có thể được áp dụng ở nhiều tầng khác nhauUT 76 5.2TU UT PhânTU tích một số kỹ thuật tích hợp sử dụng MiddlewareUT 78 5.2.1TU UT KháiTU niệm middlewareUT 78 5.2.2TU UT CácTU sản phẩm Middleware sử dụng trong tích hợp hệ thốngUT 78 5.3TU UT SOATU và web service giải quyết vấn đề tích hợp như thế nàoUT 82 5.3.1TU UT CôngTU nghệ XML và web serviceUT 82 5.3.2TU UT WebTU services integration (WSI) và Service-oriented integration (SOI)UT 84 5.4TU UT ỨTU ng dụng SOA và web service để tích hợp các hệ thống được xây dựng trên .NET và J2EEUT 87 5.5TU UT ỨTU ng dụng SOA và web service trong việc tích hợp các hệ thống cũUT 90 ChTU ương 6 SOA VÀ QUẢN LÝ TIẾN TRÌNH NGHIỆP VỤUT 95 6.1TU UT MTU ột số khái niệm cơ bản về Quản lý tiến trình nghiệp vụUT 95 6.1.1TU UT TiTU ến trình nghiệp vụUT 95 6.1.2TU UT QuTU ản lý tiến trìnhUT 96 6.1.3TU UT HTU ệ quản lý tiến trình:UT 97 6.2TU UT QuTU ản lý tiến trình, SOA và Web ServiceUT 98 6.2.1TU UT QuTU ản lý tiến trình, SOA và Web Service được kết hợp thế nàoUT 99 6.2.2TU UT PhânTU tích một ví dụ kết hợp Quản lý tiến trình, SOA và web serviceUT 102
  8. Trang iii 6.3TU UT ThiTU ết kế tiến trìnhUT 108 6.3.1TU UT OrchestrationTU và ChoreographyUT 108 6.3.2TU UT CácTU yêu cầu kỹ thuật khi thiết kế tiến trìnhUT 110 6.3.3TU UT GiTU ới thiệu một số ngôn ngữ đặc tả tiến trìnhUT 112 ChTU ương 7 ỨNG DỤNG “SOA SUITE”UT 125 7.1TU UT GiTU ới thiệuUT 125 7.1.1TU UT ỨTU ng dụng “SOA Suite”UT 125 7.1.2TU UT CácTU thành phần của SOA SuiteUT 126 7.2TU UT ServiceBusTU UT 126 7.2.1TU UT VaiTU trò chức năng của ServiceBusUT 126 7.2.2TU UT ServiceBusTU và cơ sở tri thứcUT 129 7.2.3TU UT CácTU thành phần của ServiceBus:UT 130 7.2.4TU UT CTU ơ chế hoạt động của ServiceBusUT 134 7.2.5TU UT ServiceBusTU tích hợp với IISUT 136 7.3TU UT BpelEngineTU UT 136 7.3.1TU UT KiTU ến trúc của BpelEngineUT 136 7.3.2TU UT CácTU bước triển khai một business process trong BpelEngineUT 144 ChTU ương 8 THÀNH PHẦN BPEL DESIGNER CỦA SOA SUITEUT 145 8.1TU UT GiTU ới thiệuUT 145 8.2TU UT ChTU ức năngUT 145 8.2.1TU UT TTU ạo mới, chỉnh sửa, thiết kế một tiến trìnhUT 145 8.2.2TU UT ChTU ức năng kết xuất tiến trình ra file ảnhUT 145 8.2.3TU UT ChTU ức năng triển khai một tiến trình mới lên serverUT 146 8.3TU UT ThiTU ết kế cài đặtUT 146 8.3.1TU UT CTU ấu trúc chương trìnhUT 146 8.3.2TU UT GiaoTU diện chương trìnhUT 147 8.4TU UT HTU ướng dẫn sử dụngUT 164 8.4.1TU UT ThiTU ết kế một tiến trìnhUT 164 8.4.2TU UT TriTU ển khai một tiến trìnhUT 169 ChTU ương 9 ỨNG DỤNG SOA ĐỂ THIẾT KẾ MỘT SỐ TIẾN TRÌNHUT 170 9.1TU UT TiTU ến trình dịch tự động đa ngôn ngữUT 170 9.1.1TU UT MôTU tảUT 170 9.1.2TU UT STU ơ đồUT 171 9.1.3TU UT MôTU tả luồng xử lýUT 172 9.2TU UT TiTU ến trình thu thập thông tin từ bên ngoàiUT 172 9.2.1TU UT MôTU tảUT 172 9.2.2TU UT STU ơ đồUT 173 9.2.3TU UT MôTU tả luồng xử lýUT 173 9.3TU UT TiTU ến trình chấm thi tự động qua mạngUT 174 9.3.1TU UT MôTU tảUT 174 9.3.2TU UT STU ơ đồUT 175 9.3.3TU UT MôTU tả luồng xử lýUT 176
  9. Trang iv ChTU ương 10 Kết luậnUT 177 10.1TU UT MTU ột số kết quả đạt đượcUT 177 10.2TU UT HTU ướng phát triểnUT 178 TàiTU liệu tham khảoUT 180 PhTU ụ lục A UT ĐẶTU C TẢ NGÔN NGỮ BPEL V1.1UT 182 A.1TU UT ĐịTU nh nghĩa một tiến trình nghiệp vụ (business process)UT 182 A.1.1TU UT CTU ấu trúc của một tiến trình nghiệp vụ:UT 182 A.1.2TU UT ChuTU kỳ sống của một tiến trình nghiệp vụUT 187 A.2TU UT Partner,TU Partner Link Type, và Partner LinkUT 189 A.2.1TU UT PartnerTU UT 189 A.2.2TU UT PartnerTU Link TypeUT 190 A.2.3TU UT PartnerTU LinkUT 190 A.3TU UT XTU ử lý dữ liệuUT 191 A.3.1TU UT BiTU ểu thứcUT 191 A.3.2TU UT VariableTU (biến)UT 193 A.4TU UT PhépTU gánUT 195 A.5TU UT CácTU xử lý cơ bảnUT 197 A.5.1TU UT CácTU thuộc tính cơ sở của mỗi xử lýUT 197 A.5.2TU UT CácTU thành phần cơ sở của mỗi xử lýUT 198 A.5.3TU UT GTU ọi một phương thức của Web Service (Invoke)UT 198 A.5.4TU UT CungTU cấp các phương thức của Web ServiceUT 200 A.5.5TU UT CTU ập nhật nội dung của biếnUT 201 A.5.6TU UT BáoTU lỗi (signaling fault)UT 201 A.5.7TU UT WaitingTU UT 202 A.5.8TU UT KhôngTU làm gì cảUT 202 A.6TU UT CácTU xử lý có cấu trúc (structure activity)UT 203 A.6.1TU UT SequenceTU UT 203 A.6.2TU UT SwitchTU UT 204 A.6.3TU UT WhileTU UT 205 A.6.4TU UT PickTU UT 206 A.6.5TU UT FlowTU UT 207 A.7TU UT ScopeTU UT 215 A.7.1TU UT XTU ử lý dữ liệu data và Partner LinkUT 216 A.7.2TU UT XTU ử lý lỗi trong tiến trình nghiệp vụUT 216 A.7.3TU UT CompensationTU handlerUT 217 A.7.4TU UT XTU ử lý lỗiUT 219 A.7.5TU UT XTU ử lý sự kiệnUT 221 PhTU ụ lục B UT SOATU VÀ WEB SERVICESUT 225 B.1TU UT KiTU ến trúc Web servicesUT 225 B.2TU UT CácTU đặt trưng của Web servicesUT 227 B.2.1TU UT LooselyTU coupledUT 227 B.2.2TU UT TínhTU đóng góiUT 227
  10. Trang v B.2.3TU UT ContractedTU UT 227 B.2.4TU UT GiaoTU thức chuẩnUT 227 B.2.5TU UT TTU ự định nghĩaUT 228 B.2.6TU UT TìmTU kiếm và triệu gọi độngUT 228 B.3TU UT LTU ợi ích của Web servicesUT 228 B.4TU UT SOAPTU UT 230 B.5TU UT TUWSDLUT 231 B.6TU UT UDDITU UT 234 B.7TU UT MTU ột số chuẩn Web services mớiUT 238 B.8TU UT SOATU và Web ServiceUT 238 PhTU ụ lục C UT ĐỊTU NH DẠNG CÁC FILE TRONG PROJECT BPEL DESIGNERUT 243
  11. Trang vi Danh sách hình HìnhTU 1-1 – Tích hợp dạng điểm nối điểmUT 2 HìnhTU 1-2 – Các thành phần của đối tượng CORBAUT 4 HìnhTU 1-3 – Mô hình tương tác của đối tượng EJBUT 5 HìnhTU 1-4 – Mô hình tương tác của các đối tượng DCOMUT 6 HìnhTU 1-5 – Thực trạng cơ sở hạ tầng IT của hầu hết các tổ chức hiện nay.UT 8 HìnhTU 2-1 – Sơ đồ cộng tác trong SOAUT 10 HìnhTU 2-2 - Tính chất loose-couplingUT 13 HìnhTU 2-3 – Các đối tượng fine-grainedUT 16 HìnhTU 2-4 – Các đối tượng coarse-grainedUT 16 HìnhTU 2-5 – Các mức độ granularityUT 17 HìnhTU 2-6 - Mô hình service registryUT 23 HìnhTU 2-7 – Mô hình service brokerUT 24 HìnhTU 2-8 – Mô hình service busUT 25 HìnhTU 2-9 – Mô hình service bus phân tánUT 25 HìnhTU 2-10 – Kiến trúc phân tầng của hệ thống SOAUT 26 HìnhTU 2-11 – Một công thông tin cung cấp thông tin trong một vùng nhìn duy nhấtUT 29 HìnhTU 2-12 – Các portlet truy xuất dữ liệu từ nhiều nguồn khác nhau được cung cấp dưới dạng dịch vụUT 29 HìnhTU 3-1 - Các bước cần thực hiện khi triển khai một hệ thống SOA.UT 35 HìnhTU 3-2 – Phân rã domain thành một dãy các vùng chức năng liên quanUT 38 HìnhTU 3-3 – Sơ đồ sử dụng của hệ thống bán hàngUT 39 HìnhTU 3-4 – Sơ đồ các use case và quy trình nghiệp vụUT 39 HìnhTU 3-5 – Ví dụ về mô hình goal-serviceUT 41 HìnhTU 3-6 – Các use case nghiệp vụ được “gắn” trên hệ thống conUT 43 HìnhTU 3-7 – Phân bổ dịch vụUT 44 HìnhTU 3-8 – Mẫu đặc tả thành phầnUT 45 HìnhTU 3-9 – Chọn lựa một giải pháp thực thi thích hợp.UT 46
  12. Trang vii HìnhTU 3-10 – Sơ đồ tổng quan về thương mại điện tử theo yêu cầuUT 46 HìnhTU 4-1 – Kiến trúc bảo mật hướng dịch vụ (SOSA)UT 60 HìnhTU 4-2 – Cấu trúc phân tầng của Standard-based Security Info Exchange Platform.UT 61 HìnhTU 4-3 – Security Token Service.UT 63 HìnhTU 4-4 – Các tầng kỹ thuật bên dưới của một hệ thống bảo mật.UT 66 HìnhTU 4-5 – Xác nhận số một thông điệp.UT 69 HìnhTU 4-6 – Mã hóa một thông điệpUT 69 HìnhTU 4-7 – Điều phối thông điệp SOAP.UT 70 HìnhTU 4-8 – Cơ chế sử dụng bộ lọc của WSEUT 72 HìnhTU 5-1 – Vai trò cơ bản của middleware.UT 78 HìnhTU 5-2 – Cơ chế hàng đợiUT 79 HìnhTU 5-3 – Cơ chế Publish/SubscribeUT 80 HìnhTU 5-4 - Remote Procedure CallUT 80 HìnhTU 5-5 – Distributed Object ModelUT 81 HìnhTU 5-6 – Sử dụng web service trong vấn đề tích hợp.UT 83 HìnhTU 5-7 – Web services integration (WSI)UT 85 HìnhTU 5-8 – Service-oriented integration (SOI)UT 86 HìnhTU 5-9 – Sự khác nhau giữa kiến trúc .NET và J2EEUT 88 HìnhTU 5-10 – Vai trò của WSDL trong liên kết các hệ thống.UT 89 HìnhTU 5-11 – WSDL mô tả cách các thông điệp SOAP được xử lýUT 89 HìnhTU 5-12 – Dịch vụ hóa một CORBA serverUT 92 HìnhTU 6-1 – Minh họa một tiến trình nghiệp vụUT 95 HìnhTU 6-2 – Các thành phần của một hệ thống quản lý tiến trình nghiệp vụUT 97 HìnhTU 6-3 – Thực trạng “không đồng nhất”của các hệ thống doanh nghiệp.UT 99 HìnhTU 6-4 – Tầng dịch vụ dựa trên mô hình SOA với công nghệ Web ServiceUT 100 HìnhTU 6-5 – Tầng tiến trình nghiệp vụ sử dụng tầng dịch vụUT 100 HìnhTU 6-6 – Các hệ thống BPM khi không có tầng servicesUT 101 HìnhTU 6-7 – Ví dụ về các hệ thống cũ cần được service hóa.UT 103 HìnhTU 6-8 – Mô hình dữ liệu, dịch vụ và tiến trình.UT 103
  13. Trang viii HìnhTU 6-9 – Xây dựng các service đơn vịUT 105 HìnhTU 6-10 – Xây dựng các dịch vụ tích hợp.UT 106 HìnhTU 6-11 – Xây dựng các tiến trình nghiệp vụUT 107 HìnhTU 6-12 – Cung cấp các tiến trình nghiệp vụ cho người dùng.UT 108 HìnhTU 6-13 – Sự khác nhau giữa orchestration và choreography.UT 109 HìnhTU 6-14 – Tiến trình cung cấp khả năng tái sử dụng.UT 111 HìnhTU 6-15 – Tiến trình được định nghĩa bằng WSFLUT 112 HìnhTU 6-16 – Sơ đồ luồng trong WSFLUT 113 HìnhTU 6-17 – Sơ đồ tổng thể trong WSFLUT 113 HìnhTU 6-18 – Liên kết giữa các xử lý trong WSFLUT 114 HìnhTU 6-19 – Một ví dụ về các luồng thông điệp trong tương tác giữa các serviceUT 115 HìnhTU 6-20 – Minh họa Web Service Cherography InterfaceUT 116 HìnhTU 6-21 – Một tiến trình được mô tả bằng WSCIUT 117 HìnhTU 6-22 – Một tiến trình đặc tả bởi ngôn ngữ BPELUT 119 HìnhTU 6-23 – Mẫu xử lý WP2 và WP3UT 120 HìnhTU 6-24 – Mẫu xử lý WP4 và WP5UT 121 HìnhTU 6-25 – Mẫu xử lý WP8UT 122 HìnhTU 6-26 – Mẫu giao tiếp CP1 và CP2UT 123 HìnhTU 6-27 – Mẫu giao tiếp CP4UT 124 HìnhTU 7-1 – Các thành phần của SOASuiteUT 126 HìnhTU 7-2 – Môi trường trao đổi thông điệp SOAP của serviceBUSUT 127 HìnhTU 7-3 – Liến kết giữa ServiceBus và WSE MessagingUT 127 HìnhTU 7-4 – Qui trình xử lý thông điệp của serviceBUS.UT 135 HìnhTU 7-5 – Sơ đồ kiến trúc của BpelEngine.UT 137 HìnhTU 7-6 – Tạo các đối tượng activity implementation.UT 139 HìnhTU 7-7 – Sơ đồ điều phối thông điệp của engineUT 141 HìnhTU 7-8 – Sơ đồ phân cấp của các xử lý.UT 143 HìnhTU 8-1 – Cấu trúc thư mục dùng triển khai một tiến trình BPELUT 169 HìnhTU 9-1 – Tiến trình dịch tự độngUT 171
  14. Trang ix HìnhTU 9-2 – Tiến trình thu thập thông tin và dịch tự độngUT 173 HìnhTU 9-3 – Tiến trình chấm thi tự độngUT 175 HìnhTU B-1 – Một SOAP Operation đơn giảnUT 231 HìnhTU B-2 – Cấu trúc thông điệp SOAPUT 231
  15. Trang x Danh sách các thuật ngữ và khái niệm • Service Consumer : người sử dụng dịch vụ ở đây có thể là một ứng dụng, một dịch vụ hoặc là các module phần mềm khác yêu cầu sử dụng dịch vụ. Đây là thực thể thực thi quá trình định vị dịch vụ thông qua service registry, liên kết với dịch vụ và thực thi các chức năng của dịch vụ. Người sử dụng dịch vụ thực thi chức năng dịch vụ bằng cách một gửi yêu cầu theo đúng dịnh dạng được mô tả trong hợp đồng. • Service provider : nhà cung cấp dịch vụ ở đây là một dịch vụ chấp nhận và xử lý những yêu cầu từ người sử dụng dịch vụ. Nó có thể là một hệ thống mainframe, một thành phần hoặc các dạng phần mềm khác xử lý yêu cầu dịch vụ. Nhà cung cấp gửi hợp đồng lên service registry để những người sử dụng dịch vụ có thể truy cập đến nó. • Service Registry : service registry là “thư mục” trên mạng chứa tất cả các dịch vụ đăng ký. Service registry chấp nhận và lưu trữ các hợp đồng gửi đến từ nhà cung cấp dịch vụ và cung cấp các hợp đồng tùy theo yêu cầu của người sử dụng dịch vụ. • Service contract : một hợp đồng (contract) là một đặc tả về cách thức bên sử dụng dịch vụ trao đổi liên lạc với bên cung cấp dịch vụ. Nó chỉ rõ ra định dạng yêu cầu và đáp trả của dịch vụ. • Distributed computing : một dạng tính toán trong đó dữ liệu và ứng dụng được phần tán trên nhiều máy hoặc hệ thống tách biệt nhưng lại được liên kết và tích hợp thông qua các dịch vụ mạng và chuẩn tích hợp để mà chúng có thể thực thi chức năng như trong một môi trường thống nhất. • Enterprise application : một sản phẩm phần mềm được thiết kế để tích hợp các hệ thống máy tính bên trong doanh nghiệp lại với nhau. Mục tiêu là để tích hợp các xử lý nghiệp vụ chính (ví dụ như bán lẻ, kiểm toán, tài chính, quản lý nhân sự, tồn kho và sản xuất). Enterprise application được dùng rộng rãi trong
  16. Trang xi bối cảnh cần liên hệ chặt chẽ với nhà cung cấp, với đối tác kinh doanh và với khách hàng. • Loose coupling: đây là một khái niệm trong tích hợp ứng dụng. Hai thành phần trao đổi thông tin không kết nối trực tiếp với nhau mà qua một thành phần trung gian được đặc tả rõ ràng từ trước. Các thành phần tham gia phải đảm bảo một cơ chế ngữ nghĩa chung để các thông điệp chứa bên trong chúng một ngữ nghĩa đủ để tự mô tả chính mình. • Tight coupling : ngược lại với loose coupling. • Interface : thành phần giao tiếp. • Coarse-grained : mô tả mức độ gom nhóm xử lý của một thành phần xử lý thông tin. Các thành phần có tính coarse-grained thường truyền nhận và xử lý theo từng khối dữ liệu có thông tin ngữ cảnh lớn và số lần trao đổi thông tin trong một giao tác là ít. Xem Hình 2-4 để hiểu rõ hơn. • Fine-grained : ngược lại với coarse-grained. Các thành phần có tính fine- grained truyền nhận và xử lý theo từng đơn vị nhỏ và có ngữ cảnh ngầm định, cần nhiều lần trao đổi thông tin trong một giao tác dẫn đến tăng băng thông sử dụng và kéo dài thời gian hồi đáp. Xem hình Hình 2-3 để hiểu rõ hơn. • Legacy system : các hệ thống ứng dụng được cài đặt từ trước nhưng vẫn còn được sử dụng. Thông thường đây là những hệ thống sử dụng công nghệ đã lỗi thời nhưng vẫn quan trọng và còn hoạt động tốt. Đây là thành phần nền tảng cung cấp xử lý cho các dịch vụ hoạt động ở cấp cao hơn. • Granularity : khái niệm mô tả độ phức tạp của tiến trình hoặc dịch vụ. Granularity được chia làm hai loại là “fine-grained” và “coarse-grained”. Khái niệm granularity được hiểu một cách trừu tượng không phần biệt hai loại trên và tùy ngữ cảnh mà có cảnh hiểu khác nhau. • Interoperability : khả năng cộng tác, trao đổi thông tin giữa các hệ thống phân tán
  17. Trang xii • Orchestration : sự kết hợp, điều phối hoạt động của những Web Service theo một quy trình mong muốn. Chereography : tương tự như orchestration nhưng chỉ tập trung vào quan hệ • giữa các thành phần dịch vụ với nhau theo mô hình peer-to-peer. • Middleware : Khái niệm middleware dùng để mô tả phần mềm liên kết các phần mềm khác lại với nhau. • BPEL : Business Process Execution Language, một ngôn ngữ XML được thiết kế nhằm cho phép kết hợp các xử lý trên một môi trường tính toán phân tán lại với nhau theo một luồng xử lý hoặc quy trình nghiệp vụ có cấu trúc định trước.
  18. Trang xiii MỞ ĐẦU Ngày nay, công nghệ thông tin đang là nền công nghệ mũi nhọn trong chiến lược phát triển kinh tế, xây dựng đất nước của hầu hết các quốc gia. Các sản phẩm công nghệ thông tin đã và đang được ứng dụng rộng rãi trong mọi lãnh vực của đời sống kinh tế, xã hội và hầu hết đều đem đến những giá trị thiết thực. Đối tượng phục vụ chủ yếu của ngành công nghệ thông tin hiện nay chính là các tổ chức, các cơ sở doanh nghiệp, Nhu cầu ứng dụng các sản phẩm của ngành công nghệ mũi nhọn này để hỗ trợ tin học hóa các qui trình nghiệp vụ, mà vốn từ trước đến nay chỉ được thực hiện một cách thủ công, đang ngày trở nên một nhu cầu cấp thiết. Các sản phẩm dạng này đều có chung các đặc điểm là độ phức tạp lớn, chi phí sản xuất và bảo trì cao, mức độ cụ thể còn tùy thuộc vào độ lớn của tổ chức cũng như là độ phức tạp của các qui trình nghiệp vụ cần xử lý. 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, các cơ sở 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. Lúc này các sản phẩm sẽ có độ phức tạp lớn hơn, từ đó kéo theo các vấn đề liên quan như chi phí sản xuất, chi phí quản lý và bảo trì. Bên cạnh đó, ngành công nghệ phần mềm 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 các hệ thống khác nhau của nhiều tổ chức Để giải quyết các vấn đề trên, nhiều giải pháp đã được nghiên cứu và ứng dụng. Nhưng hầu hết các giải pháp này không giải quyết các khó khăn một cách triệt để và kết quả đạt được cũng không như mong đợi. Hiện nay, 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 bước đầu đã được ứng dụng trong một số dự án và đều đem lại những kết quả khả quan. Và người ta tin rằng SOA có thể giải quyết tốt những thách thức đã nêu trên, và sẽ
  19. Trang xiv là “xu thế trong tương lai”. Thế thì “Kiến trúc hướng dịch vụ” là gì? Cách giải quyết vấn đề cũng như là những lợi ích đạt được của kiến trúc này như thế nào? Đây chính lý do để chúng em thực hiện đề tài “NGHIÊN CỨU KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED ARCHITECTURE) VÀ ỨNG DỤNG” Mục tiêu của đề tài Đề tài sẽ tập trung vào tìm hiểu các vấn đề sau: • Nghiên cứu các cơ sở lý thuyết của kiến trúc hướng dịch vụ (SOA) thông qua việc tìm hiểu khái niệm về “kiến trúc hướng dịch vụ”, các tính chất cùng với những lợi ích đạt được của hệ thống SOA. • Tìm hiểu các vấn đề liên quan đến xây dựng hệ thống SOA, bao gồm những thách thức gặp phải, những nguyên tắc thiết kế và các bước cần thực hiện khi triển khai hệ thống SOA. • Ứng dụng SOA trong xây dựng kiến trúc bảo mật hướng dịch vụ. Tìm hiểu một số chuẩn bảo mật trong XML và khai thác tính năng bảo mật web service của bộ thư viện lập trình WSE (Web Services Enhancements). • Tìm hiểu về nhu cầu và các thách thức gặp phải trong việc tích hợp hệ thống. Từ đó, ứng dụng SOA và Web service để giải quyết vấn đề tích hợp. • Tìm hiểu khái niệm về tiến trình nghiệp vụ, quản lý tiến trình, mối quan hệ của tiến trình nghiệp vụ trong hệ thống SOA. Xem xét các nguyên tắc thiết kế và khảo sát một số ngôn ngữ đặc tả tiến trình nghiệp vụ. • Xây dựng ứng dụng SOASuite nhằm hỗ trợ trong việc thiết kế, xây dựng và triển khai hệ thống kiến trúc hướng dịch vụ. Ứng dụng cung cấp môi trường linh hoạt để quản lý các dịch vụ có trong hệ thống dựa trên cơ chế thông điệp. Ngoài ra, SOASuite còn cung cấp môi trường phát triển cho phép người dùng
  20. Trang xv có thể thiết kế, xây dựng và thực thi và quản lý các tiến trình nghiệp vụ từ những web services đã được xây dựng sẵn thông qua các thao tác kéo thả mà không cần viết mã lệnh xử lý. Nội dung luận văn Nội dung của luận văn được trình bày gồm: • Chương 1: trình bày, phân tích về một số khó khăn của ngành công nghệ phần mềm hiện nay. Từ đó giới thiệu một số mô hình kiến trúc phân tán được xây dựng để giải quyết các khó khăn trên như là CORBA, EJB, DCOM. • Chương 2: giới thiệu khái niệm về kiến trúc hướng dịch vụ SOA, các nguyên tắc cũng như là tính chất của hệ thống SOA; phân tích một số lợi ích đạt được và khảo sát một số mô hình của kiến trúc hướng dịch vụ. Chương này cũng trình bày về kiến trúc phân tầng của hệ thống SOA. • Chương 3: trình bày các vấn đề liên quan đến việc xây dựng hệ hống SOA, bao gồm phân tích các thách thức gặp phải và xem xét qui trình các bước nên thực hiện khi triển khai hệ thống SOA. • Chương 4: trình bày về các khó khăn gặp phải trong việc bảo vệ hệ thống SOA. Từ đó xem xét, phân tích một giải pháp đó là mô hình kiến trúc bảo mật hướng dịch vụ. Chương này cũng giới thiệu một số chuẩn bảo mật trong XML như WS-Security, XML-Signature, XML-Encryption, XML Key Management Specification, SAML và bộ thư viện WSE (Web Services Enhancements) hỗ trợ lập trình bảo mật web services. • Chương 5: trình bày và phân tích về nhu cầu và một số khó khăn gây trở ngại trong vấn đề tích hợp hệ thống. Qua đó xem xét môt số giải pháp được sử dụng trong tích hợp, bao gồm giải pháp sử dụng các sản phẩm middleware và giải pháp ứng dụng SOA và Web services: Web Service Integration (WSI) và Service-Oriented Integration (SOI). Sau đó, xem xét cụ thể giải pháp ứng dụng
  21. Trang xvi SOA và Web services trong tích hợp các hệ thống xây dựng trên nền .NET và J2EE và trong tái sử dụng lại các hệ thống cũ. • Chương 6: trình bày một số khái niệm liên quan về quản lý tiến trình. Phân tích mối quan hệ kết hợp giữa quản lý tiến trình, SOA và Web services. Xem xét các vấn đề liên quan đến thiết kế tiến trình nghiệp vụ. Ngoài ra, chương này cũng sẽ giới thiệu về một số ngôn ngữ đặc tả tiến trình hiện đang được sử dụng phổ biến, như là Web Service Flow Language (WSFL), XLANG, Web Service Choreography Interface (WSCI) và Business Process Execution Language For Web Service (BPEL4WS) • Chương 7: giới thiệu tổng quát về ứng dụng SOASuite. Trình bày về hai thành phần ServiceBus và BpelEngine. ServiceBus cung cấp môi trường quản lý các dịch vụ dựa trên cơ chế thông điệp và BpelEngine cung cấp môi trường triển khai và thực thi cho các tiến trình nghiệp vụ. • Chương 8: giới thiệu về thành phần thứ ba của SOASuite, bộ công cụ “BpelDesigner” cung cấp môi trường trực quan hỗ trợ người dùng xây dựng, thiết kế các tiến trình nghiệp vụ • Chương 9: giới thiệu một số mẫu tiến trình được thiết kế bằng bộ công cụ BpelDesigner. • Chương 10: trình bày một số kết luận và hướng phát triển của đề tài.
  22. Trang 1 Chương 1 TỔNG QUAN " Nội dung của chương 1 trình bày về một số khó khăn của ngành công nghệ phần mềm hiện nay. Từ đó giới thiệu, phân tích các ưu khuyết điểm của một số mô hình kiến trúc phân tán được xây dựng để giải quyết các khó khăn trên như là CORBA, EJB, DCOM 1.1 Thực trạng hiện tại Phần mềm ngày nay đang ngày càng trở nên phức tạp và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển phần mềm hiện có. Albert Einstein đã nói :“Mọi việc nên thực hiện theo cách đơn giản đến mức có thể ” , một thực trạng đáng buồn là có rất nhiều hệ thống phần mềm được xây dựng với kiến trúc quá phức tạp, chi phí phát triển và bảo trì cao, đặc biệt là với các hệ thống phần mềm cao cấp. Hàng chục năm qua, nhiều kiến trúc phần mềm đã được xây dựng và triển khai nhằm giải quyết các vấn đề này. Thế nhưng độ phức tạp phần mềm vẫn cứ tiếp tục tăng và dường như đã trở nên vượt quá khả năng xử lý của các kiến trúc truyền thống. Nguyên nhân khiến cho độ phức tạp của các hệ thống phần mềm không ngừng tăng cao như thế là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất, trong khi nhu cầu về trao đổi, chia sẻ, tương tác giữa các hệ thống không thể đáp ứng được trong một môi trường như vậy. Làm sao có thể dung hòa được những cách biệt giữa cái cũ và cái mới? Các hệ thống cũ (legacy systems) cần được sử dụng lại thay vì phải gỡ bỏ và thay mới bởi vì chi phí thực hiện lại từ đầu chắc chắn sẽ cao hơn việc chi phí chuyển đổi cái cũ rất nhiều lần. Vấn đề này liên quan đến một khái niệm và cũng là một thách thức mà các tổ chức phải đối mặt, đó là “tích hợp hệ thống” (Enterprise Architecture Integration - EAI). Hiện các dự án dạng này đang được rất nhiều tổ chức quan tâm đến, với mức đầu tư về chi phí đang dẫn đầu so với các dạng dự án khác.
  23. Trang 2 Một nguyên nhân khác cũng góp phần dẫn đến tình trạng khó khăn như thế chính là vấn đề lập trình dư thừa và không thể tái sử dụng. Hãy xét một ví dụ, một ngân hàng có nhiều chi nhánh khác nhau – mỗi chi nhánh có một hệ thống tách biệt và cần kết nối với các hệ thống khác của ngân hàng để phục vụ khách hàng được hiệu quả hơn. Giả sử rằng các hệ thống này đều được thiết kế rất tốt. Thế nhưng các hệ thống này được xây dựng trong những khoảng thời gian khác nhau, trong những dự án độc lập và khác nhau. Thông thường chức năng “lấy số liệu thống kê tài khoản” bị lặp lại trong mỗi hệ thống ATM, mỗi chi nhánh và trong hệ thống lưu trữ tài khoản, và ngay cả khi người dùng truy cập vào cùng một tài khoản trong cùng một cơ sở dữ liệu. Bây giờ nếu ngân hàng đó cần phát triển một hệ thống cung cấp dịch vụ gửi tiền hay cho vay tiền qua mạng để tăng chất lượng phục vụ cho các khách hàng. Hệ thống mới này sẽ được xây dựng thế nào? Nếu giải pháp chọn xây dựng lại hệ thống mới, thì lại tiếp tục mắc lại sai lầm trước đó: dư thừa, không đồng nhất Còn nếu chọn giải pháp là sử dụng lại các chức năng sẵn có, thì ta phải đối mặt với chuyện thiết lập các mối liên kết với toàn bộ các hệ thống trước. Hầu như mọi tổ chức đều phải đối mặt với vấn đề tích hợp vì nhiều lý do, đặc biệt là trong thị trường ngày nay, sự thay đổi luôn diễn ra với tốc độ chóng mặt; có thể là mở rộng thêm chi nhánh, một hệ thống bạn hàng mới, hoặc chỉ đơn giản là cần kết nối các hệ thống có sẵn. Nếu có n hệ thống ứng dụng cần được kết nối trực tiếp với nhau, thì cần n*(n-1) kết nối, hoặc là interface. Hình 1-1 – Tích hợp dạng điểm nối điểm
  24. Trang 3 Tương tự, nếu có thêm một hệ thống ứng dụng thứ (n+1) cần đựơc tích hợp thêm vào hệ thống, thì nó đòi hỏi 2*n interface mới, bao gồm cả việc thu thập sưu liệu , kiểm thử, và bảo trì. Theo như Hình 1-1 trên thì 5 ứng dụng đòi hỏi 20 kết nối trực tiếp, một ứng dụng thứ 6 tích hợp thêm vào sẽ yêu cầu thêm 10 kết nối mới! Tệ hơn nữa, mã nguồn của các ứng dụng cũ phải được chỉnh sửa để thêm vào các kết nối, từ đó kéo theo chi phí kiểm thử, bảo trì. Những vấn đề trước chưa giải quyết, mà nay các tổ chức lại phải đối mặt với những thách thức mới: đáp ứng nhanh chóng các sự thay đổi, giảm chi phí phát triển, tăng tính tương thích và khả năng tái sử dụng, Tất cả đã tạo nên một áp lực nặng nề đối với các nhà phát triển phần mềm. 1.2 Phân tích, đánh giá một số mô hình kiến trúc phân tán hiện tại Ba kiến trúc phân tán phổ biến nhất hiện này là CORBA, DCOM và EJB. Các kiến trúc này là sự mở rộng của các 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ể có không gian địa chỉ bên ngoài ứng dụng, hoăc ở một máy khác với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một phần của ứng dụng. • CORBA – Common Object Request Broker Architecture: ► CORBA được định nghĩa bởi Object Management Group (OMG), là một kiến trúc phân tán mở, độc lập nền tảng và độc lập ngôn ngữ. ► CORBA Component Model (CCM) là một cải tiến đáng kể nhằm định nghĩa các mô hình thành phần so với CORBA. Nó định nghĩa ra quy trình thiết kế, phát triển, đóng gói, triển khai và thực thi các thành phần phân tán. CCM định nghĩa khái niệm Ports cho các thành tố. Các port này được sử dụng để kết nối các thành phần có sẵn với nhau, tạo các hệ thống phân tán phức tạp hơn. Mỗi thành phần CCM có một đối tượng Home chịu trách nhiệm quản lý chu kỳ sống của đối tượng và được triển khai bên trong một trình chứa (container).
  25. Trang 4 ► Ưu điểm của CORBA là các lập trình viên có thể chọn bất kỳ ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thoả các tính chất của CORBA. Tuy nhiên CORBA số một nhược điểm là nó là ngôn ngữ lập trình cấp thấp, rất phức tạp, khó học và cần một đội ngũ phát triển có kinh nghiệm. Ngoài ra các đối tượng CORBA cũng khó có thể tái sử dụng. Hình 1-2 – Các thành phần của đối tượng CORBA • EJB - Enterprise Java Bean: ► Kiến trúc EJB là một kiến trúc thành tố bên phía máy chủ dùng cho việc phát triển và triển khai các ứng dụng phân tán hướng đối tượng cỡ vừa và lớn. ► Kiến trúc EJB có 3 tầng với tầng đầu tiên là tầng trình diễn, tầng thứ hai là tầng xử lý nghiệp vụ, và tầng thứ ba là các tài nguyên như cơ sở dữ liệu máy chủ. Truyền thông giữa các đối tượng EJB thông qua Remote Method Invocation (RMI). Các client không bao giờ tương tác trực tiếp với các bean. Thay vì vậy chúng sẽ sử dụng các phương thức được định nghĩa trong các interface Remote và Home. Mỗi bean tồn tại bên trong trình chứa, chịu trách nhiệm việc tạo thể hiện mới, lưu trữ dữ liệu và các quản lý khác. Trình chứa sẽ triệu gọi các phương thức callback của mỗi thể hiện bean khi có sự kiện tương
  26. Trang 5 ứng. Không giống như CCM, EJB không định nghĩa các port kết nối trực tiếp giữa các thành phần liên quan bởi vì mỗi bean bên trong trình chứa là một thực thể độc lập không có bất kỳ ràng buộc nào bên ngoài. ► EJB là một kiến trúc tốt cho việc tích hợp các hệ thống vì nó độc lập nền tảng nhưng nó cũng gặp vấn đề là nó không phải là một chuẩn mở, khả năng giao tiếp với các chuẩn khác vẫn còn hạn chế. Hình 1-3 – Mô hình tương tác của đối tượng EJB • DCOM – Distributed Component Object Model: ► DCOM là một mô hình phân tán dễ triển khai với chi phí thấp, hỗ trợ tigh coupling giữa các ứng dụng và hệ điều hành. Mô hình Component Object Model (COM) định nghĩa cách thức các các thành phần và client liên lạc trao đổi với nhau trên cùng một máy. DCOM mở rộng COM bằng cách sử dụng các giao thức mạng chuẩn khi cần trao đối dữ liệu với máy khác trên mạng. DCOM hỗ trợ kết nối giữa các đối tượng và những kết nối này có thể được thay đổi lúc đang chạy. Các đối tượng DCOM được triển khai bên trong các gói nhị phân chứa các mã lệnh quản lý chu kỳ sống của đối tượng và việc đăng ký đối tượng. ► DCOM mang đến nhiều ưu điểm như tính ổn định, không phụ thuộc vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng, là một lựa chọn tốt cho các doanh nghiệp sử dụng công nghệ của Windows để chạy các ứng dụng có yêu
  27. Trang 6 cầu cao về sự chính xác và ổn định. Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là chúng bị giới hạn trên nền tảng Windows. Hình 1-4 – Mô hình tương tác của các đối tượng DCOM Các kiến trúc trên đều hướng đến việc xây dựng một hệ thống “hướng dịch vụ” tuy nhiên chúng vẫn còn gặp phải một số vấn đề. • Đầu tiên là chúng tighly coupled, nghĩa là kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch vụ và phía sử dụng dịch vụ phải giống nhau. Điều này đồng nghĩa với khó khăn mỗi khi có sự thay đổi từ một trong 2 phía bởi vì mỗi thay đổi cần được đánh giá, lên kế hoạch và sửa chữa ở cả 2 phía. • Tiếp đến những chuẩn trên đa phần là chuẩn đóng, chúng hầu như không thể kết hợp, hoạt động với chuẩn khác. Ví dụ như bắt đối tượng Java trao đổi dữ liệu trực tiếp với một đối tượng DCOM là không thể. Cuối cùng các đối tượng của các mô hình trên là fine grained, nghĩa là lượng thông tin giữa trong mỗi lần thực hiện giao dịch là ít, và được thực hiện nhiều lần dẫn đến chiếm dụng băng thông sử dụng và tăng thời lượng đáp trả dữ liệu. 1.3 Các vấn đề phát sinh, nguyên nhân và biện pháp khắc phục Ngày nay áp lực đặt lên các doanh nghiệp ngày càng lớn: giảm chi phí đầu tư cơ sở hạ tầng, khai thác có hiệu quả các công nghệ có sẵn, phải cố gắng phục vụ yêu cầu của khách hàng ngày càng tốt hơn, đáp ứng tốt các thay đổi nghiệp vụ, khả năng tích
  28. Trang 7 hợp cao với các hệ thống bên ngoài Nguyên nhân chính của mọi khó khăn trên đó là: sự không đồng nhất và sự thay đổi. Hầu hết các doanh nghiệp ngày nay đều sở hữu nhiều hệ thống, ứng dụng, với những kiến trúc khác nhau, xây dựng vào những khoảng thời gian khác nhau và dựa trên những công nghệ khác nhau. Vào những năm 1990, các doanh nghiệp chọn giải pháp trọn gói, mua hẳn một vài gói phần mềm lớn với những module được tích hợp sẵn thay vì cố gắng “sửa và kết hợp” chúng với nhau, bởi vì lúc bấy giờ kết hợp các sản phẩm từ nhiều nhà cung cấp khác nhau thực sự là một cơn ác mộng. Ngày nay, các doanh nghiệp không thể chi trả như vậy, vì một giải pháp trọn gói thường không linh hoạt và có giá thành cao. Các doanh nghiệp quay lại tìm kiếm những giải pháp kết hợp những ứng dụng cũ sao cho thoả mãn nhu cầu, để những ứng dụng đó giải quyết phần việc của mình, sau đó chỉ việc tổng hợp thông tin trả về. Trong quá trình kết hợp chắc chắn sẽ gặp những khó khăn như: • Không đủ khả năng quản lý quy trình nghiệp vụ • Tốn chi phi tích hợp • Số lượng lớn nhà cung cấp và khách hàng, đó là chưa kể các đối thủ cạnh trạnh, các quy trình nghiệp vụ phức tạp • Số lượng lớn các ứng dụng cần kết hợp và quản lý như Enterprise Resource Planning (ERP), Supply Chain Management (SCM), và Product Data Management(PDM) . • Quá nhiều định dạng dữ liệu • Vấn đề bảo mật Trong khi đó những thay đổi vẫn liên tục xảy ra • Toàn cầu hoá dẫn đến tính cạnh tranh khốc liệt đòi hỏi phải rút ngắn quy trình sản phẩm để tăng ưu thế cạnh tranh với các đối thủ. • Nhu cầu và yêu cầu khách hàng thường xuyên thay đổi nhanh chóng nhằm cho ra các sản phẩm có tính cạnh tranh liên tục xuất hiện trên thị trường. • Cải tiến công nghệ dẫn đến thay đổi các thành phần liên quan
  29. Trang 8 Hình 1-5 – Thực trạng cơ sở hạ tầng IT của hầu hết các tổ chức hiện nay. Đa phần những khó khăn trên là bắt nguồn từ một trong ba nguyên nhân: phức tạp, không linh hoạt và không bền vững. • Phức tạp: Ngày nay mỗi doanh nghiệp công nghệ thông tin có nhiều hệ thống đủ loại khác nhau và làm việc theo những cách khác nhau. Các công ty phát triển phần mềm phải thuê những nhóm nhân viên giàu kinh nghiệm, có khả năng trên nhiều lãnh vực khác nhau để phát triển, triển khai và quản lý các ứng dụng và hệ thống mà bản thân chúng không thống nhất với nhau. Thêm vào đó là việc nâng cấp rối rắm, tích hợp cùng với nhu cầu về bảo mật ngày một tăng làm gia tăng tính phức tạp cho những vấn đề vốn đã khó giái quyết với các doanh nghiệp. • Không linh hoạt: cùng với sự phức tạp là tính cứng nhắc trong chính sách, chiến lược phát triển, cũng như là cơ sở hạ tầng của các công ty. Hầu như công ty nào cũng có những ứng dụng có sẵn mà khó nâng cấp, khó kết hợp hoạt động hoặc tệ hơn, không thể thay thế. Vấn đề tích hợp vì thế trở nên tốn kém và khó khăn hơn. • Không bền vững: trái ngược với sự cứng nhắc nói trên là sự không bền vững đi cùng với khả năng thất bại và những vấn đề khác đi kèm. Các phương pháp tiếp
  30. Trang 9 cận truyền thống trong việc xây dựng các hệ thống phần mềm thường dẫn đến một “mớ hỗn độn” các giải pháp lắp ghép, tích hợp. Kết quả là mỗi khi có thay đổi về quy trình nghiệp vụ hoặc yêu cầu thì các công ty phải chấp nhận phát triển những dự án nâng cấp tốn kém hoặc là hủy và thay thế hẳn công nghệ không phù hợp. Rủi ro cùng lúc cũng tăng lên với sự phụ thuộc chồng chéo giữa các thành phần , hệ thống có sẵn. Chính vì vậy các doanh nghiệp cần một cách tiếp cận mới để giải quyết vấn đề môi trường không đồng nhất và tốc độ chóng mặt của sự thay đổi trong khi phải xoay sở với nguồn ngân sách hạn hẹp và nền kinh tế khó khăn. May mắn thay, vẫn có một cách tiếp cận giải quyết khá toàn diện mọi khó khăn nêu trên và nó đã được triển khai trong thực tế. Cách tiếp cận đó gọi là “kiến trúc hướng dịch vụ” Service- oriented Architecture (SOA).
  31. Trang 10 Chương 2 GIỚI THIỆU VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED ARCHITECTURE) " Nội dung của chương 2 trình bày về cơ sở lý thuyết của mô hình SOA, bao gồm: khái niệm về kiến trúc hướng dịch vụ (SOA), những đặc trưng và ích lợi đạt được của mô hình kiến trúc này. Ngoài ra, chương này cũng sẽ đi sâu vào tìm hiểu các tầng kiến trúc bên trong của mô hình SOA 2.1 Kiến trúc hướng dịch vụ là gì ? 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. Hiểu một cách đơn giản thì một hệ thống SOA là một 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ụ. Trong SOA có ba đối tượng chính, minh họa trong Hình 2-1 Hình 2-1 – Sơ đồ cộng tác trong SOA
  32. Trang 11 Nhà cung cấp (service provider) dịch vụ cần cung cấp thông tin về dịch vụ của mình cho một dịch vụ lưu trữ thông tin dịch vụ (service registry). Người sử dụng (service consumer) thông qua service registry để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp. SOA cung cấp 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à cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có. Thật ra, tư tưởng về một hệ thống SOA không phải là mới. Comnon Object Request Broker Architecture (CORBA) và mô hình Distributed Component Object Model (DCOM) của Microsoft hay như Enterprise Java Bean (EJB) của Java của đã cung cấp tính năng này từ lâu. Tuy nhiên những cách tiếp cận hướng dịch vụ này vẫn còn gặp phải một số vấn đề khó khăn (đã phân tích ở trên). SOA không chỉ là một cải tiến đáng kể giúp giải quyết những yếu điểm của các công nghệ trước mà còn đem đến nhiều ưu điểm nổi trội hơn ( xem lợi ích của SOA mục 2.4 ). 2.2 Bốn nguyên tắc chính của hệ thống SOA 2.2.1 Sự phân định ranh giới rạch ròi giữa các dịch vụ Các dịch vụ 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 giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng 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 thông tin và chức năng của dịch vụ. Ta chỉ cần gửi các thông điệp theo các định dạng đã được định nghĩa trước mà không cần phải quan tâm đến cách xử lý của dịch vụ như thế nào (môi trường thực thi, ngôn ngữ lập trình ). Điều này đạt được do sự tách biệt giữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ .
  33. Trang 12 2.2.2 Các dịch vụ tự hoạt động Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc lập mà không lệ thuộc vào một dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó sẽ không bị sụp đổ khi có sự cố. Để thực hiện điều này, 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 một dịch vụ cộng tác bị hỏng; và để tránh các cuộc tấn công từ bên ngoài (như gửi thông điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các kỹ thuật về an toàn, bảo mật Đây chính là ý nghĩa của khái niệm ‘loose coupling service’ mà ta đã đề cập trong định nghĩa SOA. 2.2.3 Các dịch vụ chia sẻ lược đồ Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) 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 (độc lập ngôn ngữ, độc lập hệ nền.). Như thế hệ thống của ta sẽ có tính liên kết và khả năng dễ mở rộng. 2.2.4 Tính tương thích của dịch vụ dựa trên chính sách Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ đó như là mã hóa, bảo mật Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính sách đó. 2.3 Các tính chất của một hệ thống SOA 2.3.1 Loose coupling Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module với nhau. Có hai loại coupling là rời (loose) và chặt (tight). Các module có tính loose coupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tight coupling lại có nhiều ràng buộc không thể biết trước. Hầu như mọi kiến trúc phần mềm đều
  34. Trang 13 hướng đến tính loose coupling giữa các module. Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó. Kết dính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch vụ mỗi khi có thay đổi nào đó xảy ra. Mức độ coupling tăng dần khi khi bên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp. Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ giữa hai bên càng chặt. Ngược lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước khi triệu gọi nó thì quan hệ giữa hai bên càng có tính loose coupling. SOA hỗ trợ loose coupling thông qua việc sử dụng hợp đồng và liên kết (contract and binding). Một người sử dụng truy vấn đến nơi lưu trữ và cung cấp thông tin dịch vụ (registry) để lấy thông tin về loại dịch vụ cần sử dụng. Registry sẽ trả về tất cả những dịch vụ thoải tiêu chuẩn tìm kiếm. Từ bây giờ người dùng chỉ việc chọn dịch vụ mà mình cần, và thực thi phương thức trên đó theo mô tả dịch vụ nhận được từ registry. Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào cài đặt của dịch vụ mà chỉ dựa trên hợp đồng mà dịch vụ đó hỗ trợ. Application 2 Application 1 Programming Programming Language Language Database Agreements Database Object Model Object Model Operating Messages Operating System System Application Application Server Server Hình 2-2 - Tính chất loose-coupling 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 nhằm tăng hiệu suất, khả năng mở rộng
  35. Trang 14 và khả năng đáp ứng cao. Những thay đổi cài đặt cũng được che dấu đi. Loose coupling đem đến sự độc lập 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 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. 2.3.2 Sử dụng lại dịch vụ Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi nhất định nên chúng dễ dàng được tìm thấy và tái sử dụng. Nếu một dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến interface mô tả. Các dịch vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích khác nhau. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lắp và tăng độ vững chắc trong cài đặt, nó còn giúp đơn giản hoá việc quản trị. Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụng thành tố hay lớp. Những dịch vụ được dùng chung bởi tất cả các ứng dụng của một hệ thống SOA gọi là những shared infrastructure service. 2.3.3 Sử dụng dịch vụ bất đồng bộ Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận. Bên nhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp được xử lý xong. Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc độ tối ưu. Do bên gọi không phải chờ 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 đồng bộ và bất đồng bộ. 2.3.4 Quản lý các chính sách Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các policy. Các policy cần được quản lý các áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi.
  36. Trang 15 Việc này tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng. Bởi vì các policy được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm. Nếu không sử dụng các policy, các nhân viên phát triển phần mềm, nhóm điều hành và nhóm nhóm hỗ trợ phải làm việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những policy. Ngược lại , nếu sử dụng policy, những nhân viên phát triển phần mềm giờ chỉ cần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào các luật kết hợp. 2.3.5 Coarse granularity Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách. Đầu tiên, nó được hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ. Thứ hai, nó được hiểu trong phạm vi từng phương thức của từng interface triển khai. Mức độ granularity cũng được hiểu ở mức tương đối. Ví dụ, nếu một dịch vụ cài đặt tất cả chức năng của một hệ thống ngân hàng, chúng ta xem nó là coarse-grained. Nếu nó hỗ trợ chỉ chức năng kiểm tra thể tính dụng, chúng ta lại xem nó là fine-grained. Trước khi có kiến trúc thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựa trên ý tưởng phân tán đối tượng. Những hệ thống phân tán đối tượng chứa bên trong nó nhiều đối tượng fine-grained trao đổi thông tin với nhau qua mạng. Mỗi đối tượng có những ràng buộc với nhiều đối tượng khác bên trong hệ thống. Do truy cập đến một đối tượng phải qua nhiều trung gian mà hiệu quả đạt được không cao nên khuynh hướng thiết kế hệ thống phân tán đối tượng đang dần chuyển sang thiết kế các coarser-grained interface. Hình 2-3 minh họa một hệ thống phân tán đối tượng với nhiều mối liên kết. Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những ràng buộc này trở nên ngày càng khó quản lý. Hiệu suất cũng giảm tương ứng số lượng các kết nối trung gian. Khả năng bảo trì cũng giảm khi số lượng ràng buộc giữa những đối tượng ngày một tăng. Khi một đối tượng cần được thay đổi ở interface, nó có thể ảnh hưởng đến một lượng lớn những đối tượng phân tán khác. Nhân viên phát triển phải biên dịch và triển khai lại toàn bộ đối tượng bị thay đổi và những đối tượng liên quan với chúng.
  37. Trang 16 Một hệ thống dựa trên quản lý các truy cấp đến đối tượng bên trong dịch vụ thông qua một số coarse-grained interface như Hình 2-4. Một dịch vụ có thể được cài đặt như một tập những đối tượng fine-grained nhưng bản thân những đối tượng đó lại được sử dụng trực tiếp qua mạng. Trong khi đó một service được cài đặt như những đối tượng có một hoặc nhiều đối tượng coarse-grained hoạt động như những facades phân tán thì những đối tượng này lại có thể được sử dụng qua mạng và cho phép truy cập đến các đối tượng sâu bên trong. Tuy nhiên các đối tựơng bên trong service đó bây giờ sẽ trao đối trực tiếp với nhau ở trong cùng một máy chứ không phải trên mạng. Hình 2-3 – Các đối tượng fine-grained Hình 2-4 – Các đối tượng coarse-grained
  38. Trang 17 Mặc dù những service nói chung hỗ trợ coarser-grained interface hơn các hệ thống phân tán đối tượng và các hệ thống hướng thành tố, độ “thô” vẫn hàm chứa bên trong nó chứa một mức độ granularity nào đó , như hình Hình 2-5. Hình 2-5 – Các mức độ granularity 2.3.6 Khả năng cộng tác Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác (Interoperability), khả năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau. Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối. Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu. Interoperability is achieved bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client. Kỹ thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian. Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống. Ví dụ Web Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống, JAX-RPC và JAXM chuyển đối tượng dạng Java thành SOAP. 2.3.7 Tự động dò tìm và ràng buộc động SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery). Một người sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần. Người sử dụng chỉ cần hỏi một registry về dịch vụ nào thoả yêu cầu tìm kiếm. Ví dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng. Registry trả về một tập các entry thoả yêu cầu. Các
  39. Trang 18 entry chứa thông tin về dịch vụ, bao gồm cả phí giao dịch. Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến nhà cung cấp dịch vụ đó dựa trên thông tin registry entry để sử dụng dịch vụ kiểm tra thẻ tín dụng. Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô tả cung cấp và gửi đi. Nhà cung cấp dịch vụ sẽ thực thi kiểm trả thẻ tín dụng và trả về một thông điệp có định dạng đúng như trong phần mô tả dịch vụ. Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian. Mối ràng buộc này là ràng buộc trong thời gian chạy chứ không phải ràng buộc trong lúc biên dịch. Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy. Ví dụ trên cho thấy cách bên sử dụng triệu gọi dịch vụ một cách “động”. Đây là một thế mạnh của SOA. Với SOA, bên sử dụng dịch vụ không cần biết định dạng của thông điệp yêu cầu và thông điệp trả về,cũng như địa chỉ dịch vụ cho đến khi cần. 2.3.8 Tự hồi phục Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ thống tự hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con người. Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nao trong tình trạng hỗn loạn. Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp từ những từ nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy phụ thuộc vào khả năng phụ hồi của phần cứng sau khi bị 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 khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó ứng dụng được xây dựng. Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên.
  40. Trang 19 Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu 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 cùng một interface. Nếu một thể hiện service 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 khách hàng mà không bị ảnh hưởng gì. Khả năng này chỉ có được khi client chỉ tương tác với interface của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ. Đây là một trong những tình chất cơ bản của các hệ thống hướng dịch vụ. 2.4 Lợi ích của SOA Nói đến SOA là nói đến ‘tiết kiệm’- cả tiết kiệm chi phí lẫn thu được giá trị nhiều hơn từ các hệ thống có sẵn. Hẳn cũng phải có lý do để hàng trăm tập đoàn đã chú ý đến SOA như một giải pháp tích hợp nhằm giảm giá thành của một đề án một cách rất ấn tượng. ¾ Sử dụng lại những thành phần có sẵn Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công ty thu được giá trị nhiều hơn bằng cách sử dụng lại những tài nguyên sẵn có; kết quả là giảm chi phí cho phần kiến trúc và tích hợp. Ngoài ra nó còn giúp giảm chi phí mua phần mềm mới. Thời gian viết chương trình lấy dữ liệu từ máy chủ trước đây được tính bằng tháng thì bây giờ chỉ còn tính bằng phút ! Lợi ích của việc sử dụng lại có thể chia làm 2 phần : • Lợi ích từ việc sử dụng lại những thành phần nhằm giảm tính dư thừa. • Lợi ích từ việc sử dụng lại những thành phần có sẵn khi thiết kế cung cấp một chức năng mới. Đầu tiên như đã nói, nhiều phần mềm doanh nghiệp đã phát triển thành những nhóm phần mềm tách biệt (funtional silos), thông thường là tương ứng với mỗi đơn vị kinh doanh. Ví dụ một công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống phân phối, một nhóm phần mềm cho hệ thống lưu kho và một nhóm phần mềm cho những chức năng liên kết. Thông thường những nhóm phần mềm này đựơc phát triển trên nhiều nền tảng khác nhau, sử dụng nhiều ngôn ngữ lập trình khác nhau và
  41. Trang 20 thường có nhiều tính năng lặp lại giữa chúng. Một hệ thống SOA cho phép các công ty tránh tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng. Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản của dịch vụ cần được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹ năng tương ứng với những kỹ năng đã dùng để phát triển dịch vụ. Lợi ích rõ ràng nhất là giảm chi phí bảo trì phần mềm. Ngoài ra điều này còn giúp doanh nghiệp chịu trách nhiệm nhiều hơn với những thay đổi về về mặt nghiệp vụ và cho phép doanh nghiệp cập nhật những tính năng của nó nhanh hơn. Bằng cách phân rã một ứng dụng thành những đơn thể dịch vụ nghiệp vụ, sau đó cho những dịch vụ này liên kết lại với nhau, các hệ thống bây giờ có thể sử dụng lại được các thành phần có sẵn, giảm chi phí phát triển từng phần độc lập cho mỗi tính năng mới chưa có. Thay vì phải “thay đổi” , với SOA ta chỉ cần tạo ra các “cầu nối” liên hệ giữa những hệ thống và ứng dụng khác nhau, thay vì chỉnh sửa hoặc xây dựng lại từ đầu. Bởi vì có đa phần các dịch vụ mới sử dụng lại những dịch vụ sẵn có nên chi phí phát triển các thành phần mới được giảm đến mức tối thiểu. Nghĩa là : • Các công ty có thể triển khai những tiến trình xử lý mới nhanh hơn rất nhiều. • Chi phí dành cho phát triển và kiểm thử giảm đáng kể • Giảm rủi ro khi dịch vụ tạm ngưng hoạt động Lợi ích cuối cùng của việc tái sử dụng thường khó nhận thấy, đó là sử dụng những thành phần có sẵn trước đó mỗi khi có thể thì mỗi khi có lỗi xảy ra ta có thể giới hạn vào khu vực có những thành phần đang được phát triển. Nhờ đó rủi ro về lỗi phần mềm giảm đi và tăng chất lượng dịch vụ. Giảm chi phí phát triển và kiểm thử, và tránh công việc trùng lặp là một trong những lợi ích mà SOA mang lại. Nhưng quan trọng vẫn là lợi ích từ việc tăng khả năng kinh doanh. Nếu những nhân tố này được đánh giá đúng mức thì lợi ích mang lại là rất đáng kể.
  42. Trang 21 ¾ Giải pháp ứng dụng tổng hợp cho doanh nghiệp Cũng với ví dụ trên, SOA mang đến khả năng tổng hợp một lớp các ứng dụng mới bằng cách kết hợp chức năng từ những hệ thống có sẵn, cung cấp cho người cuối những chức năng liên kết. Ở đây một số tiến trình cũ có thể được kết hợp với nhau bên trong một cổng thông tin (portal) giúp cho người dùng cuối chỉ cần truy cập một lần mà vẫn có thông tin về hàng loạt sản phẩm của doanh nghiệp. Loại kết hợp này có thể khó khăn nếu không sử dụng SOA vì nó đòi hỏi việc tích hợp phức tạp, nỗ lực lập trình và kiểm thử. Nhưng với SOA , một ứng dụng tổng hợp có thể được tổng hợp dễ dàng, bất kể sự khác nhau về địa lý hoặc công nghệ phát triển các dịch vụ đó. Điều này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí đến mức tối thiểu và tăng sức mạnh thoả mãn yêu cầu của người dùng cuối hiệu quả hơn. ¾ Tính loose coupling giúp tăng tính linh hoạt và khả năng triển khai cài đặt Lợi ích kế tiếp đến từ tính loose coupling của SOA, trong đó phía triệu gọi dịch vụ không cần quan tâm đến địa chỉ hoặc công nghệ nền tảng của service. Nó mang đến khả năng linh hoạt cao và nhiều lợi ích khác. Trong một hệ thống SOA ta triệu gọi dịch vụ thông qua các interface theo một dạng thức chuẩn nên giúp lập trình viên tránh được việc phải lặp lại công việc tạo mới các service có khả năng hiểu tất cả những công nghệ được sử dụng bởi từng dịch vụ trong hệ thống. Thứ hai, trong trường hợp cần kết nối với các đối tác thương mại thì những dịch vụ có tính loose-coupling, những interface chuẩn càng đem lại nhiều lợi ích hơn. Với một hệ thống SOA, thật dễ dàng khi cung cấp một loạt những dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng. Nhờ tính độc lập địa chỉ và công nghệ của SOA, đối tác kia không cần quan tâm đến dịch vụ được cài đặt như thế nào, và nhờ các dịch vụ đã theo chuẩn giao tiếp nên đối tác đó chỉ cần một lượng thông tin nhỏ vừa đủ để sử dụng dịch vụ. Tương tự cho điều ngược lại, nếu đối tác đã xây dựng một hệ thống SOA thì việc đem sử dụng chức năng một số dịch vụ của họ vào sử dụng bên trong hệ thống của mình cũng trở nên dễ dàng và nhanh chóng. Đặc tính này của SOA hứa hẹn tăng hiệu suất và tự động hoá.
  43. Trang 22 Cuối cùng một lợi ích mà tính loose coupling mang lại là tăng khả năng triển khai. Như đã phân tích ở trên, những thành phần có tính loose coupling có thể được triệu gọi mà không cần biết chúng được cài đặt như thế nào mà chỉ cần biết cách thức triệu gọi chúng thông qua một interface chuẩn. Vì vậy chỉ cần bọc những thành phần sử dụng interface ứng dụng thành dạng dịch vụ, ta đã có một đơn thể thành phần được sử dụng trong hệ thống SOA như những dịch vụ bình thường khác. ¾ Thích ứng với những thay đổi trong tương lai Các phương pháp tiếp cận truyền thống trong quy trình phát triển phần mềm có thể mô tả ngắn gọn là người dùng mô tả họ cần gì – công ty phát triển phần mềm – triển khai hệ thống theo yêu cầu. Quy trình này đôi khi gặp khó khăn khi gặp những tình huống thay đổi không định trước. Với SOA, công ty phát triển phần mềm có thể tạo nên những quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “theo yêu cầu” và theo “thời gian thực“. ¾ Hỗ trợ đa thiết bị và đa nền tảng. SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới. Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cả những trình duyệt và thiết bị di động như pager, điện thoại di động, PDA và các thiết bị chuyên dụng khác sử dụng cùng một chức năng mà vẫn có thông tin trả về tùy theo dạng thiết bị. Tính độc lập công nghệ này giúp cho các công ty tiết kiệm chi phí rất nhiều nhất là khi phải xử lý với vô số công nghệ hiện đang được sử dụng. ¾ Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp. Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách thêm nhiều thể hiện (instance) của một service. Công nghệ chia tải (load-balancing) sẽ tự động tìm và định tuyến yêu cầu đến thể hiện service thích hợp. Tương tự, SOA có thể chuyển tiếp nội dung yêu cầu đến một thể hiện khác khi cần,nhờ đó tăng khả năng sẵn sàng phục vụ.
  44. Trang 23 Cần nhấn mạnh là lợi ích mà SOA mang lại không phải là ít mà là rất ấn tượng. Thực tế giá trị kinh tế mà SOA mang lại lớn đến nỗi các tạp đoàn trên thế giới đang suy xét xem làm thế nào để chuyển toàn bộ các kiến trúc phần mềm có sẵn của họ thành SOA. 2.5 Một số mô hình triển khai SOA Chúng ta sẽ thảo luận về ba mô hình triển khai chính của SOA là : service registy, service broker và service bus. Service registry : đây là mô hình truyền thống để định vị và liên kết các dịch vụ trong một hệ thống SOA. (xem hình Hình 2-6) . Mô hình service registry về cơ bản chỉ cần các chuẩn Web services thông thường là SOAP, WSD và UDDI. Vấn đề lớn nhất của mô hình này là các liên kết dịch vụ là kết nối tĩnh và phải định nghĩa trong thiết kế, điều này làm cho mô hình trở nên cứng nhắc. Có một cách cải tiến làm cho mô hình này linh hoạt hơn là tìm kiếm, định vị các dịch vụ khi chạy. UDDI hỗ trợ nhiều cấu hình khác nhau cho cùng một dịch vụ cung cấp bởi nhiều nhà cung cấp dịch vụ khác nhau. Điều này cho phép chia tải và tăng tính tin cậy bởi vì service directory có thể tìm kiếm một dịch vụ nào đó trên tất cả các nhà cung cấp dịch vụ hiện có . Hình 2-6 - Mô hình service registry
  45. Trang 24 Service broker : Một bộ trung gian làm việc giữa dịch vụ cung cấp và dịch vụ tiêu thụ. Trong mô hình cơ bản, tất cả những thông điệp đều được trung chuyển qua service broker. Dịch vụ này có thể làm nhiều chức năng như định tuyến dựa trên dữ liệu thông điệp, xử lý lỗi, chuyển đổi thông điệp, chia tải và lọc thông tin. Nó cũng có thể cung cấp dịch vụ bảo mật, chuyển đổi giao thức, lưu vết và các dịch vụ hữu ích khác. Tuy nhiên, service broker là nơi có thể xảy ra hiện tượng nghẽn cổ chai và là điểm dễ bị hỏng hóc. Mô hình broker phân tán là một bước cải tiến mới, ở đó mỗi nền tảng dịch vụ có một broker cục bộ cho phép giao tiếp với một service broker trung tâm và giao tiếp trực tiếp với các service broker cùng cấp ở các nền tảng dịch vụ khác. Hình 2-7 – Mô hình service broker
  46. Trang 25 Service bus : đây là mô hình ra đời sau nhất trong 3 mô hình nhưng nó đã được sử dụng trong các sản phẩm thương mại large-scale (như IBM, BEA). Service bus cũng là mô hình có tính loose coupling nhất trong các mô hình, trong đó các dịch vụ không kết nối trực tiếp với nhau. Đôi khi các service bus kết nối với nhau thành một mạng các service bus. Hình 2-8 – Mô hình service bus Hình 2-9 – Mô hình service bus phân tán
  47. Trang 26 2.6 Kiến trúc phân tầng chi tiết của SOA Ở tầng thấp nhất, tầng kết nối (connectivity), những dịch vụ được mô hình hoá dựa trên những ứng dụng enterprise bên dưới. Tầng này chứa các dịch vụ như “lấy thông tin chi tiết sản phẩm” hoặc “cập nhật thông tin khách hàng” , chúng tương tác trực tiếp với các hệ thống phi dịch vụ bên dưới. Các dịch vụ này là đặc trưng cho mỗi ứng dụng enterprise. Phía bên trên tầng kết nối là một số dịch vụ orchestration được thêm vào để tạo ra các dịch vụ thật sự xử lý những chức năng nghiệp vụ độc lập dựa trên những ứng dụng enterprise bên dưới. Những dịch vụ này còn gọi là những dịch vụ tổng hợp (composite service). Trên cùng của tầng service orchestration là các ứng dụng tổng hợp sử dụng các service and cung cấp giao diện cụ thể cho người sử dụng. Hình 2-10 – Kiến trúc phân tầng của hệ thống SOA 2.6.1 Tầng kết nối Mục đích của tầng kết nối là kết nối đến các ứng dụng enterprise hoặc tài nguyên bên dưới và cung cấp chúng thành dạng những dịch vụ. Tầng này là tầng chuyên giao tiếp với các nhà cung cấp, hoạt động như một bộ chuyển đổi (adapter) giữa các ứng dụng phi dịch vụ và mạng các dịch vụ khác. Tùy vào ứng dụng cụ thể nào mà bộ chuyển đổi tương ứng được sử dụng.
  48. Trang 27 Về cơ bản, tầng này có thể dùng để thực hiện kết nối đến các hệ cơ sở dữ liệu. Những ngôn ngữ lập trình hiện đại cung cấp những tập hàm API cho phép truy cập đến hầu hết cơ sở dữ liệu thông dụng. Với các ứng dụng enterprise thì lại khác, vì mỗi nhà cung cấp cung cấp tập hàm API khác nhau. 2.6.2 Tầng orchestration Tầng orchestration chứa các thành phần đóng vai trò vừa là những dịch vụ sử dụng vừa là những dịch vụ cung cấp. Những dịch vụ này sử dụng những dịch vụ của tầng kết nối và các dịch vụ orchestration khác để kết hợp những chức năng cấp thấp hơn thành những dịch vụ hoạt động ở cấp cao hơn, có hành vi gần với những chức năng nghiệp vụ thực hơn. Simple composite service : là những dịch vụ đơn thuần kết hợp những lời triệu gọi đến các dịch vụ bên dưới, hoạt động như mẫu mặt tiền. Chúng giúp đơn giản hoá qua trình tương tác với các dịch vụ cấp thấp và che dấu tính phức tạp tới người sử dụng các dịch vụ ở tầng cao. Process service: là những dịch vụ định ra một tiến trình kết nối những dịch vụ cấp thấp hơn. Điều này rất hữu dụng khi thiết kế các dịch vụ kết nối đến nhiều hệ thống enterprise bên dưới sau đó thực thi như một tiến trình. Ví dụ dịch vụ “Submit New Order” có thể được xem như một process service thực hiện tương tác với cơ sở dữ liệu khách hàng để lấy thông tin chi tiết về khách hàng, quyết định dựa trên thông tin tài khoản của khách hàng, tương tác hệ thống lưu kho và hệ thống tài chính để hoàn tất yêu cầu đặt hàng. Bởi vì process service có những đặc tính gần với quy trình nghiệp vụ của doanh nghiệp nên hiện có rất nhiều nỗ lực để chuẩn hoá cách thức định nghĩa ra chúng. WS- BPEL (Web Service Business Process Execution Language) là tên được tổ chức OASIS chọn cho chuẩn này. Cho đến tháng 5 năm 2004, chuẩn này vẫn được liên tục cập nhật để có thể mô tả nhiều process đa dạng với mức độ phức tạp ngày càng cao.
  49. Trang 28 Data service : là những dịch vụ cung cấp dữ liệu thu thập từ nhiều nguồn dữ liệu tách biệt khác nhau. Trong nhiều trường hợp dữ liệu cùng tồn tại trên nhiều ứng dụng và cơ sở dữ liệu khác nhau. Ví dụ thường thấy là thông tin về khách hàng. Doanh nghiệp thường lưu trữ thông tin khách hàng trong hệ thống đặt hàng, hệ thống tài chính và hệ thống CRM. Mỗi hệ thống chỉ chứa một phần dữ liệu trong toàn bộ dữ liệu về khách hàng. Data service thường không được xem như một dịch vụ orchestration mà nó chịu trách nhiệm tương tác trực tiếp với những cơ sở dữ liệu bên dưới thông qua những phương thức truy cập phi dịch vụ (non-service oriented accesss) như JDBC hoặc J2CA. Chúng cung cấp dữ liệu từ những ứng dụng độc lập và kết hợp dữ liệu từ nhiều nguồn khác nhau. Data service thường sử dụng một số ngôn ngữ truy vấn và cơ chế mô tả khác để xác định quan hệ giữa những lược đồ dữ liệu (data schema). Các công nghệ phổ biến hiện nay là SQL, XSLT và Xquery trong đó XQuery và XSLT là hai công nghệ thuần về việc truy vấn dữ liệu trong bối cảnh Web Service vì chúng xử lý và kết xuất dữ liệu dạng XML. 2.6.3 Tầng ứng dụng tổng hợp Dữ liệu truyền qua lại giữa những dịch vụ cuối cùng cũng định hướng đến người sử dụng theo nhiều dạng giao diện khác nhau. Tầng này được xem là tầng tích hợp cuối cùng của quá trình tích hợp.
  50. Trang 29 Hình 2-11 – Một công thông tin cung cấp thông tin trong một vùng nhìn duy nhất Hình 2-12 – Các portlet truy xuất dữ liệu từ nhiều nguồn khác nhau được cung cấp dưới dạng dịch vụ
  51. Trang 30 Tầng ứng dụng tổng hợp là tầng đơn thuần sử dụng các dịch vụ, nó cung cấp các ứng dụng cho người dùng cuối. Nhờ tính linh hoạt của SOA và đặc tính của các dịch vụ được tổng hợp từ tầng orchestration, các ứng dụng tổng hợp có khả năng biểu diễn mọi loại thông tin từ mọi nguồn thông tin, thậm chí còn cho phép người sử dụng gửi thông tin tổng hợp mà thông tin đó sẽ được phân phối lại cho các hệ thống bên dưới. Bản chất của giao diện là khó xây dựng. Chúng cũng khó được chia thành từng thành phần logic tương tác với nhau theo dạng chuẩn hoá. Đôi khi cố gắng phân rã một thành phần giao diện thành những phần nhỏ lại làm mất bố cục chặt chẽ và khó sử dụng hơn là ứng dụng gốc. Tầng ứng dụng tổng hợp chia làm hai tầng nhỏ hơn là Portal và tầng Portlet. Một Portlet được định nghĩa như một ứng dụng chạy trong một cửa số thành phần trong một ngữ cảnh lớn hơn với sự tách biệt rõ ràng giữa Portlet và ngữ cảnh của nó. Portlet là thành phần cung cấp và sử dụng dịch vụ . Có điều là dịch vụ chúng cung cấp là một dạng dịch vụ giao diện đặc biệt được thiết kế đặc biệt để được sử dụng bởi một bộ UI Framework consumer (một Portal). Mỗi portlet sử dụng một số dịch vụ liên quan của tầng orchestration bên dưới và cho phép người sử dụng gửi thông tin bổ sung. Công nghệ web hiện nay như Java Server Faces (JSF) và ASP.NET đều hỗ trợ xây dựng portlet. Portal là một bộ khung tích hợp sử dụng các Porlet, trang bị cho chúng một vẻ ngoài thống nhất và thể hiện thành một giao diện hoàn chỉnh cho người dùng cuối. " Kiến trúc hướng dịch vụ thật sự đem đến những lợi ích to lớn. Thế nhưng để đạt được những lợi ích này ta phải xây dựng và triển khai thành công hệ thống SOA. Chương 3 sẽ trình bày về các vấn đề này.
  52. Trang 31 Chương 3 XÂY DỰNG HỆ THỐNG SOA " Chương 3 sẽ trình bày các vấn đề liên quan đến việc xây dựng và triển khai hệ thống SOA trong thực tế một cách hiệu quả, bao gồm phân tích các thách thức gặp phải và xem xét qui trình các bước nên thực hiện khi xây dựng hệ thống SOA. 3.1 Những thách thức khi xây dựng hệ thống SOA Những lợi ích đạt được của một hệ thống SOA đã quá rõ ràng. Thế nhưng việc triển khai một hệ thống SOA không phải là điều dễ dàng. Trong thời gian qua, chúng ta đã chứng kiến các sự thay đổi các mô hình tính toán trong các tổ chức. Từ mô hình tính toán tập trung (mainframe) sang các mô hình phân tán client/server, rồi sau đó là các kiến trúc dựa trên nền tảng Web bởi phát triển lớn mạnh của Internet. Và nay, quá trình này vẫn còn tiếp tục. Chúng ta đang ở thời kỳ quá độ sang mô hình tính toán dựa trên dịch vụ và kiến trúc hướng dịch vụ (SOA). Với mọi sự chuyển đổi đều có những thảo luận, tranh cãi, kinh nghiệm ; có những người “dẫn đường” và những người “nối bước”; có những người “chiến thắng” và những người “thất bại”; có những hệ thống vận hành hiệu quả và những hệ thống bị đổ vỡ Lần này cũng sẽ không có gì khác. Ta sẽ xem xét các vấn đề mà sẽ gây nhiều trở ngại cho trong quá trình triển khai các hệ thống SOA. Phần này sẽ trình bày thách thức mà một tổ chức sẽ phải đối mặt tương ứng với các pha trong một dự án triển khai thực tế. • Xác định dịch vụ ► Dịch vụ là gì? Chức năng nghiệp vụ nào cần được cung cấp bởi một dịch vụ? Độ “mịn” (granularity) của dịch vụ thế nào là tốt? ► Việc xác định dịch vụ và quyết định đối tượng cung cấp dịch vụ một cách thích hợp, hiệu quả là giai đoạn quan trọng và đầu tiên trong một giải pháp
  53. Trang 32 hướng dịch vụ. Trong thực tế, nhiều chức năng nghiệp vụ tương tự nhau có thể được cung cấp bởi nhiều hệ thống trong một tổ chức. • Phân bổ dịch vụ ► Ta nên đặt dịch vụ ở vị trí nào trong hệ thống? ► Các dịch vụ thường hoạt động dựa trên các thực thể nghiệp vụ. Các đối tượng này được lưu và quản lý trong hệ thống. Vị trí của các thực thể này cũng là vị trí tốt nhất để đặt dịch vụ. Tuy nhiên, bởi đặc tính của một hệ thống phân tán nên các đối tượng này được phân bố rải rác ở nhiều vị trí và có thể có tình trạng một đối tượng được quản lý ở nhiều nơi. Vì thế, đồng bộ dữ liệu giữa các hệ thống trở nên là một yêu cầu quan trọng. Trong môi trường như thế thì dịch vụ sẽ được đặt ở đâu? • Xác định miền dịch vụ ► Làm sao gom nhóm các dịch vụ thành các miền luận lý (logic domain)? ► Việc phân loại, gom nhóm các dịch vụ thành các miền luận lý sẽ đơn giản hóa kiến trúc hệ thống bởi sẽ giảm được số lượng các thành phần cần xây dựng. Ngoài ra, việc định nghĩa các miền luận lý như thế cũng ảnh hưởng đến nhiều khía cạnh khác của kiến trúc hệ thống như cân bằng tải (load balancing), điều khiển truy cập (access control), sự phân chia theo chiều sâu hay chiều rộng các xử lý nghiệp vụ. Tuy nhiên, điều khó khăn nhất đó là làm sao đạt được đồng nhất quan điểm của các đơn vị, các bộ phận kỹ thuật về tính hợp lý của một miền tạo ra. • Đóng gói dịch vụ ► Làm sao có thể bao bọc các chức năng sẵn có của hệ thống cũ vào trong một dịch vụ? ► Nếu hệ thống khi được thiết kế đã quan tâm và hỗ trợ vấn đê tích hợp với các hệ thống mới thì vấn đề này sẽ dễ dàng hơn. Tuy nhiên, khi các hệ thống cũ này trước đây được xây dựng như the mô hình kín, đóng gói (monolithic) trong đó chứa toàn bộ các thông tin về nguyên tắc và qui trình
  54. Trang 33 xử lý thì nay, khi được tích hợp, các thông tin này cần được chia sẻ và phân bố trong nhiều ứng dụng khác nhau. • Service orchestration: ► Làm sao để có thể tạo ra các dịch vụ tổng hợp (composite service)? ► Nhu cầu kết hợp nhiều dịch vụ để đáp ứng được nhiều yêu cầu phức tạp từ đối tượng sử dụng là có thực. Vấn đề là làm sao kết hợp các dịch vụ này một cách có hiệu quả, theo những qui trình với những ràng buộc phức tạp. • Định tuyến dịch vụ ► Làm sao để chuyển một yêu cầu từ một đối tượng sử dụng dịch vụ đến dịch vụ hay miền dịch vụ thích hợp? ► Một hệ thống SOA phải có tính độc lập địa chỉ cho đối tượng sử dụng các service của hệ thống. Ngòai ra còn phải quan tâm đến vấn đề hiệu suất hoạt động của hệ thống vì việc định vị một dịch vụ là một quá trình cũng chiếm nhiều thời gian. • Quản lý dịch vụ ► Vấn đề quản lý và bảo trì các dịch vụ, việc tạo xây, theo dõi và thay đổi các dịch vụ như thế nào cho có hiệu quả? • Chuyển đổi thông điệp chuẩn dịch vụ ► Làm sao để lựa chọn một chuẩn định dạng thông điệp trao đổi giữa các chuẩn? Làm sao có thể xây dựng một chuẩn định dạng dữ liệu mà mọi hệ thống đều có khả năng hiểu và xử lý. Ngoài các khó khăn trên mỗi tổ chức với mỗi đặc thù riêng của mình có thể sẽ phải đối diện với các vấn đề khác trong quá trìnhtriển khai hệ thống
  55. Trang 34 3.2 Xây dựng hệ thống SOA 3.2.1 Giới thiệu bài toán Phần này sẽ giới thiệu các giai đoạn cần tiến hành để triển khai một hệ thống SOA đạt hiệu quả cao. Để trình bày vấn đề một cách trực quan hơn, ta sẽ thực hiện xây dựng một giải pháp tổng thể cho bài toán “Bán hàng qua mạng” Mô tả bài toán: • Khách hàng (customer) sẽ truy cập vào website của đại lý (retailer) để xem qua các mặt hàng và đặt hàng các sản phẩm điện tử như là TV, đầu DVD và video camera. • Đại lý chuyển yêu cầu (order) đến cho bộ phận thủ kho (warehouse) để xử lý. • Nếu nguồn hàng trong kho dưới mức cho phép thì yêu cầu bổ sung hàng (replenishment order) được gửi đến nhà sản xuất (manufacturer). • Nhà sản xuất không giải quyết ngay yêu cầu bổ sung hàng, mà có thể sau một khoảng thời gian nào đó khi sản xuất đủ lượng hàng.
  56. Trang 35 3.2.2 Một số khái niệm Phần này sẽ giới thiệu các phương pháp để xác định các services theo phương pháp top-down (xuất phát từ các yêu cầu nghiệp vụ) và bottom-up (xuất phát từ thực trạng của hệ thống hiện có). Cụ thể hơn, sẽ trình bày một số kỹ thuật cũng như là mô tả các bước cần tiến hành để xây dựng hay chuyển đối một hệ thống sẵn có theo mô hình SOA. Phương pháp này bao gồm 7 bước chính được thể hiện ở Hình 3-1. Các bước này không nhất thiết phải được thực hiện một cách tuần tự và tuyến tính, mà quy trình có thể được điều chỉnh bằng cách quyết định các bước nào cần được thực hiện song song, và sự ràng buộc giữa các bước là như thế nào tùy vào các đặc trưng của hệ thống cụ thể cần triển khai. Hình 3-1 - Các bước cần thực hiện khi triển khai một hệ thống SOA. Chúng ta sẽ đi theo qui trình từ trên xuống (theo như trong Hình 3-1). Với các bước mà song song nhau thì trong thực tế có thể tiến hành cùng một lúc. Một số khái niệm cần quan tâm :
  57. Trang 36 • Miền nghiệp vụ (Business domain): Là một miền hay môi trường trong đó diễn ra hoạt động tương tác (như trao đổi tài nguyên) giữa các tác nhân nghiệp vụ (economic agents), như là mua bán, sản xuất, dịch vụ • Tiến trình nghiệp vụ: Là một hoạt động thực hiện trong quá trình quản lý nghiệp vụ một cách thủ công hay tự động. Mọi tiến trình đều cần dữ liệu đầu vào và cho ra một kết quả khi kết thúc. Tùy thuộc vào độ phức tạp mà một tiến trình có thể là một tác vụ đơn giản hay là một thủ tục phức tạp • Tiến trình con: Là một tiến trình được thực hiện như một phần của tiến trình khác. Tiến trình con có thể được “trừu tượng hóa” để che dấu chi tiết bên trong và “cụ thể hóa” để thể hiện đầy đủ quy trình thực hiện bên trong. • Sơ đồ nghiệp vụ sử dụng: Tập trung hơn vào mô tả các qui trình xử lý, còn các vấn đề liên quan đến kỹ thuật, cách cài đặt chỉ được mô tả một cách tổng quát, trừu tượng, như là chỉ nêu lên những dự định (intentions). • Sơ đồ hệ thống: Trong sơ đồ hệ thống mô tả rõ ràng những quyết định (decisions) liên quan đến cài đặt, triển khai, kỹ thuật, ví dụ như trong khi mô tả sẽ sử dụng các thuật ngữ như system, report, screen ) • Hệ thống con: Một hệ thống sẽ được chia thành nhiều hệ thống con chịu trách nhiệm về một hay một nhóm chức năng của hệ thống. Hệ thống con sẽ được xây dựng như những thành phần độc lập để có thể sử dụng lại. • Thành tố: Một hệ thống gồm nhiều thành phần, và một thành phần đảm nhiệm việc thực thi một nhóm chức năng có liên quan của hệ thống. Một thành phần sẽ chứa nhiều dịch vụ và cung cấp các dịch vụ này ra bên ngoài như là thành phần giao tiếp.
  58. Trang 37 • Thành phần nghiệp vụ: Thành phần nghiệp vụ là một thành phần cài đặt của một chức năng hay qui trình nghiệp vụ. Thành phần nghiệp vụ được xây dựng như những thành đơn vị độc lập và có khả năng tái sử dụng của hệ thống. Một vài ví dụ của thành phần nghiệp vụ như: quản lý danh mục hàng hóa, quản lý thanh toán, quản lý đặt hàng và tính thuế • Thành phần kỹ thuật: thành phần kỹ thuật thực thi các chức năng kỹ thuật trong cơ sở hạ tầng của hệ thống (như security component , scheduling component), độc lập với các chức năng nghiệp vụ. • Value-chain : Là khái niệm nhằm chỉ các loại hoạt động nghiệp vụ được thực hiện với mục đích nâng cao lợi nhuận của doanh nghiệp, bao gồm các hoạt động như thu thập nguyên vật liệu, sản xuất, phân phối sản phẩm, marketing, chăm sóc khách hàng • Vùng chức năng: Là khái niệm dùng để mô tả một bộ phận chịu trách nhiệm cho một nhóm các chức năng có liên quan như là về khách hàng, sản xuất, phân phối sản phẩm, lưu trữ kho • Top-down : trong xây dựng một hệ thống SOA, thì phương pháp top-down là phương pháp mà điểm xuất phát của nó sẽ là từ các yêu cầu nghiệp vụ để xác định các yêu cầu chức năng, các tiến trình và tiến trình con, các trường hợp sử dụng (use cases) để tiến tới việc xác định các thành phần hệ thống (components), các dịch vụ • Bottom-up : phương pháp này sẽ dựa trên việc phân tích tình trạng, các tài nguyên của hệ thống hiện có và sẽ tái sử dụng lại những thành phần này trong việc xây dựng các dịch vụ mới.
  59. Trang 38 3.2.3 Các bước xây dựng hệ thống SOA 3.2.3.1 Phân rã domain Ở giai đoạn này ta có thể sử dụng kỹ thuật top-down để phân rã domain (toàn bộ qui trình nghiệp vụ) thành các quy trình nghiệp vụ, tiến trình con và sơ đồ sử dụng. Nếu xem xét ở khía cạnh nghiệp vụ thì một domain bao gồm nhiều vùng chức năng. Hình 3-2 – Phân rã domain thành một dãy các vùng chức năng liên quan Sau khi phân rã domain thành một dãy các vùng chức năng liên quan, ta tiếp tục phân tích từng vùng chứuc năng để xác định các sơ đồ sử dụng. • Mô hình use case: ► UC1: Purchase Goods (khách hàng chọn và mua hàng từ danh sách nhà bán lẻ cung cấp) ► UC2: Source Goods (nhà bán lẻ lấy hàng từ kho để giao cho khách hàng) ► UC3: Replenish Stock (yêu cầu bổ sung hàng khi lượng hàng trong kho dưới mức sàn). ► UC4: Supply Finished Goods (xử lý yêu cầu bổ sung hàng) ► UC5: Manufacture Finishes Goods (sản xuất thêm hàng để đáp ứng yêu cầu khi lượng hàng hiện có không đủ cung cấp) ► UC6: Configure and Run Demo (chạy demo ứng dụng). ► UC7: Log Events (theo dõi và lưu lại các hoạt động được thực hiện bởi các hệ thống) ► UC8: View Events (xem lại thông tin hoạt động đã được lưu lại trước đó.)
  60. Trang 39 Hình 3-3 – Sơ đồ sử dụng của hệ thống bán hàng • Các use case xác định được sẽ là những “ứng cử viên” cho các dịch vụ mà cuối cùng sẽ được cung cấp như những Web service trong các thành phần của hệ thống. Điều này giúp chúng ta đạt được mục tiêu đó là “tiến trình nghiệp vụ tương ứng với hệ thống thông tin”. Hình 3-4 – Sơ đồ các use case và quy trình nghiệp vụ
  61. Trang 40 Phân tích các use case để xác định các use case nghiệp vụ và quy trình nghiệp vụ: Với mỗi use case nghiệp vụ, ta cần xác định dữ liệu vào và dữ ra. Các thông tin dữ liệu tại thời điểm này có thể còn ở mức trừu tượng, tuy thế ta vẫn đảm bảo tính đầy đủ của nó vì các thông tin này sẽ được tinh chế trong các giai đoạn sau khi thiết kế các dịch vụ và thành phần . Chúng ta đang ở trong giai đoạn phân tích, và khi chuyển sang giai đoạn thiết kế thì mỗi vùng chức năng sẽ được ánh xạ thành một hay nhiều các hệ thống con và các use case nghiệp vụ sẽ được ánh xạ thành các use case hệ thống. 3.2.3.2 Xây dựng mô hình Goal-service Trong giai đoạn phân rã domain ta đã xác định được các use case nghiệp vụ, và đây sẽ là cơ sở chính để ta xác định các dịch vụ. Trong giai đoạn này, chúng ta sẽ thiết kế mô hình goal-service để kiểm tra “các ứng cử viên” trên có thật sự là tốt không? Thông qua việc phỏng vấn các đối tượng quản lý nghiệp vụ (business owners) ta sẽ hiểu các mục tiêu trong công việc của họ là gì. Ta sẽ xuất phát từ mục tiêu chính (goal) và từng bước phân tích để xác định các công việc cần làm để đạt được mục tiêu chính đó là gì (sub-goal). Quá trình phân rã như thế (goal thành các sub-goal) sẽ được thực hiện cho tới khi nào ta thấy rằng “mục tiêu này có thể được thực hiện bởi một dịch vụ nào đó”. Như vậy các dịch vụ sẽ gắn liền với các sub-goal nào mà nó cần thực thi trong mô hình goal-service. Điều này sẽ làm cho các dịch vụ có thể truy vết tới business goal (mục tiêu chính). Đây là một đặc điểm quan trọng để đảm bảo rằng toàn bộ các dịch vụ nghiệp vụ là có thể xác định được trong thời gian sớm nhất. Có rất nhiều cách để thể hiện mô hình goal-service. Ở đây, ta sử dụng một cách đơn giản đó là dùng danh sách phân cấp lồng nhau để biểu diễn các goal, sub-goal và dịch vụ. Dưới đây là một ví dụ về mô hình goal-service của nghiệp vụ bán lẻ
  62. Trang 41 Hình 3-5 – Ví dụ về mô hình goal-service • Goal: được thể hiện bằng font chữ bình thường • Dịch vụ: được thể hiện bằng font chữ in nghiêng • Giá trị gia tăng (đây là những dịch vụ cần thiết, nhưng chưa được xác định trong giai đoạn domain decomposition): thể hiện bằng font chữ in đậm. • Giải thích ý nghĩa mô hình: ► Bắt đầu với mục tiêu chính (business goal) đó là increasing revenue (tăng doanh thu). Điều này đạt được nếu ta increasing sales (tăng số lượng bán). Để tăng số lượng bán, ta cung cấp seft-service shopping (hỗ trợ bán hàng tự động), hai use case “Purchase Goods” và “Source Goods” (đã được xác định trong bước phân rã domain) xử lý yêu cầu này. ► Nếu xét kỹ càng hơn về goal seft-service shopping, thì ta thấy rằng sẽ tốt hơn nếu ta có những hỗ trợ tính tiện dụng và thân thiện cho người dùng (provide user-friendly interaction experience). Để giải quyết vấn đề này, thì ta cần cung cấp cho người dùng shopping catalog để xem qua các sản phẩm, đồng thời hỗ trợ shopping card để thực hiện thanh toán qua mạng. • Trong quá trình xây dựng mô hình goal-service này, ta sẽ xác định thêm các dịch vụ cần thiết.
  63. Trang 42 3.2.3.3 Phân tích hệ thống con Trong giai đoạn này, ta sẽ đi sâu hơn trong việc thiết kế và xây dựng kiến trúc hệ thống. Các use case nghiệp vụ sẽ là cơ sở để thiết kế các use case hệ thống. Hệ thống con bao gồm các thành phần nghiệp vụ (như là Customer, Order và Product) và các thành phần kỹ thuật (như là messaging, security và logging). Trong suốt giai đoạn phân tích hệ thống con, các thành phần nghiệp vụ và thành phần kỹ thuật sẽ được xác định như sau: • Phân tích luồng xử lý bên trong của hệ thống con (thường là một chuỗi các use case) để tìm ra các “ứng cử viên” cho thành phần nghiệp vụ. • Phân tích các yêu cầu phi chức năng để tìm ra các thành phần kỹ thuật. • Xác định các chức năng được yêu cầu cho mỗi thành phần nghiệp vụ, nghĩa là, xác định các use case hệ thống mà các thành phần này phải hỗ trợ. Các use case nghiệp vụ được xác định trong giai đoạn phân rã domain thường là những “ứng cử viên” tốt để đưa vào tầng giao tiếp (interface) của các thành phần của hệ thống con, nhằm cung cấp các dịch vụ bên trong của thành phần. Các use case nghiệp vụ này sẽ kết hợp với nhau để hỗ trợ cho một quy trình nghiệp vụ. Trong bài toán của ta, bốn hệ thống con là Retailer, Warehouse, Manufacturer và Logging Facility. Mỗi hệ thống con cung cấp một tập các service nghiệp vụ . Hình 3-6 minh họa hệ thống con Retailer. Sau khi tạo mô hình goal-service xong, ta phân tích use case nghiệp vụ “Purchase Goods” thành hai dịch vụ là “Get Catalog” và “Submit Order”.
  64. Trang 43 Hình 3-6 – Các use case nghiệp vụ được “gắn” trên hệ thống con Mỗi use case nghiệp vụ tương ứng với một tập các use case hệ thống được đóng gói trong hệ thống con. Hệ thống con sẽ sử dụng các thành phần nghiệp vụ và thành phần kỹ thuật để thực thi các use case hệ thống và hỗ trợ cho dịch vụ nghiệp vụ đã được cung cấp ra ngoài (như là Submit Order). Mô hình thể hiện ở Hình 3-6 chỉ nhằm mục đích minh họa. Trong thực tế, các kỹ thuật mô hình hóa sử dụng chuẩn UML sẽ được sử dụng. Sau khi kết thúc giai đoạn phân tích hệ thống con, ta sẽ có được các thành phần được xây dựng như là các dịch vụ . • Retailer dịch vụ cung cấp chức năng truy cập vào danh sách hàng hóa và đặt hàng. • Warehouse dịch vụ hỗ trợ gửi hàng đã đặt và cập nhật tồn kho khi xuất nhập hàng. Mỗi khi lượng hàng tồn kho thấp hơn mức sàn, thì nó sẽ gửi “Purchase Order” (PO) đến cho nhà sản xuất để xử lý. • Warehouse Callback dịch vụ nhận thông tin phản hồi từ phía nhà sản xuất về kết quả xử lý PO rằng có thành công hay không. • Manufacturer: dịch vụ nhận PO và bắt đầu quá trình sản xuất. • Loggin: dịch vụ theo dõi thông tin diễn biến của các hoạt động đã xảy ra và hỗ trợ cho người dùng cuối xem lại thông tin này. Tại thời điểm này, các dịch vụ trên đã có thể kết hợp (orchestration) để tạo nên các dịch vụ tổng hợp hỗ trợ quy trình nghiệp vụ.
  65. Trang 44 3.2.3.4 Phân bổ dịch vụ Ta đã xác định được tất cả các dịch vụ cần thiết qua hai giai đoạn là phân rã domain và xây dựng mô hình goal-service. Trong giai đoạn này, chúng ta sẽ thực hiện “phân bổ” các dịch vụ này vào các thành phần. Phân bổ dịch vụ sẽ xác định xem thành phần nào sẽ cung cấp phần thực thi và quản lý cho mỗi dịch vụ. Phân bổ dịch vụ sẽ thể hiện tính năng truy vết giữa các dịch vụ và các thành phần chịu trách nhiệm thực thi và quản lý chúng. Hình 3-7 – Phân bổ dịch vụ Trong bài toán của ta thì giai đoạn này tương đối đơn giản vì số lượng các dịch vụ không nhiều. 3.2.3.5 Đặc tả thành tố Sau giai đoạn phân tích hệ thống con, ta đã xác định được interface của các hệ thống con, các use case hệ thống, thành phần nghiệp vụ và kỹ thuật. Và ta cũng đã thực hiện gán các dịch vụ vào trong các thành phần . Trong giai đoạn này sẽ tiến hành xây dựng các đặc tả cho từng thành phần. Mẫu của đặc tả này được thể hiện ở Hình 3-8
  66. Trang 45 Hình 3-8 – Mẫu đặc tả thành phần 3.2.3.6 Cấu trúc thành phần và dịch vụ Ta đã xác định mối liên kết giữa thành phần và dịch vụ, và cũng đã xây dựng đặc tả của các thành phần. Trong giai đoạn này ta sẽ thực hiện phân bố các dịch vụ và các thành phần vào các tầng của SOA. Khi thực hiện giai đoạn này ta cần cân nhắc kỹ càng trước khi đưa ra quyết định, vì kết quả của giai đoạn này không chỉ quyết định kiến trúc của hệ thống mà còn ảnh hưởng đến các kỹ thuật, công nghệ đã được thiết kế và sử dụng để triển khai hệ thống. 3.2.3.7 Lựa chọn giải pháp thực thi Khi các đặc tả chức năng của dịch vụ và thành phần đã được xác định một cách chi tiết, thì giai đoạn tiếp theo là xác định cơ chế, môi trường để thực thi các đặc tả đó. Quyết định này cũng đóng một vai trò rất quan trọng. Ta có thể thực hiện một trong các lựa chọn sau: • Xây dựng các thành phần mới hoàn toàn • Chuyển đổi các hệ thống cũ để tái sử dụng lại các chức năng đã được dịch vụ hóa. • Thực hiện tích hợp hệ thống cũ vào các hệ thống mới • Mua các sản phẩm của hãng khác và tích hợp vào hệ thống của mình • Đăng ký và thuê (outsource) một số phần chức năng thông qua web service
  67. Trang 46 Hình 3-9 – Chọn lựa một giải pháp thực thi thích hợp. Phần xử lý của một dịch vụ có thể sử dụng lại các hệ thống cũ với một trong các cách sau: • Bao bọc (wrapping) hệ thống cũ lại bằng một dịch vụ xử lý thông điệp theo hàng đợi hay một Web service. Nhưng đôi khi giải pháp này không thật sự hiệu quả vì phải thể hiện toàn bộ chức năng của hệ thống ra ngòai. Thành phần hóa những phần nào của hệ thống cũ để chỉ cung cấp các chức năng cần thiết ra bên ngoài. Quá trình này còn được gọi là chuyển đổi (transformation). Cần quan tâm đến vấn đề “giới hạn” (scope) khi thực hiện quá trình này, tránh chuyển đổi cả những phần không cần thiết. 3.3 Triển khai SOA trong thực tế Hình 3-10 – Sơ đồ tổng quan về thương mại điện tử theo yêu cầu
  68. Trang 47 Doanh nghiệp muốn tập trung vào hoạt động kinh doanh chính, giảm chi phí và sử dụng lại những thông tin có sẵn theo những cách mới mà không phải đại tu lại toàn bộ kiến trúc có sẵn của họ. Luôn có một áp lực đòi hỏi phải cân bằng giữa như cầu tính linh hoạt, tiết kiệm chi phí và hiệu quả. Phần sau sẽ phân tích sơ lược các đặc trưng kinh doanh và công nghệ nền tảng. Hình 2-10 minh họa các thành phần chính của “thương mại điện tử theo yêu cầu” (e-business on demand) 3.3.1 Các đặc trưng chính về kinh doanh Ở góc nhìn của doanh nghiệp, thương mại điện tử theo yêu cầu là cung cấp một cách thức cho những công ty cân đối lại hoạt động kinh doanh và môi trường công nghệ phù hợp với yêu cầu tái sử dụng lại những chức năng nghiệp vụ. Các đặc trưng thể được tóm gọn trong những ý sau : ¾ Tập trung Cho phép doanh nghiệp tập trung vào các hoạt động kinh doanh chính, điều khiến họ thành công và nổi trội. Các chiến lược cộng tác cũng được hình thành từ đây để nhằm huy động vốn từ những nguồn này. ¾ Trách nhiệm Là khả năng ứng phó nhanh với các yêu cầu từ phía khách hàng, những mối hiểm nguy từ bên ngoài và nắm bắt cơ hội thị trường. ¾ Đa dạng Nhằm đạt được tính linh hoạt trong hoạt động và quy trình nghiệp vụ. Nhằm thích ứng với điều kiện giá cả khác nhau, tăng năng suất hoạt động. ¾ Vững vàng Tính vững vàng giúp doanh nghiệp đáp ứng lại những thay đổi cả ở trong kinh doanh lẫn môi trường công nghệ. Điều này còn giúp quản lý thay đổi, quản lý rủi ro và ước lượng doanh thu.
  69. Trang 48 3.3.2 Các đặc trưng chính về công nghệ Thương mại điện tử theo yêu cầu cần được hỗ trợ bởi một kiến trúc công nghệ được định nghĩa, mô tả chi tiết rõ ràng. Các đặc trưng về công nghệ này mang lại khả năng linh hoạt, trách nhiệm và hiệu quả mà doanh nghiệp cần có: • Tích hợp • Trừu tượng hóa • Tự động hoá • Các chuẩn mở 3.3.2.1 Tích hợp Thành phần cơ bản của cấu trúc theo yêu cầu (on demand infrastructure) là tích hợp. Năm 2002, Sam Palmisano, Chief Executive Officer của IBM định nghĩa on demand như sau : “Một hoạt động kinh doanh theo yêu cầu (on demand business) là một tổ chức có quy trình nghiệp vụ, tích hợp với các đối tác chính, các nhà cung cấp và khách hàng mà vẫn có thể đáp ứng nhanh mọi yêu cầu của khách hàng, mối hiểm nguy từ bên ngoài và nắm bắt được cơ hội trên thị trường” . Quá trình tích hợp có thể diễn ra ở nhiều mức độ khác nhau :  Con người  Quy trình  Ứng dụng  Hệ thống  Dữ liệu
  70. Trang 49 3.3.2.2 Trừu tượng hóa Nhiều công nghệ trong đời sống thường ngày của chúng ta khai thác khái niệm trừu tượng hóa như điện thoại di động, PDA, kết nối mạng không dây, máy in, vân vân . Các khía cạnh của trừu tượng hóa còn gây tác động ảnh hưởng sâu rộng đến các quan niệm kiến trúc như thiết kế và phát triển hướng đối tượng, Web Service và XML. 3.3.2.3 Tự dộng hoá Tính toán tự động giúp giải quyết nhu cầu của một tổ chức muốn giới hạn thời gian và chi phí xuất phát từ những nguyên nhân sau: • Chi phí cao cho ứng dụng mới và nhân công chất lượng cao • Thời gian tiêu phí cho những nền tảng công nghệ khác hẳn nhau thậm chí ở bên trong cùng một tổ chức. • Ngân sách IT chi cho bảo trì chứ không phải cho giải pháp giải quyết vấn đề. • Tính phức tạp giữa những hệ thống không đồng nhất. Vậy thì làm cách nào một tổ chức xác định được các vấn đề liên quan sử dụng môi trường thực thi theo yêu cầu (on demand Operating Enviroment) ? Lúc này là lúc cần đến khả năng tính toán động (autonomic computing). Khả năng tính toán động có thể được tóm gọn trong 4 ý chính : ¾ Tự hồi phục Là khả năng duy trì chức năng hoạt động của một hệ thống bằng cách dò tìm, ngăn ngừa và phục hồi sau khi bị lỗi mà chỉ cần một sự can thiệp tối thiểu hoặc không cần can thiệp từ phía con người. Yêu cầu này tỉ lệ với mối ràng buộc ngày càng nhiều với kiến trúc công nghệ. Nhu cầu tự hồi phục tăng khi yêu cầu về khả năng đáp ứng của tổ chức tăng. ¾ Tự cấu hình Khả năng thích ứng động với sự thay đổi của môi trường, thêm hoặc bớt thành phần từ các hệ thống và thay đổi môi trường để thích nghi với yêu cầu công việc khác nhau.
  71. Trang 50 ¾ Tự tối ưu hoá Tự động chọn cấu hình đạt hiệu quả làm việc tối ưu bao gồm việc tối ưu tài nguyên và quản lý công việc. Điều này giúp giảm bớt gánh nặng khan hiêm tài nguyên phục vụ cho các yêu cầu thường xuyên. Mục tiêu là điều chỉnh hệ thống nhằm đáp ứng được với những thay đổi trong công việc. Các hệ thống phải kiểm tra và tự điều chỉnh liên tục để có thể đáp ứng và thay đổi phù hợp với môi trường xung quanh. ¾ Tự bảo vệ Bảo mật là một trong những yêu cầu cần được quan tâm trước khi các tổ chức chuẩn bị chia sẻ dữ liệu ra bên ngoài. Khả năng tự bảo vệ (self-protecting) yêu cầu hệ thống phải cung cấp một cách thức an toàn để bảo về thông tin và dữ liệu. Qua trình tự bảo vệ làm việc theo quy tắc dự đoán, dò tìm, nhận dạng và bảo vệ hệ thống khỏi những hiểm nguy từ bên ngoài lẫn bên trong. 3.3.3 Các chuẩn mở Các chuẩn mở ảnh hưởng đến môi trường thực thi theo yêu cầu giữa các tầng như khả năng tự động hoá, tích hợp và trừu tượng hóa. Các chuẩn mở là nhân tố quan trọng ảnh hưởng đến tính linh hoạt và khả năng cộng tác giữa những hệ thống không đồng nhất. Tính phổ biến toàn cầu của đặc tả chuẩn cho phép các hệ thống tách biệt tương tác lẫn nhau. Các nền tảng bên dưới có thể khác hẳn và độc lập với nhau nhưng các chuẩn mở cho phép xây dựng những tiến trình bất kể sự khác biệt đó. Các chuẩn mở cung cấp cho môi trường thực thi thương mại điện tử theo yêu cầu (e- business on demand Operating Enviroment) một cơ chế mở và đúng chuẩn để có thể triệu gọi những service hệ thống. 3.3.4 Kiến trúc hướng dịch vụ và Thương mại điện tử theo yêu cầu SOA được định nghĩa là một cách tiếp cận trong việc định ra những kiến trúc tích hợp dựa trên khái niệm dịch vụ. Các chức năng nghiệp vụ và kiến trúc được cung cấp
  72. Trang 51 dưới dạng những dịch vụ. Đây là khái niệm nền tảng của hệ thống. SOA sử dụng Web Service như một tập các chuẩn linh hoạt và có khả năng cộng tác cho các hệ thống phân tán. Có sự bổ sung qua lại tự nhiên giữa SOA và Web Service, SOA nhấn mạnh đến 4 thành phần của thương mại điện tử theo yêu cầu theo cách sau : ¾ Các chuẩn mở • SOA cung cấp một cách thức triệu gọi chuẩn đến các Web Service cho các tổ chức chia sẻ sử dụng qua mạng. • Web Service sử dụng các chuẩn mở cho phép kết nối đa doanh nghiệp qua mạng và internet ► Giao thức thông điệp (SOAP) ► Giao thức truyền tải (HTTP, HTTPS, JMS) ► Xử lý bảo mật ở tầng truyền tải (HTTPS) lẫn tầng giao thức (WS-Security) • WSDL cho phép Web Service tự mô tả về mình ¾ Tích hợp • Cung cấp các interface nhằm bao bọc các điểm cuối dịch vụ hướng đến xây dựng một kiến trúc độc lập hệ thống. • SOA có thể cung cấp tính năng truy tìm và kết nối dịch vụ động (dynamic service discovery and binding), nghĩa là có thể tích hợp dịch vụ theo yêu cầu. ¾ Virtualization • Một đặc tính quan trọng của SOA là các dịch vụ được triệu gọi mà không cần biết chi tiết cài đặt của service kể cả địa chỉ, nền tảng của service đó. ¾ Tự động hoá Công nghệ Grid đang được áp dụng vào trong SOA để triển khai kiến trúc dịch vụ nhằm cung cấp một cách tiếp cận mới mẻ tăng tính tự động hoá. " Trong môi trường mở và phân tán như SOA, việc thiết lập một môi trường thật sự an toàn trong quá trình tương tác giữa các dịch vụ thật sự là một khó khăn. Vấn đề liên quan đến bảo mật an toàn hệ thống này sẽ được trình bày trong chương 4.
  73. Trang 52 Chương 4 SOA VÀ VẤN ĐỀ BẢO MẬT " Chương này trình bày về các khó khăn gặp phải trong việc bảo vệ hệ thống SOA. Từ đó xem xét, phân tích một giải pháp đó là “kiến trúc bảo mật hướng dịch vụ”. Chương này cũng giới thiệu một số chuẩn bảo mật trong XML như WS-Security, XML-Signature, XML-Encryption, XML Key Management Specification, SAML và bộ thư viện WSE (Web Services Enhancements) hỗ trợ lập trình bảo mật web services. 4.1 Các thách thức về bảo mật trong hệ thống SOA 4.1.1 Đặt vấn đề Với việc phát triển không ngừng của công nghệ web service đã tạo nên những ảnh hưởng nhất định trong việc xây dựng các mô hình tính toán phân tán. Các kiến trúc phân tán hướng đối tượng DOA (Distributed Object Architecture) sử dụng các công nghệ như là CORBA, DCOM, DCE, và Java RMI đang nhanh chóng chuyển sang các kiến trúc hướng dịch vụ (SOA) với những công nghệ mới như SOAP, HTTP và XML. Việc thay đổi kiến trúc hệ thống như thế đã dẫn đến những thay đổi nhất định trong việc đưa ra những giải pháp cho vấn đề bảo mật của hệ thống. Hầu hết các giải pháp bảo mật đang được sử dụng ngày nay đều dựa trên thực trạng là cả hệ thống máy khách và máy chủ đều đặt tại cùng một mạng vật lý (ví dụ như là LAN) hay mạng logic (như VPN). Những giải pháp này đảm bảo an toàn cho hệ thống, thắt chặt vấn đề an ninh thông qua việc giám sát, điều khiển tất cả mọi ngõ vào và ngõ ra của mạng. Thế nhưng, một hệ thống SOA với các đặc tính mở của nó, đã thật sự làm cho các giải pháp này không còn thích hợp nữa.