TÌM HIỂU DỊCH vụ SERVICE BROKER TRONG MICROSOFT SQL SERVER 2005

TRƯỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM
KHOA CÔNG NGHỆ THÔNG TIN
***
BÁO CÁO BÀI TẬP LỚN
HỌC PHẦN “HỆ QUẢN TRỊ CƠ SỞ DỮ LIỆU”
Đề tài:
TÌM HIỂU DỊCH VỤ SERVICE BROKER TRONG MICROSOFT
SQL SERVER 2005
Hải Phòng, tháng 5 năm 2013
Bài tập lớn HQTCSDL, N11:Service Broker
2013
Contents
VÀI NÉT VỀ DỊCH VỤ SERVICE BROKER TRONG MICROSOFT
SQL SERVER 2005 2
I – SERVICE BROKER CÓ THỂ LÀM NHỮNG GÌ? 3
II – CẤU TRÚC CỦA MỘT SERVICE BROKER 8
III – VẤN ĐỀ BẢO MẬT ĐỐI VỚI SERVICE BROKER 17
IV – LỢI ÍCH CỦA SERVICE BROKER 20
V – CÀI ĐẶT MỘT SERVICE BROKER 25
VI – KẾT LUẬN 37
TÀI LIỆU THAM KHẢO 37
VÀI NÉT VỀ DỊCH VỤ SERVICE BROKER TRONG
MICROSOFT SQL SERVER 2005
Service Broker là một dịch vụ trong Microsoft SQL Server 2005, giúp
người lập trình cơ sở dữ liệu có thể tạo ra các ứng dụng có tính bảo mật, uyển
chuyển và đáng tin cậy. Vì Service Broker là một phần của Database Engine,
quyền quản trị của những ứng dụng này cũng là một phần quyền quản trị của
cơ sở dữ liệu.
Service Broker cung cấp kỹ thuật hàng đợi và tính năng trao đổi thông
điệp cho SQL Server. Service Broker còn được sử dụng cả cho những ứng
dụng trong một instance của cơ sở dữ liệu và những ứng dụng phân tán trên

nhiều instance.
Với một instance đơn của SQL Server, Service Broker cung cấp một
mô hình lập trình không đồng bộ mạnh. Các ứng dụng cơ sở dữ liệu thường
2
Bài tập lớn HQTCSDL, N11:Service Broker
2013
sử dụng lập trình không đồng bộ để rút ngắn thời gian phản ứng tương tác và
tăng tính tổng thể của ứng dụng.
Service Broker cũng cung cấp tính năng trao đổi thông điệp giữa các
instance của SQL Server. Service Broker giúp người lập trình tạo ra các ứng
dụng từ các thành phần độc lập, khép kín được gọi là dịch vụ. Các ứng dụng
này đòi hỏi các chức năng tiếp xúc trong các dịch vụ sử dụng thông điệp để
tương tác với các dịch vụ khác. Service Broker sử dụng giao thức TCP/IP để
trao đổi thông điệp giữa các instance. Service Broker bao gồm các tính năng
ngăn chặn các truy cập trái phép từ mạng và mã hóa các tin nhắn được gửi
qua mạng.
I – SERVICE BROKER CÓ THỂ LÀM NHỮNG GÌ?
Như đã giới thiệu ở trên, Service Broker cung cấp tính năng trao đổi
thông điệp giữa các instance của SQL Server. Service Broker giúp người dùng
xây dựng những ứng dụng độc lập và tự quản lý các thành phần của chúng
được gọi là dịch vụ.
Service Broker sử dụng giao thức truyền thông TCP/IP để trao đổi
thông điệp giữa các instance.
Tóm lại, Service Broker giúp người dùng xây dựng các ứng dụng
không đồng bộ (Asynchronous) và được cài đặt một cách độc lập nhưng cùng
thực thi một tác vụ là trao đổi thông điệp. Sau đây là các bước mà Service
Broker thực hiện để trao đổi thông điệp giữa hai instance của SQL Server.
3
Bài tập lớn HQTCSDL, N11:Service Broker
2013

1. Giao tiếp – Trao đổi thông tin (Conversation)
Service Broker được thiết kế phù hợp với việc thực hiện các chức năng
cơ bản về gửi và nhận thông điệp. Mỗi định dạng thông điệp của quá trình
trao đổi đều được xác định và nhất quán trong kênh giao tiếp. Mỗi thông điệp
cũng như cuộc giao tiếp, đều phải theo một khuôn mẫu riêng biệt do Service
Broker bắt buộc nhằm giúp người lập trình viết được những ứng dụng đáng
tin cậy.
Những phát biểu Transtact-SQL cho phép ứng dụng gửi và nhận những
thông điệp đáng tin cậy. Một ứng dụng sẽ gửi một thông điệp đến một dịch vụ
được đặt tên bởi một tập hợp các tác vụ có liên quan, trong khi đó, ứng dụng
sẽ nhận một thông điệp từ hàng đợi được trình bày bởi một bảng dữ liệu nội
bộ.
Những thông điệp của cùng một tác vụ thuộc về cùng một cuộc giao
tiếp. Trong mỗi cuộc giao tiếp, Service Broker đảm bảo rằng, ứng dụng sẽ
nhận một lần thông điệp chính xác theo thứ tự mà thông điệp đó được gửi đi.
Sự bảo mật của Service Broker giúp bạn có thể bảo vệ được các thông
điệp riêng tư và kiểm soát sự truy cập dịch vụ.
Một cách hiểu đơn giản nhất về Service Broker là xem dịch vụ này như
là dịch vụ gửi và nhận thư của bưu điện (Postal Service). Để giữ liên lạc với
một người đồng nghiệp ở xa, bạn và người đó có thể giao tiếp với nhau bằng
cách gửi thư cho nhau thông qua dịch vụ thư tín của bưu điện. Những lá thư
sẽ được chuyển đến tay người nhận theo trình tự mà nhân viên bưu điện sắp
xếp, bằng nhiều phương tiện vận chuyển khác nhau. Bạn và dồng nghiệp của
bạn có thể nhận thư từ hộp thư, đọc thư, hồi đáp và gửi thư cho đến khi cuộc
giao tiếp giữa hai bạn chấm dứt.
4
Bài tập lớn HQTCSDL, N11:Service Broker
2013
Việc chuyển phát thư diễn ra theo cơ chế không đồng bộ, vì việc gửi
hay hồi đáp của hai bạn có thể bị gián đoạn trong một thời gian, do bạn hay

