Trong giai đoạn này các use case nghiệp vụ sẽ là dùng để 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ụ.
Trong bài toán thanh toán hóa đơn, có các hệ thống con được phân rã trong bước phân rã domain là ATM, Web Server, CoreBanking và Nhà cung cấp dịch vụ. Mỗi hệ thống con cung cấp một tập các service nghiệp vụ . Một use case nghiệp vụ có thể bao gồm 1 hoặc nhiều use case hệ thống. Như trong nghiệp vụ vấn tin hóa đơn sẽ có hai use case hệ thống là use case vấn tin thông tin tài khoản trong CoreBanking và use case vấn tin hóa đơn bên Nhà cung cấp dịch vụ.
2.2.4 Đƣa ra các dịch vụ
Các dịch vụ đã được xác định qua hai giai đoạn là phân rã domain và xây dựng mô hình goal-service[5]. Trong giai đoạn này, chúng ta sẽ thực hiện đưa các dịch vụ này vào các thành phần. Bước này 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 13 – Đƣa các dịch vụ vào các thành phần
2.2.5 Đặc tả thành phần
Bước này là đặc tả lại các thành phần sau khi đã thực hiện các bước trên như đặc tả đầu vào đầu ra web service…
2.2.6 Cấu trúc thành phần và dịch vụ
Trong giai đoạn này ta sẽ thực hiện đưa các dịch vụ và các thành phần vào các trong các tầng của SOA. Đây là bước quan trọng vì sẽ ảnh hưởng đến kiến trúc hệ thống, ảnh hưởng đến công tác xây dựng và triển khai hệ thống.
2.2.7 Lựa chọn giải pháp thực thi
Đây là bước quan trọng để quyết định giải pháp kỹ thuật ảnh hưởng đến tiến độ và chi phí của dự án như quyết định có sử dụng lại hệ thống cũ với các chức năng đã được thiết kế theo hướng dịch vụ hay là xây dựng một hệ thống hoàn toàn mới …
2.3 SOA và Web Service
SOA là một kiến trúc phần mềm, bao gồm một tập các nguyên tắc thiết kế độc lập với kỹ thuật và công nghệ nhằm liên kết các dịch vụ. SOA bắt đầu với việc định nghĩa thành phần giao tiếp (interface) và sau đó, xây dựng kiến trúc hệ thống như là sự liên kết của các thành phần interface, phần thực thi của các interface và cách thức tương tác giữa các interface. Trong khi đó, Web services lại là một tập hợp các kỹ thuật và công nghệ (SOAP, WSDL, UDDI, HTTP...) được dùng để hiện thực hóa các nguyên tắc thiết kế của SOA. Trong thực tế, khái niệm SOA không phải là một khái niệm hoàn toàn mới, mà đã xuất hiện cách đây khá lâu. Và trong quá khứ đã có rất nhiều kỹ thuật khác được dùng để triển khai một hệ thống SOA như :
• Distributed object : như CORBA, J2EE, COM/DCOM • Message-oriented middleware (MOM) : WebSphere MQ
Phần dưới đây sẽ giới thiệu rõ hơn về Web service, khái niệm, kiến trúc và các thành phần trong Web service
2.3.1 Kiến trúc Web services
Web service [4]-[6]-[10] là một tập các chuẩn đặc tả mở rộng khả năng của các chuẩn có sẵn như XML, URL và HTTP nhằm cung cấp chuẩn truyền thông giữa các hệ thống với nhau. Web services là những thành phần thực thi một số xử lý nghiệp vụ thông qua những dịch vụ và cung cấp những dịch vụ qua mạng, những dịch vụ này có thể được triệu gọi bởi các dịch vụ client bằng cách sử dụng giao thức SOAP trên HTTP. Web services độc lập về ngôn ngữ và độc lập về nền tảng bởi vì nó tách biệt đặc tả ra khỏi cài đặt; nó còn hỗ trợ tích hợp loose coupling giữa các ứng dụng với nhau qua trao đổi các thông điệp đồng bộ và bất đồng bộ thông. Web services dựa trên kiến trúc phân tán trong đó không có bất kì dịch vụ xử lý trung tâm nào và tất cả dạng truyền thông đều sử dụng các giao thức chuẩn. Các giao thức không được có bất kì ý nghĩa ngầm định nào bên trong mà phải được mô tả rõ ràng.
Trong Web services thì giữa thành phần triệu gọi web service(client) và Web services đều không cần biết cài đặt của nhau.
Web services sử dụng XML, một ngôn ngữ độc lập trong việc biểu diễn dữ liệu, làm ngôn ngữ trao đổi thông tin.
Mô hình web services dạng đơn giản định nghĩa cách thức tương tác giữa Service Requester, Service Provider, và Service Directory như sau : Bên sử dụng dịch vụ tìm kiếm các dịch vụ trong một UDDI Service Directory. Chúng sẽ lấy thông tin
mô tả WSDL của các Web services cung cấp bởi Service Providers từ trước thông qua Service Directory. Sau khi lấy được mô tả WSDL, bên yêu cầu dịch vụ kết nối đến nhà cung cấp dịch vụ bằng cách triệu gọi các dịch vụ thông qua giao thức SOAP. Web services cơ bản bao gồm các khái niệm SOAP, WSDL, và UDDI. Chúng ta sẽ lần lượt phân tích trong các phần sau. Cần lưu ý là các chuẩn trên có thể được kết hợp với nhau hoặc dùng độc lập tùy trường hợp cụ thể.
Hình 14 - Các tầng của Web service
Hình 14 mô tả các tầng hình thành nên Web service. Hình 15 mô tả các tác nhân trong Web service tương ứng với các tầng này.
Có 3 thành phần tác nhân chính tham gia vào Web service.
1. Service Provider: Dùng Web Services Description Language (WSDL) để mô tả dịch vụ mà mình có thể cung cấp cho Service Broker (tương tự với Service Registry trong SOA).
2. Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider. Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp. Thành phần chính của Service Broker là Universal Discovery, Description, and Integration (UDDI) repositories.
3. Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng và gởi cho service Broker.
WSDL WSDL
SOAP
Hình 15 - Tƣơng tác giửa các tác nhân trong Web service (adsbygoogle = window.adsbygoogle || []).push({});
Yêu cầu dịchvụ (Serice Requester) Nhà cung cấp dịch vụ (Service Provider) Môi giới dịch vụ(Service Broker)
2.3.2 Simple Object Access Protocol – SOAP
SOAP là một protocol giao tiếp dùng trong Web service được xây dựng dựa trên XML. SOAP được sử dụng để đặc tả và trao đổi thông tin về các cấu trúc dữ liệu cũng như các kiểu dữ liệu giữa các thành phần trong hệ thống.
Hình 16[4] mô tả giao tiếp của một ứng dụng với một web service được thực hiện qua thông điệp SOAP sử dụng giao thức HTTP. Ứng dụng sẽ đặc tả yêu cầu trong SOAP message và thông qua giao thức mạng gởi đến cho web service. Web service sẽ nhận và phân tích yêu cầu sau đó trả về kết quả thích hợp.
Hình 16 - Truyền thông điệp sử dụng SOAP
Hình 17 - Cấu trúc SOAP message
Hình 17 mô tả cấu trúc một thông điệp SOAP. Một thông điệp SOAP bao gồm các thành phần sau:
Protocol Header: Chứa thông tin về các chuẩn giao thức được sử dụng.
SOAP Envelop: Bao gồm 2 thành phần là SOAP header và SOAP body. Trong SOAP header chứa các header của message còn trong SOAP body chứa thông tin về name và data được đặc tả dưới dạng XML và trường lỗi được dùng để đưa ra các lỗi khi gọi web service.
2.3.3 Web Service Description Language (WSDL)
Trong WSDL sẽ miêu tả các dịch vụ thực hiện một quy trình nghiệp vụ gồm đầu vào và đầu ra, cổng kết nối web service,…
Hình 18[4] mô tả các thành phần cơ bản của một file WSDL dùng để đặc tả một web service.
Hình 18 – WSDL
Port Types: định nghĩa một web service, các tác vụ mà service cung cấp và định dạng các thông điệp được sử dụng để khởi động các tác vụ này.
Services: Chứa các method có thể được sử dụng thông qua các giao thức. Ports: Địa chỉ dùng để kết nối đến web service.
Operations: Mỗi operation có thể được xem như một method hay một lời gọi hàm trong các ngôn ngữ lập trình cổ điển.
Binding: chỉ định port type, các operation, SOAP binding stype (RPC/Document), SOAP protocol được dùng.
Message: Mỗi message tương ứng với một operation và chứa các thông tin cần thiết để thực thi operation đó. Mỗi message có một name duy nhất và một hay nhiều logical part. Các logical part được phân biệt với nhau qua name và có thể lưu trữ các tham số cần cho operation.
Element: Được định nghĩa trong Types. Mỗi element có một name duy nhất và kiểu dữ liệu. Element được dùng để đặc tả dữ liệu dùng trong message. Element có thể đặc tả các dữ liệu đơn giản (string, integer) hay phức tạp hơn như array, struct, ...
XSD file: Các element thường được định nghĩa trong các XML Schema Definition (XSD) file. XSD file có thể ở trong cùng file WSDL hoặc ở file riêng biệt.
2.3.4 UDDI
UDDI (Universal Description, Discovery, and Intergration) là chuẩn phục vụ các tổ chức đăng ký và tìm kiếm các Web Service. UDDI hỗ trợ tìm kiếm, định vị thông tin về một nhà cung cấp dịch vụ bao gồm địa chỉ, thông tin liên lạc và các định danh.
2.4 Kết luận
Chương này 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ả, xem xét quy trình phát triển ứng dụng theo mô hình SOA.
Trong chương cũng nêu các vấn đề liên quan đến Web services như kiến trúc Web service, các thành phần của Web service, các khai niệm về niệm SOAP, WSDL, và UDDI trong Web service.
Chương sau sẽ đề cập tới bài toán thanh toán hóa đơn tại BIDV sử dụng mô hình SOA dùng Web Service.
Chƣơng 3 - ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG THANH TOÁN HÓA ĐƠN CỦA BIDV
3.1 Phát biểu bài toán
Trong những năm qua BIDV không ngừng 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ức gia nhập tổ chức thương mại thế giới WTO thì BIDV đ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ì cốt lõi 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ụ. (adsbygoogle = window.adsbygoogle || []).push({});
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…
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 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.
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[4]. 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.
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.
3.2 Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV
Thành phần sử lý trung tâm hệ thống thanh toán hoá đơn Bill Payment Gateway sẽ định nghĩa ra các hàm web service để các kênh thanh toán như quầy giao dịch
BIDV Branch, Internet hay Mobile sẽ gọi và trao đổi thông điệp. Sau khi Bill Payment Gateway xử lý sẽ truyền thông điệp sang nhà cung cấp dịch vụ cũng sử dụng web service để trao đổi dữ liệu. Các thông điệp trao đổi là đồng bộ và Bill Payment Gateway có thể xử lý song song nhiều thông điệp. Mô hình cũng đề xuất sử dụng Message Queue của IBM để tăng khả năng xử lý tránh trường hợp quá tải với Bill Payment Gateway.
Hình 19 - Mô hình tổng quát hệ thống thanh toán hoá đơn của BIDV
Bill Payment Gateway: Trung tâm của hệ thống Thanh toán hóa đơn là hệ thống Bill Payment Gateway đóng vai trò là cổng kết nối giao diện giữa hệ thống CoreBanking /SIBS, quầy giao dịch tại các chi nhánh của Ngân hàng Đầu tư và Phát triển Việt nam, hệ thống ATM/SWITCH với các nhà cung cấp dịch vụ . Bill Payment Gateway được thiết kế và xây dựng để thực hiện các nhiệm vụ sau:
• Tiếp nhận các yêu cầu thanh toán hóa đơn từ 02 kênh thanh toán: ATM và quầy giao dịch của tất cả các chi nhánh trên phạm vi toàn hệ thống Ngân hàng Đầu tư và phát triển Việt nam.
• Thực hiện gửi các yêu cầu hạch toán online vào hệ thống SIBS đối với các giao dịch thanh toán hóa đơn xuất phát từ quầy giao dịch.
• Switching giao dịch đến đúng nhà cung cấp dịch vụ theo yêu cầu thanh toán được gửi đến từ kênh thanh toán ATM hoặc quầy giao dịch.
SWITCH: Máy chủ Switch được thiết kế và xây dựng để thực hiện các nhiệm vụ sau:
• Tiếp nhận các yêu cầu thanh toán hóa đơn từ các ATM Terminal và switching các yêu cầu đó sang hệ thống Bill Payment Gateway.
• Thực hiện gửi các yêu cầu hạch toán online 24/7 vào hệ thống SIBS đối với các giao dịch xuất phát từ ATM Terminal.
ATM Terminal: Các ATM Terminal đóng vai trò cung cấp dịch vụ thanh toán hóa đơn cho khách hàng qua máy giao dịch tự động ATM. ATM Terminal được cài đặt một phần mềm thích hợp để có thể gửi yêu cầu thanh toán hóa đơn tới SWITCH.
Chi nhánh BIDV: Là danh sách các chi nhánh, hoặc điểm giao dịch của Ngân hàng Đầu tư và phát triển Việt nam được chọn lựa để phục vụ yêu cầu thanh toán hóa đơn của khách hàng. Tại các điểm này, một phần mềm thích hợp được trang bị để có thể gửi yêu cầu thanh toán hóa đơn tới Bill Payment Gateway.
CoreBanking – SIBS: tiếp nhận và xử lý các yêu cầu hạch toán vào tài khoản các nhà cung cấp mở tại Ngân hàng Đầu tư và phát triển Việt nam từ Bill Payment Gateway và ATM/SWITCH
Các nhà cung cấp nhƣ EVN, Mobile Phone…: Giao tiếp với Bill Payment Gateway thông qua Web service
Các thuê bao di động sử dụng kênh SMS : giao tiếp thông qua tổng đài 8049, máy chủ tổng sẽ giao tiếp với Bill Payment Gateway thông qua Web service.
3.3 Quy trình hoạt động
Hiện tại BIDV mới triển khai hệ thống thanh toán hoá đơn qua các kênh chi nhánh BIDV, ATM và dịch vụ nạp tiền điện thoại cho thuê bao trả trước thêm kênh SMS. Trong tương lai gần sẽ triển khai thêm kênh internet, kênh mobile cho tất cả các dịch vụ. Ở đây ta sẽ chỉ đề cập chính đến hệ thống thanh toán hoá đơn cho hai kênh đã triển khai rộng là ATM và quầy giao dịch của BIDV
Luồng giao dịch giữa các cấu thành của hệ thống
Luồng giao dịch của kênh thanh toán tại quầy Giao dịch vấn tin hóa đơn
Khách hàng ra quầy thanh toán sẽ nhập mã hóa đơn khách hàng rồi gửi lên Gateway. Gateway sẽ xử lý và gửi sang bên nhà cung cấp rồi gửi trả lại web server để hiển thị lên màn hình cho biết chi tiết hóa đơn của khách hàng hay lỗi.