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

1
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 6

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 8

1.1 Nhu cầu thực tiễn 8
1.2 Hiện trạng các giải pháp kết nối thanh toán 9
1.3 Giải pháp đề xuất của luận văn 11
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 13

2.1 Giới thiệu công nghệ WebSphere MQ 13
2.1.1 Các đối tượng cơ bản của Websphere MQ 13
2.1.2 Đặc trưng của Websphere MQ và cơ chế truyền tải message 17
2.2 Công nghệ Web Service với WebSphere MQ 19
2.2.1 Cơ bản về Web Service 19
2.2.2 Web Service và Websphere MQ 21
2.3. An toàn bảo mật thông tin qua SSL với Websphere MQ và Web Service 26

2.3.1. Vấn đề an toàn bảo mật thông tin qua SSL với Web service 26
2.3.2 SSL và Websphere MQ 26
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 29

3.1. Mô tả hoạt động nghiệp vụ 29
3.1.1 Một số khái niệm 29
3.1.2 Mô tả nghiệp vụ: 29
3.1.3 Các yêu cầu của hệ thống 31
3.2. Xây dựng mô hình hệ thống 32
3.2.1 Mô hình kết nối 32
3.2.2 Cấu hình WebSphere MQ 34
3.2.3 Cơ chế hoạt động 40
3.3. Phân tích thiết kế hệ thống 50
3.3.1 Mô hình phân tích 50
3.3.2 Phát triển mô hình ca sử dụng 54
3.3.3 Phân tích một số ca sử dụng điển hình của hệ thống 61
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 69
Tài liệu tham khảo 72

2
Danh mục các thuật ngữ và các từ viết tắt
Từ/cụm từ Ý nghĩa
Authentication Xác thực
Bank Gateway
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
Channel Kênh (dùng để truyền tải message)
CipherSpec Thông số mã hóa và xác thực
CipherSuite Bộ mật mã

Client/Server Máy khách/ Máy chủ
CoreBanking Lõi ngân hàng
Dead-letter queue
Hàng đợi chứa các message không được phân
phối
Encryption Mã hoá
HTTP (Hyper Text Transport
Protocol) Giao thức vận chuyển siêu văn bản
Listener
Một tiến trình của WebSphere MQ để "nghe"
các kết nối
Local queue Queue cục bộ
Message Thông điệp
MQI (Message Queue Interface) Giao diện quản lý các hàng đợi
QM (Queue Manager) Quản trị các hàng đợi (queue)
QMC (Queue Manager Cluster) Bó cụm các queue manager
Queue Hàng đợi, nơi chứa các thông điệp
Receiver Bên nhận
Remote queue Queue đại diện cho một queue khác ở xa
Request Yêu cầu
Response Đáp ứng
Sender Bên gửi
SOAP (Simple Object Access
Protocol) Giao thức truy cập đối tượng đơn giản
SSL (Secure Sockets Layer)
Giao thức truyền đạt thông tin một cách an
toàn qua mạng
TA (Trading Account)
Tài khoản chuyên dùng cho hoạt động thanh
toán chứng khoán

Transmission queue Queue truyền tải
UDDI (Universal Description
Discovery and Integration) Hợp nhất và phát hiện các mô tả toàn thể
URI (Universal Resource Định danh tài nguyên toàn thể

3
Indicator or Identifier)
Web Service Dịch vụ web
WebSphere MQ (WebSphere
Message Queue) Một công nghệ truyền tải thông điệp của IBM
Websphere MQ Explorer
Trình quản lý và cấu hình WebSphere MQ một
cách trực quan.
WSDL (Web Services Description
Language) Ngôn ngữ mô tả dịch vụ web
XML (Extensible Markup
Language) Ngôn ngữ đánh dấu mở rộng

4
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ủ 36
Bảng 3.3-1: Các chức năng của hệ thống 50
Bảng 3.3-2: Từ điển dữ liệu của hệ thống 54
Bảng 3.3-3: Các tác nhân và vai trò trong hệ thống 55
Bảng 3.3-4: Mô tả ca sử dụng cập nhật CTCK 57
Bảng 3.3-5: Mô tả ca sử dụng cập nhật tài khoản TA 58
Bảng 3.3-6: Mô tả ca sử dụng vấn tin tài khoản TA 58
Bảng 3.3-7: Mô tả ca sử dụng phong toả tài khoản TA 59
B
ảng 3.3-8: Mô tả ca sử dụng giải phong toả tài khoản TA 59