đồng nghiệp của bạn đang làm một việc gì khác.
Quá trình gửi thư và nhận thư trong dịch vụ thư tín của bưu điện được
mô tả bởi hình vẽ sau:
So sánh dịch vụ Service Broker với dịch vụ thư tín của bưu điện, ta
thấy những thông điệp cần truyền tải tương ứng với những lá thư và dịch vụ
Service Broker chính là địa chỉ người nhận để người đưa thư chuyển đến.
Tương tự, hàng đợi (Queues) là hộp thư, nơi lưu trữ những lá thư khi chúng
được chuyển đến đúng địa chỉ người nhận.
Như vậy, ta có thể thấy một chương trình sử dụng Service Broker để
nắm giữ những quá trình trao đổi thông điệp với các chương trình khác thì
giống như dịch vụ thư tín của bưu điện.
2. Thứ tự và phối hợp thông điệp (Messages Orderding and
Coordination)
Như đã giải thích ở trên, trong dịch vụ thư tín của bưu điện, bạn không
thể biết được chính xác thời điểm đồng nghiệp của bạn đọc thư hay phúc đáp.
Cũng như vậy, một ứng dụng sử dụng dịch vụ Service Broker sẽ không thể
biết các dịch vụ khác xử lý thông điệp như thế nào, hoặc khi nào một ứng
dụng khác sẽ xử lý thông điệp.
5
Bài tập lớn HQTCSDL, N11:Service Broker
2013
Service Broker kiểm soát hàng đợi, kỹ thuật lập trình cơ sở dữ liệu
thông thường với hai điểm mấu chốt sau:
a. Tích hợp hàng đợi vào cơ sở dữ liệu
Tích hợp hàng đợi có nghĩa là việc báo trì và quản trị cơ sở dữ liệu phải
bao gồm cả dịch vụ Service Broker. Đặc biệt, người quản trị cơ sở dữ liệu
không có một lộ trình nào ứng với tác vụ để bảo trì Service Broker, vì nó đã
được tích hợp vào cơ sở dữ liệu.
b. Quan hệ giữa hàng đợi và thông điệp
Framework của Service Broker cung cấp một giao diện Transact-SQL

đơn giản, cho phép gửi và nhận thông điệp kết hợp với việc đảm bảo thực
hiện quá trình phân phối và xử lý thông điệp. Service Broker đảm bảo rằng,
chương trình chỉ nhận mỗi thông điệp trong cuộc hội thoại đúng một lần theo
thứ tự chúng được gửi, chứ không phải là thứ tự của chúng trong hàng đợi.
Những hàng đợi thông thường cho thông điệp ra theo thứ tự mà chúng được
đưa vào hàng đợi, đòi hỏi phải có một ứng dụng để xác định trình tự và gộp
các thông điệp lại thành nhóm. Ngoài ra, Service Broker bảo đảm rằng,
không có hai bộ đọc hàng đợi nào có thể xử lý đồng thời các thông điệp của
cùng một cuộc hội thoại hoặc của cùng một nhóm hội thoại được tích hợp.
Chương trình khởi tạo bắt đầu một cuộc hội thoại cho mỗi tác vụ, sau
đó gửi một thông điệp đến dịch vụ đích. Thông điệp này chứa các dữ liệu cần
thiết để thực hiện một bước cụ thể trong tác vụ như nhận thông điệp, xử lý
thông điệp và phản hồi trở lại cho dịch vụ khởi tạo nó. Cuộc hội thoại tiếp
diễn và cuối cùng kết thúc, theo các quy tắc mà người lập trình đã đặt ra.
6
Bài tập lớn HQTCSDL, N11:Service Broker
2013
3. Kỹ thuật lập trình không đồng bộ (Transactional
Asynchronous Programming)
Trong kiến trúc của Service Broker, thông điệp được chuyển phát giữa
nhũng ứng dụng được cài đặt tính chuyển tắc và không đồng bộ. Bởi vì nếu
một thông điệp bị lỗi hoàn toàn thì bộ hành động của Service Broker sẽ được
phục hồi, bao gồm việc gửi và nhận thông điệp.
Khi gửi thông điệp theo cơ chế không đồng bộ, Database Engine sẽ
kiểm soát sự phân phối trong khi ứng dụng tiếp tục thực thi các tác vụ khác.
Để cải thiện khả năng mở rộng, Service Broker cung cấp cơ chế cho các
chương trình khởi tạo tự động để xử lý hàng đợi khi có những việc hữu ích
cho chương trình làm.
Lập trình không đồng bộ giúp người lập trình viết các ứng dụng có sử
dụng hàng đợi. Nhiều ứng dụng cơ sở dữ liệu bao gồm các bảng có chức năng

