Xây dựng hệ thống kết nối thanh toán giữa ngân hàng và các công ty chứng khoán

Header Page 1 of 27.

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

Phạm Thị Hồng Nhung

XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN
GIỮA NGÂN HÀNG
VÀ CÁC CÔNG TY CHỨNG KHOÁN

Ngành: Công nghệ Thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC
TS. NGUYỄN HẢI CHÂU

Footer Page 1 of 27.


Header Page 2 of 27.

MỤC LỤC
Trang phụ bìa
Lời cam đoan
Lời cảm ơn
Mục lục ............................................................................................................1
Danh mục các thuật ngữ và các từ viết tắt ......................................................2

Danh mục các bảng ...........................................................................................4
Danh mục các hình vẽ ........................................................................................5
MỞ ĐẦU ....................................................................................................................9
CHƢƠNG 1: TỔNG QUAN VỀ VẤN ĐỂ KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ
CÁC CÔNG TY CHỨNG KHOÁN ...........................................................................11
1.1 Nhu cầu thực tiễn

11

1.2 Hiện trạng các giải pháp kết nối thanh toán 12
1.3 Giải pháp đề xuất của luận văn 13
CHƢƠNG 2: GIỚI THIỆU CÔNG NGHỆ WEBSPHERE MQ VÀ ỨNG DỤNG TRONG HỆ
THỐNG KẾT NỐI THANH TOÁN ............................................................................16
2.1 Giới thiệu công nghệ WebSphere MQ 16
2.1.1 Các đối tượng cơ bản của Websphere MQ 16
2.1.2 Đặc trưng của Websphere MQ và cơ chế truyền tải message

21

2.2 Công nghệ Web Service với WebSphere MQ 23
2.2.1 Cơ bản về Web Service
24
2.2.2 Web Service và Websphere MQ

26

2.3. An toàn bảo mật thông tin qua SSL với Websphere MQ và Web Service Error! Bookmark
not defined.
2.3.1. Vấn đề an toàn bảo mật thông tin qua SSL với Web service
Error! Bookmark not

defined.
2.3.2 SSL và Websphere MQ

Error! Bookmark not defined.

CHƢƠNG 3: XÂY DỰNG HỆ THỐNG KẾT NỐI THANH TOÁN GIỮA NGÂN HÀNG VÀ
CÁC CÔNG TY CHỨNG KHOÁN ................................. Error! Bookmark not defined.
3.1. Mô tả hoạt động nghiệp vụ
Error! Bookmark not defined.
3.1.1 Một số khái niệm
Error! Bookmark not defined.
Footer Page 2 of 27.


Header Page 3 of 27.

3.1.2 Mô tả nghiệp vụ:

Error! Bookmark not defined.

3.1.3 Các yêu cầu của hệ thống

Error! Bookmark not defined.

3.2. Xây dựng mô hình hệ thống Error! Bookmark not defined.
3.2.1 Mô hình kết nối
Error! Bookmark not defined.
3.2.2 Cấu hình WebSphere MQ Error! Bookmark not defined.
3.2.3 Cơ chế hoạt động
Error! Bookmark not defined.

3.3. Phân tích thiết kế hệ thống
Error! Bookmark not defined.
3.3.1 Mô hình phân tích Error! Bookmark not defined.
3.3.2 Phát triển mô hình ca sử dụng
Error! Bookmark not defined.
3.3.3 Phân tích một số ca sử dụng điển hình của hệ thống Error! Bookmark not defined.

Footer Page 3 of 27.


Header Page 4 of 27.

Danh mục các thuật ngữ và các từ viết tắt
Từ/cụm từ
Authentication
Bank Gateway
CA (Current Account)
Channel
CipherSpec
CipherSuite
Client/Server
CoreBanking
Dead-letter queue
Encryption
HTTP (Hyper Text Transport
Protocol)
Listener
Local queue
Message
MQI (Message Queue Interface)

QM (Queue Manager)
QMC (Queue Manager Cluster)
Queue
Receiver
Remote queue
Request
Response
Sender
SOAP (Simple Object Access
Protocol)
SSL (Secure Sockets Layer)
TA (Trading Account)
Transmission queue
UDDI (Universal Description
Discovery and Integration)
Footer Page 4 of 27.

Ý nghĩa
Xác thực
Cổng giao tiếp/Máy chủ quản lý giao dịch
giữa Ngân hàng và Công ty chứng khoán
Tài khoản tiền gửi tại ngân hàng
Kênh (dùng để truyền tải message)
Thông số mã hóa và xác thực
Bộ mật mã
Máy khách/ Máy chủ
Lõi ngân hàng
Hàng đợi chứa các message không được
phân phối
Mã hoá

Giao thức vận chuyển siêu văn bản
Một tiến trình của WebSphere MQ để "nghe"
các kết nối
Queue cục bộ
Thông điệp
Giao diện quản lý các hàng đợi
Quản trị các hàng đợi (queue)
Bó cụm các queue manager
Hàng đợi, nơi chứa các thông điệp
Bên nhận
Queue đại diện cho một queue khác ở xa
Yêu cầu
Đáp ứng
Bên gửi
Giao thức truy cập đối tượng đơn giản
Giao thức truyền đạt thông tin một cách an
toàn qua mạng
Tài khoản chuyên dùng cho hoạt động thanh
toán chứng khoán
Queue truyền tải
Hợp nhất và phát hiện các mô tả toàn thể


Header Page 5 of 27.

URI (Universal Resource
Indicator or Identifier)
Web Service
WebSphere MQ (WebSphere
Message Queue)

Websphere MQ Explorer
WSDL (Web Services Description
Language)
XML (Extensible Markup
Language)

Footer Page 5 of 27.

Định danh tài nguyên toàn thể
Dịch vụ web
Một công nghệ truyền tải thông điệp của
IBM
Trình quản lý và cấu hình WebSphere MQ
một cách trực quan.
Ngôn ngữ mô tả dịch vụ web
Ngôn ngữ đánh dấu mở rộng


Header Page 6 of 27.

Danh mục các bảng
Bảng 3.2-1: Cấu hình WebSphere MQ trên các máy chủError! Bookmark not defined.
Bảng 3.3-1: Các chức năng của hệ thống ................. Error! Bookmark not defined.
Bảng 3.3-2: Từ điển dữ liệu của hệ thống ................. Error! Bookmark not defined.
Bảng 3.3-3: Các tác nhân và vai trò trong hệ thống ... Error! Bookmark not defined.
Bảng 3.3-4: Mô tả ca sử dụng cập nhật CTCK .......... Error! Bookmark not defined.
Bảng 3.3-5: Mô tả ca sử dụng cập nhật tài khoản TA Error! Bookmark not defined.
Bảng 3.3-6: Mô tả ca sử dụng vấn tin tài khoản TA ... Error! Bookmark not defined.
Bảng 3.3-7: Mô tả ca sử dụng phong toả tài khoản TAError! Bookmark not defined.
Bảng 3.3-8: Mô tả ca sử dụng giải phong toả tài khoản TAError! Bookmark not defined.

