Các thành phần logic của web service
Web service bao gồm một số thành phần cơ bản: Service Requester (bên yêu cầu dịch vụ), Service Provider (bên cung cấp dịch vụ), Service Broker (bên phân phối dịch vụ), đƣợc mô tả chi tiết trong Bảng 2.1. Service Registry đƣợc sử dụng để Service Requester tìm kiếm các dịch vụ.
Bảng 2.1 : Các thành phần logic của web service[14]
STT Tên thành phần Mô tả
1 Service Requester Bên yêu cầu một dịch vụ dựa trên việc tìm kiếm trong một service registry. Thông thƣờng, một service requester sẽ sử dụng một giao thức chuẩn để khai thác các dịch vụ trong service registry (VD sử dụng UDDI để tìm kiếm). Khi đã tìm thấy dịch vụ mong muốn, service requester sẽ liên kết tới dịch vụ đó thông qua một SOAP proxy. 2 Service Provider Bên cung câp dịch vụ có vai trò tạo và cung cấp
các dịch vụ nghiệp vụ (VD nhƣ dịch vụ bán lẻ,..) tới bên yêu cầu. Các dịch vụ nghiệp vụ (business service) đƣợc đăng ký tới service registry bằng cách sử dụng ngôn ngữ mô tả WSDL. Service requester sẽ sử dụng các đặc tả này để lấy thông tin về giao diện và thực thi của dịch vụ.
3 Service Broker Là bên trung gian có nhiệm vụ tập hợp, sắp xếp và phân phối các dịch vụ dựa trên yêu cầu của các service requester (VD một nhân viên bán hàng là thể hiện của một service broker đối với ngƣời mua hàng). Một service provider cũng có thể là một service broker.
4 Service Registry Đóng vai trò nhƣ một trang vàng chứa thông tin về tất cả các dịch vụ và các nhà cung cấp dịch vụ(service provider) tƣơng ứng.
Hình 2.10 là một ví dụ về việc sử dụng web service. Bên mua hàng là khách hàng của Service Broker. Service Broker đóng vai trò nhƣ một bên trung gian cung cấp các dịch vụ của Service Provider. Service Broker sẽ mô tả các dịch vụ trong các UDDI Service Registry. Service Provider cũng khai báo về dịch vụ của mình trong một kho UDDI Service Registry và thông báo tới Service Broker.
Hình 2.10: Các thành phần logic của web service Tham gia vào kịch bản web service sẽ bao gồm các hành động sau[14]:
- Khai thác/tìm kiếm dịch vụ
- Liên kết (Bind) dịch vụ: liên kết tới dịch vụ (tại thời điểm run-time) tại điểm cuối sử dụng URL cung cấp (Thao tác này giống nhƣ việc kết nối điện thoại sau khi đã quay số điện thoại).
- Đăng tải dịch vụ (publish): công bố thông tin về dịch vụ tới Service Registry bằng cách sử dụng ngôn ngữ đặc tả WSDL.
- Ngừng đăng tải dịch vụ (unpublish): dừng việc công bố thông tin về dịch vụ tới Service Registry bằng cách sử dụng ngôn ngữ đặc tả WSDL.
Ca sử dụng web service
Hình 2.11 và 2.12là biểu đồ mô tả ca sử dụng và biểu đồ tuần tự của một web service. Hình 2.11mô tả 5 ca sử dụng về cách sử dụng web service. Bên yêu cầu dịch vụ (Service Requester) muốn tìm kiếm trong một Service Registry (kho dịch vụ) một số dịch vụ cần thiết. Khi tìm đƣợc thông tin về các dịch vụ, Service Registry sẽ chỉ đến Nhà cung cấp dịch vụ (Service Provider) tƣơng ứng.
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