như hàng đợi của các tác vụ phải thực hiện khi tài nguyên cho phép. Hàng đợi
cho phép cơ sở dữ liệu giữ nguyên trách nhiệm của người dùng hiện hành
trong khi làm việc với các tài nguyên khác. Service Broker đưa ra hàng đợi
như là một phần quan trọng của Database Engine
Hàng đợi cho phép ứng dụng thực thi công việc trên nhiều tác vụ khác
nhau. Điều này được mở rộng cho nhiều instance của SQL Server hay SQL
Server trên nhiều Server.
Service Broker hỗ trợ người lập trình cơ sở dữ liệu bằng cách cung cấp
các hàng đợi được xây dựng sẵn và những thông điệp tin cậy giữa các
instance
7
Bài tập lớn HQTCSDL, N11:Service Broker
2013
4. Hỗ trợ ứng dụng độc lập (Support for Loosely Coupled
Applications)
Service Broker hỗ trợ các ứng dụng độc lập, cho phép gửi và nhận thông điệp
độc lập với nhau, mặc dù các ứng dụng này có chung cơ chế trao đổi thông
điệp và sử dụng kiến trúc tương tác giữa các dịch vụ với nhau.
Tuy nhiên, các ứng dụng này chỉ cần chạy trên cùng một instance của SQL
Server, chứ không cần chạy tại cùng một thời điểm, đồng thời cũng không
phụ thuộc vào khoảng cách địa lý.
II – CẤU TRÚC CỦA MỘT SERVICE BROKER
Service Broker dùng một framework sử dụng thông điệp như một đơn vị
thông tin. Tuy nhiên, sự kiểm soát và xử lý các thông điệp này được thực hiện
bởi một số yểu tố: conversations, constracts, queues và services.
Trong phần này, chúng ta sẽ tìm hiểu về các thành phần được sử dụng trong
một Service Broker
1. Thành phần hội thoại (Conversations)
Service Broker sử dụng các cuộc hội thoại để trao đổi thông tin liên tục một
cách đáng tin cậy và không đồng bộ. Thành phần hội thoại sử dụng thông

điệp, hộp thoại và nhóm hội thoại để kiểm soát các luồng dữ liệu trong một
ứng dụng sử dụng dịch vụ Service Broker.
a. Thông điệp (Messages)
Thông điệp là một đơn vị thông tin trong cuộc hội thoại. Khi các ứng dụng sử
dụng Service Broker giao tiếp với nhau, chúng phải chấp nhận loại dữ liệu sẽ
8
Bài tập lớn HQTCSDL, N11:Service Broker
2013
được truyền tải, và những yêu cầu định dạng, xác nhận dữ liệu (nếu có). Mỗi
thông điệp được gắn thẻ nhận dạng tương ứng với từng cuộc hội thoại và tuân
theo một trình tự nhất định, để việc xử lý thông điệp có thể diễn ra một cách
tuần tự.
Nội dung và định dạng của thông điệp được định nghĩa bởi các ứng dụng. Khi
một thông điệp được tiếp nhận bởi Service Broker, nội dung thông điệp sẽ
được xác nhận tùy thuộc vào kiểu của thông điệp. Mặc dù thông điệp được
lưu trữ ở mức tối đa, song một loại đối tượng thông điệp sẽ định nghĩa kiểu
thông điệp và lưu trữ thông tin đó vào đối tượng cơ sở dữ liệu. Loại đối tượng
thông điệp phải được tạo ra trên bất kỳ SQL Server nào sử dụng loại thông
điệp tương ứng.
Thao tác tạo một kiểu thông điệp yêu cầu bạn cung cấp một tham số xác nhận
chính xác định dạng của thông điệp. Các loại thông điệp thường được xác
nhận bằng cách sử dụng well-formed XML hoặc XML được định nghĩa bởi
một giản đồ đặc biệt, mặt khác bạn cũng có thể định nghĩa kiểu thông điệp
rỗng, nghĩa là nội dung thông điệp là NULL. Bạn có thể bỏ qua quá trình xác
nhận thông điệp. Các loại dữ liệu khác vẫn có thể được sử dụng trong Service
Broker, miễn là SQL không yêu cầu phải xác nhận nội dung thông điệp.
b. Hộp thoại (Dialog Conversations)
Khi thông điệp được gửi giữa hai instance của SQL Server, một hộp
thoại sẽ được tạo ra. Hộp thoại sử dụng để chuyển phát các thông điệp được
định nghĩa chính xác và duy nhất theo thứ tự nhất định (exactly-one-in-order).

Định danh hộp thoại và tham số xác nhận cho mỗi thông điệp được dùng để
nhận dạng các thông điệp có liên quan để đảm bảo rằng chúng được chuyển
phát theo một thứ tự đúng. Do đó, hộp thoại thiết lập một kênh giao tiếp liên
tục để trao đổi những thông điệp giữa hai dịch vụ.
9
Bài tập lớn HQTCSDL, N11:Service Broker
2013
Đối với mỗi hộp thoại, một Service Broker đóng vai trò như người khởi
xướng, thiết lập nên cuộc hội thoại. Service Broker còn lại sẽ chấp nhận và
quá trình trao đổi sẽ diễn ra trong cuộc hội thoại vừa thiết lập. Hợp đồng cho
cuộc hội thoại xác định các thông điệp mà mỗi người tham gia có thể gửi đi.
Hộp thoại tự động xác nhận khi nhận được thông điệp để đảm bảo sự
chuyển phát là đáng tin cậy. Mỗi thông điệp gửi đi được lưu trữ trong một
hàng đợi cho đến khi hộp thoại xác nhận là đã nhận được. Quá trình tự động
hóa này ngăn chặn các thông điệp không có một cơ chế xác nhận rõ ràng,
riêng biệt. Sự xác nhận thông điệp là một phần trong chức năng nội bộ của
Service Broker, và không thuộc về ứng dụng kênh giao tiếp chính thức.
Bởi vì Service Broker được thiết kế phù hợp với chức năng truyền tin
không đồng bộ, nếu một dịch vụ ở xa không có sẵn, thông điệp sẽ được lưu
trữ trong một hàng đợi cho đến khi dịch vụ đó sẵn sàng, hoặc thời gian tồn tại
của hộp thoại đã hết.
Thời gian tồn tại của hộp thoại phụ thuộc vào một vài yếu tố. Hộp thoại
có thể được chấm dứt khi có một ứng dụng chấm dứt rõ ràng, hoặc nhận được
một thông điệp báo lỗi. Mỗi bên tham gia chịu trách nhiệm ngang nhau về sự
chấm dứt của hộp thoại khi một trong hai điều kiện trên được đáp ứng. Kịch
bản thông thường của sự chấm dứt hộp thoại yêu cầu một trong các bên tham
gia thông báo với những bên tham gia còn lại rằng hộp thoại đã kết thúc thành
công mà không xảy ra lỗi.
Khi thiết kế các ứng dụng sử dụng Service Broker, người lập trình ứng
dụng cũng có thể chỉ định thời gian tồn tại tối đa của hộp thoại. Khi đạt tới