Bảng 3.3-9: Mô tả ca sử dụng Chuyển tiền ............... Error! Bookmark not defined.
Bảng 3.3-10: Mô tả ca sử dụng tổng hợp kết quả giao dịchError! Bookmark not defined.
Bảng 3.3-11: Mô tả ca sử dụng sao kê chi tiết tài khoản TAError! Bookmark not defined.

Footer Page 6 of 27.


Header Page 7 of 27.

Danh mục các hình vẽ
Hình 2.2-1: Mô hình kiến trúc Web Service .............................................................25
Hình 2.2-2 Kiến trúc phân tầng của Web Service ....................................................26
Hình 2.2-3: Web Services qua HTTP .....................................................................27
Hình 2.2-4: Web Services qua WebSphere MQ ....................................................27
Hình 2.2-5: Web Service client sử dụng proxy ........... Error! Bookmark not defined.
Hình 3.2-1: Mô hình Hệ thống kết nối thanh toán ...... Error! Bookmark not defined.
Hình 3.2-2: Cấu hình Remote queue Q.RMT.BR.GW Error! Bookmark not defined.
Hình 3.2-3: Cấu hình Remote queue Q.RMT.GW.BR Error! Bookmark not defined.
Hình 3.2-4: Cấu hình transmision queue Q.XMIT.BR Error! Bookmark not defined.
Hình 3.2-5: Cấu hình transmision queue Q.XMIT.GW.BR ........ Error! Bookmark not
defined.
Hình 3.2-6: Các queue của queue manager GW ....... Error! Bookmark not defined.
Hình 3.2-7: Cấu hình channel CH.BR.GW ................. Error! Bookmark not defined.
Hình 3.2-8: Các channel của queue manager GW .... Error! Bookmark not defined.
Hình 3.2-9: Cấu hình channel CH.BR.GW ................. Error! Bookmark not defined.
Hình 3.2-10: Mô hình “request-and-response” vận chuyển message dưới giao thức
SOAP thông qua WebSphere MQ. ............................ Error! Bookmark not defined.
Hình 3.2-11: Đường đi của message theo chế độ kết nối server. ... Error! Bookmark
not defined.
Hình 3.2-12: Triển khai WebSphere MQ transport for SOAP.... Error! Bookmark not

defined.
Hình 3.3-1: Sơ đồ tiến trình hoạt động kết nối thanh toán ........ Error! Bookmark not
defined.
Hình 3.3-2: Biểu đồ thực thể của lĩnh vực quản lý hoạt động kết nối thanh toánError!
Bookmark not defined.
Hình 3.3-3: Mô hình ca sử dụng mức tổng thể của hệ thống.... Error! Bookmark not
defined.
Hình 3.3-4: Biểu đồ tuần tự hệ thống Đăng ký tài khoản TA..... Error! Bookmark not
defined.
Hình 3.3-5: Biểu đồ lớp phân tích thực thi ca sử dụng Đăng ký tài khoản TA ... Error!
Bookmark not defined.
Footer Page 7 of 27.


Header Page 8 of 27.

Hình 3.3-6: Biểu đồ tuần tự phân tích thực thi ca sử dụng Đăng ký tài khoản TA
................................................................................... Error! Bookmark not defined.
Hình 3.3-7: Biểu đồ tuần tự hệ thống Phong toả tài khoản TA . Error! Bookmark not
defined.
Hình 3.3-8: Biểu đồ lớp phân tích thực thi ca sử dụng Phong toả tài khoản TA Error!
Bookmark not defined.
Hình 3.3-9: Biểu đồ tuần tự phân tích thực thi ca sử dụng Phong tỏa tài khoản TA
................................................................................... Error! Bookmark not defined.
Hình 3.3-10: Biểu đồ tuần tự hệ thống Giải phong toả tài khoản TAError! Bookmark
not defined.
Hình 3.3-11: Biểu đồ lớp phân tích thực thi ca sử dụng Giải phong toả tài khoản TA
................................................................................... Error! Bookmark not defined.
Hình 3.3-12: Biểu đồ tuần tự phân tích thực thi ca sử dụng Giải phong toả tài khoản
TA .............................................................................. Error! Bookmark not defined.

Hình 3.3-13: Biểu đồ tuần tự hệ thống Chuyển tiền ... Error! Bookmark not defined.
Hình 3.3-14: Biểu đồ lớp phân tích thực thi ca sử dụng Chuyển tiền ................ Error!
Bookmark not defined.
Hình 3.3-15: Biểu đồ tuần tự phân tích thực thi ca sử dụng Chuyển tiền .......... Error!
Bookmark not defined.

Footer Page 8 of 27.


Header Page 9 of 27.

MỞ ĐẦU
Theo điều 32, Quyết định số 27/2007/QD9-BTC ngày 24-4-2007 của Bộ Tài chính
về việc ban hành quy chế tổ chức và hoạt động của công ty chứng khoán, các Công ty
chứng khoán (CTCK) không được trực tiếp nhận tiền giao dịch chứng khoán của khách
hàng (nhà đầu tư).
Nếu như trước đây các CTCK vẫn kiêm nhiệm phần việc quản lý tiền của nhà đầu
tư như một ngân hàng thực thụ, khách hàng khi giao dịch chứng khoán phải mở Tài khoản
(TK) và nộp tiền vào CTCK, sau đó CTCK là người quản lý và kiểm soát TK và tài sản của
khách hàng. Với những công ty lớn như SSI, BVSC, VCBS, ACBS… số dư tiền mặt trong
tài khoản của nhà đầu tư có thời điểm lên tới vài nghìn tỷ đồng, một tài khoản đầu tư
nhỏ lẻ cũng vài chục triệu đồng. Về nguyên tắc, quyền sử dụng tiền của nhà đầu tư
không thuộc về các CTCK, nhưng với nhiều công ty đây là nguồn vốn khá quan trọng, họ
có thể mượn tạm vào một thời điểm nào đó và hoàn lại tài khoản nhà đầu tư khi có nhu
cầu. Cũng không loại trừ trường hợp CTCK nộp tiền vào ngân hàng với lãi suất theo thỏa
thuận và ăn chênh lệch, cao hơn lãi suất nhà đầu tư được hưởng (loại không kỳ hạn).
Tuy nhiên, việc một tổ chức không có nghiệp vụ quản lý tiền mặt và không phải chịu chế
tài của một tổ chức tài chính, lại quản lý một lượng tiền lên tới hàng trăm tỷ đồng mỗi
ngày có thể ẩn chứa nhiều rủi ro lớn về mặt vĩ mô cũng như vi mô, cho cả nền kinh tế và
cho chính tổ chức đó.

