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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (804.93 KB, 28 trang )

(1)<div class='page_container' data-page=1>

ĐẠ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 KHỐ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Ĩ

</div>
(2)<div class='page_container' data-page=2>

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 TỐ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 tồ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 tồ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 KHỐN ... Error! Bookmark not defined.

</div>
(3)<div class='page_container' data-page=3>

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.

</div>
(4)<div class='page_container' data-page=4>

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 khốn
CA (Current Account) Tài khoản tiền gửi tại ngân hàng

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

tồ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)

</div>
(5)<div class='page_container' data-page=5>

URI (Universal Resource
Indicator or Identifier)

Định danh tài nguyên toàn thể

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)

</div>
(6)<div class='page_container' data-page=6>

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.

</div>
(7)<div class='page_container' data-page=7>

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 tố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 tố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.

</div>
(8)<div class='page_container' data-page=8>

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.

</div>
(9)<div class='page_container' data-page=9>

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 khốn, các Cơng ty
chứng khốn (CTCK) khơng được trực tiếp nhận tiền giao dịch chứng khố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à hồ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 đó q trình thanh tốn trong giao dịch sẽđược
ngân hàng đó thanh tố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 khố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 khốn” cung cấp giải pháp cho các cơng ty chứng khố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 khố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 khố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:

</div>
(10)<div class='page_container' data-page=10>

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 tố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 tố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.

</div>
(11)<div class='page_container' data-page=11>

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 KHỐ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 khố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 khốn tại các cơng ty
chứng khố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 khố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 khố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 khố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 khố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 chun 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 sốt tiền. Bản thân các cơng ty chứng khố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
khố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 khốn sẽ gửi tồ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 khố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.

</div>
(12)<div class='page_container' data-page=12>

chất để thực hiện, ngân hàng còn đảm bảo an tồ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 khố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 khố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 khố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
khố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
tồ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 khố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 khốn cịn được 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 khố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 khố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ư.

</div>
(13)<div class='page_container' data-page=13>

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 tồ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 khố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 khố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 khố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 chun về thanh tốn điện tử (Ví dụ như cơng ty cổ phần
dịch vụ thanh tố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
ngun nhân xem lỗi là tại CTCK, tại ngân hàng hay tại công ty trung gian.

</div>
(14)<div class='page_container' data-page=14>

Trong xu thế các cơng ty chứng khố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 khốn, việc giao tiếp trở nên khó hồ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 tồn bộ hoặc một phần của hệ thống bị lỗi, tính
tồ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 tồn trong q 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à

</div>
(15)<div class='page_container' data-page=15>

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

</div>
(16)<div class='page_container' data-page=16>

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 TỐ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:

</div>
(17)<div class='page_container' data-page=17>

ộ ố 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 đượ

- ề ả là 1 loại đặ ệ ủ

ueue, nơi message được lưu trữ ới khi chúng có thể đượ ề
đi và lưu trữ thành cơng tạ ở

- ừ Đặ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ế ền thông giữ
các queue manager, nó có thể ền các message đã được định trướ ớ ố

lượ ấ ỳ các queue được đặ ạ ở ặ ố lượ ấ ỳ

</div>
(18)<div class='page_container' data-page=18>

Để ột message có thể ử ớ ộ ở

ụ ộ ả định nghĩa một transmission queue và mộ ớ

ở xa đó. Cuố ỗi channel có mộ ấ ệu phân tách để ết đó là
kênh gửi hay kênh nhậ ột channel đơn giả ồ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ướ ấ ế ứ ụng yêu cầu các message

ồ ả ả ời) đượ ả ề ừ ộ ở xa thì cầ

ải có một channel khác, channel này được định nghĩa để ự ệ ề
ngượ ạ ữa các queue manager.

ỗi queue manager dùng mộ ặ ều channel để ửi và nhậ

ộ ạ ộ ẽ ử ặ ậ ữ ệ

ộ ổng đặ ệ ỗ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

</div>
(19)<div class='page_container' data-page=19>

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ứ sender đượ ử
ụng để thông báo nơi chứ ủ ấ ỳ ự thay đổi nào tớ ạng thái