hoặc vượt quá thời gian này, một thông điệp “a time-out error” sẽ được đặt
vào hàng đợi của Service Broker, và thông điệp mới cho hộp thoại đó sẽ bị từ
chối. Các thông điệp được tạo ra trước khi cuộc hội thoại kết thúc vẫn có thể
10
Bài tập lớn HQTCSDL, N11:Service Broker
2013
nhận được sau khi kết thúc cuộc hội thoại, nhưng không một thông điệp nào
có thể gửi đi hoặc nhận được sau khi kết thúc cuộc hội thoại.
c. Nhóm hội thoại (Conversation Groups)
Nhóm hội thoại dùng để xác định các cuộc hội thoại có liên quan với
nhau, cho phép ứng dụng sử dụng Service Broker phối hợp các hội thoại có
liên quan để cùng thực hiện một công việc cụ thể. Nhóm hội thoại được kết
hợp với một dịch vụ cụ thể. Các cuộc hội thoại là thành viên của nhóm hội
thoại được gửi đi hoặc nhận về từ dịch vụ này. Đối với mỗi dịch vụ, SQL sẽ
kết hợp các thông điệp với một nhóm hội thoại thích hợp, sao cho các thông
điệp nhận bởi ứng dụng đối với mỗi cuộc hội thoại được xử lý theo một thứ tự
xác định. Điều này cho phép ứng dụng nhận thông điệp từ nhiều nguồn khác
nhau, nhưng các thông điệp quá trình liên quan từ các nguồn này được sắp
xếp theo thứ tự chúng được nhận bởi tất cả các dịch vụ.
Nhóm hội thoại có tính chủ quan, có nghĩa là dịch vụ khởi xướng có
thể xử lý một thông điệp thuộc về nhóm hội thoại A, trong khi dịch vụ đích có
thể xử lý một thông điệp thuộc về nhóm hội thoại B. Điều này cho phép mỗi
bên tham gia có thể xử lý thông điệp theo cách thích hợp cho các ứng dụng.
Ví dụ, một ứng dụng quản lý bán hàng có thể nhận thông điệp từ một
dịch vụ quản lý thông tin giá cả các mặt hàng, cũng như thông điệp từ một
dịch vụ quản lý các mặt hàng tồn kho. Ứng dụng quản lý bán hàng có thể tag
các thông điệp từ dịch vụ quản lý thông tin giá cả, cũng như dịch vụ quản lý
hàng tồn kho như là một phần của cùng một nhóm hội thoại, điều này có thể
sử dụng để xác định xu hướng bán hàng của các mặt hàng dựa trên sự lên
xuống của giá cả. Cả dịch vụ quản lý hàng tồn kho cũng như dịch vụ quản lý

giá cả đều không nhận thức được mối quan hệ này, bởi vì nó không liên quan
đến cách chúng gửi thông điệp đến ứng dụng quản lý bán hàng.
11
Bài tập lớn HQTCSDL, N11:Service Broker
2013
2. Kiểu thông điệp (Message Types)
Những ứng dụng sử dụng Service Broker giao tiếp bằng cách gửi thông
điệp đến ứng dụng nó cần, như là một phần của cuộc hội thoại. Các bên tham
gia trong cuộc hội thoại phải chấp nhận tên và nội dung của mỗi thông điệp.
Một đối tượng kiểu thông điệp (message type object) định nghĩa tên cho kiểu
thông điệp và định nghĩa kiểu dữ liệu mà thông điệp chứa đựng. Các kiểu
thông điệp vẫn tồn tại trong cơ sở dữ liệu mà ở đó kiểu thông điệp được tạo
ra. Bạn có thể tạo ra các kiểu dữ liệu giống hệt nhau cho mỗi cơ sở dữ liệu
tham gia vào cuộc hội thoại.
SQL Server có thể xác nhận thông điệp chứa XML hợp lệ, thông điệp
chứa XML phù hợp với một giản đồ cụ thể, hoặc thông điệp không chứa dữ
liệu. Đối với dữ liệu tùy ý hoặc dữ liệu nhị phân, kiểu thông điệp có thể chỉ
định SQL Server không xác nhận nội dung thông điệp.
Hiện nay, Service Broker hỗ trợ các xác nhận sau đây:
 Well-formed XML
 XML được định nghĩa bởi một giản đồ đặc biệt
 Không xác nhận
 Rỗng
Sự xác nhận được SQL thực hiện ngay khi dịch vụ đích nhận được
thông điệp. Nếu nội dung thông điệp không phù hợp với xác nhận Service
Broker chỉ định, một thông điệp báo lỗi sẽ được Service Broker gửi về service
phát đi thông điệp.
12
Bài tập lớn HQTCSDL, N11:Service Broker
2013

Chú ý: Bất kể Service Broker chỉ định xác nhận nào, ứng dụng cũng
phải xác minh xem nội dung thông điệp có phù hợp với ứng dụng không trước
khi sử dụng dữ liệu trong thông điệp.
Đối với kiểu thông điệp rỗng, thân thông điệp phải không chứa dữ liệu
nào. Đối với kiểu thông điệp được chỉ định kiểu xác nhận well-formed XML,
thân thông điệp phải là well-formed XML. Đối với kiểu thông điệp được xác
nhận bởi XML định nghĩa bằng một tập hợp giản đồ riêng biệt, thân thông
điệp phải chứa well-formed XML có trong một trong những giản đồ của tập
hợp. Đối với kiểu thông điệp không cần xác nhận, SQL Server chấp nhận bất
cứ nội dung gì, bao gồm cả dữ liệu nhị phân, XML hoặc không nội dung.
Service Broker cung cấp một kiểu thông điệp được xây dựng sẵn gọi là
DEFAULT (kiểu thông điệp mặc định). Nếu như kiểu thông điệp không được
chỉ định trong lệnh SEND của Service Broker, hệ thống sẽ sử dụng kiểu thông
điệp mặc định.
3. Hợp đồng (Contracts)
Hợp đồng là những ràng buộc giữa hai dịch vụ về các thông điệp mỗi máy
chủ có thể gửi để thực thi một tác vụ nhất định. Đối với mỗi kiểu thông điệp,
13
Bài tập lớn HQTCSDL, N11:Service Broker
2013
một hợp đồng được định nghĩa để xác định những đối tượng có thể gửi kiểu
thông điệp đó.
Có thể chia hợp đồng làm 3 loại:
 Initiator Only: Chỉ có dịch vụ khởi xướng mới có thể gửi các kiểu