Theo Quyết định 27, các hoạt động nộp tiền, rút tiền và giữ tiền mặt của các nhà
đầu tư chứng khoán đều phải tập trung về các Ngân hàng (NH), khách hàng sẽ mở TK
tiền tại một ngân hàng thương mại do CTCK chỉ định trong danh sách các ngân hàng
được Uỷ ban chứng khoán lựa chọn. Sau đó quá trình thanh toán trong giao dịch sẽ được
ngân hàng đó thanh toán, đây là chức năng chính của ngân hàng chứ không phải là hoạt
động của CTCK, còn chứng khoán của khách hàng sẽ được quản lý và lưu ký tại Trung
tâm Lưu Ký Chứng Khoán.
Như vậy cần phải có một hệ thống kết nối thanh toán giữa Ngân hàng và các
CTCK, giúp các CTCK quản lý tiền gửi giao dịch chứng khoán của khách hàng và liên kết
để kiểm tra điều kiện, thực hiện các giao dịch mua bán chứng khoán của khách hàng.
Luận văn “Xây dựng hệ thống Kết nối thanh toán giữa Ngân hàng và các Công ty
Chứng khoán” cung cấp giải pháp cho các công ty chứng khoán có thể dễ dàng kết nối, sử
dụng các dịch vụ của ngân hàng nhằm đem đến cho nhà đầu tư các dịch vụ tiện ích hơn.
Với các dịch vụ được cung cấp, công ty chứng khoán có nhiều phương án điều
chỉnh tác nghiệp của mình: tích hợp ứng dụng chứng khoán, xây dựng chương trình độc
lập,...
Về bố cục, nội dung của luận văn bao gồm 3 chương:
Chương 1: Giới thiệu tổng quan về vấn để kết nối thanh toán giữa Ngân hàng và
Footer Page 9 of 27.


Header Page 10 of 27.

các Công ty Chứng khoán, xuất phát từ nhu cầu thực tiễn cũng như hiện trạng các giải
pháp kết nối thanh toán hiện nay, từ đó đưa ra giải pháp của luận văn.
Chương 2: Giới thiệu các công nghệ sử dụng trong giải pháp xây dựng Hệ thống
kết nối thanh toán, bao gồm các công nghệ như: WebSphere MQ của IBM, Công nghệ web
service và việc ứng dụng công nghệ web service vào vận chuyển message bằng SOAP qua
WebSphere MQ.
Chương 3: Đi sâu vào mô tả các hoạt động nghiệp vụ, xây dựng mô hình kết nối,

cách cấu hình cũng như cơ chế hoạt động của mô hình, vấn đề bảo mật…Chương này
cũng đi sâu phân tích thiết kế hệ thống, theo sát các yêu cầu nghiệp vụ để phát triển các
ca sử dụng..
Phần kết luận: Đánh giá hiệu quả của giải pháp kết nối thanh toán, rút ra những
điểm đã đạt được cũng như chưa đạt được của luận văn, đồng thời đưa ra hướng
nghiên cứu, phát triển tiếp theo.
Ngoài ra, luận văn còn có thêm các danh mục thuật ngữ, từ viết tắt, danh mục bảng
biểu, hình vẽ và danh mục các tài liệu tham khảo để thuận tiện cho việc tìm hiểu và tra
cứu nội dung của luận văn.

Footer Page 10 of 27.


Header Page 11 of 27.

CHƢƠNG 1: TỔNG QUAN VỀ VẤN ĐỂ KẾT NỐI THANH TOÁN
GIỮA NGÂN HÀNG VÀ CÁC CÔNG TY CHỨNG KHOÁN
1.1 Nhu cầu thực tiễn
Theo như Điều 32 Quyết định 27 (ban hành ngày 24/04/2007) của Bộ Tài chính
về quy chế tổ chức và hoạt động của công ty chứng khoán, nhà đầu tư sẽ phải nộp
tiền, rút tiền tại ngân hàng và thực hiện việc giao dịch chứng khoán tại các công ty
chứng khoán. Rõ ràng là, khi chuyển qua hình thức quản lý mới này, khó khăn lớn
nhất nằm ở chỗ hệ thống thông tin của nhiều công ty chứng khoán còn chưa kết nối
được với hệ thống ngân hàng. Hơn nữa một công ty chứng khoán còn phải bảo đảm
kết nối được cùng lúc với nhiều ngân hàng lớn, và ngược lại, các ngân hàng cũng
mong muốn có được kết nối với nhiều công ty chứng khoán để hình thành nên mạng
lưới đồng bộ và thông suốt.
Từ trước tới nay, tất cả tài khoản giao dịch của nhà đầu tư đều mở tại các
công ty chứng khoán. Những công ty này sẽ đứng ra nhận, trả tiền cho khách và
chuyển tiền từ tài khoản này đến tài khoản khác trong quá trình giao dịch.

Theo các chuyên gia, các công ty chứng khoán đã nắm giữ một số lượng tiền
tới hàng chục nghìn tỷ đồng, trong khi họ không có chức năng và không đủ nghiệp vụ
để giữ và kiểm soát tiền. Bản thân các công ty chứng khoán dù rất tiếc món hời bấy
lâu cũng phải thừa nhận tình trạng này.
Việc công ty chứng khoán giữ tiền của nhà đầu tư như hiện nay chỉ ở Việt
Nam mới có, còn các nước trên thế giới đều áp dụng theo mô hình: Công ty chứng
khoán không quản lý tiền trong tài khoản của nhà đầu tư mà việc này được giao cho
các ngân hàng thực hiện nhằm đảm bảo sự minh bạch. Do đó việc thực hiện quản lý
tách biệt tiền giao dịch chứng khoán của nhà đầu tư là việc làm cần thiết.
Với cách quản lý trước đây, tiền gửi vào tài khoản do các công ty chứng khoán
nơi nhà đầu tư mở tài khoản quản lý. Công ty chứng khoán sẽ gửi toàn bộ tiền của
nhà đầu tư vào một tài khoản chung tại ngân hàng. Lúc này, ngân hàng chỉ biết tổng
số tiền trong tài khoản chung còn con số cụ thể trong từng tài khoản của nhà đầu tư
thì chỉ duy nhất công ty chứng khoán nắm được.
Đã có không ít trường hợp tài khoản của nhà đầu tư tự nhiên thiếu một khoản
tiền lớn hoặc có lệnh mua “từ trên trời rơi xuống” xuất hiện mà chủ tài khoản không
hề đặt lệnh thực hiện. Việc quản lý tách biệt tiền gửi của nhà đầu tư là một trong
những mục tiêu quan trọng của Bộ Tài chính nhằm cải cách hệ thống giao dịch trên
thị trường chứng khoán và giúp tài khoản của nhà đầu tư được quản lý chặt chẽ,
tránh tình trạng tiền bị sử dụng tùy tiện.
Chính vì vậy, quyết định chuyển tiền của nhà đầu tư sang ngân hàng là phù
hợp bởi đây vốn là chuyên môn của các nhà băng. Ngoài việc đủ nhân lực, cơ sở vật
Footer Page 11 of 27.