Bảng 3.3-9: Mô tả ca sử dụng Chuyển tiền 60
Bảng 3.3-10: Mô tả ca sử dụng tổng hợp kết quả giao dịch 61
Bảng 3.3-11: Mô tả ca sử dụng sao kê chi tiết tài khoản TA 61

5
Danh mục các hình vẽ
Hình 2.2-1: Mô hình kiến trúc Web Service 20
Hình 2.2-2 Kiến trúc phân tầng của Web Service 21
Hình 2.2-3: Web Services qua HTTP 22
Hình 2.2-4: Web Services qua WebSphere MQ 22
Hình 2.2-5: Web Service client sử dụng proxy 23
Hình 3.2-1: Mô hình Hệ thống kết nối thanh toán 33
Hình 3.2-2: Cấu hình Remote queue Q.RMT.BR.GW 36
Hình 3.2-3: Cấu hình Remote queue Q.RMT.GW.BR 37
Hình 3.2-4: Cấu hình transmision queue Q.XMIT.BR 37
Hình 3.2-5: Cấu hình transmision queue Q.XMIT.GW.BR 38
Hình 3.2-6: Các queue của queue manager GW 38
Hình 3.2-7: Cấu hình channel CH.BR.GW 39
Hình 3.2-8: Các channel của queue manager GW 39
Hình 3.2-9: Cấu hình channel CH.BR.GW 39
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 40
Hình 3.2-11: Đường đi của message theo chế độ kết nối server. 42
Hình 3.2-12: Triển khai WebSphere MQ transport for SOAP 43
Hình 3.3-1: Sơ đồ tiến trình hoạt động kết nối thanh toán 51
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án 52
Hình 3.3-3: Mô hình ca sử dụng mức tổng thể của hệ thống 56
Hình 3.3-4: Biểu đồ tuần tự hệ thống Đăng ký tài khoản TA 62
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 63

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 63
Hình 3.3-7: Biểu đồ tuần tự hệ thống Phong toả tài khoả
n TA 64
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 64
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 65
Hình 3.3-10: Biểu đồ tuần tự hệ thống Giải phong toả tài khoản TA 65
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 66
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. 66
Hình 3.3-13: Biểu đồ tu
ần tự hệ thống Chuyển tiền 67
Hình 3.3-14: Biểu đồ lớp phân tích thực thi ca sử dụng Chuyển tiền 67
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 68

6
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 4 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à các

7
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.
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 Message Queue của IBM,
Công nghệ web service và việc ứng dụng công nghệ web service và 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
Chương 4: Đá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 các thuật ngữ, các 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.


8
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.

9
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. 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.

Ngoài việc đủ nhân lực, cơ sở vật 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.

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ư.

10
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 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

11
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
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 của hãng IBM. 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.