thông điệp được định nghĩa trong hợp đồng.
 Target Only: Chỉ có dịch vụ nhận mới được quyền gửi các kiểu thông
điệp này
 Any: Cho phép cả dịch vụ khởi xướng và dịch vụ đích có thể gửi các
kiểu thông điệp này.
Trong SQL Server 2005, một hợp đồng mặc định được tạo ra và được cấu

hình để sử dụng các kiểu thông điệp mặc định. Hợp đồng này thuộc loại
“Any”
Hình sau mô tả quá trình lắp ráp của hai kiểu thông điệp để tạo thành hợp
đồng:
14
Bài tập lớn HQTCSDL, N11:Service Broker
2013
4. Hàng đợi (Queues)
Hàng đợi là một thành phần chính trong cấu trúc Service Broker.
Chúng được sử dụng trong quá trình xử lý dữ liệu không đồng bộ giữa các
ứng dụng và dịch vụ khi cần thiết. Service Broker sử dụng hàng đợi để lưu trữ
thông điệp. Khi một thông điệp được gửi đi hoặc được nhận về bởi một dịch
vụ, nó sẽ được đưa vào hàng đợi đến hoặc đi tương ứng. Các hàng đợi được
quản lý bởi Service Broker, và nội dung của các hàng đợi có thể được truy
vấn như ở một bảng hoặc một khung nhìn.
Trong một hàng đợi, mỗi dòng chứa nội dung của thông điệp, kiểu
thông điệp, dịch vụ đích, mã xác nhận, hợp đồng và thông tin cuộc hội thoại
tương ứng. Ứng dụng sử dụng Service Broker sẽ dùng những thông tin này để
xác định và xử lý thông điệp như mong đợi. Hàng đợi cũng được sử dụng để
đảm bảo rằng các thông điệp được xử lý theo thứ tự chúng được gửi, chứ
không phải thứ tự chúng được tiếp nhận.
Trong SQL Server 2005, bạn có thể sử dụng các thủ tục thường trú để
xử lý các thông điệp trong hàng đợi khi cần đến. Service Broker cũng cho
phép bạn chạy nhiều instances của cùng một thủ tục thường trú để xử lý các
thông điệp trong hàng đợi hiệu quả hơn.
5. Services
Từ service khi sử dụng trong Service Broker đề cập tới một thành phần của
phần mềm thực thi một tác vụ đặc biệt hoặc một tập hợp các tác vụ. Thành
phần hội thoại, như đã nói ở trên, được định nghĩa giữa hai services. Tên của
service được sử dụng như địa chỉ đầu cuối để chuyển phát thông điệp đến

15
Bài tập lớn HQTCSDL, N11:Service Broker
2013
hàng đợi thích hợp trong Service Broker, để dẫn thông điệp đến service thích
hợp, cũng như thực thi hợp đồng và yêu cầu bảo mật từ xa đối với một cuộc
hội thoại mới.
Mỗi service sử dụng một hàng đợi riêng biệt để lưu trữ thông điệp đến và hợp
đồng được sử dụng bởi service định nghĩa những tác vụ được chấp nhận cho
một cuộc hội thoại mới.
6. Routes (Các tuyến đường)
Các tuyến đường được sử dụng để chỉ ra nơi thông điệp sẽ được chuyển đến.
Khi thông điệp được gửi bởi một service khởi xướng, Service Broker bắt buộc
phải tìm được service đích. Giống như khi bạn sử dụng bản đồ để tìm ra nhà
hàng gần nhất, Service Broker phải tìm mọi cách liên hệ với service đích để
khởi tạo một cuộc hội thoại. Các tuyến đường được tạo ra bởi ba thành phần
để giúp Service Broker nhận ra service đích một cách chính xác:
 Tên service: Tên service phải chính xác, phù hợp với service đích
 Broker instance inditifier: Một giá trị của kiểu dữ liệu GUID, dùng để
nhận dạng cơ sở dữ liệu giữ hàng đợi cho các service
 Địa chỉ mạng: Thường là tên một máy chủ hoặc địa chỉ IP của máy chủ
chứa service đích. Nó có thể được thay thế bởi địa chỉ của một
forwarding broker hiểu cách chuyển tiếp thông điệp đến một service
đích thích hợp.
Khi tìm kiếm các tuyến đường thích hợp cho một cuộc hội thoại, SQL phải
đối chiếu tên service và broker instance inditifier được quy định trong một
tuyên bố BEGIN DIALOG CONVERSATION với tên service và broker
instance inditifier ở các tuyến đường. Nếu các tuyến đường không cung cấp
16
Bài tập lớn HQTCSDL, N11:Service Broker
2013