Header Page 12 of 27.

chất để thực hiện, ngân hàng còn đảm bảo an toàn cho nguồn tiền đó cũng như các
quyền lợi phát sinh khác có liên quan cho nhà đầu tư. Việc tập trung thu nhận tiền về
một mối sẽ giúp các CTCK tập trung nhân lực cho các dịch vụ chính của mình. Hơn

nữa, các ngân hàng có mạng lưới hoạt động rộng cũng sẽ tạo thuận lợi cho nhà đầu
tư khi cần gửi tiền hay rút tiền...Quy định trên sẽ đem lại sự an toàn về tiền gửi cho
khách hàng khi CTCK gặp những khó khăn trong hoạt động kinh doanh. Đây là một
việc làm mới và tích cực trong việc minh bạch hóa hơn trong chuyện quản lý tài sản
của khách hàng và là bước đi lớn trong việc quản lý vĩ mô của nhà nước về chứng
khoán, đồng thời cũng mở ra một kênh huy động vốn khác cho các ngân hàng thương
mại. Tuy nhiên, vấn đề đặt ra là để làm được điều này, thì việc quan trọng nhất là
phải có sự liên thông giữa hệ thống phần mềm của ngân hàng với phần mềm quản lý
giao dịch của các công ty chứng khoán.

1.2 Hiện trạng các giải pháp kết nối thanh toán
Quy định về việc các công ty chứng khoán phải ủy quyền cho một ngân hàng
thương mại nhận và quản lý tiền của nhà đầu tư là một thách thức không nhỏ đối
với các ngân hàng, đặc biệt là các công ty chứng khoán, khi thực trạng về hạ tầng
CNTT của các bên còn nhiều khác biệt, mức độ sẵn sàng cũng khác nhau. Vấn đề
nhà đầu tư quan tâm là việc liên thông các hệ thống giao dịch của công ty chứng
khoán với hệ thống lõi của ngân hàng sẽ được thực hiện thế nào để bảo đảm tính an
toàn bảo mật, trực tuyến cho các giao dịch của họ ; đặc biệt là tính đa kết nối để tạo
sự liên thông giữa hai bên, thuận lợi cho nhà đầu tư.
Khi chuyển qua hình thức quản lý mới này, khó khăn lớn nhất là hệ thống
thông tin của nhiều công ty chứng khoán còn chưa kết nối được với hệ thống ngân
hàng. Hơn nữa, một công ty chứng khoán còn được yêu cầu phải bảo đảm kết nối
được cùng một lúc với nhiều ngân hàng lớn. Ngược lại, các ngân hàng cũng muốn
kết nối với nhiều công ty chứng khoán để hình thành nên một mạng lưới đồng bộ và
thông suốt.
Nếu giải pháp sử dụng cho ngân hàng, nó phải giúp ngân hàng phân tích thông
tin đến từ các công ty chứng khoán khác nhau và đặc biệt cho phép có sự tương tác
hai chiều giữa ngân hàng và công ty chứng khoán.
Trước mắt, để quản lý nguồn tiền gửi của các nhà đầu tư, các công ty chứng
khoán là người đại diện mở tài khoản chung tại ngân hàng và giao ngân hàng quản

lý. Ngân hàng sẽ cử một đại diện bên cạnh công ty chứng khoán để thu tiền của các
nhà đầu tư.
Trên thực tế, trong tổng số 103 CTCK đang hoạt động, những CTCK hoàn tất
việc tách bạch tài khoản tiền gửi của mình với nhà đầu tư tại ngân hàng đa phần là
những công ty "trẻ", có số tài khoản không nhiều. Số còn lại vẫn đang ì ạch tách tài
Footer Page 12 of 27.


Header Page 13 of 27.

khoản tiền gửi của nhà đầu tư sang ngân hàng quản lý. Việc chậm trễ này có rất
nhiều lý do như CTCK sợ rủi ro về kỹ thuật, sợ không đảm bảo tính an toàn và nhanh
chóng trong giao dịch, sợ quá tải, sợ những rủi ro trong quá trình kết nối khiến CTCK
mất khách hàng… nên việc tách tài khoản tiền của nhà đầu tư sang ngân hàng vẫn chỉ
làm rón rén...
Hiện tại có rất ít CTCK có kết nối trực tuyến thực sự với ngân hàng để thực
hiện các giao dịch mua bán chứng khoán (Ví dụ như CTCK Âu Lạc kết nối với ngân
hàng Eximbank và ngân hàng Phương Đông; CTCK Viễn Việt, Phương Đông, Đông
Á, Chợ Lớn kết nối với ngân hàng TMCP Đông Á; giải pháp SmartConnect của công
ty FPT kết nối CTCK Sao Việt và Ngân hàng Phương Đông, CTCK MHBS và ngân
hàng BIDV…). Còn lại với đa số các CTCK khác, mặc dù khách hàng đã mở tài
khoản tiền gửi thanh toán chứng khoán tại ngân hàng và việc nộp rút tiền được thực
hiện tại ngân hàng nhưng được thực hiện theo cách thủ công. Ví dụ, ngân hàng sẽ
đặt một quầy giao dịch ngay tại sàn giao dịch của CTCK, khách hàng nộp tiền tại
ngân hàng (vào tài khoản tổng của CTCK hoặc vào TK tiền gửi cá nhân), sau đó
CTCK mới căn cứ vào phiếu nộp tiền để cập nhật vào TK đầu tư chứng khoán của
nhà đầu tư. Hoặc khi khách hàng muốn rút tiền thì phải qua sự đồng ý của CTCK
trước (để cập nhật số dư tài khoản đầu tư chứng khoán) sau đó cầm phiếu rút tiền
sang bên ngân hàng để rút tiền (và ngân hàng cập nhật số dư tài khoản tiền gửi).
Tương tự, việc cập nhật số dư tài khoản tiền gửi của khách hàng khi có kết quả mua