12
- 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.
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 đó (mesaging
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.


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
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:
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 1
queue hoặc được định tuyến để chuyển tới 1 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.

14
Một số Queue cơ bản:
- Local queue (queue cục bộ): là nơi dữ liệu được lưu trữ để chờ xử lý. Trong
mỗi Queue manager, local queue lưu trữ các message mà queue manager
nhận được.
- Transmission queue (queue truyền tải): là 1 loại đặc biệt của local queue,

nơi message được lưu trữ cho tới khi chúng có thể được truyền đi và lưu trữ
thành công tại queue manager ở xa.
- Remote queue (queue từ xa): Đặ
c trưng cho một queue tại Queue manager
khác, nó định nghĩa một local queue của một queue manager khác. Để gửi
một message tới một queue trong một queue manager ở xa, queue manager
gửi phải có một định nghĩa về local queue của queue manager nhận trong nó
và đó chính là remote queue.
- Dead-letter queue: Mỗi queue manager thường có một dead-letter queue
(được biết đến như một queue chứa các message không được phân phối),
queue này thường được định nghĩa cùng với queue manager. Message được
đưa vào queue này nếu nó không thể đượ
c phân phối tới đích đã được chỉ ra.
- Alias queue: là một định nghĩa bổ sung của một queue có sẵn chứ thực sự
không phải là queue. Alias queue tham chiếu đến một local queue nhưng tên
của alias queue khác tên của local queue, do đó khi các local queue có sự
thay đổi thì ứng dụng sử dụng nó không cần thay đổi mà chỉ cần tạo lại một
alias queue để trỏ vào local queue mới được thay đổi đó.
- Model queue: là một m
ẫu cho các queue mà queue manager tự động tạo ra
khi cần thiết. Khi một ứng dụng có gắng đạt message vào một model queue,
queue manager sẽ tự tạo ra một local queue có cùng tên với model queue.
Queue tạo bằng cách này có thể chỉ là tạm thời hoặc vĩnh viễn.
- 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.
Channel:
Các message được truyền tải giữa các queue manager thông qua các kênh
(channel). Mỗt channel là một con
đường để liên kết truyền thông giữa các queue

manager, nó có thể truyền các message đã được định trước với số lượng bất kỳ
các queue được đặt tại queue manager ở xa hoặc số lượng bất kỳ các queue
manager đích.
Để một message có thể gửi tới một queue manager ở xa, queue manager cục bộ
phải định nghĩa một transmission queue và một channel tới queue manager ở xa
đó. Cuối mỗi channel có một dấu hiệu phân tách để
biết đó là kênh gửi hay kênh

15
nhận. Một channel đơn giản gồm có channel gửi (định nghĩa tại queue manager
cục bộ) và channel nhận (định nghĩa tại queue manager ở 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.
Mỗi channel có một hướng duy nhất, nếu ứng dụng yêu cầu các message (bao
gồm cả message trả lời) được trả về từ một queue manager ở xa thì cần phải có
một channel khác, channel này được đị
nh nghĩa để thực hiện chiều ngược lại giữa
các queue manager.
Mỗi queue manager dùng một hoặc nhiều channel để gửi và nhận message. Trong
một mạng TCP/IP, một channel sẽ gửi hoặc nhận dữ liệu qua một cổng đặc biệt.
Mỗi sending channel có một đích đã được định nghĩa và được kết hợp với một
transmission queue. Một receiving channel sẽ nhận dữ liệu từ bất kỳ
Queue
manager nào có cùng sending channel. Khi receiving channel nhận một message,
nó kiểm tra xem queue manager và queue nào được định trước. Khi đường truyền
bị lỗi, MQ có thể tự động kết nối lại khi lỗi đã được sửa.
WebSphere MQ sử dụng 2 loại channel khác nhau:
+ Message channel: là một liên kết truyền thông không trực tiếp giữa 2 queue
manager. Websphere MQ sử dụng các message channel để truyền message
giữa các queue manager.
Message channel có thể là một trong các loại sau:

- Sender: Sender channel là một message channel mà queue manager
sử dụng để g
ửi message tới queue manager khác. Để gửi message
dùng message channel, trong queue manager khác cũng phải tạo một
receiver channel cùng tên với sender channel. Cũng có thể sử dụng
sender channels cùng với requester channels khi thi hành cơ chế
"callback".
- Server: một server channel là một message channel mà queue
manager sử dụng để gửi message tới queue manager khác. Để gửi
message sử dụng server channel trong queue manager khác cần phải
tạo một receiver channel cùng tên với server channel. Có thể sử dụng
server channel cùng requester channel.
- Receiver: receiver channel là một message channel mà queue
manager sử dụng để nhận message từ queue manager khác.
Để nhận
message bằng cách sử dụng receiver channel thì cần phải tạo trong
queue manager khác một sender hoặc server channel cùng tên với
receiver channel này.
- Requester: Một requeser channel là một message channel mà queue
manager dùng để gửi message tới queue manager khác. Để gửi

16
message qua requester channel cần phải tạo trong queue manager
khác một sender channel (nếu đang thi hành cơ chế callback), hoặc
một server channel.
- Cluster-sender: Cluster-sender channel định nghĩa đầu gửi của một
channel trong phạm vi một cluster queue manager có thể gửi thông tin
về cluster tới một trong các nơi chứa. Cluster-sender được sử dụng để
thông báo nơi chứa của bất kỳ sự thay đổi nào tới trạng thái của
queue manager (ví dụ việc bổ sung hoặc huỷ bỏ m

ột queue). Cluster-
sender channel cũng dùng để truyền tải message. Bản thân toàn bộ
nơi chứa các queue manager cũng có các cluster sender channel trỏ
tới nhau để truyền các thay đổi trạng thái cluster cho nhau.
- Cluster-receiver: Cluster-receiver channel định nghĩa đầu nhận của
một channel trong phạm vi một cluster queue manager có thể nhận
message từ các queue manager khác trong một cluster. Cluster-
receiver channel mang thông tin về cluster đã được định trước cho
nơi chứa. Bằng việc định nghĩa cluster receiver channel, queue
manager chỉ ra cho các cluster queue manager khác rằng nó đã sẵn
sàng cho việc nh
ận message.
+ MQI channel: để định hướng và kết nối một ứng dụng (MQI client) tới một
queue manager trên máy chủ. Websphere MQ sử dụng MQI channel để
truyền tải các lời gọi và đáp MQI giữa các MQI client và queue manager.
MQI channel có thể là một trong 2 loại:
- Server connection: Server connection channel là một MQI channel
định hướng sử dụng để kết nối một Websphere MQ client tới một
Websphere MQ server. Server connection channel là đầu server của
channel.
- Client connection: Client connection channel là một MQI channel
định hướng sử dụng
để kết nối một Websphere MQ client tới một
Websphere MQ server. Websphere MQ Explorer cũng sử dụng client
connection để kết nối tới các queue manager ở xa. Client connection
channel là đầu client của channel. Khi ta tạo một client connection
channel hệ thống sẽ tạo ra một file trong máy tính chứa queue
manager và cần phải copy file này tới máy Websphere MQ Client.
Listener
Listener là một Websphere MQ process để “nghe” các kết nối tới queue manager.

Mỗi đối tượng listener trong Websphere MQ Explorer biểu diễn một tiến trình
“nghe”, tuy nhiên nếu tiến trình “nghe” này được start từ command line thì
listener không được biểu di
ễn bởi listener object trong Websphere MQ Explorer.

17
Do đó để quản lý tiến trình “nghe” từ Websphere MQ Explorer cần phải tạo đối
tượng listener trong Websphere MQ Explorer và khi start đối tượng listener trong
Websphere MQ Explorer, tiến trình “nghe” sẽ bắt đầu. Listener có chức năng phát
hiện kết nối từ các channel và quản lý kết nối từ sending channel đến receiving
channel. Trong mạng TCP/IP, Listener sẽ “nghe” các kết nối tại một cổng đặc
biệt được chỉ ra khi 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 Definition, 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 QM 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ảm tải giữa các chương trình: Nếu số lượng message được gửi đến
một queue trong cluster vượt quá khả năng xử lý của queue đó, để giảm tải, ta có
thể định nghĩa một queue mới có cùng tên với queue đó nhưng ở Queue Manager

khác trong cluster. Khi message được gửi tới một queue mà đượ
c định nghĩa ở 2
Queue manager khác nhau, WebSphere MQ sẽ tự động làm công việc giảm tải
bằng việc phân phối message đều cho mỗi queue.
2.1.2 Đặc trưng của Websphere MQ và cơ chế truyền tải message
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.
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ục
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.

18
Messaging topologies: 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.
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.
Trong suốt đối với vị trí của queue (Remote Queue Definition):
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
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 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ế truyền tải message tới m
ột queue ở xa
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)

19
- 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.
Để truyền dữ liệu tới một queue trong queue manager khác, message được đặt
trong remote queue. Một remote queue được gửi thông qua transmission queue
lưu trữ tạm thời cùng với một channel. Tại nơi đặt message trong remote queue,
message sẽ được truyền thông qua remote channel. Nếu việc truyền thành công,
message sẽ được chuyển khỏi transmission queue. Tại n
ơi nhận message, queue
manager nhận sẽ kiểm tra message để quyết định message đó là cho chính nó hay
được yêu cầu chuyển tiếp tới một queue manager khác. Nếu nó là đích thì queue
được yêu cầu sẽ được kiểm tra và nếu queue này tồn tại thì message sẽ được đặt
vào đó, nếu không message sẽ được đặt vào dead letter queue.
Tạo và quản trị các WebSphere MQ objects
Các đối tượng trongWebSphere 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
2.2.1 Cơ bản về Web Service
a. Đặc trưng của Web Service
Web Service (dịch vụ Web) là một cách chuẩn để tích hợp các ứng dụng trên nền
web (Web-based applications). Giá trị cơ bản của Web Service dựa trên việc cung
cấp các phương thức theo chuẩn trong việc truy nhập đối với hệ thống đóng gói và
hệ thống kế thừa.
Web Service cho phép client và server tương tác được với nhau ngay cả trong
những môi trường khác nhau, với những ngôn ngữ lập trình khác nhau. Ví dụ, đặt
Web server cho ứng dụ
ng trên một máy chủ chạy hệ điều hành Linux trong khi

người dùng sử dụng máy tính chạy hệ điều hành Windows, ứng dụng vẫn có thể
chạy và xử lý bình thường mà không cần thêm yêu cầu đặc biệt để tương thích
giữa hai hệ điều hành này.
Một Web Service được tạo nên bằng cách lấy các chức năng và đóng gói chúng
sao cho các ứng dụng khác dễ dàng nhìn thấy và có thể truy cập đến những dịch
v
ụ mà nó thực hiện, đồng thời có thể yêu cầu thông tin từ Web Service khác. Một
Web Service bao gồm các mô đun độc lập cho hoạt động của doanh nghiệp và bản
thân nó được thực thi trên server.

20
b. Mô hình kiến trúc Web Service











Hình 2.2-1: Mô hình kiến trúc Web Service
- Service provider: 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: 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.
- Service broker (hay Service Registry): 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: 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: Service requestor cần thực hiện một hoạt động tìm kiếm để phát hiện
Service
Provider
Service
Broker
Service
Requestor
Client
Application
Bind, invoke
Publish
WSDL + UDDI

UDDI Re
g
istr
y
Find
WSDL + UDDI

Web service
SOAP
Browser
SOAP
Browser
SOAP

21
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: 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.
Kiến trúc sâu hơn của Web Service được mô tả trong hình d
ưới:
Web Service
UDDI (Discovery)
WSDL (description)
SOAP (remote service call)
HTTP (transport application protocol)
TCP/IP (transport protocol)
Hình 2.2-2 Kiến trúc phân tầng của Web Service

Trong đó, tầng giao thức tương tác dịch vụ (Service Communication Protocol) với
công nghệ chuẩn là SOAP. SOAP là giao thức nằm giữa tầng vận chuyển và tầng
mô tả thông tin về dịch vụ, cho phép người dùng triệu gọi một dịch vụ từ xa thông
qua một thông điệp XML. Ngoài ra, để các dịch vụ có tính an toàn, toàn vẹn và
bảo mật thông tin, trong kiến trúc dịch vụ Web, chúng ta có thêm các tầng Policy,
Security, Transaction, Management.
2.2.2 Web Service và Websphere MQ
Websphere MQ cung cấp sự truyền tải thông điệp giữa các ứng dụng và Web
Service, đồng thời đưa ra khả năng kết nối linh hoạt, tin cậy. Websphere MQ dùng
việc xếp hàng và các công cụ trợ giúp giao dịch để duy trì tính toàn vẹn của thông
điệp khi di chuyển trong mạng. Message được phân phối chính xác làm giảm khả
năng mất dữ liệu khi dịch vụ hoặc mạng bị lỗi.
Websphere MQ tích hợp cả sự hỗ tr
ợ cho việc truyền message thông qua SOAP,
hỗ trợ việc thực thi .NET SOAP. Truyền thông trong Websphere MQ được bảo
đảm thông qua việc sử dụng SSL (Secure Sockets Layer). Kỹ thuật Cluster cũng
được sử dụng trong Websphere MQ để hỗ trợ cho tính sẵn sàng cao và khả năng
cân bằng tải.
2.2.2.1 SOAP qua Websphere MQ
a. SOAP qua HTTP
Hình dưới đây minh hoạ cho việc một Web Service client thực hiện yêu cầu tới
Web Service server thông qua giao thức HTTP:

22

Hình 2.2-3: Web Services qua HTTP
Các bước sau đây chỉ ra 1 cách nhìn đơn giản trong quá trình liên quan đến việc
tạo và xử lý yêu cầu (request):
1. Client gọi 1 phương thức của 1 lớp lưu trữ trên server thông qua một proxy
của lớp có khả năng truy cập tới client.

2. Tầng SOAPbắt giữ lời gọi phương thức và tạo một sự miêu tả lời gọi bằng
mẫu XML
3. XML tự gói nó trong vỏ bọc SOAP vẫn trong định d
ạng XML
4. Dữ liệu vừa được xây dựng sẽ được gửi tới dịch vụ đích như một yêu cầu
HTTP thông qua TCP/IP.
5. HTTP server nhận yêu cầu HTTP.
6. Dữ liệu SOAP qua tầng SOAP bằng HTTP server
7. Tầng SOAP phía server phân tích vỏ bọc SOAP, rút ra biểu diễn XML của
phương thức
8. Tầng SOAP xác định dịch vụ đích và gọi hàm theo yêu cầu của client
9. Dịch vụ thi hành hàm và trả
về kết quả
10. Kết quả được trả về cho client với kiểu tương tự.
b. SOAP qua WebSphere MQ
Hình dưới đây mô tả một Web Service client tạo một yêu cầu tới Web Service
server thông qua WebSphere MQ thay vì HTTP:

Hình 2.2-4: Web Services qua WebSphere MQ

23
Tất cả các bước đều giống cách thức SOAP/HTTP ở trên ngoại trừ các bước 4,5
và 6. Thay vì gửi dữ liệu thông qua HTTP, tầng SOAP chuyển nội dung và vỏ bọc
SOAP tới SOAP/WebSphere MQ sender. SOAP/WebSphere MQ sender đặt thông
điệp SOAP vào hàng đợi giống một thông điệp WebSphere MQ. Tiến trình
SOAP/WebSphere MQ listener sẽ đọc thông điệp từ hàng đợi và chuyển dữ liệu
SOAP tới tầng SOAP phía máy chủ giống cách Web Service thực hiện trong
trường hợp HTTP. Kết quả
được trả về với cơ chế tương tự.
Thoạt nhìn có vẻ như cách này đã bổ sung thêm một lớp gián tiếp cho việc vận

chuyển dữ liệu, nhưng thực tế việc WebSphere MQ để truyền tải dữ liệu có một số
lợi thế:
- Ứng dụng có thể tận dụng lợi ích của tính năng đảm bảo phân phối để chắc
chắ
n rằng yêu cầu đã được gửi đến đích và gửi đúng một lần.
- Một cơ sở hạ tầng WebSphere MQ đang sẵn sàng để sử dụng cho tương tác
ứng dụng có thể được sử dụng cho việc truyền tải.
- Việc truyền tải có thể được đảm bảo hoặc nén bằng việc khai thác các tính
năng của WebSphere MQ. Với việc truyền tả
i qua WebSphere MQ, gói tin
khi đang trên đường truyền có thể được mã hoá bằng SSL để đảm bảo sự
bảo mật.
- Tính năng bó cụm WebSphere MQ có thể hỗ trợ khả năng cân bằng tải, nâng
cao tính sẵn sàng và tin cậy.
c. Ứng dụng client
Về mặt logic, các ứng dụng client khởi tạo ra dòng giao thức hoặc dòng message
khi một yêu cầu Web Service được xử lý. Về mặt đặc thù, client sử dụng proxy để
truy cập các hàm hoặc ph
ương thức của dịch vụ như miêu tả ở hình dưới:

Hình 2.2-5: Web Service client sử dụng proxy
Một proxy là một lớp biểu diễn cùng giao diện và dấu hiệu phương thức như
service nhưng thay vì thi hành trực tiếp hành vi được yêu cầu, nó gọi đến phương
thức ở xa. Lớp proxy được tạo từ WSDL và được dịch cũng như được làm cho sẵn
sàng cục bộ như một phần của quá trình triển khai.

24
Các ứng dụng WebSphere MQ client có thể chạy một trong hai cơ sở hạ tầng
SOAP cung cấp bởi .NET và Apache Axis1.1. Cả hai môi trường này đều cung
cấp các công cụ để tạo các proxy từ WSDL.

2.2.2.2 Tầng SOAP
Cơ sở hạ tầng SOAP đang được sử dụng để thu thập các lời gọi hàm hoặc phương
thức và định dạng các lời gọi này như một message theo định dạng XML để sẵn
sàng cho việc truyền t
ải tới service. Khi message đã sẵn sàng, nó có thể được
chuyển tới phần mềm truyền tải đã được đăng ký để quản lý URL cho Web
Service.
Tại phía server (service), tầng SOAP mở gói message, xây dựng lại lời gọi và yêu
cầu service, các giá trị trả về được xây dựng trong response message và SOAP
truyền tải nó để chuyển trả lại.
Websphere MQ như một phương tiện truyền tải cho SOAP mà không xử lý hoặc
cố gắng chuyể
n đổi dữ liệu SOAP. Vì vậy Websphere MQ hỗ trợ tương tác giữa
các phần chỉ trong phạm vi thực thi SOAP có hỗ trợ.
URI cho một Web Service để được truy cập có sử dụng Websphere MQ theo sau
cú pháp đã sử dụng cho SOAP/JMS luôn bắt đầu với “//jms:/queue?”. Phần còn lại
của URI là một chuỗi các cặp tên-giá trị. Các cặp tên-giá trị cung cấp thông tin
quyết định như:
- Destination: có thể là tên queue Websphere MQ hoặc tên queue và queue
manager của request queue. Tham số này cung cấp một chuỗ
i cặp tên-giá trị
chỉ ra chính xác cách Websphere MQ sender có thể kết nối tới Websphere
MQ queue manager để đặt yêu cầu vào đó. Nó cung cấp chi tiết response
queue tới bên trả lời thông điệp SOAP đã được định tuyến. Tuỳ chọn để
cung cấp sự bảo mật cũng có thể đưa vào đây.
- ResponseQueue: Queue để trả lời từ một Web Service đã gửi
- InitialContextFactory: khi sử dụng định dạng jms URL, tham số
này chỉ rõ
trình cung cấp Java Naming and Directory Interface (JNDI) được sử dụng để
tìm kiếm tham số connectionFactory.

- TargetService: tên của target service. Tầng SOAP phía server sử dụng tham
số này để phân biệt các service đang chạy.
Ngoài ra còn các tham số cho phép các thuộc tính liên quan đến sự tồn tại và thời
gian sống.
SOAP/WebSphere MQ sender
Một WebSphere MQ queue manager là một dịch vụ chứa các queue để các ứng
dụng có thể lấy các message và có thể đọc sau đó bởi cùng một ứng dụng hoặc các

25
ứng dụng khác. Queue manager có thể được cấu hình để định tuyến các message
để đi từ ứng dụng gửi đến các queue trong queue manager ở xa. Trong trường hợp
này, ứng dụng gửi là SOAP/WebSphere MQ sender. Ứng dụng đọc message là
SOAP/WebSphere MQ listener kết hợp với Web Service.
Sender thực hiện các công việc sau khi tầng SOAP yêu cầu cùng với URI và thông
điệp SOAP:
- Một cấu trúc header (WebSphere MQRFH2) được tạo và bổ sung trước dữ
liệu thông điệp SOAP (SOAP message data), trong đó chứa d
ữ liệu biến
đổi về thông điệp SOAP có thể được xử lý bởi SOAP/WebSphere MQ
listener khi đi qua dữ liệu SOAP để tới phía service.
- Sender kết nối tới queue manager như mô tả trong tham số
connectionFactory. Queue manager có thể là cục bộ hoặc ở xa so với
sender và có thể có hoặc không chứa queue đích cho thông điệp SOAP.
- Một queue response, với chức năng nhận thông điệp trả lời từ service,
được mở ra
để nhận trả lời. Nếu queue này không có trong mô tả của URI
thì sender sử dụng một queue mặc định.
Sender đặt message vào một queue trong queue manager. Nếu queue đích là queue
local, WebSphere MQ kiểm tra nơi sender được phép ghi. Như một phần của thao
tác put, một header khác là Message Descriptor được bổ sung vào message.

Message Descriptor chứa thông tin về ứng dụng gửi, sự tồn tại và thời gian sống
của message cũng như queue đích và queue manager. Thông tin về queue response
cũng được đưa vào. Thông tin này được dùng để WebSphere MQ đị
nh tuyến
message và cung cấp thông tin về sender đặt và yêu cầu message.
SOAP/WebSphere MQ listener
WebSphere MQ đưa các message được đặt bởi sender tới queue request, nơi
SOAP/WebSphere MQ listener sẵn sàng nhận yêu cầu. Nếu SOAP/WebSphere
MQ listener không sẵn sàng và listener triggering đã được cấu hình khi triển khai
thì listener sẽ được bật lên khi có message đến.
Listener đọc message và thu được Message Dispatcher cùng WebSphere
MQRFH2 header. Listener rút ra thông tin yêu cầu để định vị và yêu cầu Web
Service sau đó đưa nó qua tầng SOAP.
2.2.2.3 Triển khai Service
Một trong những công việc quan trọng nhất để Web Service có hiệu lực là triển
khai các server, các client proxy và các client. Thông thường việc này xảy ra sau
khi service và ứng dụng client đã được viết. Các mã có thể thực thi, các proxy và
WSDL thích hợp có thể được phân phối tới các vị trí và thư mục nơi cuối cùng
chúng chạy. Việc thực thi SOAP dưới service đang chạy có thể được cấu hình để