một tên service hay broker instance inditifier, bất kỳ một tên service hoặc
broker instance inditifier nào cũng có thể được đối chiếu. SQL Server sẽ chọn
một tuyến đường thích hợp dựa trên một danh sách trong một bảng có tên là
sys. router của cơ sở dữ liệu chứa service khởi xướng. Nếu Service Broker
không thể tìm được tuyến đường chính xác cho thông điệp, thông điệp sẽ bị
drop.
Đối với cơ sở dữ liệu nào chứa tuyến đường có tên AutoCreatedLocal, SQL sẽ
đối chiếu với bất kỳ tên service và broker instance inditifier nào. Tuy vậy, sự
chuyển phát thông điệp sẽ bị giới hạn trong instance hiện tại. Mặc dù điều này
có thể chấp nhận được với các ứng dụng sử dụng các service được lưu trữ trên
cùng một SQL Service instance, nói chung nó vẫn là một ý tưởng hay để tạo
thủ công một tuyến đường cho mỗi service nhằm đảm bảo sự sẵn sàng của
service. Nó cũng tránh cho tuyến đường AutoCreatedLocal không bị sửa đổi
thành một điểm vô dụng đối với mục đích vốn có của nó.
Bạn có thể sử dụng câu lệnh CREATE ROUTE để chỉ định các tùy chọn
kết nối cho một service ở xa. Đó thường là địa chỉ và số cổng được sử dụng
để kết nối với một thiết bị đầu cuối trên service đích.
III – VẤN ĐỀ BẢO MẬT ĐỐI VỚI SERVICE
BROKER
Bảo mật tất nhiên là một vấn đề đáng quan tâm khi xây dựng các giải
pháp có sử dụng Service Broker. Kể cả khi ứng dụng của bạn sử dụng một cơ
sở dữ liệu duy nhất trên localhost, hay trải rộng trên nhiều cơ sở dữ liệu trên
nhiều server khác nhau, bạn cũng cần phải hiểu tác động của bảo mật có vai
trò gì đối với các ứng dụng của bạn.
Service Broker sử dụng hai chế độ bảo mật để xác định cách thức bảo
đảm an toàn thông tin liên lạc cho ứng dụng:
17
Bài tập lớn HQTCSDL, N11:Service Broker
2013
 Bảo mật hộp thoại (Dialog security): Dùng để kiểm soát sự mã

hóa, sự chứng thực từ xa, sự ủy quyền từ xa đối với các cuộc hội
thoại.
 Bảo mật phương tiện (Transport security): Dùng để kiểm soát sự
bảo mật giữa các instances ở hai máy chủ
1. Bảo mật hộp thoại (Dialog Security)
Bảo mật hộp thoại tập trung vào bảo mật các cuộc hội thoại mang tính
cá nhân giữa các service. Nếu cả service khởi xướng và service đích đều tồn
tại trong cùng một cơ sở dữ liệu, sự mã hóa được tự động kích hoạt, và một
khóa được dùng để mã hóa các thông tin liên lạc. Sự mã hóa cũng có thể được
tắt đối với các service truyền thông nội bộ trong cùng một cơ sở dữ liệu,
nhưng được khuyến cáo là không nên. Bảo mật hộp thoại cũng cung cấp hai
chế độ làm việc khi truyền đạt thông tin giữa các service: Bảo mật đầy đủ
(full security) và bảo mật vô danh (anonymous security).
a. Bảo mật đầy đủ (Full Security)
Bảo mật đầy đủ yêu cầu một mối quan hệ gắn bó khăng khít được thiết
lập giữa service khởi xướng và service đích. Điều này được thực hiện thông
qua việc sử dụng Public Key Certificates. Khi service đích chạy trên một máy
chủ ở xa, một người dùng có quyền truy cập vào service sử dụng Service
Broker phải sở hữu một chứng chỉ và một khóa riêng tương ứng. Thông tin
của người dùng và chứng chỉ (nhưng không gồm khóa riêng) phải được định
rõ trong cơ sở dữ liệu chứa service khởi xướng trong một ràng buộc từ xa.
Các service từ xa ràng buộc tên người dùng, chứng chỉ, và service đích từ xa
với nhau nhằm tìm kiếm và xây dựng một kết nối đáng tin cậy. Chứng chỉ
18
Bài tập lớn HQTCSDL, N11:Service Broker
2013
được sử dụng trong chế độ bảo mật đầy đủ phải có các tùy chọn để bắt đầu
hộp thoại Service Broker. Điều này được thực hiện bằng cách sử dụng phát
biểu Transact-SQL ACTIVE FOR BEGIN_DIALOG = ON <tùy chọn> trong
phát biểu CREATE CERTIFICATE.

b. Bảo mật vô danh (Anonymous Security)
Bảo mật vô danh xác định service đích từ service khởi xướng, nhưng
không có phương pháp khác xung quanh. Không giống chế độ bảo mật đẩy
đủ, chế độ này không yêu cầu chứng chỉ đối với người dùng ở xa, nhưng
người dùng chỉ định trong những ràng buộc từ xa phải là một thành viên đóng
vai trò công khai trong cơ sở dữ liệu đích. Điều này đòi hỏi vai trò nào trong
cơ sở dữ liệu đích được cấp quyền truy cập trong service đích. Thông điệp sử
dụng bảo mật vô danh được mã hóa bằng cách sử dụng một khóa được tạo bởi
cơ sở dữ liệu có service khởi xướng.
2. Bảo mật phương tiện (Transport Security)
Bảo mật phương tiện được quản lý nhờ kiểm soát các truy cập tới các
thiết bị đầu cuối được sử dụng để kết nổi với các service ở xa. Khi tạo ra các
thiết bị đầu cuối, bạn có thể chỉ định các tùy chọn xác thực: sử dụng
Kerberos, NTML, hoặc xác thực bằng chứng chỉ. Bạn cũng có thể chí định
các tùy chọn mã hóa, sử dụng AES hoặc RC4. Một lần nữa nhắc lại, nên nhớ
rằng bảo mật phương tiện được định nghĩa đối với tất cả các instance của máy
chủ, bao gồm mọi service trong tất cả cơ sở dữ liệu.
19
Bài tập lớn HQTCSDL, N11:Service Broker
2013
IV – LỢI ÍCH CỦA SERVICE BROKER
Service Broker cung cấp cho ứng dụng cơ sở dữ liệu nhiều tiện ích, bao gồm:
Tương tác cơ sở dữ liệu, thứ tự và phối hợp thông điệp, tính độc lập và khả
năng xử lý uyển chuyển, khóa thông điệp và kích hoạt tự động.
1. Tương tác cơ sở dữ liệu (Database Integration)
Tương tác cơ sở dữ liệu nâng cao khả năng thực thi ứng dụng và đơn
giản hóa công việc quản trị. Thiết kế tích hợp của Service Broker cung cấp
nhiều tiện ích cho việc thực thi ứng dụng và quản trị.
Tương tác với SQL Server cho phép thực hiện tác vụ của thông điệp mà
không cần tới sự phối hợp của các chuyển tác khác từ bên ngoài. Một ứng