bán chứng khoán cũng được thực hiện thủ công bằng cách CTCK căn cứ vào kết quả
giao dịch của nhà đầu tư để gửi bảng kê sang yêu cầu ngân hàng chuyển tiền từ tài
khoản tiền gửi của nhà đầu tư sang tài khoản tổng của CTCK và ngược lại.
Cũng có những CTCK thực hiện kết nối trực tuyến với ngân hàng nhưng thông
qua một công ty trung gian chuyên về thanh toán điện tử (Ví dụ như công ty cổ phần
dịch vụ thanh toán điện tử Việt Phú là trung gian kết nối CTCK Thành Công với ngân
hàng Công Thương và một số ngân hàng, CTCK khác). Công ty trung gian này sẽ
đứng ra đảm nhiệm việc kết nối giữa nhiều ngân hàng và nhiều CTCK, đảm bảo
thực hiện các thay đổi cần thiết về mặt kỹ thuật, công nghệ phía các CTCK để có
thể thực hiện giao dịch với tài khoản tiền gửi của nhà đầu tư tại ngân hàng. Ưu điểm
của giải pháp kết nối qua công ty trung gian này đối với Ngân hàng và CTCK là sẽ
giảm thiểu được thời gian, nhân lực cho việc thay đổi cơ sở hạ tầng công nghệ đang
sử dụng mà vẫn kết nối trực tuyến được với nhiều ngân hàng và nhiều CTCK vì
việc này đã có công ty trung gian đảm nhiệm. Tuy nhiên hạn chế của mô hình này là
chi phí cho việc kết nối chắc chắn sẽ cao hơn, và vì phải qua một công ty trung gian
nên có thể sẽ phát sinh những vấn đề rủi ro khi thực hiện giao dịch mà rất khó tìm
nguyên nhân xem lỗi là tại CTCK, tại ngân hàng hay tại công ty trung gian.

1.3 Giải pháp đề xuất của luận văn
Footer Page 13 of 27.


Header Page 14 of 27.

Trong xu thế các công ty chứng khoán ngày càng phát triển, để thực hiện triệt
để quy định của Bộ tài chính cũng như thực hiện tách bạch tài khoản tiền gửi của
nhà đầu tư với tài khoản của CTCK giống các nước khác trên thế giới mà không phải
làm một cách thủ công thì nhu cầu kết nối trực tuyến giữa ngân hàng và chứng
khoán cũng gia tăng theo.
Như trên đã nói, hiện nay đã có một số ngân hàng và CTCK thực hiện kết nối

trực tuyến với nhau, và đa số các giải pháp này sử dụng kênh kết nối qua Web
Service.
Luận văn cũng đưa ra giải pháp kết nối trực tuyến dùng Web Service nhưng
được kết hợp với phương thức truyền tải message SOAP qua công nghệ WebSphere
MQ (WebSphere Message Queue) của hãng IBM[6]. Các chức năng của hệ thống
được lập trình bằng Microsft Visual studio .Net C# và sử dụng hệ quản trị cơ sở dữ
liệu oracle.
Việc dùng WebSphere MQ để truyền tải message sẽ đáp ứng được các nhu
cầu sau của một hệ thống kết nối:
- Sự tích hợp: Hệ thống kết nối cần phải tích hợp các ứng dụng lõi của các
ngân hàng và các công ty chứng khoán, việc giao tiếp trở nên khó hoàn tất khi
các ứng dụng này: mở rộng phạm vi giao dịch; được viết bằng nhiều ngôn ngữ
khác nhau; dựa trên các hệ điều hành hoặc bộ xử lý khác nhau; sử dụng các
phương thức giao tiếp khác nhau…WebSphere MQ cung cấp một phương thức
chung để giao tiếp giữa các ứng dụng, không bị phụ thuộc bởi ngôn ngữ, hệ
điều hành, bộ xử lý, các giao thức truyền thông.
- Giao tiếp không đồng bộ: Giao tiếp đồng bộ đòi hỏi các chương trình ứng
dụng phải cùng sẵn sàng tại một thời điểm, nếu không thì một số chương
trình sẽ bị ngăn cản làm việc cho đến khi chương trình khác sẵn sàng. Vì vậy
cần có chương trình để giao tiếp không phụ thuộc lẫn nhau. WebSphere MQ
cung cấp một cơ chế giao tiếp độc lập giữa các chương trình với nhau (giao
tiếp không đồng bộ)
- Phân phối có bảo đảm: Khi toàn bộ hoặc một phần của hệ thống bị lỗi, tính
toàn vẹn của thông tin đang truyền có thể bị tổn hại: Thông tin có thể bị mất
nếu không được lưu trữ an toàn trong quá trình truyền đi hoặc có thể bị trùng
nếu gửi lại một cách không cần thiết. WebSphere MQ bảo đảm thông tin trao
đổi giữa các phần trong hệ thống không bị mất cũng như không bị trùng lặp khi
truyền.
- Tính linh hoạt: Khi có thêm các CTCK kết nối vào hệ thống, thời gian và công
sức bỏ ra để kết nối một hệ thống mới vào một mạng có sẵn có thể rất lớn và

đòi hỏi phải có một thời gian đáng kể để ngắt dịch vụ và ngừng hoạt động.
Footer Page 14 of 27.


Header Page 15 of 27.

WebSphere MQ cung cấp một phương pháp để tích hợp các hệ thống mới vào
với việc ngắt dịch vụ tối thiểu.
- Tính nhanh chóng và tiện lợi: Việc truyền nhận message qua lại trong hệ thống
sẽ trở nên nhanh chóng và dễ dàng hơn khi sử dụng WebSphere MQ để truyền
tải message. Hơn nữa, để cài đặt, cấu hình WebSphere MQ và viết chương
trình để sử dụng WebSphere MQ cũng rất đơn giản.
WebSphere MQ sẽ đáp ứng tất cả các nhu cầu trên bằng việc cung cấp một
môi trường cho việc truyền thông tin và sắp xếp hàng đợi các thông tin đó (messaging
and queuing).
Ngoài ra, việc dùng Web Service kết hợp với WebSphere MQ sẽ giúp cho việc
truyền tải message nhanh chóng và chính xác hơn nhiều, giảm bớt thao tác cần phải
thực hiện khi triển khai Web Service và quan trọng hơn cả là không cần phải dựng
web server.

Footer Page 15 of 27.


Header Page 16 of 27.