ủa queue manager (ví dụ ệ ổ ặ ỷ ỏ ộ

</div>
(20)<div class='page_container' data-page=20>

- 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ủ ử ụng MQI channel để
ề ải các lờ ọ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 để ế ố ới các queue manager ở

là đầ ủ ạ ộ

</div>
(21)<div class='page_container' data-page=21>

Listener là một Websphere MQ process để “nghe” các kế ố ớ

ỗi đối tượ ể ễ ộ

ến trình “nghe”, tuy nhiên nế ến trình “nghe” này đượ ừ
line thì listener khơng đượ ể ễ ở

Do đó để ả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 đế ạ ẽ “nghe” các

ế ố ạ ộ ổng đặ ệt đượ ỉ ấ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 ngồ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ả ả ữa các chương trình: Nế ố lượng message đượ
ửi đế ộ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

</div>
(22)<div class='page_container' data-page=22>

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 tồ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.

</div>
(23)<div class='page_container' data-page=23>

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 đượ ử ớ ote queue thông qua

transmission queue lưu trữ ạ ời cùng vớ ộ ại nơi đặ

ẽ đượ ền thông qua remote channel. Nế

ệ ền thành công, message sẽ đượ ể ỏ ạ

nơi nhậ ậ ẽ ểm tra message để ết đị

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

manager khác. Nếu nó là đích thì queue được u cầ ẽ đượ ểm tra và nế
queue này tồ ại thì message sẽ được đặt vào đó ếu khơng message sẽ
đượ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

</div>
(24)<div class='page_container' data-page=24>

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ứ ẩ ệ ập đố ớ ệ

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

Web Service cho phép client và server tương tác đượ ớ ả
ững môi trường khác nhau, vớ ững ngơn ngữ ập trình khác nhau.
ột Web Service đượ ạ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 khác dễ dàng nhìn thấy và có thể ập đế

ữ ị ụ mà nó thự ện, đồ ời có thể yêu cầu thông tin từ

Service khác. Mộ ồm các mô đun độ ậ ạt độ

ủ ệp và bản thân nó đượ ực thi trên server.
b. Mơ hình kiến trúc Web Service[1]

Service 
Provider

Service 
Broker

Service 
Requestor

Client 
Application 
Bind, invoke

Publish 
WSDL + UDDI

UDDI Registry

Find 
WSDL + UDDI

Web service SOAP

Browser 
SOAP

</div>
(25)<div class='page_container' data-page=25>

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

</div>
(26)<div class='page_container' data-page=26>

ến trúc sâu hơn của Web Service được mơ tả trong hình dướ

Hình 2.2-2 Kiến trúc phân tầng của Web Service

SOAP là giao thứ ằ ữ ầ ậ ển và tầng mô tả thông tin về
ị ụ, cho phép người dùng triệ ọ ộ ị ụ ừ xa thông qua một thông
điệp XML. Ngồi ra, để các dị ụ có tính an tồn, tồn ẹn và bả ật thơng

ến trúc dị ụ Web, chúng ta có thêm các tầ

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 tồ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)[2, 5].

2.2.2.1 SOAP qua Websphere MQ [2, 5] 
a. SOAP qua HTTP

</div>
(27)<div class='page_container' data-page=27>

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 SOAP bắ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:

</div>
(28)<div class='page_container' data-page=28>

Tài liệu tham khảo

1. Edward Oguejiofor, Ken Childers, David Dhuyvetter, Peter Hood, Vijay Mann,
Sudhakar Nagarajan, Gerd Sommerhäuser (2006), IBM WebSphere and Microsoft 
.NET Interoperability, IBM Corporation, U.S.A.

2. IBM Corporation (2005), WebSphere MQ Transport for SOAP, IBM Corporation,
U.S.A.

3. IBM Corporation (2005), WebSphere MQ Security, IBM Corporation, U.S.A.

4. Peter Swithinbank, Francesca Gigante, Hedley Proctor, Mahendra Rathore, William
Widjaja (2005), WebSphere and .Net Interoperability Using Web Services, IBM

Corporation, U.S.A.

5. Saida Davies, Craig Both, Gary O’Connor, Sushil Sharma, Paul Slater, Ope

Soyannwo, Jerry L Stevens (2006), WebSphere MQ Version 6 and Web Services, IBM
Corporation, U.S.A.

6. />

7. />

</div>


Xây dựng hệ thống chỉ tiêu phân tích ngành Ngân hàng ở Việt Nam.DOC