Tài liệu Ứng dụng kiến thức hướng dịch vụ trong bài toán thanh toán tập trung

  • Số trang: 100 |
  • Loại file: PDF |
  • Lượt xem: 28 |
  • Lượt tải: 0
nhattuvisu

Đã đăng 26972 tài liệu

Mô tả:

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN ĐỨC NGỌC ỨNG DỤNG KIẾN TRÚC HƢỚNG DỊCH VỤ TRONG BÀI TOÁN THANH TOÁN TẬP TRUNG LUẬN VĂN THẠC SĨ Hà Nội - 2010 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN ĐỨC NGỌC ỨNG DỤNG KIẾN TRÚC HƢỚNG DỊCH VỤ TRONG BÀI TOÁN THANH TOÁN TẬP TRUNG Ngành : Công nghệ Thông tin Chuyên ngành : Hệ thống thông tin Mã số : 604805 LUẬN VĂN THẠC SĨ NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. NGUYỄN NGỌC HÓA Hà Nội - 2010 MỤC LỤC LỜI CAM ĐOAN LỜI CẢM ƠN MỤC LỤC DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ DANH MỤC BẢNG BIỂU DANH MỤC HÌNH VẼ MỞ ĐẦU .................................................................................................................... 1 Chƣơng 1 - TỔNG QUAN VỀ KIẾN TRÚC HƢỚNG DỊCH VỤ.............................. 5 1.1 Mở đầu ........................................................................................................ 5 1.2 Kiến trúc hướng dịch vụ ............................................................................... 7 1.2.1 Khái niệm về SOA ........................................................................... 7 1.2.2 Kiến trúc SOA ................................................................................. 9 1.2.2.1 Tầng tầng thao tác hệ thống ................................................. 9 1.2.2.2 Tầng thành phần tác nghiệp ................................................ 10 1.2.2.3 Tầng dịch vụ ....................................................................... 10 1.2.2.4 Tầng xử lý nghiệp vụ .......................................................... 10 1.2.2.5 Tầng biểu diễn .................................................................... 10 1.2.2.6 Tầng tích hợp...................................................................... 11 1.2.2.7 Tầng QoS(Tầng chất lượng dịch vụ) ................................... 11 1.3 Các tính chất của một hệ thống SOA ......................................................... 11 1.4 Kết luận ..................................................................................................... 12 Chƣơng 2 - CÁC BƢỚC TRIỂN KHAI MỘT ỨNG DỤNG THEO MÔ HÌNH SOA .......................................................................................................................... 13 2.1 Các phương pháp tiếp cận trong triển khai SOA ........................................ 13 2.2 Quy trình phát triển ứng dụng theo mô hình SOA ...................................... 14 2.2.1 Phân rã domain.................................................................................. 14 2.2.2 Xây dựng Goal-service .................................................................... 16 2.2.3 Phân tích hệ thống con .................................................................... 17 2.2.4 Đưa ra các dịch vụ ........................................................................... 17 2.2.5 Đặc tả thành phần ............................................................................ 17 2.2.6 Cấu trúc thành phần và dịch vụ........................................................ 18 2.2.7 Lựa chọn giải pháp thực thi ............................................................. 18 2.3 SOA và Web Service ............................................................................... 18 2.3.1 Kiến trúc Web services .................................................................... 18 2.3.2 Simple Object Access Protocol – SOAP .......................................... 20 2.3.3 Web Service Description Language (WSDL) .................................. 21 2.3.4 UDDI .............................................................................................. 22 2.4 Kết luận....................................................................................................... 22 Chƣơng 3 - ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG THANH TOÁN HÓA ĐƠN CỦA BIDV ............................................................................................ 23 3.1 Phát biểu bài toán ....................................................................................... 23 3.2 Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV ........ 23 3.3 Quy trình hoạt động.................................................................................... 25 3.4 Cơ sở dữ liệu ............................................................................................. 30 3.5 Thiết kế Web service dùng trong hệ thống ................................................. 30 3.6 Kết luận ..................................................................................................... 32 Chƣơng 4 - THỰC NGHIỆM VÀ ĐÁNH GIÁ ...................................................... 33 4.1 Môi trường tích hợp ................................................................................... 33 4.2 Tích hợp thử nghiệm.................................................................................. 34 4.3 Kết quả thực nghiệm .................................................................................. 39 Chƣơng 5 - KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN ........................................... 59 TÀI LIỆU THAM KHẢO ....................................................................................... 60 PHỤ LỤC - CÁC USE CASE CỦA HỆ THỐNG THANH TOÁN HÓA ĐƠN .... 61 DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ BIDV Bank for Investment and Ngân hàng Đầu tư và Phát triển Development of Vietnam Việt Nam Corebanking Corebanking Hệ thống ngân hàng cốt lõi Service Consumer 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. 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 provider Service provider Service Registry Service Registry Service registry là 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 Service contract SIBS SIBS 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 và yêu cầu và đáp trả của dịch vụ Hệ thống ngân hàng tích hợp Siverlake SOA Service Oriented Architect Kiến trúc hướng dịch vụ DANH MỤC BẢNG BIỂU Bảng 1- Các yêu cầu triển khai thử nghiệm ................................................................ 35 Bảng 2- Bảng kịch bản test dịch vụ vnmart ................................................................ 47 Bảng 3 - Kết quả triển khai thực tế............................................................................. 55 Bảng 4 - Các dịch vụ và kênh thanh toán dự kiến triển khai trong tương lai ............... 56 Bảng 5 - Danh sách các use case hệ thống ................................................................. 62 DANH MỤC HÌNH VẼ Hình 1- Các kênh giao dịch của ngân hàng khi cùng thực hiện thao tác chuyển khoản . 6 Hình 2 - Kiến trúc EJB ................................................................................................ 6 Hình 3 - Mô hình CORBA ........................................................................................... 7 Hình 4 - Mô hình DCOM............................................................................................. 7 Hình 5 - Các đối tượng trong SOA............................................................................... 8 Hình 6 - Kiến trúc phân tầng của hệ thống SOA .......................................................... 9 Hình 7 - Một khung nhìn chi tiết về một dịch vụ ........................................................ 10 Hình 8 - Các dịch vụ khác nhau được cung cấp trên một website ............................... 11 Hình 9 - Các bước cần thực hiện khi triển khai một hệ thống SOA. ........................... 13 Hình 10 - Phân rã domain hệ thống thanh toán hóa đơn ............................................ 14 Hình 11 – Danh sách use case khi triển khai theo mô hình SOA ................................ 15 Hình 12 – Các domain và use case sử dụng................................................................ 16 Hình 13 – Đưa các dịch vụ vào các thành phần .......................................................... 17 Hình 14 - Các tầng của Web service .......................................................................... 19 Hình 15 - Tương tác giửa các tác nhân trong Web service ......................................... 19 Hình 16 - Truyền thông điệp sử dụng SOAP .............................................................. 20 Hình 17 - Cấu trúc SOAP message ............................................................................ 20 Hình 18 – WSDL ....................................................................................................... 21 Hình 19 - Mô hình tổng quát hệ thống thanh toán hoá đơn của BIDV ........................ 24 Hình 20- Web service dùng trong hệ thống thanh toán hoá đơn ................................. 32 Hình 21 - Môi trường RAD cuả IBM ......................................................................... 33 Hình 22 - Môi trường Message Queue của IBM......................................................... 34 Hình 23 - Sơ đồ bảo mật của hệ thống thanh toán hoá đơn BIDV .............................. 35 Hình 24 - Sơ đồ backup Database .............................................................................. 36 Hình 25 - Màn hình đăng nhập hệ thống .................................................................... 48 Hình 26 - Màn hình quản lý người sử dụng ................................................................ 48 Hình 27 - Màn hình quản lý chi nhánh ....................................................................... 49 Hình 28 - Màn hình quản lý nhà cung cấp .................................................................. 49 Hình 29 - Màn hình quản lý dịch vụ........................................................................... 50 Hình 30 - Màn hình đăng ký khách hàng.................................................................... 50 Hình 31 - Màn hình vấn tin hóa đơn .......................................................................... 51 Hình 32 - Màn hình thanh toán hóa đơn ..................................................................... 52 Hình 33 - Các màn hình giao dịch tại ATM ............................................................... 54 Hình 34- Màn hình Gateway xử lý từ các kênh thanh toán ......................................... 54 Hình 35 - Use case quản lý chi nhánh ........................................................................ 62 Hình 36 - Use case quản lý người sử dụng ................................................................. 66 Hình 37 - Use case quản lý nhà cung cấp .................................................................. 71 Hình 38 - Use case quản lý dịch vụ ............................................................................ 77 Hình 39 - Use case quản lý khách hàng ...................................................................... 81 Hình 40 - Use case xử lý thanh toán hoá đơn ............................................................. 86 Hình 41 - Use case đăng nhập .................................................................................... 92 1 MỞ ĐẦU Trong thời kỳ phát triển và hội nhập kinh tế thế giới của Việt Nam những năm gần đây các doanh nghiệp Việt Nam gặp rất nhiều khó khăn khi phải cạnh tranh với các doanh nghiệp nước ngoài không những mạnh về quản trị nhân lực, mạnh về vốn và cả công nghệ… Việc áp dụng khoa học công nghệ vào lĩnh vực kinh tế, trong đó có ngành Ngân hàng, một trong những ngành kinh tế đặc biệt tác động trực tiếp đến hệ thống tài chính của quốc gia, trở nên cấp thiết hơn bao giờ hết. Trong quá trình điều hành và vận hành hệ thống Ngân hàng, điều mà các lãnh đạo quan tâm nhất là làm sao nắm bắt được tình hình hoạt động của hệ thống mình một cách nhanh nhất, chính xác và kịp thời nhất, để đưa ra các quyết định đúng đắn, giảm tối thiểu rủi ro, đảm bảo lợi ích của Ngân hàng mình. Hơn nữa, các ngân hàng thương mại còn phải hướng đến việc nâng cao chất lượng dịch vụ để phục vụ khách hàng. Với việc Việt Nam chính thứ gia nhập tổ chức thương mại thế giới WTO thì các ngân hàng đang phải đối mặt với sự cạnh tranh của các ngân hàng ngoại vốn mạnh về tài chính và công nghệ và còn phải cạnh tranh khốc liệt với khối ngân hàng nội đang từng bước lớn mạnh. Để cạnh tranh được thì vấn đề cốt lõi của các ngân hàng là phải hiện đại hóa về hệ thống CNTT mà nền tảng là đa dạng hóa dịch vụ. Một trong những dịch vụ quan trong cần phải đặc biệt chú trong dó chính là dịch vụ thanh toán tập trung tại ngân hàng. Bài toán thực tế Trước khi đi vào mục tiêu chính của luận văn, chúng ta sẽ phân tích bài toán thực tế tại ngân hàng Đầu tư và phát triển Việt Nam BIDV như sau: (i) Tập đoàn điện lực Việt Nam EVN từ trước đến nay đều thu tiền điện qua mạng lưới cộng tác viên đến thu tiền trực tiếp tại nhà dân hay tại các điểm thu tiền của EVN. Điều này dẫn tới mạng lưới đội ngũ cộng tác viên này rất lớn phức tạp trong quản lý. Hơn nữa số tiền mà các cộng tác viên này thu được phải mất vài ngày đến hàng tuần mới đến nộp được cho sở điện lực. Nếu số tiền này mà được gửi ngay tại ngân hàng thì EVN vừa dễ quản lý và theo dõi lại được phát sinh một số tiền lãi rất lớn. Ngoài ra cũng tránh được nhiều nguy cơ rủi ro như tiền giả, cộng tác viên dùng sai mục đích… Các yêu cầu về thanh toán cước viễn thông trả sau với Tổng công ty viễn thông quân đội Viettel, với tập đoàn bưu chính viễn thông Việt Nam VNPT, với công ty viễn thông điện lực EVN Telecom, thu hộ tiền nước… (ii) Dịch vụ nạp tiền cho thuê bao trả trước với nhà cung cấp dịch vụ VNPAY : Thay vì phải đến các điểm bán thẻ trả trước để cào lấy mã số thẻ rồi nạp tiền thì khách 2 hàng có thêm một kênh là nạp tiền cho điện thoại di động qua tin nhắn hay mua thẻ tại ATM thông qua mở tài khoản tại ngân hàng. (iii) Dịch vụ nạp tiền ví điện tử vnmart: Đây là dịch vụ phối hợp với với công ty VNPAY. Dịch vụ thanh toán trực tuyến mới phát triển trong vài năm gần đây tại Việt Nam. Đây là dịch vụ giúp chủ thẻ tại BIDV có thể nạp rút tiền vào tài khoản ảo qua đó dùng ví điện tử này kết hợp với các website bán hàng trực tuyến để thanh toán trực tuyến. Khi dùng dịch vụ ví điện tử này sẽ đảm bảo an toàn hơn khi thanh toán trực tuyến thay vì thanh toán trực tuyến bằng tài khoản ngân hàng. Sự phát triển của dịch vụ gắn liền với sự quảng bá dịch vụ với các website bán hàng trực tuyến. (iv) Dịch vụ nạp tiền tài khoản Vietpay: Đây là dịch vụ phối hợp với với công ty VietPay dùng để nạp tiền game cho các ại lý. (v) Dịch vụ thanh toán vé máy bay Jetstart: Đây là dịch vụ phối hợp với với công ty Onepay triển khai qua hai kênh ATM và quầy giao dịch : Khách hàng sau khi vào website của jetstart pacific để đặt chỗ rồi sẽ qua ATM hay quầy giao dịch của BIDV để thanh toán bằng cách nhập vào mã đặt chỗ. Đây là dịch vụ sẽ rất hữu ích tại những nơi không có đại lý bán vé máy bay của Jetstart đặc biệt tại các tỉnh và các huyện xa. (vi) Dịch vụ mua bảo hiểm xe máy, ô tô qua ATM với công ty bảo hiểm BIDV (BIDV Insurance Company BIC) : Thay vì ra các đại lý bảo hiểm thì khách hàng là chủ thẻ của BIDV có thể ra ATM để đặt mua bảo hiểm ô tô, xe máy. Phương thức này giúp khách hàng có thể tiết kiệm được thời gian đồng thời có tỉ lệ chiết khấu cao hơn khi ra đại lý mua vì công ty bảo hiểm sẽ không phải trích trả cho đại lý. Đây cũng là hình thức quảng bá sự đa dạng dịch vụ cho BIDV. Dịch vụ này mới triển khai. (vii) Dịch vụ thanh toán phí bảo hiểm qua ATM với công ty bảo hiểm Prudential: Phí đóng bảo hiểm hàng tháng sẽ được công ty gửi cho khách hàng qua bưu điện, email, điện thoại…Khách hàng chỉ cần ra ATM nhập mã hợp đồng và số tiền phải đóng vào là có thể thanh toán được phí bảo hiểm với Prudential. Đây cũng là một dịch vụ rất mới giúp cho công ty bảo hiểm giảm bớt số lượng cộng tác viên đồng thời giúp quản lý dòng tiền thu được từ khách hàng một cách nhanh chóng chính xác tránh nhiều rủi ro khi cần đội ngũ cộng tác viên đi thu như mất tiền, tiền không hợp lệ… Nắm bắt được các yêu cầu của các doanh nghiệp trong nghiệp vụ thanh toán hóa đơn cũng như phát triển thêm thanh toán không dùng tiền mặt đồng thời đẩy mạnh phát triển dịch vụ tại BIDV. BIDV đã tiến hành khảo sát và ký kết với các đơn vị trên để phát triển một cổng thanh toán đáp ứng được các nghiệp vụ thanh toán hóa đơn. Vấn đề là cổng thanh toán đó phải tích hợp được nhiều kênh thanh toán như ATM, quầy, SMS… đồng thời phải mở rộng được các nhà cung cấp dịch vụ mới. 3 Kiến trúc hướng dịch vụ SOA (Service Oriented Architecture) ra đời như là giải pháp tối ưu để tích hợp các dịch vụ giữa BIDV và các nhà cung cấp để giải quyết bài toán thanh toán trên. SOA là một trong những hướng thời sự hiện nay của ngành công nghệ thông tin. Nó cho phép cung cấp những dịch vụ có tính đầy đủ nhất đối với nhu cầu của người sử dụng. Vấn đề tích hợp được đặt ra để cho phép các ứng dụng, cơ sở dữ liệu riêng lẻ có thể tích hợp với nhau trong các quy trình nghiệp vụ và không chỉ giới hạn trong nội bộ doanh nghiệp mà còn có khả năng tích hợp với các quy trình của khách hàng và đối tác bên ngoài. Tuy nhiên, trong đa số trường hợp, việc tích hợp chỉ mới dừng lại ở mức tích hợp doanh nghiệp và trong một số ít trường hợp ở mức tích hợp logic nghiệp vụ, sử dụng các phương cách tích hợp truyền thống như tích hợp điểm-nối-điểm (hai ứng dụng cần trao đổi thông tin sẽ kết nối trực tiếp với nhau), tích hợp tĩnh (ví dụ như viết các mã tích hợp đan xen với mã ứng dụng nên khó thay đổi trong tương lai). Theo thời gian, phương cách tích hợp truyền thống sẽ tạo ra một hệ thống kết nối chồng chéo, phụ thuộc lẫn nhau một cách chặt chẽ, rất khó chỉnh sửa khi yêu cầu nghiệp vụ thay đổi, dẫn đến chi phí tích hợp ngày càng gia tăng đáng kể. Một số tổ chức, doanh nghiệp Việt Nam đang bước đầu tiếp cận kiến trúc tích hợp linh hoạt của SOA và thường bắt đầu theo hai hướng: tích hợp con người nhằm nâng cao năng suất làm việc và mở rộng thêm các kênh truy cập vào hệ thống ứng dụng bằng cách xây dựng cổng làm việc điện tử, cổng giao dịch điện tử... Ngoài hai hướng này, các hướng tiếp cận khác của SOA bao gồm tích hợp và tự động hóa quy trình nghiệp vụ, tích hợp thông tin và xây dựng kho tài nguyên dịch vụ có khả năng sử dụng lại trong các ứng dụng mới. SOA là một mô hình kiến trúc tích hợp hiện đại dựa trên khái niệm dịch vụ. Các chức năng nghiệp vụ và cơ sở hạ tầng được cung cấp như là các dịch vụ, các dịch vụ này riêng lẻ hoặc kết hợp với nhau sẽ cung cấp các chức năng ứng dụng cho các ứng dụng đầu cuối hoặc cho các dịch vụ khác. Các dịch vụ được kết nối với nhau thông qua trục tích hợp doanh nghiệp, xây dựng theo kiến trúc bus thay cho kiến trúc điểm-nối-điểm. Nhờ kiến trúc tích hợp linh hoạt của SOA, doanh nghiệp có thể xây dựng các hệ thống linh hoạt cho phép thay đổi các quy trình nghiệp vụ nhanh chóng và có thể tái sử dụng các cấu thành hệ thống. Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức năng (mô-đun phần mềm) thực hiện qui trình nghiệp vụ nào đó. Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối 'mềm dẻo' với nhau (nghĩa là một ứng dụng có thể 'nói chuyện' với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới. 4 Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất kể công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ. Ưu điểm quan trọng nhất của SOA là khả năng kết nối "mềm dẻo" (nhờ sự chuẩn hóa giao tiếp) và tái sử dụng. Các dịch vụ được đóng gói có thể được gọi bởi ngôn ngữ bất kỳ. Với ngữ cảnh đó, luận văn hướng đến mục tiêu tập trung nghiên cứu, tìm hiểu sâu về mô hình kiến trúc hướng dịch vụ, từ đó ứng dụng trong bài toán thanh toán tập trung tại ngân hàng BIDV. Nội dung chính của luận văn được tổng hợp, trình bày trong 5 chương chính sau: - Chương 1: Giới thiệu khái niệm về kiến trúc hướng dịch vụ SOA, các tính chất của hệ thống SOA. 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 2: Chương thứ hai của luận văn đề cập đến xây dựng một bài toán dựa theo mô hình SOA, giới thiệu về Web Service… - Chương 3: Chương này đưa ra ứng dụng SOA trong bài toán thanh toán hoá đơn của BIDV bao gồm phát biểu bài toán, mô hình tích hợp đề xuất và nêu quy trình hoạt động của bài toán, thiết kế chi tiết bài toán. - Chương 4: Giới thiệu môi trường phát triển và triển khai hệ thống thanh toán hoá đơn, chính sách bảo mật của hệ thống, kết quả thực nghiệm sau khi triển khai. - Chương 5: Kết luận và hướng phát triển của đề tài. 5 Chƣơng 1 - TỔNG QUAN VỀ KIẾN TRÚC HƢỚNG DỊCH VỤ 1.1 Mở đầu Trong những năm qua có rất nhiều kiến trúc phần mềm đã và đang được xây dựng và triển khai nhằm giải quyết các vấn đề như giảm chi phí phát triển phần mềm, giảm chi phí bảo trì vận hành phần mềm... Rất nhiều hãng phần mềm khác nhau trên thế giới đã nghiên cứu, tìm tòi nhiều công nghệ mới, nhiều kiến trúc phần mềm khác nhau nhưng lại dựa trên các chuẩn khác nhau dẫn đến môi trường không đồng nhất. Nhiều hệ thống cũ thay vì được sử dụng lại thì lại được xây dựng lại từ đầu dẫn đến quá tốn kém về thời gian và tiền bạc. Hơn nữa giữa các hệ thống khác nhau, các môi trường khác nhau sẽ không thể giao tiếp được với nhau một khi chưa thống nhất được chuẩn để giao tiếp với nhau. Đó là khó khăn rất lớn trong quá trình tích hợp các hệ thống với nhau. Một nguyên nhân cũng gây rất nhiều khó khăn cho các đơn vị tích hợp hệ thống là vấn đề lập trình dư thừa và không tái sử dụng được. Ví dụ như Ngân hàng A phát triển một dịch vụ như chuyển khoản qua các kênh ATM, quầy giao dịch và internet của Ngân hàng A. Các dịch vụ này đều có mục đích là truy nhập vào CoreBanking để thực hiện giao dịch cộng tiền vào tài khoản đích và trừ tiền vào tài khoản nguồn. Nếu không được tái sử dụng thì ở mỗi kênh trên ta đều gặp phải bài toán là viết một đoạn chương trình thực hiện ghi có tài khoản đích và ghi nợ tài khoản nguồn. Hơn nữa với tưng kênh giao dịch lại sử dụng môt ngôn ngữ lập trình khác nhau dẫn tới tốn rất nhiều thời gian và công sức thể thực hiện bài toán cho các kênh đó. ATM «uses» Chuyển khoản Internet «uses» Chuyển khoản Quầy GD «uses» Chuyển khoản 6 Hình 11- Các kênh giao dịch của ngân hàng khi cùng thực hiện thao tác chuyển khoản Cứ khi triển khai thêm một kênh mới như SMS, Mobile… thì công việc chuyển khoản lại phải xây dựng gây sự nhàm chán, tốn chi phí thời gian và tiền bạc với người lập trinh viên. Như Hình 1 thì lập trình viên phải viết lại đoạn chương trình thực hiện chuyển khoản trên các ngôn ngữ khác nhau. Về mô hình kiến trúc phần mềm truyền thống, đã có rất nhiều cách tiếp cận khác nhau đối với việc xây dựng, phát triển các ứng dụng phân tán chẳng hạn:  EJB (Enterprise Java Beans) Hình 2 2- Kiến trúc EJB  Common Object Request Broker Architecture (CORBA ) : 7 Hình 3 3- Mô hình CORBA  DCOM – Distributed Component Object Model: Hình 44 - Mô hình DCOM Các kiến trúc trên đều yêu cầu 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. Mỗi khi có một sự thay đổi thì thì yêu cầu đều phải thay đổi cả bên cung cấp dịch vụ và bên triệu gọi sử dụng dịch vụ. Các kiến trúc trên đa phần là chuẩn đóng rất khó để giao tiếp với các chuẩn khác… Chính vì những nhược điểm của các mô hình đã có yêu cầu tìm ra một kiến trúc mới có thể tương thích được các chuẩn, các môi trường và sử dụng lại được các hệ thống cũ. Kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA) ra đời giúp giải quyết các nhược điểm của các mô hình phân tán đã có. 1.2 1.2.1 Kiến trúc hƣớng dịch vụ Khái niệm về SOA Trước khi ta hiểu khái niệm kiến trúc hướng dịch ta ta tìm hiểu khái niệm về dịch vụ là gì? Dịch vụ là là các thành phần logic dùng để thực hiện một thao tác nghiệp vụ được truy nhập qua internet sử dụng các chuẩn mở. Kiến trúc hướng dịch vụ 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ụ. Dịch vụ là yếu tố then chốt trong SOA. SOA là tập hợp các dịch vụ kết nối „mềm dẻo‟ với nhau (nghĩa là một ứng dụng có thể „nói chuyện‟ với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới. Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử 8 dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ. SOA Trong SOA[5]-[8]-[11] có ba đối tượng chính là nhà cung cấp dịch vụ (service provider), người sử dụng dịch vụ (service consumer) và nơi lưa trữ dịch vụ (service registry) như minh họa trong Hình 5 Nơi đăng ký dịch vụ (Service Registry) Tìm dịch vụ() Người sử dụng dịch vụ (Service Consumer) Xuất bản dịch vụ () Gọi dịch vụ() Nhà cung cấp dịch vụ (Service Provider) Hình 55 - Các đối tƣợng trong SOA Nhà cung cấp dịch vụ (service provider) : Cung cấp thông tin về dịch vụ cho một nơi lưu trữ thông tin dịch vụ (service registry). Người sử dụng dịch vụ (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. Nơi lưu trữ thông tin dịch vụ (service registry) : Là nơi lưu trữ các dịch vụ khi một dịch vụ của nhà cung cấp dịch vụ được đưa ra. Đây chính là nơi người sử dụng dịch vụ có thể tìm và triệu gọi các dịch vụ được 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ó. Tư tưởng của SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc tương tự. Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví dụ như các ứng dụng phân tán muốn làm việc với nhau phải đạt được thỏa thuận về chi tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay đổi tương ứng đối với mã lệnh truy cập thành phần COM này. 9 Ưu điểm quan trọng nhất của SOA là khả năng kết nối mềm và tái sử dụng. Các dịch vụ có thể được sử dụng với trình client chạy trên nền tảng bất kỳ và được viết với ngôn ngữ bất kỳ. Ví dụ như ứng dụng Java có thể liên kết với dịch vụ web .NET và ngược lại. SOA dựa trên 2 nguyên tắc thiết kế quan trọng:  Mô-đun hoá: Tách vấn đề lớn thành nhiều vấn đề nhỏ.  Đóng gói: Che đi dữ liệu và lô-gic trong từng mô-dun đối với truy cập từ ngoài. Sau đây sẽ trình bày về kiến trúc phân tầng của SOA. 1.2.2 Kiến trúc SOA Sau đây là kiến trúc phân tầng của SOA[7] -[8] gồm 7 tầng chính là : Tầng Operational Systems (tầng tích hợp các hệ thống cũ đang hoạt động), tầng Enterprise components ( tầng thành phần tác nghiệp), tầng dịch vụ, tầng xử lý nghiệp vụ, tầng biểu diễn, tầng tích hợp và tầng theo dõi, quản lý chất lượng dịchvụ. Hình 6 - Kiến trúc phân tầng của hệ thống SOA 1.2.2.1 Tầng tầng thao tác hệ thống Mục đích tầng này là gọi đến các ứng dụng cũ đã xây dựng trước đó như các ứng dụng xây dựng bằng các ngôn ngữ lập trình hướng đối tượng cũ, các ứng dụng thực hiện các thao tác nghiệp vụ thông minh, các gói ứng dụng CRM, ERP.. Để tích hợp các hệ thống đã tồn tại này thì dùng kỹ thuật tích hợp hướng dịch vụ. 10 1.2.2.2 Tầng thành phần tác nghiệp Tầng này có nhiệm vụ thực hiện các chức năng và vận hành các dịch vụ đưa ra. Tầng này quản lý các tài nguyên mức đơn vị nghiệp vụ. 1.2.2.3 Tầng dịch vụ Tầng dịch vụ đưa ra các đặc tả dịch vụ, đặc tả các đơn vị thành phần nghiệp vụ. 1.2.2.4 Tầng xử lý nghiệp vụ Các dịch vụ được đưa vào thành 1 luồng để xử lý như một ứng dụng đơn lẻ. Tầng này hỗ trợ đặc tả các use case và thực hiện các quy trình nghiệp vụ. 1.2.2.5 Tầng biểu diễn Hình 7 - Một khung nhìn chi tiết về một dịch vụ 11 Hình 8 - Các dịch vụ khác nhau đƣợc cung cấp trên một website Tầng biểu diễn cung cấp các ứng dụng cho người dùng cuối dưới dạng các dịch vụ được xây dựng từ các tầng trên. Người dùng cuối sẽ không quan tâm đến xử lý trong bản thân các dịch vụ mà chỉ quan tâm đến đầu vào và đầu ra của dịch vụ. 1.2.2.6 Tầng tích hợp Tầng này cho phép tích hợp các dịch vụ trước đó như đưa ra tập các khả năng tin cậy như định tuyến thông minh, các giao thức điều chỉnh hoặc các cơ chế chuyển đổi khác thường được miêu tả là ESB. 1.2.2.7 Tầng QoS(Tầng chất lƣợng dịch vụ) Tầng này cung cấp các khả năng để quản lý, theo dõi,vận hành chất lượng các dịch vụ như an ninh, hiệu năng xử dụng của hệ thống và độ sẵn sàng của hệ thống. Đây là bước xử lý phía sau và cần cài đặt các công cụ để theo dõi vận hành ứng dụng SOA. 1.3 Các tính chất của một hệ thống SOA SOA gồm các tính chất cơ bản sau [8]-[9]  Sử dụng lại dịch vụ Trong SOA tính chất sử dụng lại dịch vụ cho phép các một dịch vụ mới có thể tái sử dụng các dịch vụ đã. 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 dư thừa giúp giảm thời gian và chi phí cho việc phát triển và quản trị phần mềm.  Tính đóng gói dịch vụ
- Xem thêm -