CHƢƠNG 2: GIỚI THIỆU CÔNG NGHỆ WEBSPHERE MQ VÀ ỨNG
DỤNG TRONG HỆ THỐNG KẾT NỐI THANH TOÁN
2.1 Giới thiệu công nghệ WebSphere MQ
2.1.1 Các đối tƣợng cơ bản của Websphere MQ
Trong bối cảnh cạnh tranh ngày càng khốc liệt, cùng với việc Việt Nam gia

nhập WTO và phải đối mặt những đối thủ khổng lồ với hệ thống thông tin tích hợp
hiện đại và chính xác thì nhu cầu tích hợp dữ liệu quản lý doanh nghiệp càng bức
thiết cho bất cứ doanh nghiệp nào muốn đứng vững. IBM được coi là một trong
những công ty tiên phong trong việc xây dựng các sản phẩm hỗ trợ tích hợp doanh
nghiệp, và điển hình phải nói đến bộ sản phẩm tích hợp ứng dụng IBM WebSphere.
Sản phẩm WebSphere Message Queue (hay thường gọi là Websphere MQ) là lựa
chọn đầu tiên trong quá trình xây dựng kiến trúc tích hợp.
Websphere MQ bao gồm các đối tượng thành phần cơ bản sau đây[7]:
Message:
Message có thể là tập hợp các dữ liệu nhị phân hoặc ký tự (ASCII hoặc
EBCDIC) được sử dụng trong quá trình giao tiếp giữa các chương trình để chuyển
đổi dữ liệu. Mỗi message bao gồm 2 phần: Message header và Data. Message header
chứa các thông tin điều khiển như Message ID, địa chỉ gửi message đến…
Queue Manager:
Queue manager là một chương trình cung cấp các dịch vụ về message cho các
ứng dụng. Các ứng dụng dùng Message Queue Interface (MQI) có thể đặt và lấy
message từ các queue. Queue manager đảm bảo các message được gửi đúng tới một
queue hoặc được định tuyến để chuyển tới một queue manager khác.
Các Queue manager là các thành phần cơ bản trong WebSphere MQ. Queue
manager chứa các queue và các channel để kết nối các queue manager với nhau. Mỗi
máy tính chứa các queue đều cần phải có một Queue Manager. Mỗi Queue Manager
có một tên duy nhất, có nhiệm vụ quản trị các queue được tạo trong nó (các local
queue). Trong một Queue Manager, mỗi queue có một tên, tên queue cùng với queue
manager của nó sẽ cung cấp một địa chỉ đích duy nhất cho các message.
Queues:
Là nơi chứa các message cho đến khi một chương trình lấy các message đó.
Chương trình gửi sẽ đặt message vào một queue tương ứng và message sẽ được
một chương trình khác lấy ra từ queue đó. Mỗi queue có thể lưu giữ một dung
lượng và số lượng giới hạn các message, đồng thời cũng giới hạn độ dài của mỗi
message.

Footer Page 16 of 27.


Header Page 17 of 27.

ộ

ố Queue cơ bả

ụ

-

ộ là nơi ữ ệu được lưu trữ để

ờ ử lý.

ỗi Queue manager, local queue lưu trữ các message mà
ận đượ

ề

ueue, nơi message được lưu trữ
đi và lưu trữ thành công tạ

là 1 loại đặ

ủ

ới khi chúng có thể đượ

Đặc trưng cho mộ

manager khác, nó định nghĩa mộ
khác. Để ử

ệ

ề

ở

ừ

-

ả

ộ

ớ
ử

ủ
ộ

ạ
ộ

ộ

ở

ải có một định nghĩa về

ủ

ận trong nó và đó chính là remote queue.
ỗi queue manager thường có mộ

queue (đượ

ế đến như mộ

ứa các message không đượ

phân phối), queue này thường được định nghĩa cùng vớ
manager. Message được đưa vào queue này nếu nó không thể đượ
phân phố ới đích đã đượ
-

ỉ

Cluster queue: là một queue được chia sẻ trong một cluster mà tất cả các
queue manager trong cluster có thể đặt và lấy message từ queue sử dụng
cluster channel.

Các message đượ

ề

ả

ữa các queue manager thông qua các

kênh (channel). Mỗi channel là một con đường để liên kế
các queue manager, nó có thể
lượ

ấ

ỳ các queue được đặ ạ

các queue manager đích.
Footer Page 17 of 27.

ền thông giữ

ền các message đã được định trướ

ớ

ố

ở

ấ

ỳ

ặ

ố lượ


Header Page 18 of 27.

Để
ụ

ột message có thể ử ớ

ộ

ộ

ở

ả định nghĩa một transmission queue và mộ
ở xa đó. Cuố

ỗi channel có mộ

kênh gửi hay kênh nhậ
ạ

ấ

ột channel đơn giả

ụ

ớ

ệu phân tách để

ết đó là

ồm có channel gửi (định nghĩa

ộ) và channel nhận (đị h nghĩa tạ

ở

xa), hai định nghĩa này có cùng tên (tối đa 20 ký tự) và cùng nhau tạo thành
định nghĩa cho mỗ
ỗi channel có một hướ
ồ

ả

ấ

ả ời) đượ

ế ứ

ả ề ừ

ụng yêu cầu các message

ộ

ở xa thì cầ

ải có một channel khác, channel này được định nghĩa để
ngượ

ạ

ộ
ổng đặ

đượ
ệ

ế
ừ

ệ

ề

ữa các queue manager.

ỗi queue manager dùng mộ

ộ

ự

ợ
ấ

ệ
ớ

ạ

ều channel để

ộ

ẽ ử

ặ

ửi và nhậ
ậ

ữ ệ

ỗi sending channel có một đích đã được định nghĩa và
ộ

ộ

ỳ
ậ

ặ

ẽ

ậ

ữ

nào có cùng sending channel. Khi receiving
ột message, nó kiểm tra xem queue manager và queue nào

được định trướ
ử ụ

ại channel khác nhau:

: là một liên kế



ền thông không trự

ế

ử ụng các message channel để

ữ
ề

ữa các qu

Message channel có thể là một trong các loạ
-

Sender channel là một message channel mà queue
ử ụng để ử

Footer Page 18 of 27.

ới queue manager khác. Để ử


Header Page 19 of 27.

message dùng message channel, trong queue manager khác cũng
ả ạ

ộ

ceiver channel cùng tên vớ

ột server channel là một message channel mà queue

-

ử ụng để ử

ới queue manager khác. Để ử

ử ụng server channel trong queue manager khác cầ
ả ạ

ộ

cùng tên vớ

Có thể

ử ụng server channel cùng requester channel.
receiver channel là một message channel mà queue

-

ử ụng để
ậ

ậ

ừ queue manager khác. Để

ằng cách sử ụng receiver channel thì cầ

trong queue manager khác mộ

ả ạ

ặc server channel cùng

