Hình 2.12 : Biểu đồ tuần tự
Để làm đƣợc điều này, bên cung cấp dịch vụ (Service Provider) và bên phân phối dịch vụ (Service Broker) phải đăng ký trƣớc với Service Registry. Khi đăng ký xong, các bên sẽ đăng tải thông tin về các dịch vụ của họ trong Service Registry.
Trong hình 2.12, Service Requester sẽ tìm kiếm trong Service Registry các thông tin về các dịch vụ của các Service Broker và Service Provider khác nhau. Để tìm kiếm thông tin, bên Service Requester sẽ khởi tạo các lời gọi API nhƣ các lời gọi UDDI API find_business và find_service. Đây là tiến trình tìm kiếm dịch vụ.
Khi Service Requester xác định đƣợc Service Broker hoặc Service Provider cần thiết, Service Registry client sẽ đƣa ra một truy vấn API tới Service Registry. Nếu đó là một UDDI Service Registry, UDDI API tƣơng ứng là get_businessDetail hoặc get_serviceDetail. Service Registry sẽ trả về thông tin về bên cung cấp (nhƣ tên, địa chỉ, ngƣời liên lạc,…) hoặc thông tin chi tiết về dịch vụ.
Nếu Service Requester muốn sử dụng dịch vụ ngay lập tức, Service Registry client có thể đƣa ra một lời gọi dịch vụ find_binding tới URI(Universal Resource Identifier, hoặc URL mô tả dịch vụ của Service Provider) của tổ chức hay dịch vụ dó. Khi nhận đƣợc URI, Service Requester có thể khởi tạo một lời gọi SOAP, dựa trên loại cổng giao tiếp, tên giao tiếp và URI của dịch vụ. URL dịch vụ cuối chỉ các dịch vụ đƣợc cung cấp bởi các URL (ví dụ http://mydemo.nextfrontiers.com:8080/soap/rpc) và đƣợc lƣu trong Service Provider hay Service Broker.
Khi Service Provider muốn đăng tải một dịch vụ mới trên Service Registry, hoặc cập nhật về dịch vụ sẵn có, nó cần phải sử dụng các API để đăng ký các thông tin về tổ chức, chi tiết về dịch vụ và các liên kết đến dịch vụ cuối (end–point URL). Với
UDDI Service Registry có thể sử dụng một số API nhƣ save_business, save_service và save_binding. Tƣơng tự nếu Service Provider và Service Broker khong muốn đăng tải dịch vụ trong Service Registry, có thể dụng tập các API tƣơng tự.
CHƯƠNG 3. ỨNG DỤNG WEB SERVICE ĐỂ XÂY DỰNG KIẾN TRÚC HƯỚNG DỊCH VỤ
3.1. Tổng quan về kiến trúc hướng dịch vụ
3.1.1. SOA là gì?
SOA (viết tắt của từ Service Oriented Architecture – Kiến trúc hƣớng dịch vụ) là một kiểu kiến trúc mà khuyến khích việc tạo các dịch vụ nghiệp vụ nối kết lỏng lẻo [1].Các dịch vụ lỏng lẻo có thể tƣơng tác, không phụ thuộc vào kĩ thuật và có thể thay đổi nghiệp vụ.Một giải pháp SOA bao gồm một tập các dịch vụ nghiệp vụ thực hiện một quy trình nghiệp vụ. Mỗi dịch vụ cung cấp một miêu tả dịch vụ để hỗ trợ cho những tiến trình có thể cấu hình lại một cách uyển chuyển và tự động.SOA là một kiểu kiến trúc có khả năng mở rộng, mở, bao gồm các dịch vụ có khả năng tƣơng tác, khả năng khám phá, tự trị, có thể phục vụ cho nhiều khách hàng khác nhau, có khả năng sử dụng lại. [5]
Nhƣ vậy, trong khái niệm kiến trúc hƣớng dịch vụ, ―dịch vụ‖ là yếu tố then chốt. Vậy ta có thể hiểu khái niệm ―dịch vụ‖ ở đây là gì?
Khái niệm ―dịch vụ‖ (DV) [6]:Chúng ta luôn phải trả tiền cho ―DV‖, chẳng hạn DV hay ―phí phục vụ‖ tại khách sạn, nhà hàng, trên xe taxi... Cụ thể hơn, đến một tiệm ăn, chúng ta ―gửi thông tin‖ cho ngƣời phục vụ (gọi thức ăn, đồ uống) và rồi thƣởng thức món ăn. Chúng ta không thấy ngƣời đầu bếp chế biến món ăn đó ra sao, cũng không tham gia vào quá trình nấu, nhƣng đó chính là ―dịch vụ‖ mà chúng ta phải trả tiền.Với ví dụ trên, tiệm ăn rõ ràng đã cung cấp ―DV nấu ăn‖ bao gồm những hoạt động nhƣ chuẩn bị nguyên liệu (nhặt rau, làm cá), nấu nƣớng và trình bày món ăn.... Trong quá trình hoạt động của doanh nghiệp (DN), ta thấy các DV thƣờng là những công việc ―lặp đi lặp lại‖, với ―các bƣớc thực hiện rõ ràng‖, chính vì vậy cácDV thƣờng đƣợc ―tái sử dụng‖ (reuse) nhiều lần. Quá trình hoạt động của ngân hàng có thể tiêu biểu cho việc sử dụng một DV nhiều lần (nói cách khác là tái sử dụng) trong nhiều quy trình. Chẳng hạn, DV tạo tài khoản (account opening) hay kiểm tra khả năng thanh toán của ngƣời vay nợ (credit checking) thƣờng nằm trong nhiều quy trình cho vay tiền của ngân hàng.
Nhƣ vậy, ta có thể hiểu 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ử 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ụ [12].
3.1.2. Các lợi ích của SOA:
Tái sử dụng phần mềm:Giả sử ta đóng gói các gói mã thực hiện một chức
năng nào đó thành một dịch vụ có quy mô và kích thƣớc phù hợp để có thể đƣợc tái sử dụng trong những lần sau. Khi một đội phát triển một ứng dụng phần mềm mới cần sử dụng chức năng cụ thể đó, họ sẽ không cần biết về việc mã đƣợc đóng gói nhƣ thế nào hay nó có nguồn gốc từ đâu. Tất cả những thứ mà họ cần làm là xây dựng một kết nối đến gói mã đó. Điều này thực sự có ích đối với các công ty thƣờng xuyên xây dựng những hệ thống mới dựa trên những chức năng tƣơng tự - ví dụ một công ty bảo hiểm với nhiều bộ phận, mỗi một bộ phận đảm nhận cho các sản phẩm khác nhau – việc tái sử dụng này sẽ tiết kiệm đƣợc thời gian dành cho việc phát triển, kiểm thử và bảo trì với mỗi module có sử dụng cùng chức năng này, điều này đồng nghĩa với việc năng suất gia tăng, giảm thiểu chi phí cũng nhƣ thời gian phát triển dự án.
Linh hoạt:Khi có những yêu cầu cải tiến về mặt chức năng lên các dịch vụ
đã xây dựng, đội phát triển chỉ cần thực hiện thay đổi lên từng gói dịch vụ mà không làm ảnh hƣởng đến các ứng dụng phía client sử dụng dịch vụ đó, điều này giúp cho doanh nghiệp nhanh chóng đƣa ra các sản phẩm có chất lƣợng cao, tăng tốc trong việc ra quyết định, phản ứng nhanh với nhu cầu của khách hàng.
3.1.3. Khi nào sử dụng SOA ?
Khi thiết kế hệ thống một câu hỏi lớn đƣợc đặt ra là: việc cân nhắc giữa khả năng sử dụng lại và hiệu quả của hệ thống. Nếu hệ thống cần việc chạy nhanh cho một ứng dụng đặc biệt thì RMI, CORBA, DCOM là sự lựa chọn.Nhƣng hệ thống khó có thể thay đổi hoặc sử dụng lại.Nếu hệ thống dự định thay đổi thƣờng xuyên mà không quan tâm đến tốc độ thì SOA là phƣơng cách tiếp cận tốt nhất.Nó dễ dàng sử dụng lại trong tƣơng lai và cho phép các ứng dụng tƣơng tự đƣợc thiết kế một cách nhanh chóng [4].
3.1.4. Mối quan hệ giữa web service và kiến trúc hƣớng dịch vụ (SOA)
Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. Còn công nghệ web service thì cho phép truy cập thông qua định nghĩa giao thức-và- giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhƣng chúng không phải là một.
Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng nhƣ là mô hình các giao tiếp, hiện thực giao tiếp và phƣơng thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi ―kiến trúc định hƣớng giao tiếp‖ thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ đƣợc truy cập thông qua giao tiếp, thƣờng theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ một chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tƣơng tác định hƣớng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ.
Định nghĩa cơ bản của web service dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration), cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp.
Rõ ràng, theo định nghĩa thì web service là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Web service đƣa ra giải pháp kỹ thuật để thực hiện SOA, nhƣng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải web service (và không phải tất cả web service đều có kiến trúc SOA). Tuy nhiên, với các công nghệ nhƣ DCOM và CORBA đòi hỏi sự 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, thì với web service, việc giao tiếp giữa các đối tƣợng trở nên linh hoạt và rất dễ dàng. Chính vì vậy có thể nói SOA và dịch vụ web có mối quan hệ tƣơng hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công.
Hình 3.1: Mô hình SOA phát triển lên từ mô hình đối tượng
3.2. Bài toán ứng dụng công nghệ Web Service trong xây dựng kiến trúc hướng dịch vụ
Bài toán tích hợp hiện nay là bài toán mà bất kỳ doanh nghiệp nào cũng có thể gặp phải, đặc biệt là trong các tổ chức tài chính và ngân hàng. Cùng với sự gia nhập WTO của Việt Nam, sức ép cạnh tranh giữa các tổ chức tín dụng là rất lớn, đòi hỏi các ngân hàng luôn phải không ngừng có sự cải tiến về công nghệ, tăng cƣờng phát triển các dịch vụ để nâng cao vị thế và sức cạnh tranh của mình trƣớc các đối thủ. Tuy nhiên, để có thể tung ra các dịch vụ một cách nhanh chóng mà vẫn phải đảm bảo chất lƣợng không phải là một vấn đề đơn giản, đòi hỏi hệ thống phải có một kiến trúc mềm dẻo và linh hoạt. Chính vì vậy việc sử dụng kiến trúc hƣớng dịch vụ SOA là một lựa chọn mà các ngân hàng hiện nay đang nhắm tới [7]. Bên cạnh đó, do đặc thù của các hệ thống ngân hàng là các hệ thống chứa những thông tin và dữ liệu nhạy cảm, đòi hỏi sự bảo mật cao, vì thế nó thƣờng là các hệ thống đóng, các cơ chế, các chuẩn giao tiếp cũng nhƣ định dạng dữ liệu thƣờng do hệ thống ngân hàng lõi (core banking) tự định nghĩa. Do vậy, khi các ngân hàng muốn phát triển các sản phẩm dịch vụ có sự tƣơng tác với các hệ thống bên ngoài (ví dụ nhƣ các dịch vụ thanh toán, dịch vụ B2B, dịch vụ ebanking,..) thƣờng gặp phải những khó khăn về vấn đề giao tiếp.Để các hệ thống bên ngoài có thể giao tiếp với hệ thống ngân hàng lõi mà vẫn đảm bảo bí mật thông tin về cơ chế tổ chức dữ liệu, kiến trúc và hoạt động của hệ thống ngân hàng lõi,việc sử dụng công nghệ web service là một lựa chọn phù hợp. Bài toán tập trung vào giải quyết vấn đề tƣơng tác giữa các hệ thống bên ngoài với hệ thống ngân hàng lõi, trong đó xây dựng một web service đóng vai trò là thành phần trung gian, giúp 2 hệ thống sử dụng các định dạng thông điệp khác nhau có thể giao tiếp đƣợc với nhau.
Bài toán xây dựng một web service hỗ trợ việc tích hợp giữa hệ thống core banking của ngân hàng với các hệ thống dịch vụ bên ngoài sử dụng các chuẩn thông điệp (message) khác nhau.Các hệ thống ngoài sử dụng định dạng thông điệp phổ biến nhất hiện nay là định dạng XML để giao tiếp với hệ thống ngân hàng lõi, hệ thống core sử dụng một định dạng thông điệp đặc biệt để giao tiếp giữa các module dịch vụ. Web service này sẽ thực hiện việc tiếp nhận thông điệp yêu cầu từ hệ thống bên ngoài, sau đó thực hiện chuyển đổi (transform) giữa 2 định dạng thông điệp, bổ sung các thông tin cần thiết với thông điệp đó theo đặc tả của hệ thống ngân hàng lõi, và gọi đến các module xử lý tƣơng ứng. Khi nhận kết quả trả về từ các module của hệ thống, web service sẽ thực hiện việc bóc tách đoạn thông điệp để lấy ra dữ liệu trả về, sau đó tiến hành chuyển đổi định dạng để tạo thành thông điệp theo chuẩn của hệ thống dịch vụ và gửi trả kết quả đến hệ thống này.
3.2.2. Đặc tả về các hệ thống giao tiếp
- Hệ thống ngân hàng lõi (Core banking): Các module trong hệ thống ngân hàng lõi sử dụng cơ chế truyền thông điệp (message) để giao tiếp với nhau. Định dạng thông điệp do hệ thống tự định nghĩa. Các thông điệp từ bên ngoài gửi vào hệ thống thông qua giao thức TCP/IP. Sau khi đƣợc gửi vào tầng Socket của hệ thống, các thông tin chứa trong phần header của thông điệp đƣợc bóc tách để trích xuất các thông tin cần thiết và đƣợc gửi đến các module xử lý tƣơng ứng. Sau khi xử lý xong, thông điệp chứa dữ liệu trả về lại đƣợc ghép các thông tin trong header và gửi trả lại tầng socket của hệ thống để trả kết quả ra bên ngoài.
- Các hệ thống dịch vụ: có rất nhiều các hệ thống dịch vụ bên ngoài cần kết nối tới hệ thống ngân hàng lõi, đặc biệt có thể kể đến hệ thống thanh toán (thanh toán vé tàu, thanh toán các loại hóa đơn, thanh toán vé máy bay, các hệ thống thanh toán online trên internet, hệ thống nạp tiền cho di động bằng tải khoản ATM, …), các hệ thống B2B (các công ty chứng khoán, thuế, hải quan,…),tuy nhiên trong bài toán đặt ra ta sẽ không quan tâm đến một hệ thống cụ thể nào mà chỉ quan tâm đến việc giao tiếp của nó tới hệ thống ngân hàng lõi (core banking). Các dịch vụ mà các hệ thống này có thể yêu cầu tới hệ thống ngân hàng lõi bao gồm: dịch vụ vấn tin số dƣ tài khoản, dịch vụ cập nhật số dƣ tài khoản,…
Hình 3.2:Mô hình kết nối giữa 2 hệ thống
Chúng ta hãy tham khảo mô hình kiến trúc SOA cho ngân hàng. Đây là mô hình tham khảo dựa trên nền tảng kiến trúc SOA do công ty IBM đề xuất [3]. Trong mô hình này bao gồm các thành phần tham khảo sau:
Hình 3.3: Mô hình kiến trúc SOA cho ngân hàng của IBM - Cung cấp các dịnh vụ ngân hàng thông qua eBanking - Cung cấp các dịnh vụ ngân hàng thông qua eBanking
o eTeller o Mobile banking o Internet banking o Call center o ATM online - Dịch vụ Business-to-Business (B2B) gateway o Chứng khóan o Hải Quan o Thuế
o Thanh toán online
- Tích hợp và quản lí qui trình tự động hóa cho ngân hàng (BPM & ESB) o Cognos: hệ thông báo cáo thông minh
o Ứng dụng quản lí tự động hóa qui trình tín dụng (Loans Origination) o Ứng dụng quản lí rủi ro (Risk Mgmt)
o Hệ thông ngân hàng lõi (Core Banking) o Ứng dụng quản lí quan hệ khách hàng (CRM) o Vá các ứng dụng khác
- Bus Dịch vụ doanh nghiệp (Enterprise Service Bus): cung cấp một cơ sở hạ tầng có thể loại bỏ bất kỳ kết nối trực tiếp nào giữa ngƣời sử dụng dịch vụ và nhà cung cấp dịch vụ. Ngƣời dùng kết nối với bus dịch vụ doanh nghiệp