dụng có thể nhận một thông điệp hoặc nhiều hơn, xử lý chúng và gửi đi một
thông điệp trả lời trong một tác vụ cơ sở dữ liệu đơn lẻ. Nếu tác vụ này thất
bại, tất cả các tác vụ sẽ trở lại trạng thái ban đầu, thông điệp quay trở lại hàng
đợi để xử lý một lần nữa. Không một hành động nào có thể thực thi cho đến
lúc ứng dụng hoàn thành xong tác vụ. Ứng dụng vẫn không đổi trạng thái.
Công việc quản trị cũng dễ dàng hơn khi dữ liệu, thông điệp và ứng
dụng đều chứa trong cơ sở dữ liệu một cách có hệ thống, bởi vì công việc
quản trị đối với ứng dụng (bao gồm khắc phục sự cố, bảo mật, sao lưu dữ liệu,
,,,) trở thành một phần của công việc quản trị cơ sở dữ liệu, và quản trị viên
không cần phải quản lý ba hoặc bốn phần riêng biệt.
20
Bài tập lớn HQTCSDL, N11:Service Broker
2013
Đối với hệ thống thông điệp truyền thống, thông điệp lưu trữ trong cơ
sở dữ liệu có thể trở nên không đồng nhất với cơ sở dữ liệu. Ví dụ, khi một
thành phần được phục hồi từ bản sao, các thành phần khác cũng phải được
phục hồi từ bản sao trong cùng một thời điểm, ngược lại, thông tin trong
thông điệp sẽ không trùng khớp với thông tin trong cơ sở dữ liệu; bời vì
Service Broker nắm giữ thông điệp và dữ liệu trong cùng một cơ sở dữ liệu,
không đồng nhất cũng không phải là một vấn đề.
Môi trường phát triển chung cũng là một lợi thế của tương tác cơ sở dữ
liệu. Phần thông điệp và phần dữ liệu của ứng dụng có thể dùng chung ngôn
ngữ và các công cụ của SQL Server trong ứng dụng sử dụng Service Broker,
người lập trình có thể sử dụng kỹ thuật lập trình cho các chương trình trao đổi
thông điệp. Các thủ tục thường trú thực hiện trên một service của Service
Broker có thể được viết bằng Transact-SQL hoặc một trong các ngôn ngữ
CLR (common language runtime). Các ứng dụng nằm ngoài cơ sở dữ liệu có
thể sử dụng Transact-SQL và một giao diện lập trình cơ sở dữ liệu như
ADO.NET
2. Thứ tự và phối hợp các thông điệp (Ordering and

Coordination
Trong hệ thống thông điệp truyền thống, ứng dụng có trách nhiệm sắp
xếp và phối hợp các thông điệp theo một thứ tự nhất định. Ví dụ, ứng dụng A
gửi đi các thông điệp được đánh số 1,2,3. Ứng dụng B nhận thông điệp 1 và 2,
nhưng phát sinh lỗi ở thông điệp thứ 2, Do đó, ứng dụng A gửi lại thông điệp
2, như vậy lúc này thông điệp đó sẽ được nhận sau thông điệp 1 và 3.
Trước đây, người lập trình hoặc phải viết ứng dụng sao cho thứ tự
thông điệp không quan trọng, hoặc phải lưu thông điệp thứ 3 vào bộ nhớ
21
Bài tập lớn HQTCSDL, N11:Service Broker
2013
cache cho đến khi nhận được thông điệp thứ 2 để ứng dụng có thể xử lý thông
điệp đúng thứ tự. Không có giải pháp đơn giản nào trong hai giải pháp trên.
Một vấn đề khác của hệ thống thông điệp truyền thống là trùng lặp.
Trong ví dụ trên, nếu ứng dụng B nhận thông điệp 2, nhưng thông điệp xác
nhận gửi trở lại ứng dụng A bị thất lạc, ứng dụng A sẽ gửi lại thông điệp 2,
dẫn đến ứng dụng B nhận thông điệp 2 hai lần. Ứng dụng sẽ loại bỏ trùng lặp
hoặc xử lý bằng cách ghi đè. Đứng trên góc độ lập trình, cả hai giải pháp trên
đều khó cài đặt.
Phối hợp thông điệp cũng là một vấn đề khó kiểm soát. Ví dụ, một ứng
dụng có thể đệ trình tới service hàng trăm, hàng ngàn yêu cầu. Service xử lý
các yêu cầu này song song và trả về kết quả ngay khi quá trình xử lý kết thúc.
Bởi vì mỗi yêu cầu tốn một lượng thời gian khác nhau để xử lý, ứng dụng sẽ
nhận phản hồi theo thứ tự khác với thứ tự ứng dụng gửi các thông điệp đi.
Tuy nhiên, để xử lý đúng các phản hồi, ứng dụng phải liên kết mỗi phản hồi
với các thông điệp đi tương ứng.
Service Broker giải quyết tất cả các vấn đề nêu trên bằng cách kiểm
soát thứ tự thông điệp, chuyển phát một lần duy nhất và tự động nhận dạng
hội thoại. Một khi cuộc hội thoại được thiết lập giữa hai thiết bị đầu cuối của
Service Broker, ứng dụng sẽ chỉ nhận mỗi tin nhắn một lần, theo thứ tự mà

chúng được gửi đi. Ứng dụng của bạn chỉ xử lý thông điệp đúng một lần theo
thứ tự. Cuối cùng, Service Broker tự động bao gồm một định danh trong mỗi
thông điệp.
22
Bài tập lớn HQTCSDL, N11:Service Broker
2013
3. Tính độc lập và uyển chuyển trong xử lý (Loosely Coupling
and Workload Felixibility)
Service Broker cung cấp tính năng xử lý độc lập giữa ứng dụng khởi
xướng và ứng dụng đích. Một ứng dụng có thể gửi thông điệp vào hàng đợi và
sau đó tiếp tục với việc xử lý, phản hồi trên Service Broker để bảo đảm rằng
thông điệp đến được với ứng dụng đích. Tính năng xử lý độc lập cung cấp cơ
chế uyển chuyển. Service khởi xướng có thể gửi đi nhiều thông điệp và nhiều
service đích có thể xử lý chúng song song. Mỗi service đích xử lý các thông
điệp với tốc độ của nó, phụ thuộc vào khối lượng công việc hiện tại.
Kỹ thuật hàng đợi cho phép hệ thống xử lý công việc đồng đều, giảm
công suất đỉnh theo yêu cầu của máy chủ. Điều này có thể cải thiện thông
lượng tổng thể và hiệu suất của ứng dụng cơ sở dữ liệu.
Nếu không lập tức có sẵn ứng dụng đích, các thông điệp vẫn nằm trong
hàng đợi. Service Broker sẽ gửi lại thông điệp cho đến khi thông điệp được
gửi thành công, hoặc đến khi hết thời gian cho phép tiếp tục một cuộc hội
thoại đáng tin cậy giữa hai service, ngay cả khi một service tạm thời không có
sẵn trong một số điểm của cuộc hội thoại. Thông điệp trong hàng đợi là một
phần của cơ sở dữ liệu; Service Broker chuyển phát thông điệp ngay cả khi
instance thất bại hoặc khởi động lại.
4. Khóa thông điệp (Related Message Locking)
Một trong các vấn đề khó nhất để thực hiện một ứng dụng gửi thông
điệp kiểu truyền thống là cho phép nhiều chương trình đọc thông điệp song
song từ cùng một hàng đợi. Trong hệ thống thông điệp truyền thống, thông
điệp có thể được xử lý không theo thứ tự khi nhiều chương trình hoặc nhiều

liên kết đang đọc từ cùng một hàng đợi. Service Broker ngăn chặn tình trạng
này xảy ra bằng việc khóa các nhóm hội thoại.
23
Bài tập lớn HQTCSDL, N11:Service Broker
2013
Bạn hãy xem xét một ứng dụng xử lý đơn hàng truyền thống. Thông
điệp A chứa cách tạo tiêu đề của đơn hàng, thông điệp B chứa cách tạo các
dòng để ghi tên các mặt hàng, cả hai đều được nhận vào hàng đợi. Nếu cả hai
thông điệp bị loại bỏ khỏi hàng đợi bởi các instance ứng dụng riêng biệt, và
được xử lý trong cùng một thời điểm, các dòng ghi các mặt hàng giao dịch có
thể được thực hiện đầu tiên, và thất bại bởi đơn hàng không tồn tại. Sự thất
bại này sẽ khiến giao dịch phải thực hiện lại, thông điệp lại đến hàng đợi và
được xử lý một lần nữa, gây lãng phí tài nguyên. Theo cách truyền thống,
người lập trình giải quyết vấn đề đó bằng cách kết hợp thông tin từ thông điệp
A và thông điệp B để thành một tin nhắn duy nhất. Phương pháp này có thể
khả thi đối với hai thông điệp, nhưng sẽ bất khả thi đối với những hệ thống
chứa đến hàng trăm hàng nghìn thông điệp.
Service Broker giải quyết vấn đề này bằng cách kết hợp các thông điệp
có liên quan với nhau thành một nhóm hội thoại. Service Broker tự động khóa
tất cả các thông điệp trong cùng một nhóm hội thoại để các thông điệp này chỉ
có thể được nhận và xử lý bởi một instance ứng dụng. Trong khi đó, các
instance khác của ứng dụng có thể tiếp tục loại bỏ khỏi hàng đợi và xử lý các
thông điệp trong các nhóm hội thoại khác. Điều này cho phép nhiều instance
có thể làm việc song song một cách đáng tin cậy và có hiệu quả mà không yêu
cầu những mã khóa phức tạp trong ứng dụng.
5. Kích hoạt tự động (Automatic Activation)
Một trong các tính năng hữu ích nhất của Service Broker là kích hoạt tự
động. Kích hoạt tự động cho phép tự động điều chỉnh dung lượng thông điệp
đến hàng đợi. Service Broker cung cấp các tính năng cho phép các chương
trình chạy bên trong cơ sở dữ liệu và các chương trình chạy bên ngoài cơ sở

dữ liệu đều có thể kích hoạt. Tuy nhiên, Service Broker không yêu cầu ứng
dụng phải sử dụng tính năng này.
24
Bài tập lớn HQTCSDL, N11:Service Broker
2013
V – CÀI ĐẶT MỘT SERVICE BROKER
Service Broker là một dịch vụ hữu ích đối với các ứng dụng có cơ chế
xử lý không đồng bộ hay phân tán trên nhiều máy, chẳng hạn như : Trigger
không đồng bộ, xử lý truy vấn có xác thực, xử lý trên máy chủ với ứng dụng
phân tán, hợp nhất dữ liệu với ứng dụng khách và xử lý lô với quy mô lớn,
Mặc dù có thể cài đặt được trên nhiều ứng dụng, nhưng ta chỉ tìm hiểu
cách cài đặt Service Broker trên ứng dụng đơn giản có chức năng gửi và nhận
thông điệp.
1. Cài đặt Service Broker
Các đối tượng cần tạo được nêu ở bảng sau
Loại đối tượng Tên đối tượng Mô tả
Queue
QueueForIntiator Hàng đợi cho service khởi xướng
Queue
QueueForTarget Hàng đợi cho service đích
25