tên với receiver channel này.
ột requester channel là một message channel mà

-

queue manager dùng để ử

ới queue manager khác. Để

ử

ầ

manager khác mộ

ặ

ả

ạ

ộ

sender channel định nghĩa đầ

ạ
ề

ớ

ử

ủ

ộ

ột cluster queue manager có thể ửi thông
ột trong các nơi chứ

ụng để thông báo nơi chứ

ủ

ấ

ủa queue manager (ví dụ

ệ

ổ

sender channel cũng dùng để

sender đượ

ỳ ự thay đổi nào tớ
ặ
ề

ỷ ỏ
ả

ử

ạng thái
ộ
ản thân

toàn bộ nơi chứa các queue manager cũng có các cluster sender
ỏ ới nhau để

Footer Page 19 of 27.

ền các thay đổ

ạng thái cluster cho


Header Page 20 of 27.

receiver channel định nghĩa đầ

ộ

ạ

ậ

ủ

ột cluster queue manager có thể

ậ

ừ các queue manager khác trong mộ
receiver channel mang thông tin về cluster đã được định trướ
nơi chứ

ằ

ệc định nghĩa cluster receiver channel, queue

ỉ ra cho các cluster queue manager khác rằng nó đã
ẵn sàng cho việ

ậ

: để định hướng và kế



ố

ộ ứ

queue manager trên máy chủ
ề

ải các lờ

ụ

ớ

ộ

ử ụng MQI channel để

ọi và đáp MQI giữa các MQI client và queue manager.

MQI channel có thể là mộ

ạ
Server connection channel là mộ

định hướ

ử ụng để ế

ố

ộ

ớ

ộ

ớ

ộ

Server connection channel là đầ
ủ

Client connection channel là mộ

định hướ

ử ụng để ế

ố

ộ

Websphere MQ server. Websphere MQ Explorer cũng sử
client connection để

ế

ố

là đầ
ệ
queue manager và cầ

Footer Page 20 of 27.

ới các queue manager ở
ủ

ố

ụ

ẽ ạ

ạ

ộ

ột file trong máy tính chứ

ải copy file này tới máy Websphere MQ


Header Page 21 of 27.

Listener là một Websphere MQ process để “nghe” các kế
ỗi đối tượ

ể

ến trình “nghe”, tuy nhiên nế
line thì listener không đượ
Do đó để

ố ớ

ể

ến trình “nghe” này đượ
ễ

ễ

ộ

ừ

ở

ản lý tiến trình “nghe” từ

ầ

ả ạo đối tượng listener trong Websphere MQ Explorer và khi start đối tượ
ến trình “nghe” sẽ ắt đầu. Listener có
ức năng phát hiệ

ế

ố ừ các channel và quản lý kế

channel đế
ế

ố ạ

ố ừ

ạ
ộ

ổng đặ

ệt đượ

ỉ

ẽ “nghe” các
ấu hình.

Queue Manager Cluster:
Khi các queue được thêm vào hoặc bớt đi, việc quản trị việc truyền message
trở nên khắt khe, có nhiều ngoại lệ hơn. Bằng việc dùng Queue Manager Cluster
(QMC), gánh nặng quản trị có thể giảm. Queue Manager Cluster giống như một hộp
đen chứa mọi Queue Manager, các chương trình bên ngoài có thể truy cập đến
Queue Manager Cluster bằng WebSphere MQ Client.
Các Queue manager trong cùng một QMC có thể trao đổi message mà không
cần phải định nghĩa Remote Queue, Transmission Queue, Message Channel.
Thông tin về tất cả các queue trong một cluster sẽ được lưu trong Cluster Full
Repository. Khi một Queue manager muốn gửi message tới một queue trong cluster,
nó sẽ sử dụng thông tin về vị trí của queue đích nhờ cluster full repository. Cluster
Channel sẽ tự động được tạo ra.
QMC giúp giả
ửi đế
ả

ả

ữa các chương trình: Nế

ố lượng message đượ

ột queue trong cluster vượt quá khả năng xử ý của queue đó, để

ải, ta có thể định nghĩa mộ

ới có cùng tên với queue đó nhưng ở

Queue Manager khác trong cluster. Khi message đượ

ử ớ

ột queue mà

được định nghĩa ở 2 Queue manager khác nhau, WebSphere MQ sẽ ự độ
làm công việ

ả

ả

ằ

ệc phân phối message đề

ỗ

2.1.2 Đặc trƣng của Websphere MQ và cơ chế truyền tải message
Đảm bảo phân phối message:
Footer Page 21 of 27.

Header Page 22 of 27.

WebSphere MQ cung cấp sự đảm bảo phân phối message cùng lúc qua nhiều hệ
nền khác nhau và đảm bảo rằng message không bao giờ bị mất nếu MQ đã được cấu
hình. Hơn nữa WebSphere MQ cho phép truyền dữ liệu giữa các hệ thống với kiến
trúc và giao thức khác nhau.[6]
Không phụ thuộc thời gian và phạm vi ứng dụng:
MQ cung cấp cho các trình thiết kế ứng dụng một cơ chế kiến trúc không phụ
thuộc thời gian. Message có thể được gửi từ ứng dụng này tới ứng dụng khác ngay
cả khi các ứng dụng này không cùng chạy tại một thời điểm. Nếu một ứng dụng
nhận message không chạy khi ứng dụng khác gửi message đến thì Queue manager sẽ
giữ message này cho tới khi ứng dụng nhận hỏi đến. Trật tự sắp xếp các mesage
trong queue mặc định là FIFO.[6]
Message có thể được truyền giữa các máy và các ứng dụng trong một mạng.
Một queue có thể chứa các message gửi từ các ứng dụng trên cùng một máy hoặc
các máy khác nhau. Đồng thời các ứng dụng trên cùng một máy hoặc các máy khác
nhau cũng có thể lấy message ra từ một queue.[6]
Giao tiếp trong phạm vi rộng lớn:
WebSphere MQ cung cấp một cơ chế mềm dẻo cho việc truyền thông điệp
trong toàn bộ hệ thống. Sự mềm dẻo của WebSphere MQ cũng cho phép truyền thông
điệp giữa các ứng dụng trong và ngoài hệ thống của doanh nghiệp.[6]
Trong suốt đối với vị trí của queue:
Một chương trình có thể gửi các message tới một queue ở xa mà không cần
biết vị trí của nó miễn là queue ở xa đó đã được định nghĩa trong Queue Manager
cục bộ. Remote Queue Definition lưu địa chỉ của queue đích và transmission queue.
Queue Manager cục bộ dùng các thông tin này định vị được nơi gửi message đến.
Bằng việc dùng Remote Queue Definition, Message Channel, Transmission
Queue, mọi chương trình đều có thể gửi message tới mọi queue mà không cần quan
tâm tới vị trí của queue đó.
Giao tiếp với các Queue Manager cục bộ

Các chương trình giao tiếp với các Queue Manager cục bộ thông qua một giao
diện lập trình ứng dụng (API) như WebSphere MQ Message Queue Interface (MQI)
hoặc Java Message Service (JMS)
Chương trình tạo ra message và gửi nó tới Queue manager của nó bằng việc
gọi các hàm API. Nếu queue đích là local queue thì QM sẽ gửi trực tiếp message tới
đó. Thông qua các lời gọi API, chương trình cũng có thể lấy các message từ local
queue.
Giao tiếp bằng WebSphere MQ Clients
Footer Page 22 of 27.


Header Page 23 of 27.

Nếu một chương trình không có Queue Manager trên cùng một máy, ta có thể
sử dụng việc gọi các hàm API thông qua WebSphere MQ Client. Client sẽ giao tiếp
với queue manager ở xa bằng một client connection. Điều này cho phép chương
trình có thể tương tác với Queue Manager ở xa giống như với Queue Manager cục
bộ.
Cơ chế

ề

ả

ớ

ộ

ở

Nếu một chương trình muốn gửi message tới một queue ở xa (một queue
thuộc queue manager khác) thì cần phải có các điều kiện sau:
-

Một Message Channel (dùng để kết nối giữa Queue Manager này tới một Queue
Manager ở xa khác)

-

Một transmission queue dùng để lưu trữ message nếu message channel chưa sẵn
sàng.

Queue Manager sẽ đặt các message vào trong transmission Queue trước khi nó
được gửi tới Queue Manager đích ở xa.
Để

ề

ữ ệ

ớ

ột queue trong queue manager khác, message

được đặt trong remote queue. Message đượ
transmission queue lưu trữ ạ

ời cùng vớ
ẽ đượ

ệ

ote queue thông qua

ộ

ại nơi đặ

ền thông qua remote channel. Nế

ền thành công, message sẽ đượ

nơi nhậ

ử ớ

ậ

ể
ẽ

ỏ

ạ

ểm tra message để

message đó là cho chính nó hay được yêu cầ

ể

manager khác. Nếu nó là đích thì queue được yêu cầ

ẽ đượ

queue này tồ

ếu không message sẽ

ại thì message sẽ được đặt vào đó

ế

ớ

ết đị
ộ

ểm tra và nế

được đặt vào dead letter queue.[6]
Tạo và quản trị các đối tƣợng WebSphere MQ[8]
Các đối tượng trong WebSphere MQ (bao gồm các queue và các channel) có thể
được quản trị bằng việc sử dụng:
-

WebSphere MQ Explorer: Giao diện đồ họa, dễ sử dụng

-

WebSphere MQ Script Command (MQSC): Giao diện dòng lệnh

2.2 Công nghệ Web Service với WebSphere MQ
Footer Page 23 of 27.


Header Page 24 of 27.

2.2.1 Cơ bản về Web Service
a. Đặc trƣng của Web Service
ị

ụ Web) là một cách chuẩn để tích hợp các ứ

trên nề

Giá trị cơ bả

trên việ

ấp các phương thứ

ống đóng gói và hệ

ố

ế

ẩ

ủ

ự

ệ

ập đố

ững môi trường khác nhau, vớ

chúng sao cho các ứ
ữ

ị

ớ

ả

ững ngôn ngữ ập trình khác nhau.

ụng khác dễ dàng nhìn thấy và có thể

ụ mà nó thự

ện, đồ

ồm các mô đun độ

ệp và bản thân nó đượ

ậ

ực thi trên server.

UDDI Registry
Service
Broker
Publish
WSDL + UDDI

Browser
SOAP

Service
Provider
Web service

ập đế

ời có thể yêu cầu thông tin từ

b. Mô hình kiến trúc Web Service[1]

Footer Page 24 of 27.

ệ

ạo nên bằng cách lấy các chức năng và đóng gói

Service khác. Mộ
ủ

ớ

ừ

Web Service cho phép client và server tương tác đượ

ột Web Service đượ

ụ

Find
WSDL + UDDI

Browser
SOAP
Bind, invoke

SOAP

Service
Requestor
Client
Application

ạt độ

Header Page 25 of 27.

Hình 2.2-1: Mô hình kiến trúc Web Service

- Service provider[1]: lưu trữ (hoặc tạo nên) các thành phần phần mềm có thể sử
dụng mạng để thực thi Web Service và cài đặt chúng tại máy chủ ứng dụng.
Service provider công bố sự mô tả (sử dụng Web Services Description
Language) của Web Service tới các service broker.
- Service requestor[1]: Viết ứng dụng client gọi đến web service. Các Requestor
đầu tiên phải tìm và gọi ra các mô tả dịch vụ cho yêu cầu Web Service từ
service broker sau đó nối kết với Web Service trước khi gọi các thao tác trong
Web Service. Giao thức thường được sử dụng để trao đổi thông tin là giao thức
truy cập đối tượng đơn giản SOAP (Simple Object Access Protocol). SOAP là
giao thức để gọi một Web Service, đây cũng là giao thức có thể được sử dụng
để xuất bản và lưu trữ web service trong UDDI Registry (Universal Description
Discovery and Integration).
- Service broker (hay Service Registry)[1]: chạy UDDI Registry, nơi chứa các mô
tả dịch vụ được xuất bản bởi service provider. Service requestor tìm kiếm
những nơi chứa các service và thông tin kết nối.
Ba hoạt động điều khiển luồng và hành vi của mô hình Web Service là:
- Publish[1]: Trình cung cấp của Web Service tạo ra ngôn ngữ mô tả dịch vụ web
(Web Services Description Language WSDL). WSDL bao gồm các định nghĩa
kiểu dữ liệu, thông điệp vào ra, các hoạt động. Hoạt động publish là quá trình
đánh dấu WSDL đã sẵn sàng cho các dịch vụ tìm kiếm có thể tìm và kết nối tới
Web Service thông qua WSDL.
- Find[1]: Service requestor cần thực hiện một hoạt động tìm kiếm để phát hiện
và gọi ra WSDL để xuất bản các dịch vụ. Hoạt động tìm kiếm có thể được
thực hiện trực tiếp hoặc thông qua các yêu cầu tới service registry (như UDDI).
- Bind[1]: Trước khi gọi hoặc khởi tạo một yêu cầu Web Service, service
requestor đánh dấu việc sử dụng thông tin kết nối từ việc gọi WSDL tới việc

kết nối với Web Service.

Footer Page 25 of 27.